가정용 VPN 서버를 위한 포트 트리거링과 포트 포워딩
트리거링은 아웃바운드 트래픽이 있은 뒤에 매핑을 엽니다. 포워딩은 포트를 영구적으로 매핑합니다. 가정용 VPN 서버에는 후자가 필요하며, 실제 리스너에 한정해야 합니다.
포트 포워딩과 포트 트리거링은 대부분의 가정용 공유기에서 같은 메뉴에 있다. 그래서 둘을 한 가지 일을 하는 두 가지 방법으로 취급한다. 포워딩은 정적 규칙이다: WAN 포트로 들어오는 연결은 다른 일이 일어나든 아니든 고정된 내부 주소와 포트로 변환된다. 트리거링은 조건부다: 공유기는 아웃바운드 트래픽을 지켜보다가 일치하는 연결이 나간 뒤에야 인바운드 매핑을 연다. VPN 서버는 다른 누군가가 먼저 접속해 주기를 기다린다. 따라서 그 조건이야말로 절대 만족할 수 없는 유일한 것이다.
수명 주기가 다른 두 규칙
IPv4 NAT는 상태를 유지한다. 내부 호스트가 패킷을 밖으로 보내면 공유기는 응답이 돌아올 길을 찾도록 매핑을 만든다. 어떤 매핑과도 일치하지 않는 인바운드 패킷은 버려지며, 이 동작이 패치되지 않은 데스크톱을 인터넷에서 떼어 놓는다. 포워딩은 손으로 추가하는 영구 변환 항목이다. 트리거링은 트래픽 패턴이 지키는 임시 구멍이다.
실질적인 차이는 시간이다. 포워딩은 저장되는 순간부터 누군가 지울 때까지 존재한다. 트리거된 매핑은 트리거가 발동한 뒤 존재하고 유휴 타이머로 닫히는데, 소비자용 하드웨어에서는 분 단위로 측정되며 재부팅하면 즉시 닫힌다.
추상적으로 어느 쪽이 더 안전한 것은 아니다. 포워딩은 한 포트를 계속 노출하고, 트리거는 특정 아웃바운드 트래픽 이후에만 노출한다. 낯선 상대가 보내는 첫 패킷을 받아들여야 하는 서비스에는 둘 중 하나만 맞는다.
트리거링이 서버를 공개하지 못하는 이유
VPN 서버는 설계상 수동적이다. 카페의 노트북이든 모바일 데이터를 쓰는 휴대폰이든 상대가 첫 패킷을 보내는데, 공유기에는 그 패킷에 대한 매핑이 없다. 내부에서 트리거 포트로 트래픽을 시작한 것이 없으므로 규칙은 결코 발동하지 않고, 핸드셰이크가 시작되기 전에 연결이 끊긴다.
트리거링이 동작하는 것처럼 보이는 곳에서는 다른 무언가가 트리거 포트에 트래픽을 만든다. LAN의 클라이언트, 모니터링 프로브, 또는 서버 자체의 아웃바운드 점검이다. 그러면 매핑은 그 한 호스트에만 열리고 트래픽이 멈추면 닫히므로, 다음 외부 상대는 다시 실패하고 첫 성공만 로그에 증거처럼 남는다.
트리거링은 보통 단일 호스트용이기도 하다. 많은 구현이 한 번에 하나의 내부 장치만 매핑을 유지하게 하는데, 여러 상대에 응답해야 하는 서버에는 정확히 틀린 방식이다. 이 기능은 아웃바운드 제어 연결을 열고 두 번째 포트에서 인바운드 데이터를 기대하는 애플리케이션을 위해 만들어졌고, 지금도 그 형태에 맞는다.
포워딩이 실제로 매핑하는 것
포워딩은 하나의 변환 항목이다. WAN 포트와 프로토콜을 내부 주소와 포트로 잇는다. 반대편에서 이미 실행 중인 리스너가 필요하고, 내부 주소가 제자리에 있어야 한다. 다른 기계로 옮겨 간 DHCP 임대는 모든 터널을 조용히 엉뚱한 호스트로 보내므로, 규칙보다 먼저 예약을 만들어야 한다.
| Rule | Opens when | Closes when | Fits a VPN listener |
|---|---|---|---|
| Port forward | Saved, at boot | You delete it | Yes |
| Port trigger | Matching outbound traffic | Idle timeout or reboot | No |
프로토콜은 폼이 암시하는 것보다 중요하다. UDP 위의 OpenVPN에는 UDP 포워딩이 필요하고, WireGuard에는 UDP가 필요하며, IPsec 데이터는 ESP, IP 프로토콜 50으로 도착한다. 포트가 아예 없다. TCP나 UDP만 받는 포워딩 폼으로는 그것을 표현할 수 없으므로, IPsec에는 포트 규칙 대신 패스스루나 정적 일대일 매핑이 필요하다.
공유기 위의 계층
포워딩은 자신이 소유한 변환만 제어한다. WAN 주소가 내 것이 아닌 경우, 가입자가 100.64.0.0/10을 공유하는 통신사 NAT 뒤가 그런데, RFC 6598에 설명된 대로라면 제공자가 먼저 변환했기 때문에 인바운드 연결은 내 공유기에 닿지 않는다. 내 장치의 어떤 규칙으로도 그 순서를 고칠 수 없다.
이중 NAT는 같은 문제의 축소판이다. 내 공유기는 ISP 공유기로 포워딩하는데, 그쪽에는 일치하는 규칙이 없어 패킷을 버린다. 바깥 장치에 규칙을 추가하거나, 바깥 장치를 브리지 모드로 두고 내 장치가 공인 주소를 갖게 해야 한다.
그래서 시험은 바깥에서 와야 한다. 같은 LAN에서 공인 주소를 거쳐 하는 시험은 헤어핀 NAT 지원에 좌우되고 규칙과 무관한 이유로 통과하거나 실패할 수 있다. 모바일 데이터를 쓰는 휴대폰이나 다른 네트워크의 친구가 더 깔끔한 확인이다.
규칙을 좁히고, 그다음 두 절반을 검증하라
한 포트를 한 주소로 포워딩하라. 첫 시도가 실패해서 추가한 범위가 바로 관리 인터페이스를 인터넷에 노출시키는 길이며, VPN 리스너 옆에 공유기 관리 페이지를 공개할 필요는 없다.
그 리스너를 이미 보호하던 것은 모두 유지하라. 인증서나 키 신원, 호스트 방화벽, 최신 패키지 버전이다. 포워딩은 패킷을 들여보낼 뿐이고, 인증이 그 패킷이 터널이 될지 결정한다. 무언가 잘못될 때 이 둘은 별개의 실패다.
검증에는 두 절반이 있다. 핸드셰이크가 외부 네트워크에서 완료되어야 하고, 그다음 서버 뒤의 사설 자원이 터널을 통해 응답해야 한다. 포워딩은 터널 연결을 들여보낼 뿐 그 이상은 아니다. 10.8.0.0/24에 대한 라우팅과 권한 부여는 다른 화면의 다른 설정이다.
세 가지 질문으로 결정하라
세 가지 질문이 어떤 비교표보다 빠르게 선택을 정리한다.
- 바깥에서 무언가가 첫 패킷으로 접속하는가? 그렇다면 포워딩이나 릴레이를 쓰라. 결코 존재하지 않을 아웃바운드 트래픽 없이는 트리거링이 열릴 수 없다.
- 구멍이 유휴 시간보다 오래 살아야 하는가? 그렇다면 포워딩을 쓰라. 트리거된 매핑은 자기 일정에 따라 닫힌다.
- WAN 주소가 공개해도 되는 내 것인가? 아니라면 어떤 규칙을 고치기 전에 위 계층을 먼저 바로잡으라.
세 가지 모두 아니오라면, 상용 제공자에게 스스로 접속하는 노트북이 그런 경우인데, 두 규칙 모두 필요 없다. NAT 뒤의 클라이언트는 상태 유지 매핑을 스스로 만들기 때문에 동작하며, 자정에 포트 포워딩 문서를 읽는 사람 대부분이 여기에 해당한다.