Windows NAT-T 레지스트리 값: 먼저 토폴로지를 확인하라

Windows VPN 연결이 실패하고, 검색이 레지스트리 값을 알려주며, 그 값이 재부팅과 함께 들어간다. 그 순서는 때때로 통하고 결코 아무것도 설명하지 않는다. 문제의 설정은 서버가 NAT 장치에 대해 어디에 있는지라는 한 가지 질문에 답하며, 어느 프로토콜이 어느 단계에서 실패했는지 알기 전에는 의미가 없다.

그 값이 실제로 선택하는 것

AssumeUDPEncapsulationContextOnSendRule은 Windows IPsec 구현이 NAT 장치 뒤에 있는 피어와 연결을 시도할지 결정한다. 문서화된 기본값 0은 그 경우를 허용하지 않고, 1은 서버가 NAT 뒤에 있는 쪽일 때 허용하며, 2는 양쪽 끝이 변환되는 경우를 포함한다. 이는 누가 어디에 있는지에 대한 토폴로지 진술이다.

순서로 읽으면 숫자는 신뢰성이 점점 높아지는 것이 아니라 변환이 점점 많아지는 것을 뜻한다. 아무것도 변환되지 않는 네트워크에서 2를 설정해도 연결이 더 빠르거나 안정되지 않으며 인증 실패도 고치지 않는다. Microsoft의 L2TP/IPsec용 NAT 지침 은 정책과 그 역사적 플랫폼 맥락을 문서화한다. 그 맥락을 실제로 실행하는 Windows 버전과 역할에 비추어 확인하라. 여러 릴리스에서 살아남은 문서는 모든 현재 빌드에 대한 진술이 아니다.

숫자보다 먼저 토폴로지를 맞춰라

경로를 그리고 변환 지점을 표시하라. 클라이언트가 가정용 라우터 뒤에 있는지, 서버가 로드 밸런서나 주소를 다시 쓰는 방화벽 뒤에 있는지, 어느 한쪽 끝이 통제할 수 없는 통신사 변환 뒤에 있는지 확인하라. 그 그림을 그린 뒤에야 값이 적용되는지, 어느 쪽 끝에 적용되는지 결정할 수 있다.

현재 Windows Server 버전이 그저 NAT 트래버설이 꺼진 채 출하된다는 주장은 행동 근거로 삼기에는 너무 넓다. 중요한 것은 시스템의 정책, 그 앞의 토폴로지, 실패한 교환이다. 이 순서다. 양쪽 끝에 공인 주소가 있다면 그 설정은 문제가 아니다. 대신 제안, 인증서, 계정을 보고 레지스트리는 그대로 두어라.

먼저 실패 단계를 확인하라

L2TP/IPsec 은 적어도 세 가지 서로 다른 실패를 만든다. 피어에 도달할 수 없고, IPsec 보호를 설정할 수 없으며, 터널이 존재한 뒤 PPP 사용자 인증이 거부된다. 거부된 계정은 NAT 정책을 바꿔 고칠 수 없고, 제안 불일치는 재부팅으로 고칠 수 없다.

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

응답자가 없는 타임아웃은 정책보다 도달 가능성이나 필터링을 시사한다. 제안 메시지와 함께 오는 빠른 거부는 알고리즘을 가리킨다. 터널이 올라간 뒤의 실패는 인증 단계에 속하며, 다른 담당자와 다른 해결책이다.

HTTPS를 통한 SSTP와 기본 IKEv2에는 자체 로그와 자체 제어가 있다. Windows에서도 실행된다는 이유만으로 그것들이 NAT 트래버설 사례가 되지는 않는다.

돌아갈 길을 마련하고 변경하라

문서화된 정책과 관찰된 토폴로지가 둘 다 그렇게 요구한다면 이전 값을 기록하고, 프로필별 스크립트가 아니라 관리되는 구성으로 변경을 적용하고, 재시작을 계획하라. 다른 워크로드를 지원하는 서버에서 이것은 무해한 편집이 아니다.

NAT 장치는 여전히 캡슐화된 전송과 반환 트래픽을 나른다. 레지스트리 값은 전달 규칙을 만들지 않고, 제안을 정렬하지 않으며, 신원을 검증하지 않는다. 그래서 변경 후 작동하기 시작한 연결은 전혀 다른 이유로 작동하고 있을 수 있다. 원래 토폴로지로 원래 프로토콜을 다시 시험하고, 어느 단계가 실패했는지, 왜 그 값이 해결할 것으로 기대했는지 적어라. 그 문장이 인터넷 소문을 방어할 수 있는 구성으로 바꾼다.