VPN이 DNS를 점유해 로컬 이름이 깨졌습니다: 목록을 고치세요

터널이 올라오고 인트라넷은 열리는데 프린터 이름이 확인되지 않습니다. 반대의 경우도 있습니다. 로컬 이름은 계속 동작하지만 회사 네트워크 안쪽은 전부 시간 초과가 납니다. 두 증상 모두 같은 곳에서 나옵니다. VPN 클라이언트가 연결할 때 다시 쓴 확인자 목록입니다.

목록을 의도적으로 고친 다음 push 메커니즘은 따로 다루세요. 경로는 세 번째 주제이고 여기서 고치는 대상이 아닙니다.

응용 프로그램이 실제로 쓰는 목록

Windows는 대화 상자가 보여 주는 것이 아니라 인터페이스 수준 설정으로 확인합니다. 그래서 각 인터페이스의 유효한 목록부터 시작하세요. 표시 이름보다 별칭이 더 중요합니다. 아래 명령이 모두 인터페이스를 지정하기 때문입니다. 별칭을 틀리면 수정이 엉뚱한 어댑터에 적용됩니다. 다음 재연결까지는 동작하는 것처럼 보이다가 그때 터널 자체의 항목이 돌아옵니다.

문제는 어떤 서버가 앞에 섰는지, 그리고 정적 항목으로 왔는지 DHCP 임대로 왔는지입니다. 두 사실이 어떤 수정을 쓸 수 있는지 결정합니다.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

터널 어댑터와 물리 어댑터의 출력을 읽고 각각의 모든 주소를 적어 두세요. 정적 항목은 정책이나 스크립트로 지울 수 있습니다. DHCP가 준 항목은 임대에 묶여 있어 다시 돌아오므로 선택할 수정이 달라집니다. 원격 네트워크의 이름은 광고된 확인자가, 로컬 LAN의 이름은 물리 어댑터가 확인하며, 질의는 먼저 참조되는 목록으로 갑니다.

밀어 넣은 서버를 제거하거나 순위를 낮추세요

터널 안에서 아무것도 그 서버를 필요로 하지 않으면 밀어 넣은 서버를 지우세요. 물리 어댑터 자체의 확인자가 다시 맡기 때문입니다. 원격 네트워크가 자기 서버만 답할 수 있는 영역을 가지고 있을 때만 남기고, 그 경우 앞에 로컬 확인자를 두세요. 아래 두 명령은 두 선택을 모두 다루므로 둘 다 실행하지 말고 상황에 맞는 하나를 고르세요.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

색인 1이 먼저 참조되므로 밀어 넣은 주소는 계속 쓸 수 있지만 모든 질의의 기본 응답은 아니게 됩니다. validate=no 플래그는 터널이 아직 자리를 잡는 동안 자주 실패하는 연결 가능성 검사를 건너뜁니다. 그러니 종료 코드를 믿지 말고 show 명령으로 결과를 확인하세요.

여기에 의존하기 전에 두 가지 한계를 알아 두세요. Windows는 DHCP로 netsh을 통해 들어온 서버를 지우지 않으며, 그 값은 인터페이스의 레지스트리 키 아래 DhcpNameServer로 남습니다. 그래서 레지스트리 편집은 다음 임대 후 다시 확인해야 하는 마지막 수단입니다. 어댑터 바인딩 순서도 신뢰할 만한 순위 결정 방식이 아닙니다. VPN 클라이언트가 자기 항목을 목록 맨 위에 넣을 수 있기 때문입니다.

push를 걸러낼 수 있는 곳

더 나은 수정은 옵션이 적용되기 전에 없앱니다. Community OpenVPN 클라이언트는 밀어 넣은 지시문을 이름으로 걸러낼 수 있어 서버 구성은 그대로 둡니다.

pull-filter ignore "dhcp-option DNS "

끝의 공백은 일치 조건에 속하고 필터는 서버 주소가 아니라 옵션 이름을 씁니다. 프로필에 block-outside-dns 지시문도 있으면 그것을 없애는 것은 이름 확인이 아니라 유출 보호를 바꾸는 일입니다. 그러니 두 편집을 묶지 말고 따로 결정하세요.

고집 센 호스트 이름 하나에는 Windows hosts 파일의 한 줄이 기기 전체의 확인자를 다시 정렬하는 것보다 안정적입니다. 다음 사람에게 보이지도 않으니 기기 구성이 문서화된 곳에 적어 두세요.

수정이 재연결을 견디게 하세요

이름 확인은 두 번 시험해야 합니다 한 번은 고른 서버를 상대로, 한 번은 응용 프로그램이 쓰는 형태로. 이 짝이 확인자 순서 문제와 전혀 응답하지 않는 서버를 갈라 줍니다. 첫 시험을 건너뛰면 두 원인이 엉킨 채로 남습니다.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

터널을 다시 연결하고 두 명령을 반복하세요. 손으로 바꾼 것은 다음 연결까지만 유지됩니다. 클라이언트가 어댑터를 올리면서 확인자 상태를 다시 만들기 때문입니다. netsh 줄을 클라이언트가 지원하는 연결 스크립트에 넣고, 그 스크립트가 성공적으로 끝나게 하고, 실행 전에 짧은 대기를 더하세요. 스크립트 뒤에 DNS를 적용하는 클라이언트는 어차피 결과를 덮어씁니다.

수정 후에도 공개 이름은 확인되고 내부 이름이 계속 실패하면 확인자 목록은 더 이상 용의자가 아닙니다. 질의가 서버에 아예 닿지 않을 가능성이 크며, 이는 다른 DNS 설정이 아니라 라우팅이나 방화벽 규칙을 가리킵니다. 인터페이스 별칭과 정착한 주소를 적어 두세요. 둘 다 기기마다 다르고 어느 것도 혼자서는 재구성을 견디지 못합니다.