목차/15. 연결 문제 해결·CLI

15연결 문제 해결·CLI연결 문제 해결·CLI

원격 접속 VPN은 클라이언트가 어디에 있든 게이트웨이까지 안전한 터널을 뚫어야 하는데, 원격 클라이언트는 본질적으로 "떠돌아다닌다" 는 점이 문제를 까다롭게 만듭니다. 아침에는 협력사 네트워크 안에, 저녁에는 호텔 LAN이나 어떤 방화벽·NAT 장치 뒤에 있을 수 있습니다. 이 장은 이런 환경에서 생기는 연결 문제의 원인과 Check Point가 그것을 푸는 방법 을 빠짐없이 풀어 두고, 마지막으로 명령줄 참조가 어디 있는지 안내합니다.

연결 문제 해결

원격 클라이언트가 게이트웨이까지 닿는 과정에서 흔히 부딪히는 문제는 크게 두 갈래입니다.

단편화(fragmentation)를 지원하지 않는 NAT 장치 와 관련된 문제
중간 단속 장치에서의 서비스/포트 필터링 문제

Check Point는 이 둘을 각각 다른 기능들로 풉니다. NAT 관련 문제는 IKE over TCP, 작은 IKE phase II 프로포절(Small IKE phase II proposals), UDP 캡슐화(UDP encapsulation), IPsec 경로 최대 전송 단위(IPsec PMTU) 라는 네 가지 기능으로 풀고, 포트 필터링 문제는 Visitor Mode(정식 명칭은 TCP Tunneling)== 로 풉니다.

그 밖의 문제도 있습니다. 예를 들어 원격 클라이언트가 내부 네트워크의 IP와 똑같은 IP를 받아 라우팅 충돌 이 생기면 Office Mode로 풀고, 게이트웨이가 보호하는 내부 DNS 서버를 통한 이름 해석 문제는 Split DNS로 풉니다.

NAT 관련 문제 넘어서기

NAT 문제는 패킷 단편화를 지원하지 않는 hide NAT 장치 에서 생깁니다.

원격 접속 클라이언트가 게이트웨이와 VPN 터널을 만들려고 할 때, IKE나 IPsec 패킷이 최대 전송 단위(MTU)보다 커질 수 있습니다. 패킷이 MTU보다 크면 운영체제 TCP/IP 스택의 데이터 링크 계층에서 단편화 됩니다. 문제는 클라이언트가 단편화를 지원하지 않는 hide NAT 장치 뒤에 있을 때 터집니다.

Hide NAT는 IP 헤더뿐 아니라 UDP 헤더에 든 포트 정보까지 바꿉니다. 예를 들어 UDP 패킷이 너무 길면 원격 클라이언트가 패킷을 단편으로 쪼갭니다. 첫 번째 단편 은 IP 헤더 + UDP 헤더 + 데이터 일부로 이루어지고, 두 번째 단편 은 IP 헤더와 나머지 데이터 조각만 들어 있습니다. NAT 장치는 모든 단편을 기다렸다가 재조립해 NAT하는 법을 모릅니다.

그래서 어떤 일이 벌어지냐면 — 첫 번째 단편이 도착하면 NAT 장치가 IP 헤더의 주소 정보와 UDP 헤더의 포트 정보를 무사히 변환해 전달합니다. 그런데 두 번째 단편이 도착하면 거기엔 UDP 헤더가 없어 포트 정보를 변환하지 못하고 패킷을 버립니다. 결국 IKE 협상이 실패합니다.

IKE phase I 동안 — IKE Over TCP

큰 UDP 패킷이 왜 생기는지는 IKE 첫 단계를 들여다봐야 합니다. IKE phase I 에서 클라이언트와 게이트웨이는 서로를 인증하는데, 그 한 방법이 인증서 입니다. 인증서나 인증서 폐기 목록(CRL)이 길면 큰 UDP 패킷 이 생기고, 이것이 클라이언트 운영체제에서 단편화됩니다.

