라우터의 VPN과 포트 포워딩: 어느 쪽이 이길까?

라우터는 VPN을 스스로 종료하지만, 오래된 포워딩 규칙이 같은 UDP 포트를 계속 LAN의 한 머신으로 보내고 있다. 실제 종단점은 둘 중 하나뿐일 수 있고, 커널은 둘 사이를 중재하지 않는다. 목적지 변환은 로컬 서비스에 묻기 전에 패킷을 다시 쓰므로, VPN 프로세스는 이미 다른 곳으로 보내진 트래픽을 기다린다. 과제는 포트가 누구 것인지 정하는 일과, 그다음 규칙을 일치시키는 일이다.

포트 하나, 주인을 주장하는 둘

라우터 안에서 도는 VPN 서버는 자기 소켓으로 이어지는 인바운드 허가가 필요하다. 같은 포트에 대한 목적지 NAT 항목은 전혀 다른 곳으로 이어진다. LAN 주소와 포워딩 결정이다. 둘은 로그도 다르고 실패 방식도 다른 별개의 종단점이다. 흔한 단서는 한 주소 체계만 동작하고 다른 쪽은 동작하지 않는다는 것이다. 남은 항목이 한 체계를 위해 작성된 뒤 다시 검토되지 않았기 때문이다.

편집 전에 주장을 적어 둔다. 주소 체계, 외부 주소, 전송 방식, 포트, 변환된 목적지다.

목적지 변환은 로컬 확인보다 먼저 실행된다

목적지 NAT는 커널이 로컬 전달과 포워딩 중 하나를 고르기 전, 프리라우팅 단계에서 패킷의 목적지를 바꾼다. 목적지가 LAN 호스트가 되면 패킷은 포워딩 경로를 탄다. 라우터 자체 소켓에 대한 입력 규칙은 결코 참조되지 않는다. 그래서 클라이언트가 시간 초과를 겪는 동안 VPN 로그는 비어 있다.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

이 순서가 메커니즘의 전부이며, 장비 화면은 체크박스 뒤에 그것을 숨기되 바꾸지 않는다. 패킷이 어느 경로를 탈지는 여전히 목적지 소유자가 정한다.

LAN 호스트가 의도한 종단점이라면 포워딩이 옳고, 라우터가 같은 포트에서 함께 수신해서는 안 된다.

매핑 하나는 남기고 다른 하나는 지운다

그 포트와 주소 체계의 NAT 항목을 나열하고 살아남을 항목을 고른다.

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

같은 번호의 TCP 항목은 UDP 장애와 무관하며, 둘을 한 객체로 취급하면 잘못된 규칙을 지우게 된다. 로컬 소켓이 이겨야 할 때는 충돌하는 매핑의 소유자가 그 한 항목을 지우거나 다시 쓰고, 라우터 자체 포트의 인바운드 허가는 그대로 남는다. 무관한 포워딩, 관리 경로, 규칙 집합의 사본은 모두 이번 변경에서 살아남아야 한다.

VPN이 별도 호스트에 산다면 포워딩이 올바른 대상이다. 컨테이너나 가상 머신의 서비스는 그 상자를 라우터라고 불러도 공개 포트가 필요할 수 있다. 그러니 케이스의 라벨이 아니라 소켓과 그 네임스페이스를 추적하라.

바깥에서 소유자를 확인한다

각 주소 체계를 따로 시험한다. 라우터에서 종료되는 IPv6 연결은 오래된 규칙이 리디렉션하는 IPv4 연결에 대해 아무 말도 하지 않는다. 어느 종단점이 응답했는지 수신 서비스의 로그로 읽고, 클라이언트의 성공 메시지는 약한 증거로 다룬다. 의미 있는 시험에는 새 흐름이 필요하다. 외부 호스트에서 nc -zvu 203.0.113.7 1194로 프로브를 보내고, 승자의 로그를 journalctl -u openvpn@server -n 20로 읽는다. 라우터의 수신기는 연결 자체를 기록하고, LAN 호스트는 자기 서비스에 기록한다.

연결 추적은 기존 흐름을 원래 매핑에 붙잡아 두므로, 이미 성립한 세션은 방금 고친 규칙보다 오래 살아남을 수 있다.

의도한 종단점이 평소의 신원 확인으로 응답하면, 터널 뒤의 사설 자원을 시험한다. 바깥 수신기에 닿는 것은 첫 단계일 뿐이다. 내부 라우팅과 애플리케이션 권한 부여는 별개의 결과다.