방화벽에서 어떤 VPN 포트를 열어야 할까: 프로토콜별 정리
PPTP는 TCP 1723과 GRE가, L2TP/IPsec은 UDP 500과 4500 및 ESP가 필요하며 SSTP, OpenVPN, WireGuard는 각각 포트 하나가 필요합니다. 무엇을 열어야 하는지 정리했습니다.
VPN 터널이 방화벽을 통과할지는 클라이언트가 접속하는 포트와 페이로드를 나르는 프로토콜이라는 두 가지 별개의 규칙이 결정합니다. 앞의 것만 열면 터널은 인증까지 되지만 그 뒤로 데이터가 흐르지 않습니다. 최소 구성은 PPTP의 경우 TCP 포트 하나와 GRE, L2TP/IPsec과 IKEv2의 경우 UDP 포트 둘과 ESP, SSTP와 OpenVPN과 WireGuard의 경우 각각 포트 하나입니다. 나머지는 방향, 상태 추적, NAT가 결정합니다.
클라이언트가 접속하는 포트부터 시작하세요
모든 방식에는 클라이언트가 가장 먼저 접속하는 진입점이 있고, 허용 규칙은 바로 그 진입점을 지정해야 합니다. PPTP 클라이언트는 TCP 1723에 연결합니다. L2TP/IPsec은 UDP 500에서 IKE를 시작하고 NAT 통과가 쓰이면 UDP 4500으로 옮겨가며, L2TP 프레임 자체는 터널 안의 UDP 1701에 실립니다. SSTP는 세션을 TCP 443의 TLS로 감싸고, IKEv2는 UDP 500과 4500에서 협상하며, OpenVPN은 기본으로 UDP 1194를 쓰지만 자주 TCP 443으로 옮겨지고, WireGuard는 UDP 51820에서 대기합니다.
| Family | Rule to add on the gateway | Typical mistake |
|---|---|---|
| WireGuard | UDP port from ListenPort, for the peer address | Assuming 51820 when the config says otherwise |
| OpenVPN | The configured UDP or TCP port, often 443 | Opening 1194 after the server moved |
| SSTP | TCP 443 limited to the gateway IP | Allowing 443 to any destination |
| IKEv2 | UDP 500 and UDP 4500, plus ESP | Allowing only 500 and losing NAT-T |
| L2TP/IPsec | UDP 500, 4500, ESP, and 1701 inside the tunnel | Exposing 1701 to the internet |
| PPTP | TCP 1723 and IP protocol 47 | Writing a rule for TCP 47 |
이 번호들은 고정된 속성이 아니라 기본값으로 다루세요. WireGuard 인터페이스는 설정이 선언한 대기 포트를 쓰고, OpenVPN 서버는 관리자가 고른 어떤 포트에든 놓일 수 있습니다. 규칙을 쓰기 전에 서버 설정을 읽어야 하는데, 1194용으로 연 방화벽은 443으로 옮긴 서버에 아무 소용이 없습니다.
셋째 열이 바로 대부분의 변경 티켓이 어긋나는 지점입니다. 규칙은 있지만 목적지, 방향, 전송 방식이 틀렸습니다.
GRE와 ESP는 프로토콜 번호이지 포트가 아닙니다
GRE와 ESP에는 포트가 아예 없으므로 포트 번호만 받는 방화벽 입력란에서는 표현할 수 없습니다. GRE는 IP 프로토콜 47, ESP는 IP 프로토콜 50이며 둘 다 IP 헤더의 프로토콜 필드로 대조합니다. TCP 포트 47로 쓴 규칙은 아무것도 일치하지 않으며, 이렇게 PPTP 정책은 맞아 보이지만 핸드셰이크 뒤의 모든 패킷을 버립니다.
가정용 공유기는 이를 통과 체크상자 뒤에 숨기고, 프로토콜 규칙과 GRE의 경우 흐름을 매핑하는 데 필요한 NAT 도우미를 함께 넣습니다. 실제 방화벽에서는 PPTP 서버로 IP 프로토콜 47을, IPsec 게이트웨이로 IP 프로토콜 50을 직접 허용합니다. 플랫폼에 프로토콜 항목이 없으면 캡슐화가 출구이며, IKEv2가 UDP 4500으로 물러날 수 있고 OpenVPN과 WireGuard가 이 문제를 겪지 않는 이유도 같습니다.
클라이언트를 탓하기 전에 규칙이 실제로 무엇과 일치하는지 확인하세요. 게이트웨이에서 영으로 남아 있는 패킷 카운터는 규칙이 한 번도 발동하지 않았다는 뜻이며, 클라이언트 쪽에서 몇 번을 다시 설치해도 달라지지 않습니다.
방향, 상태, NAT가 답을 바꿉니다
밖으로 접속하는 클라이언트와 안으로 대기하는 게이트웨이는 서로 다른 요구 사항이며, 같은 포트 목록이 한 방향에서는 맞고 다른 방향에서는 틀릴 수 있습니다. 상태를 추적하는 방화벽은 500과 4500의 UDP 흐름을 따라가며 두 번째 규칙 없이 응답을 돌려보냅니다. ESP와 GRE는 포트를 나르지 않으므로 NAT 장비가 붙잡을 것이 없고 세션을 따라가려면 도우미나 캡슐화가 필요합니다.
NAT 통과가 바로 놓치기 쉬운 부분입니다. IKEv2는 UDP 500에서 시작해 NAT 장비를 감지하고 UDP 4500에서 계속하므로, 500만 허용하는 정책은 연결된 뒤 조용해지는 터널을 만듭니다. L2TP/IPsec도 같은 동작을 합니다. 캡처에 첫 교환만 보이고 지속적인 트래픽이 없다면 500에서 멈추는 규칙을 찾으세요.
모든 규칙에 방향을 기록하세요. «UDP 4500 허용»은 어디에서 어디로인지 말하기 전에는 아무 의미가 없고, 이동하는 클라이언트에 맞는 규칙은 보통 사이트 간 피어에는 틀립니다.
각 경로를 캡처로 확인하세요
캡처는 도착한 것만 기록하는 클라이언트가 아니라 게이트웨이에서 실행합니다. 다음 필터는 위의 방식들을 포괄하고 어느 단계가 빠졌는지 보여 줍니다:
sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50출력을 순서로 읽으세요. 협상은 보이는데 페이로드 프로토콜이 보이지 않으면 드롭은 클라이언트와 게이트웨이 사이 어딘가에서 일어납니다. 둘 다 보이는데도 페이지가 실패하면 방화벽은 더 이상 용의자가 아니므로, 라우팅, DNS, 클라이언트에 준 주소 풀을 보세요.
tcpdump가 없는 장비에서는 같은 증거를 인터페이스와 규칙 카운터에서 얻습니다. 터널 인터페이스에서 바이트가 들어오기만 하고 나가지 않는다면 최초 허용 규칙이 아니라 돌아오는 경로를 가리킵니다.
설명할 수 있는 규칙 집합을 남기세요
TCP 443의 SSTP는 포트 기반 필터에는 일반 HTTPS와 구별되지 않으며, 네트워크가 웹 트래픽만 허용할 때 그 점이 핵심입니다. 443 규칙이 목적지를 인터넷 전체가 아니라 게이트웨이로 지정해야 하는 이유도 여기에 있습니다. 터널이 동작하면 임시 전체 허용 규칙은 즉시 지우세요. 어떤 규칙이 일치했는지, 프로토콜 번호가 있으면 그 번호, 방향을 적어 두어 다음 사람이 증거에서 시작하게 하세요.
클라우드 지점 대 사이트 게이트웨이는 선택을 눈에 보이게 하며, 내려받은 프로필은 443의 SSTP나 500과 4500의 IKEv2 중 하나를 쓰므로 실제로 고른 쪽만 열어야 합니다. 현대 네트워크에서 PPTP를 위해 GRE 예외를 둘 가치는 없는데, 이동통신사는 방화벽과 무관하게 프로토콜 47을 자주 버리기 때문입니다. 티켓을 닫기 전에 규칙이 서버 설정의 포트와 맞는지, 프로토콜 항목이 필요한 곳에 설정되어 있는지, 목적지가 임의의 주소가 아니라 게이트웨이인지 확인하세요.