IKE over TCP 는 phase I에서 생기는 큰 UDP 패킷 문제를 풉니다. IKE 협상을 TCP 패킷으로 수행 하는 것입니다. TCP 패킷은 단편화되지 않습니다 — TCP 패킷의 IP 헤더에는 DF 플래그("do not fragment", 단편화 금지)가 켜져 있기 때문입니다. phase I 동안 IKE 협상을 위해 피어 사이에 완전한 TCP 세션 이 열립니다.

IKE phase II 동안 — 작은 프로포절

원격 접속 클라이언트는 암호화·무결성 방식에 대한 정책을 미리 갖고 있지 않습니다. 그래서 클라이언트는 일련의 프로포절(proposal)을 통해 암호화·무결성 방식을 협상 하는데, 게이트웨이와 가능한 모든 조합을 협상 하다 보면 다시 큰 UDP 패킷이 생기고, 클라이언트 OS가 보내기 전에 단편화하며, 앞에 있는 NAT 장치가 UDP 헤더(포트 정보) 없는 패킷을 버려 또 IKE 협상이 실패 합니다.

"그러면 phase I처럼 IKE over TCP를 또 쓰면 되지 않나?"라는 의문이 생깁니다. IKE over TCP는 긴 패킷의 단편화 문제는 풀지만, phase II에서는 게이트웨이가 클라이언트로 먼저 연결을 걸어야 할 때 가 있습니다. (phase I은 클라이언트만 시작하지만, 키 갱신(phase II renewal)은 어느 쪽이든 필요를 감지 할 수 있고, 게이트웨이가 감지하면 게이트웨이가 연결을 겁니다.)

이때 게이트웨이는 NAT 장치의 IP는 알지만, 그 뒤의 클라이언트로 변환되는 포트 번호를 알 수 없 습니다(이전 연결에 쓰인 포트 번호는 임시라 금세 바뀝니다). 그래서 NAT 장치가 연결을 클라이언트로 올바로 전달하지 못해, 게이트웨이가 시작한 연결이 실패 합니다.

IKE over TCP를 쓸 수는 있지만, 그러려면 TCP 연결을 늘 열어 두어야 하고, 열린 세션이 게이트웨이의 소켓을 잡아 귀중한 시스템 자원을 차지 합니다. 더 합리적인 해법은 NAT 장치로 UDP "keep alive" 패킷을 보내 포트를 계속 열어 두고, phase II는 평소 방식대로 수행하는 것입니다. 다만 단편화를 막으려면 UDP 패킷을 짧게 줄여야 합니다.

작은 IKE Phase II 프로포절 이 그 방법입니다. 게이트웨이와 원격 피어가 암호화·무결성 방식을 적은 수만 제안하며 협상을 시작합니다. 흔히 쓰는 방식들이 이 작은 프로포절에 포함됩니다.

작은 프로포절에서 매칭이 되면 그 방식을 쓰고, 단편화는 더 이상 문제가 안 됩니다.
매칭이 안 되면 더 많은 프로포절을 제안하는데, 이때 다시 큰 UDP 패킷이 생겨 클라이언트에서 단편화되고 hide NAT 장치가 버립니다.
매칭 실패는 원격 게이트웨이가 AES-128을 쓰는데 AES-128이 작은 프로포절에 없을 때 가장 흔합니다. 이 경우 AES-128을 선호 방식(preferred method)으로 지정 하면 작은 프로포절에 포함시킬 수 있습니다.

IPsec 동안 — NAT Traversal과 IPsec PMTU

IKE phase I·II를 성공적으로 마치면 IPsec 단계 로 넘어갑니다. 예를 들어 AES·SHA로 암호화한 데이터 페이로드가 IPsec 패킷 안에 담기는데, 이 IPsec 패킷에는 더 이상 TCP·UDP 헤더가 없 습니다. hide NAT 장치는 헤더 안의 포트 정보를 변환해야 하지만, TCP/UDP 헤더가 데이터와 함께 암호화되어 NAT 장치가 읽을 수 없 습니다.

