이중 NAT와 VPN: 클라이언트는 되고 서버는 안 된다

라우터가 또 다른 라우터 뒤에 있고 WAN 주소는 사설인데도 VPN 클라이언트는 연결됩니다. 이중 NAT가 터널을 깨뜨린다고 기대하는 사람에게는 의외지만, 변환이 가장 잘 처리하는 것이 바로 나가는 연결입니다. 같은 두 계층 뒤에서 VPN 서버를 운영하는 경우가 보통 실패하는 상황입니다. 무엇이든 바꾸기 전에 연결 방향을 그려 보세요.

먼저 연결 방향을 그려 보세요

안쪽 라우터의 상태 페이지를 열어 WAN 주소를 적고, 공개 서비스가 알려 주는 주소와 비교하세요. 둘이 다르면 라우터와 인터넷 사이에 변환기가 적어도 하나 있습니다. WAN 주소가 100.64.0.0/10 범위에 들어간다면 바깥 변환기는 아마 통신사 것이고, 당신은 그것을 제어하지 못합니다. 이 두 사실이 이후 단계 중 무엇이 실제로 될 수 있는지를 결정합니다.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

이중 NAT는 이중 VPN이 아닙니다. 변환은 주소와 포트를 다시 쓸 뿐, 두 번째 암호화 터널을 더하지도 않고 아무것도 암호화하지 않습니다. 두 개념을 구분하는 것이 중요한 이유는 해결책이 전혀 다르고, 하나는 설정 페이지가 아니라 통신사와의 대화를 요구하기 때문입니다.

나가는 방향: 클라이언트가 묻고 변환기가 매핑한다

나가는 터널은 당신의 기기에서 나온 패킷으로 시작하므로, 각 변환기는 매핑을 만들고 응답을 다시 들여보낼 수 있습니다. 프로토콜과 포트, 유휴 타이머가 그 매핑이 쓸모 있을 만큼 오래 유지되는지를 결정합니다. 대부분의 가정용 라우터는 별도 설정 없이 이를 처리합니다.

실제로 나타나는 장애는 대개 라우터 수가 아니라 시간 초과와 프로토콜 지원에 관한 것입니다. 몇 분 침묵 뒤에 끊기는 터널은 만료되는 매핑이며, keepalive가 표준적인 답입니다. IPsec에는 표준 NAT-traversal 확장이 있으므로 변환을 넘지 못한다는 주장은 그냥 틀렸습니다. 터널이 아예 맺어지지 않는다면 토폴로지를 탓하기 전에 엔드포인트와 자격 증명을 보세요.

wg show
ping -c3 10.8.0.1

나가는 터널이 한 네트워크에서는 되고 다른 네트워크에서는 안 되면 멈추세요. 그 비교는 네트워크에 관한 것이지 라우터 수에 관한 것이 아닙니다.

들어오는 방향: 포워딩은 당신이 소유한 장비만 덮는다

서버 운영은 반대 방향입니다. 인터넷에서 새 연결이 들어와 모든 계층을 지나 당신의 기기에 닿아야 합니다. 안쪽 라우터의 포트 포워딩 규칙은 바깥 변환기가 그 트래픽을 당신에게 전달할 때만 도움이 됩니다. 지역 규칙을 반복한다고 통신사 장비를 제어할 수 있게 되지는 않습니다.

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

안쪽 라우터의 WAN 주소를 관찰한 공개 주소와 비교하고, 각 값이 어디서 왔는지 적어 두세요. WAN 주소가 사설이거나 공유 범위에 있다면 바깥 계층이 당신이 설정할 수 없는 변환을 하고 있는 것입니다. 효력이 생길 수 없는 규칙에 저녁을 다 쓰기 전에 통신사에 어떤 인바운드 도달성을 지원하는지 물어보세요. 라우터를 없애거나 방화벽을 널리 끄는 것은 진단이 아니며, 포트 하나를 열기 위한 나쁜 거래입니다.

바깥 계층이 통신사 것이고 전달하지 않는다면 멈추세요. 그때 지원되는 답은 다른 접속 방식이나 릴레이이지, 당신 쪽의 규칙 하나가 더 아닙니다.

한 번에 변수 하나만 시험하세요

시험마다 한 가지만 바꾸고 결과를 기록하세요. 이중 NAT 경로는 단일 라우터 경로보다 변수가 많기 때문입니다. 프로필과 기기를 고정한 뒤 다른 접속 네트워크와 비교하세요. 협상이 실패하는지, 유휴 후 세션이 끊기는지, 아니면 사설 목적지만 실패하는지 적어 두세요. 그 세 가지 관찰은 서로 다른 세 계층을 가리킵니다.

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

겹치는 사설 서브넷은 별개의 함정이며, 아무리 변환해도 고쳐지지 않습니다. 집 네트워크와 원격 네트워크가 같은 범위를 쓰면, 사이에 변환기가 몇 대 있든 경로 충돌이 나타납니다. 한쪽 번호를 다시 매기는 것만이 유일하게 오래가는 답입니다.

원격 게이트웨이도 같은 주의를 받을 만합니다. 그 포워딩 규칙과 반환 경로가 빠진 조각일 수 있기 때문입니다. 인증이 되는 터널도 쓸 만한 애플리케이션 경로가 없을 수 있고, 그 장애는 클라이언트 쪽에서 똑같이 보입니다. 어느 방향이 실패하고 어느 계층이 책임지는지 말할 수 있을 때 이 안내는 끝납니다.