Windows VPN에서 잘못된 DNS 서버: 메트릭, 바인딩 순서, 접미사

Windows 클라이언트는 터널이 정상이고 기업 리졸버를 갖고 있어도 내부 이름을 집 공유기로 보낼 수 있다. 어떤 서버가 응답할지 결정하는 메커니즘은 세 가지이며 각각 다른 방식으로 실패한다. 세 가지를 모두 고칠 필요는 없다. 증상이 어느 것이 관여했는지 알려준다. 아래 결정 트리는 몇 분이면 끝나고, 메트릭 변경과 레지스트리 재정렬과 NRPT 규칙이 한꺼번에 들어와 무엇이 효과가 있었는지 아무도 모르게 되는 흔한 결말을 막는다.

결정하는 메커니즘은 셋, 보통 하나가 틀렸다

인터페이스 메트릭은 특정 주소 패밀리에 대해 어댑터의 순서를 정한다. Tcpip\Linkage 아래의 바인딩 순서는 오래된 코드 경로가 여전히 참조하는 머신 전체 수준의 인터페이스 식별자 목록이다. 이름 확인 정책 테이블(NRPT)은 이름 공간을 특정 서버에 묶고, 접미사 목록은 짧은 이름을 펼칠지 여부를 정한다. 이들은 독립적이므로 VPN 어댑터의 올바른 리졸버가 다른 곳의 낡은 우선순위에 진다.

이 메커니즘 중 어느 것도 터널 건너편이 아니다. VPN이 밀어 넣은 서버가 이름을 확인하지 못하면 클라이언트 쪽 설정은 모두 장식이며, 첫 번째 결정은 리졸버 자체가 직접 질의를 받았을 때 응답할 수 있는가이다.

결정 하나: 밀어 넣은 리졸버가 응답할 수 있는가?

서버에 명시적으로 질의하고 일반 조회와 비교한다. 두 응답의 차이가 선택 문제와 도달 가능성 문제를 갈라 준다:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

첫 번째가 성공하고 두 번째가 실패하면 리졸버에 도달할 수 있고 Windows가 잘못 고르는 것이므로 아래의 이름 공간과 순서 결정으로 간다. 첫 번째도 실패하면 클라이언트에서 도울 것이 없으니 UDP와 TCP 53이 터널을 통해 서버에 도달하는지, 서버의 호스트 방화벽이 풀을 버리지 않는지, 서버 자체 전달자가 정상인지 확인한다.

이 분기에서 멈춘다. 도달할 수 없는 리졸버에 NRPT 규칙을 적용하면 되돌릴 구성이 더 많아진 채 같은 실패가 생기고, 권위 있어 보이는 규칙 뒤에 실제 결함을 숨긴다.

결정 둘: 하나의 이름 공간인가, 모든 질의인가?

범위가 도구를 정한다. 기업 이름만 실패하면 머신을 재정렬하는 대신 이름 공간을 묶는다. NRPT 규칙이 그 접미사를 터널 리졸버로 보내고 나머지는 그대로 둔다. 모든 조회가 영향을 받으면 문제는 전역 어댑터 우선순위이며, 서버 설정을 바꾸지 않는 메트릭이 시작점이다.

주소 패밀리마다, 두 인터페이스 모두에서 메트릭을 설정하고 나서 순서를 확인한다:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

11을 위 줄의 터널 어댑터 ifIndex로 바꾼다. 11이 LAN 어댑터라면 같은 명령은 잘못된 경로를 낮추므로, 대신 LAN 어댑터를 올리면 반대편에서 같은 순서에 도달한다. netsh int ip set interface interface="Ethernet" metric=15, 그리고 두 번째 패밀리에는 netsh int ipv6 set interface interface="Ethernet" metric=15를 쓰고, int ip는 IPv4만 건드린다.