그래서 포트 번호를 추가해 주어야 합니다. UDP 캡슐화(UDP Encapsulation) 는 읽을 수 있는 포트 정보가 든 특별한 UDP 헤더를 IPsec 패킷에 덧붙이는 과정입니다. 이것이 방화벽·프록시를 위한 NAT Traversal입니다.

IPsec Path MTU(경로 MTU) 는 IPsec 패킷 단편화를 다루는 방법입니다. 데이터 링크 계층은 물리 네트워크로 보낼 수 있는 패킷 크기에 상한(MTU) 을 둡니다. OS의 TCP/IP 스택은 패킷을 보내기 전에 로컬 인터페이스에 MTU를 물어보고, IP 계층이 MTU와 패킷 크기를 비교해 필요하면 단편화 합니다.

원격 클라이언트가 여러 라우터를 거쳐 게이트웨이와 통신할 때는 그 경로상 모든 라우터 중 가장 작은 MTU 가 중요한데, 이것을 경로 MTU(PMTU) 라 합니다. 원격 접속 클라이언트에는 IPsec 패킷이 너무 클 때 클라이언트 OS가 단편화하지 못하도록 막는 특별한 IPsec PMTU 발견 메커니즘 이 있습니다.

그런데 인터넷 라우팅은 동적이라 PMTU가 일정하지 않 습니다. 게이트웨이→클라이언트 경로와 그 반대 경로가 다를 수 있어, 방향마다 PMTU가 따로 일 수 있습니다. VPN은 이를 두 가지로 처리합니다.

방식	동작
Active IPsec PMTU	IKE phase II 이후·IPsec 단계 이전에, 클라이언트가 크기가 다양한 발견용(discovery) IPsec 패킷 을 게이트웨이로 보냅니다. 패킷에는 DF 비트가 설정 됩니다. 어떤 라우터의 MTU보다 긴 패킷이면 그 라우터가 패킷을 버리고 ICMP 오류 메시지를 보냅니다. 클라이언트는 단편화되지 않은 가장 큰 패킷 으로부터 적절한 PMTU를 알아냅니다. 이 PMTU는 OS에 직접 전달되지 않고, TCP 3-way 핸드셰이크 때 SYN·SYN-ACK 패킷의 MSS(최대 세그먼트 크기)를 PMTU에 맞게 바꾸는 방식으로 반영됩니다.
Passive IPsec PMTU	동적 인터넷 라우팅 문제 를 풉니다. 어느 한쪽이 라우팅 경로 변경으로 인한 ICMP 오류 메시지를 받을 때 일어나는 과정입니다. 경로가 동적으로 바뀌어 다른 라우터가 DF 비트 설정된 패킷을 단편화해야 하면, 그 라우터는 패킷을 버리고 ="cannot fragment" ICMP 오류 메시지 를 보냅니다. 패킷을 보낸 VPN 피어가 이 메시지를 받으면 PMTU를 낮춰 재전송== 합니다.

방식

동작

Active IPsec PMTU

IKE phase II 이후·IPsec 단계 이전에, 클라이언트가 크기가 다양한 발견용(discovery) IPsec 패킷 을 게이트웨이로 보냅니다. 패킷에는 DF 비트가 설정 됩니다. 어떤 라우터의 MTU보다 긴 패킷이면 그 라우터가 패킷을 버리고 ICMP 오류 메시지를 보냅니다. 클라이언트는 단편화되지 않은 가장 큰 패킷 으로부터 적절한 PMTU를 알아냅니다. 이 PMTU는 OS에 직접 전달되지 않고, TCP 3-way 핸드셰이크 때 SYN·SYN-ACK 패킷의 MSS(최대 세그먼트 크기)를 PMTU에 맞게 바꾸는 방식으로 반영됩니다.

