PowerShell로 Windows VPN 어댑터의 DNS를 설정하고 확인하기

Windows의 VPN 연결은 설정에서 편집하는 프로필에 DNS 서버를 저장하지 않습니다. 터널이 올라오면 클라이언트가 게이트웨이와 IP 구성을 협상하고, 게이트웨이가 확인자 목록을 보내며, Windows가 그것을 터널 어댑터에 적용합니다. 그 어댑터는 Wi-Fi나 Ethernet과 별개의 인터페이스이고, 목록은 프로필이 아니라 인터페이스에 속합니다. 어떤 개체가 값을 소유하는지 알면 PowerShell에서 덮어쓰는 것은 명령 하나이며, 덮어쓴 값이 다시 연결한 뒤에도 남게 하는 것이 결정이 필요한 부분입니다.

주소를 소유하는 개체

RAS는 연결이 성공하면 터널 어댑터를 만들고 연결이 끊기면 제거합니다. ipconfig /all에서 보이는 DNS 서버는 그 구성 교환 과정에서 IPv4와 IPv6 주소, 경로와 나란히 들어옵니다. 값이 인터페이스에 붙어 있으므로 Set-DnsClientServerAddress는 연결이 존재하는 동안에만 존재하는 대상에 씁니다.

이 한 가지 사실이 VPN DNS를 둘러싼 혼란의 대부분을 설명합니다. 프로필은 연결되지 않은 상태에서도 살펴볼 수 있지만 가리킬 인터페이스가 없으므로, VPN 별칭에 대해 cmdlet을 호출하는 로그온 스크립트는 누군가 연결하기도 전에 실패합니다. 되돌아가는 것처럼 보이는 변경도 설명합니다: 되돌아간 것은 없고, 인터페이스가 파괴되어 게이트웨이가 보낸 값으로 다시 만들어진 것입니다.

DNS를 건드리기 전에 별칭 찾기

프로필 이름과 인터페이스 별칭은 대개 같은 문자열이지만 같은 개체는 아닙니다. Get-VpnConnection는 프로필을 나열하고, Get-NetAdapter는 Windows가 실제로 가진 인터페이스를 나열합니다. DNS cmdlet이 원하는 것은 후자이며, 둘은 사람들이 기대하는 것보다 자주 어긋나는데, 특히 클라이언트가 어댑터 이름에 "(RAS)" 같은 설명자를 붙일 때 그렇습니다.

프로필이 없으면 PowerShell이 네이티브 항목을 만들 수 있습니다. 터널 종류와 인증은 게이트웨이가 제공하는 것과 일치해야 하며, 불일치는 만들 때가 아니라 연결할 때 드러나기 때문입니다:

Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
  -TunnelType Ikev2 -EncryptionLevel Required `
  -AuthenticationMethod Eap -AllUserConnection

한 번 연결한 뒤 어떤 DNS 명령이든 쓰기 전에 실제 별칭을 읽으십시오:

rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"

덮어쓰기를 올바른 순서로 적용하기

구문보다 순서가 중요합니다. 어댑터가 올라와 있어야 하고, 별칭이 확인되어야 하며, 계정에 인터페이스 설정을 바꿀 권한이 있어야 합니다. 사용자별 연결은 보통 로그온한 사용자의 변경을 받아들이고, -AllUserConnection로 만든 모든 사용자 연결은 대개 상승된 셸이 필요합니다.

cmdlet 자체는 한 줄이며 Microsoft의 Set-DnsClientServerAddress 참조에 문서화되어 있습니다:

Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4

실패 유형 두 가지는 눈으로 알아볼 만합니다. 잘못된 별칭은 cmdlet에서 오류를 내는데, 침묵이 더 나쁘므로 그것이 좋은 결과입니다. 올바른 cmdlet인데 눈에 보이는 효과가 없다면 대개 다른 어댑터 — 다른 클라이언트가 남긴 터널 어댑터, 설명이 비슷한 물리 NIC, 격리된 환경의 네트워크 도구가 만든 두 번째 가상 어댑터 — 를 보고 있는 것입니다.

다시 연결하면 변경이 취소될 수 있는 이유

덮어쓴 값은 인터페이스의 한 인스턴스에 속합니다. 클라이언트가 어댑터를 허물고 다음 연결에서 다시 만들면 보낸 값이 다시 적용되어 목록이 사라집니다. 어떤 클라이언트는 연결할 때마다 인터페이스를 다시 만들고, 다른 클라이언트는 세션 내내 재사용합니다. Get-NetAdapter의 인터페이스 인덱스를 두 연결에서 비교하면 어느 쪽인지 알 수 있습니다.

지속되는 해답은 세 가지이며, 겹쳐 쓰면 그 자체로 결함이 생깁니다. 연결별 DNS 접미사와 NRPT 규칙을 함께 쓰면 내부 이름 공간만 내부 확인자로 보내고 공용 이름은 건드리지 않습니다. VPN 연결에 적용하는 그룹 정책이나 MDM 설정은 스크립트 없이 연결 시점에 DNS를 설정합니다. 연결 이벤트에 반응해 cmdlet을 다시 실행하는 예약 작업은 거친 선택이지만 동작하고 로그를 남깁니다. DNS의 소유자를 하나로 정하고 어느 것인지 적어 두십시오.

레이블이 하나인 내부 이름에는 접미사 검색 목록도 필요합니다. Set-DnsClientGlobalSetting -SuffixSearchList는 컴퓨터 전체에 적용되므로 Ethernet을 포함해 그 컴퓨터의 모든 어댑터 해석을 바꿉니다. 이미지에 넣기 전에 실험실 컴퓨터에서 시험하십시오.

설정이 아니라 해석을 확인하기

어댑터에 나열된 확인자는 값이 기록되었다는 것만 증명합니다. 의도한 서버에 직접 질의하고, 그다음 일반 경로로 질의하십시오:

Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example

이 갈림이 결함의 위치를 알려 줍니다. 직접 질의는 답하고 일반 질의가 실패하면 어댑터 설정이나 접미사 목록이 적용되지 않은 것입니다. 둘 다 실패하면 터널로 확인자에 닿지 못하는 것이므로 DNS를 다시 건드리기 전에 경로와 방화벽 규칙을 보십시오. 직접 질의는 실패하는데 일반 질의가 다른 곳에서 답하면 분할 DNS가 잘못 구성되어 내부 이름을 공용 확인자가 답하는 것이며, 이는 연결성 문제이기 전에 정책 문제입니다.

시험을 두 번, 연결 직후에 한 번, 연결을 끊고 다시 연결한 뒤에 한 번 실행하고 두 번의 Get-DnsClientServerAddress 출력을 비교하십시오. 두 번째 연결에서 보낸 값이 돌아왔다면 덮어쓴 값은 어댑터와 함께 살고 죽은 것이며, 앞 절의 NRPT나 정책 경로만 버팁니다. 두 기록과 연결 시각을 보관해 두십시오; 편집을 한 차례 더 하는 것보다 유지 여부에 대한 답이 빨리 나옵니다.