바인딩 순서는 첫 수가 아니라 마지막 수단이다. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage에는 장치 식별자의 Bind 목록이 있고, 터널 식별자를 앞으로 옮기면 어떤 어댑터가 먼저 질의되는지는 실제로 바뀌지만 이름 공간별 범위가 없는 머신 전체 레지스트리 값이다. 편집 전에 내보내고, 그 뒤 터널을 다시 연결해 클라이언트가 기대하는 상태에서 순서가 적용되게 한다.

단일 이름 공간에는 더 좁은 도구를 선호한다:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

결정 셋: 수정이 재연결을 견디는가?

다음 전화 접속 재연결까지만 유효한 메트릭은 애초에 저장되지 않은 것이다. L2TP/IPsec 등 연결 프로필은 연결이 시작될 때 다시 만들어지므로 저장된 값은 전화번호부 항목에 IpInterfaceMetric로 존재하며, 활성 인터페이스에만 있는 것이 아니다. 바로 이 이유로 그 필드를 스크립트로 처리하는 환경도 있고, 관리 정책에서 우선순위를 밀어 넣고 끝점을 그대로 두는 환경도 있다.

캐시와 등록은 별개의 계층이다. 터널이 올라온 뒤 이것을 실행하면 오래된 항목이 고쳐지고 클라이언트가 다시 등록되지만, 둘 다 어댑터를 재정렬하지 않는다:

ipconfig /registerdns
ipconfig /flushdns

같은 계층에 끄는 스위치가 있다. 물리 어댑터에서 동적 등록을 끄면 클라이언트가 VPN 쪽 주소를 잘못된 이름으로 알리지 않게 되며, 이는 위의 갱신과 다른 수리다.

IPv6는 결정에서 자기 줄을 가질 자격이 있다. 물리 어댑터에 전역 IPv6 주소가 있고 터널이 IPv4만 나른다면, Windows는 이름 확인에 터널을 거치지 않는 경로를 선호할 수 있다. 그 패밀리를 따로 확인한다. IPv4에 맞춘 메트릭은 그에 대해 아무 말도 하지 않는다:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

LAN 어댑터에서 IPv6를 끄면 그 경로와 프로토콜이 함께 사라진다. IPv6 인터페이스의 메트릭 변경이나 기업 이름 공간에 대한 NRPT 규칙은 패밀리를 유지하고 우선순위를 고친다. 그 링크에 IPv6가 없어야 한다고 정하지 않았다면 좁은 쪽을 고른다.

출처를 지목해 검증하고 소유자를 하나로 유지한다

페이지가 로드되는지만이 아니라 어떤 출처가 유효한지 보고하는 도구로 검증한다:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

그다음 필터링과 선택을 분리한다. 애플리케이션 안에서는 둘이 똑같아 보인다. OpenVPN의 block-outside-dns는 다른 어댑터에서 포트 53을 차단하지만 리졸버를 고르지는 않는다. 지금 모든 질의가 실패하면 필터가 유일하게 도달 가능한 서버를 막고 있을 수 있다. 설정한 리졸버가 무시된다면 순서나 이름 공간 규칙이 틀린 것이다. 둘을 동시에 바꾸면 차단된 질의와 무시된 질의를 구별할 수 없게 된다.

DNS 정책의 소유자는 VPN 프로필, 관리 정책, NRPT 규칙 중 하나로 유지하며 둘로 두지 않는다. 마무리하기 전에:

• 밀어 넣은 리졸버는 명시적으로 지목하면 응답하고, 일반 조회가 그것을 사용한다.
• 변경한 규칙이나 메트릭이 실제로 질의를 나르는 주소 패밀리를 덮는다.
• 설정이 연결 해제와 재연결을 견디거나, 저장된 프로필로 옮겨 두었다.
• 권위를 가진 메커니즘은 정확히 하나이고 나머지는 그대로 두었다.

순서는 끝내는 일이 아니라 환경 상태로 다룬다. 재연결 뒤, 그리고 네트워크 스택을 건드리는 Windows 업데이트 뒤에 다시 확인한다. 둘 중 어느 것이든 물리 어댑터를 다시 앞으로 되돌릴 수 있다.