Passive IPsec PMTU

동적 인터넷 라우팅 문제 를 풉니다. 어느 한쪽이 라우팅 경로 변경으로 인한 ICMP 오류 메시지를 받을 때 일어나는 과정입니다. 경로가 동적으로 바뀌어 다른 라우터가 DF 비트 설정된 패킷을 단편화해야 하면, 그 라우터는 패킷을 버리고 ="cannot fragment" ICMP 오류 메시지 를 보냅니다. 패킷을 보낸 VPN 피어가 이 메시지를 받으면 PMTU를 낮춰 재전송== 합니다.

NAT와 게이트웨이→클라이언트 역방향 연결

원격 클라이언트가 NAT 장치 뒤에서 게이트웨이(또는 클러스터)에 연결하는 상황입니다.

보통 게이트웨이 뒤의 호스트와 통신하려면 원격 접속 클라이언트가 먼저 게이트웨이로 연결을 시작 해야 합니다. 하지만 일단 클라이언트가 연결을 열고 나면, 게이트웨이 뒤의 호스트가 클라이언트로 역방향(back) 연결 을 열 수 있습니다. 역방향 연결이 성공하려면 클라이언트의 정보가 클라이언트와 게이트웨이 사이의 모든 장치와 게이트웨이 자신에 유지 되어야 합니다.

게이트웨이에서 역방향 연결을 켜는 절차입니다.

SmartConsole에서 Menu > Global properties 를 클릭합니다.
Remote Access 페이지를 선택합니다.
Remote Access > Additional Properties 섹션에서 Enable Back Connections (from gateway to client) 를 선택합니다.
OK 를 클릭합니다.
VPN 게이트웨이에 Access Control Policy 를 설치합니다.

제한된 인터넷 접속 넘어서기 — Visitor Mode

호텔이나 고객사 같은 원격지에서 접속할 때는 인터넷 연결이 표준 HTTP/HTTPS 포트(보통 HTTP 80, HTTPS 443)로만 허용 되는 경우가 많습니다. 그런데 원격 클라이언트는 포트 500에서 IKE 협상 을 하거나 IPsec 패킷(예상되는 TCP가 아닌 다른 프로토콜) 을 보내야 하므로, 평소 방식으로는 터널을 만들 수 없습니다. 이 문제를 Visitor Mode(정식 명칭 TCP Tunneling)로 풉니다.

Visitor Mode는 클라이언트↔게이트웨이의 모든 통신을 포트 443의 일반 TCP 연결 하나에 터널링 합니다.

필요한 모든 VPN 연결이 이 하나의 TCP 연결 안에 터널링 됩니다. 따라서 피어 게이트웨이는 포트 443에서 Visitor Mode(TCP) 서버를 돌려야 합니다.

사용자 수

Visitor Mode 서버의 성능을 최적으로 끌어내려면,

성능이 떨어지면 Visitor Mode를 허용하는 사용자 수를 줄 입니다.
OS에서 사용 가능한 소켓 수를 늘 립니다. 예를 들어 Linux의 소켓 디스크립터 값을 편집합니다.

사용자 정의 포트 할당

조직이 표준 포트 443 대신 사용자 정의 포트를 쓰고 싶을 수 있습니다. 이 경우 모든 원격지와 본사 조직이 서로 합의한 다른 포트 를 Visitor Mode에 쓸 수 있습니다. 협력사 환경에서 잘 맞는데, 협력사가 Visitor Mode 연결용 포트 하나만 열어 주면 됩니다.

고른 포트가 SmartDashboard의 사전 정의 서비스에 없으면 , 그 포트를 쓰려면 서비스를 새로 만들어야 합니다.
합의한 포트 앞에 프록시가 있으면 , 그 포트로 향하는 트래픽을 허용하도록 프록시를 구성 합니다.

