헤어핀 NAT: VPN 엔드포인트가 내부에서 실패하는 이유

모바일 네트워크에서는 응답하지만 소파에서는 실패하는 VPN 서버는 보통 인증서 문제가 아닙니다. LAN 안의 클라이언트가 라우터에 요청하는 것은 목적지가 라우터 자신의 공인 주소인 패킷의 변환이며, 이는 패킷이 밖으로 나갔다가 곧바로 다시 들어와야 한다는 뜻입니다. 이런 동작을 헤어핀이라고 하며, 많은 라우터가 이를 아예 구현하지 않거나 체크박스를 켰을 때만 구현합니다. 밖에서 한 시험이 통과된다는 점이 혼란스러운 이유는, 그것이 리스너와 포워딩 규칙이 정상임을 증명하기 때문입니다.

패킷이 밖으로 나갔다가 다시 들어온다

패킷을 따라가 봅시다. 클라이언트는 공인 이름을 해석하고 공인 주소로 접속하며, 라우터의 목적지 NAT가 목적지를 내부 서버로 다시 씁니다. 서버의 응답은 클라이언트의 LAN 주소로 향하므로, 소스를 되돌려 변환했을 NAT 규칙을 한 번도 지나지 않고 라우터의 LAN 인터페이스로 돌아갑니다.

이제 클라이언트는 아무것도 보내지 않은 주소에서 패킷을 받고 그것을 버립니다. 이 비대칭성이 장애의 전부입니다.

RFC 4787은 이런 경우 NAT에 기대되는 동작을 설명하며, 짧게 말하면 이론상 규정된 곳에서도 실제로는 선택 사항입니다. 어떤 라우터는 이 설정을 NAT loopback이라 부르고, 다른 것은 헤어핀 NAT나 NAT reflection이라 부르며, 아무것도 노출하지 않는 것도 있습니다. 이 기능이 없는 라우터는 설정이 틀린 것이 아니라 평범한 일을 하는 것이고, 해결책은 다른 곳에 있습니다. 내부 시험이 실패했다고 해서 공인 포워딩 규칙이 틀렸다고 결론 내리지 마십시오.

점검 1: 두 경로를 따로 시험한다

LAN 밖에서 실제 사용자가 쓸 것과 같은 프로파일로 접속해 세션이 성립하는지 확인합니다. 안에서는 같은 프로파일로 공인 주소에 접속하고 정확한 오류와 시각을 기록합니다.

정확한 내부 시험은 호스트 이름을 유지하고 주소만 바꿉니다: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ 는 올바른 서버 이름을 제시한 채 요청을 공인 주소로 보냅니다. 이는 이름 해석 문제와 변환 문제를 구분해 주며, 같은 이름이 카페에서는 될 때 둘은 쉽게 혼동되므로 클라이언트가 TCP 연결에서 실패하는지 아니면 나중에 TLS에서 실패하는지 기록하십시오. 전자는 변환을, 후자는 신원을 가리킵니다.

점검 2: 서버가 보는 것을 읽는다

가장 유용한 관찰은 서버의 시점입니다. VPN 호스트에서 클라이언트의 LAN 주소와 라우터의 LAN 주소로 필터링한 캡처를 실행한 뒤 내부 시도를 반복합니다. 아무것도 도착하지 않는다면 패킷이 변환을 견디지 못한 것입니다.

연결이 클라이언트의 주소가 아니라 라우터의 LAN 주소에서 도착한다면 헤어핀이 일어나고 소스가 다시 쓰인 것입니다. 그것은 동작하는 구성이지 결함이 아닙니다.

점검 3: 바깥 경로를 건드리지 않고 고친다

지원되는 형태는 세 가지이며 영향 범위가 커지는 순서입니다. 가장 좁은 것은 분할 DNS로, 내부 레코드를 게시해 같은 서버 이름이 LAN의 클라이언트에게는 내부 주소로 해석되게 하면 공인 경로를 완전히 피할 수 있습니다. 다음은 라우터의 문서화된 loopback 또는 reflection 옵션이 있으면 켜고 이 서비스에만 적용하는 것입니다. 가장 넓은 것은 라우터에 source-NAT 규칙을 두어 LAN에서 오는 트래픽을 서버로 다시 써서 응답이 라우터를 거쳐 돌아오게 하는 것으로, Linux 라우터에서는 서버의 주소와 포트에 일치하는 MASQUERADE 규칙을 POSTROUTING 에 두는 것입니다. 셋 모두 바깥 경로를 그대로 두며, 지켜야 할 성질이 바로 그것입니다.

내부 경로를 바깥과 비슷하게 만들기 위해 무관한 포트 포워딩을 넓히지 말고, 문제를 피하려고 서비스를 다른 포트로 옮기지 마십시오. 두 변경 모두 안쪽 세계만 보는 문제를 고치기 위해 바깥 세계가 닿을 수 있는 범위를 바꿉니다.

분할 DNS에는 언급할 만한 함정이 하나 있습니다. 호스트 이름을 임의의 IP로 바꾸면 클라이언트가 검증하는 대상이 바뀌므로, 내부 레코드는 여전히 인증서의 이름과 일치해야 합니다.

점검 4: 그 뒤에 두 경로를 모두 검증한다

LAN 밖에서 바깥 시도를 반복하고, 같은 프로파일로 내부 시도를 반복하며, 서버 로그에 하나의 성공과 하나의 침묵이 아니라 별개의 성공한 세션 두 개가 보이는지 확인합니다. 그다음 다른 클라이언트가 여전히 리스너에 도달하는지, 프라이빗 자원으로 가는 경로가 그대로인지 확인합니다.

기록은 짧게 유지하십시오: 어느 클라이언트가 어느 주소를 썼는지, 서버가 무엇을 보았는지, 세 가지 해결책 중 무엇을 적용했는지입니다. RFC 4787의 헤어핀 요구사항 은 여기서 NAT에 무엇이 기대되는지에 대한 참조이며, 이 기능이 없는 라우터가 왜 정상적으로 동작하는지 설명합니다. 바깥 세계가 재현할 수 없는 내부 실패는 반증되기 전까지 변환의 문제이므로, 그 전제로 시험하십시오.