NAT를 거치는 L2TP/IPsec: 실제로 무엇이 깨지고 왜인가

NAT가 L2TP/IPsec를 깨뜨린다는 주장은 절반만 맞고 그래서 쓸모없다. 주소 변환은 정상이고, NAT 트래버설은 바로 그것을 견디기 위해 존재하며, 매일 수백만 클라이언트가 공유기 뒤에서 접속한다. 깨지는 것은 특정 교환의 특정 단계다: IKE가 응답을 받지 못하거나, 캡슐화된 터널이 하나의 프로토콜만 허용하는 정책에 의해 버려지거나, 터널이 유휴 상태인 동안 변환 매핑이 만료된다. 어느 단계에 있는지 알면 해결은 보통 규칙 하나나 keepalive이지 새로운 VPN 설계가 아니다.

신화는 잘못된 질문이다

유용한 질문은 'NAT가 이것을 깨는가'가 아니라 '교환의 어느 부분이 변환되고, 변환하는 장치가 그것을 어떻게 다루는가'다. L2TP/IPsec는 계층 프로토콜로, IKE가 협상하고 ESP가 보호하며, L2TP가 그 보호 안에서 PPP를 나른다. 주소 변환은 계층마다 다르게 작용하고, 오류 대화상자 대신 협상 단계를 보면 실패의 signature를 구분할 수 있다.

웹 브라우징이 되는 공유기는 출발 포트 변환이 있는 TCP가 동작함을 증명할 뿐이다. UDP 500, UDP 4500, 프로토콜 50에 대해서는 아무 말도 하지 않으며, 이 배포는 바로 그 세 가지에 의존한다.

단계 1: IKE가 우선 응답을 받아야 한다

첫 교환은 UDP 500으로 응답자에게 간다. 응답이 돌아오지 않으면 사전 공유 키도 제안도 자격 증명도 읽히지 않은 채로 다른 무엇도 의미가 없다. 클라이언트의 타임아웃에서 추론하지 말고 요청과 응답을 보라:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

응답 없는 요청은 보통 방화벽이나 상류 통신사가 패킷을 버린다는 뜻이지 서버가 거부했다는 뜻이 아니다. 제안이나 인증서 문제를 지목하는 notify 페이로드가 있는 응답은 패킷이 도착했고 협상이 내용 때문에 실패했다는 뜻이며, 이는 전혀 다른 수리다.

양쪽이 변환 뒤에 있으면 개시자는 응답자에 도달하기만 하면 되므로 대부분의 클라이언트 측 배포는 단계 1부터 동작한다. 서버 측 호스팅이 인바운드 문제가 시작되는 지점이며, 그래서 두 상황을 하나로 논해서는 안 된다.

단계 2: 캡슐화가 방화벽이 보는 것을 바꾼다

ESP는 IP 프로토콜이지 TCP나 UDP 포트가 아니며, 일반적인 포트 주소 변환에는 다시 쓸 포트 필드가 없다. 그래서 NAT 트래버설은 보호된 페이로드를 UDP 4500으로 옮기고, 캡슐화는 변환 장치에게 자기가 변환할 줄 아는 것을 준다. 그렇게 되면 UDP 500만 허용한 방화벽 규칙은 협상을 허용하고 터널을 버리게 되어, 로그에는 페이즈 1 성공과 트래픽 없음이라는 혼란스러운 결과가 남는다.

IKE 교환 자체도 NAT가 감지된 뒤 UDP 4500으로 옮겨갈 수 있어, 500만 허용한 사람을 당황시킨다. 경로에서 두 포트를 양방향으로 허용하고, 상태 기반 방화벽은 트래픽이 보이는 동안만 흐름을 유지한다는 점을 기억하라.

프로토콜 50은 변환이 없는 경로에서도, 중간 장치가 허용하도록 설정된 경로에서도 여전히 중요하다. 제거로 진단한다면 규칙을 한꺼번에 추가하지 말고 가설을 끄라: 500, 4500, ESP를 허용하고 터널이 올라오는지 확인한 뒤 필요 없었던 것을 제거하라. 아무도 설명할 수 없는 규칙은 다음 장애의 원인이 되었을 때 아무도 제거하지 않는 규칙이다. 좁힌 내용을 고친 단계와 함께 변경 기록에 남겨, 다음 엔지니어가 같은 경험칙이 아니라 당신의 증거에서 시작하게 하라.

단계 3: 매핑이 만료되고 터널이 죽는다

변환 장치는 전달하는 흐름의 상태를 유지하고 그 상태에는 수명이 있다. L2TP/IPsec 터널은 아무도 쓰지 않을 때 트래픽을 거의 나르지 않으므로, 유휴 터널은 자기 매핑보다 오래 살아남아 돌아오는 트래픽을 받지 못할 수 있다. 클라이언트는 연결되어 있다고 믿고, 서버는 아무것도 보지 못하며, 첫 증상은 보통 VPN 오류가 아니라 애플리케이션 타임아웃이다.

죽은 피어 감지와 NAT keepalive가 이 때문에 있고, 양쪽 모두 그것을 보낼 준비가 되어야 한다. 서버가 변환 뒤에 있다면 Windows 측 요구 사항은 서버가 자기 아웃바운드 패킷에 UDP 캡슐화를 가정하게 하는 문서화된 레지스트리 설정이다; 그것이 없으면 응답자는 변환 장치가 되돌릴 수 없는 ESP를 보낸다. 이는 서버 구성 문제이지 클라이언트 문제가 아니다.

WAN 주소가 바뀌면 다른 방향에서 같은 결과가 나온다: 매핑이 새 주소를 중심으로 다시 만들어지고, 옛 보안 연관은 더 이상 존재하지 않는 튜플을 가리킨다. 재연결 동작은 클라이언트 구현의 몫이라, '공유기 재부팅 후 재연결'이 어떤 클라이언트에서는 되고 다른 클라이언트에서는 수동 토글이 필요하다.

통신사급 NAT 뒤에서 호스팅하는 것은 다른 문제다

집에서 L2TP/IPsec 서버를 호스팅해 밖에서 닿고 싶다면 필요한 것은 요청되지 않은 인바운드 도달성이고, 그것은 NAT 트래버설이 제공하는 것이 아니다. 공유기 앞에 통신사급 NAT가 있으면 공인 주소가 공유되고 매핑이 아웃바운드 전용이므로, 포워딩해서 도달 가능하게 만들 포트가 없다.

IPsec 패스스루 체크박스로는 바뀌지 않고, 아무리 클라이언트를 설정해도 보상되지 않는다. 지원되는 답은 실제로 도달 가능한 주소, 호스팅된 엔드포인트, 또는 모든 참가자가 아웃바운드 연결을 하는 아키텍처다. UDP 캡슐화 사양은 존재하는 흐름의 변환 문제를 풀 뿐, 통신사가 제공하지 않는 인바운드 경로를 만들지는 않는다.

그러니 추측하지 말고 네트워크를 비교하라. 같은 장치와 프로필을 다른 허용된 네트워크로 가져가 어느 단계가 거기서 실패하는지 보라. 다른 곳에서 된다면 차이는 경로에 있고, 그것이 수색을 전체 구성이 아니라 위의 세 단계로 좁힌다.