Visitor Mode 포트를 바꾸면, 원격 접속 VPN 클라이언트에서 게이트웨이 사이트 이름을 다음 형식 으로 지정해야 합니다.

[Security Gateway의 IP 주소 또는 호스트 이름]:PORT

클라이언트에서 사이트를 만드는 법은 Remote Access VPN Clients for Windows Administration Guide 의 "Getting Started with Remote Access Clients" 장 > "Helping Users Create a Site" 절, 그리고 Endpoint Security VPN for macOS Administration Guide 의 "Helping Your Users" 장 > "Helping Users Create a Site" 절을 참고하세요.

Visitor Mode와 프록시 서버

원격지가 프록시 서버를 돌리는 경우 에도 Visitor Mode를 쓸 수 있습니다. 원격 사용자가 Visitor Mode 연결이 프록시 서버를 통과하도록 설정하면 됩니다.

포트 443을 HTTPS 서버가 이미 쓰고 있을 때

지정한 포트를 이미 다른 서버가 쓰고 있으면(예: 조직 게이트웨이의 서버가 HTTPS용으로 예약), 다음 로그가 Security Management Server로 전송됩니다.

Visitor Mode Server failed to bind to xxx.xxx.xxx.xxx:yy
(either port was already taken or the IP address does not exist)

피어 게이트웨이가 표준 HTTPS 포트 443에서도 수신하는 일반 HTTP 서버를 이미 돌리고 있다면, 공인 IP를 가진 외부 인터페이스 두 개 로 구성해야 합니다 — 하나는 HTTP 서버용, 하나는 Visitor Mode 서버용입니다. 이 두 번째 라우팅 가능한 주소는 두 가지로 얻습니다.

Visitor Mode 서버용 네트워크 인터페이스를 추가로 설치 하거나,
포트를 막고 있는 같은 인터페이스에 가상 IP(virtual IP)를 활용 합니다.

Visitor Mode 서버를 돌리는 게이트웨이 객체에서 General Properties > Remote Access 페이지에 Allocated IP address 설정이 있습니다. 사용 가능한 모든 IP 주소를 포트 443에서 Visitor Mode 연결을 수신하도록 구성할 수 있습니다.

MEP 환경에서의 Visitor Mode와 인터페이스 결정

Visitor Mode는 MEP(Multiple Entry Point) 환경 에서도 동작합니다. 자세한 내용은 Multiple Entry Point의 "Visitor Mode and MEP"를 참고하세요.

Visitor Mode 환경에서 인터페이스 결정(Interface Resolution) 은 정적 IP 결정을 쓰거나 Visitor Mode 전용 인터페이스 하나를 두는 것을 권장합니다.

원격 접속 연결성 구성

이 절은 SmartDashboard와 DBedit에서 원격 접속 연결성을 구성하는 법을 다룹니다.

작은 IKE phase II 프로포절 구성

작은 phase II IKE 프로포절은 항상 AES-256을 포함하지만 AES-128은 포함하지 않 습니다. 작은 프로포절에 AES-128을 넣고 싶다면,

명령줄 데이터베이스 편집 도구 DBedit 를 엽니다. 작은 프로포절 사용 여부를 제어하는 속성이 두 개 있습니다 — 하나는 pre-NG with Application Intelligence용, 하나는 NG with Application Intelligence용입니다.

속성	의미	기본값
`phase2_proposal`	구버전 클라이언트(pre-NG with Application Intelligence) 가 작은 프로포절을 시도할지 결정	`false`
`phase2_proposal_size`	신버전 클라이언트(NG with Application Intelligence) 가 작은 프로포절을 시도할지 결정	`true`

Global Properties > Remote Access 페이지 > VPN - Advanced 하위 페이지 > User Encryption Properties 섹션에서 AES-128 을 선택합니다. 이러면 원격 사용자가 AES-128을 작은 프로포절로 제안 하도록 구성됩니다.

Visitor Mode 구성

Visitor Mode는 서버와 클라이언트 양쪽 모두를 구성 해야 합니다. "Visitor Mode and MEP"도 함께 참고하세요.

Visitor Mode와 클러스터 — 클러스터 지원은 제한적입니다. High Availability·Load Sharing 솔루션이 stickiness(고정성) 를 제공해야 합니다. 즉 Visitor Mode 연결은 항상 같은 클러스터 멤버를 거쳐야 합니다. High Availability에서 멤버 간 페일오버(failover)는 지원되지 않 습니다.

원격 클라이언트를 프록시 서버와 함께 동작시키기

원격 접속 클라이언트에서 Detect Proxy from Internet Explorer Settings 를 선택합니다.
프록시 인증용 사용자 이름·암호 를 입력합니다. 이 정보는 나중에 connect 명령과 함께 프록시 서버로 전달됩니다.

원격 접속 클라이언트는 Visitor Mode 설정을 읽을 수 있는데, 다음 두 조건이 모두 맞을 때만 가능합니다.

클라이언트가 LAN 또는 WLAN에 연결 되어 있고,
Secure Domain Logon(SDL)이 켜져 있지 않을 때.

Windows 프록시 대체(Proxy Replacement)

원격 접속 클라이언트가 LAN/WLAN에 있고 그 LAN에 프록시 서버가 구성 되어 있으면, 클라이언트가 프록시 설정을 대체 해 새 연결이 프록시를 거쳐 VPN 도메인으로 가지 않고, LAN/WLAN의 게이트웨이로 곧장 가도록 합니다. 이 기능은 Visitor Mode가 있든 없든 동작 합니다.

원격 접속 클라이언트가 프록시 파일을 대체할 때는, 전체 VPN 도메인 IP 범위와 DNS 이름을 담은 비슷한 일반 스크립트 PAC 파일 을 생성합니다(이들은 "DIRECT"로 반환). Windows OS가 이 정보를 일반 스크립트 PAC 파일 형태로 받아야 하므로 이 파일은 로컬에 저장되며, Internet Explorer에 정의된 자동 구성 스크립트를 대체 합니다.

구성 방법 — Windows 프록시 대체는 게이트웨이 또는 클라이언트 에서 구성합니다. 게이트웨이에서 구성하려면,

Menu 에서 Global Properties 를 클릭합니다.
탐색 트리에서 Advanced 를 클릭합니다.
Advanced Configuration 페이지에서 Configure 를 클릭합니다 — Advanced Configuration 창이 열립니다.
탐색 트리에서 VPN Advanced Properties > Remote Access VPN 을 클릭합니다.
다음 중 하나를 선택합니다.

옵션	동작
`ie_proxy_replacement`	선택하면 Visitor Mode가 꺼져 있어도 Windows 프록시 대체를 항상 수행
`ie_proxy_replacement_limit_to_tcpt`	선택하면 Visitor Mode가 켜졌을 때만 프록시 대체 수행

CLI

원격 접속 VPN의 명령줄 운영 명령은 R82 CLI Reference Guide 에 정리되어 있습니다. Site-to-Site VPN과 마찬가지로 vpn 명령 으로 터널 상태·SA를 점검·진단하며, 클러스터에서는 모든 멤버를 똑같이 설정 하고, Scalable Platforms에서는 Expert 모드에서 해당 Security Group 위에서 실행합니다.

정리하면, 연결이 안 될 때는 NAT(Office/Visitor Mode·NAT-T·IKE over TCP·작은 프로포절·IPsec PMTU)·인증·암호화·SCV·방화벽 차단을 순서대로 점검 하고, 깊은 진단은 vpn 명령과 클라이언트 로그(SmartConsole의 Logs & Events에서 encrypt/decrypt 실패 확인)를 활용합니다. 전체 명령 구문은 R82 CLI Reference Guide가 담당합니다.