Indstil DNS på en Windows VPN-adapter med PowerShell, og verificér det

En Windows VPN-forbindelse gemmer ikke DNS-servere i den profil, du redigerer i Indstillinger. Når tunnelen kommer op, forhandler klienten IP-konfiguration med gatewayen, gatewayen sender en resolverliste, og Windows anvender den på tunneladapteren. Den adapter er en separat grænseflade fra din Wi-Fi eller Ethernet, og listen tilhører grænsefladen, ikke profilen. Når du ved, hvilket objekt der ejer værdien, er overskrivningen i PowerShell én kommando; at gøre overskrivningen i stand til at overleve en genopkobling er den del, der kræver en beslutning.

Hvilket objekt ejer adressen

RAS opretter tunneladapteren, når forbindelsen lykkes, og fjerner den, når forbindelsen falder. De DNS-servere, du ser i ipconfig /all ankommer under den konfigurationsudveksling, ved siden af IPv4- og IPv6-adresserne og ruterne. Fordi værdien er knyttet til grænsefladen, Set-DnsClientServerAddress skriver til noget, der kun findes, så længe forbindelsen gør.

Den ene kendsgerning forklarer det meste af forvirringen omkring VPN-DNS. En profil kan inspiceres, mens den er afbrudt, men der er ingen grænseflade at pege på, så et logon-script, der kalder cmdlet'en mod VPN-aliaset, fejler, før nogen har forbundet. Det forklarer også en ændring, der ser ud til at gå tilbage: intet gik tilbage, grænsefladen blev ødelagt og genopbygget med de værdier, gatewayen sendte.

Find aliaset, før du rører DNS

Profilnavn og grænsefladealias er normalt den samme streng, men de er ikke det samme objekt. Get-VpnConnection viser profiler; Get-NetAdapter viser de grænseflader, Windows faktisk har. DNS-cmdlet'erne vil have den anden, og de to divergerer oftere, end folk forventer, især når klienten tilføjer en beskrivelse som "(RAS)" til adapternavnet.

Hvis profilen ikke findes, kan PowerShell oprette en indbygget post. Tunneltypen og godkendelsen skal matche det, gatewayen tilbyder, fordi en uoverensstemmelse viser sig ved forbindelse, ikke ved oprettelse:

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

Forbind én gang, og læs derefter det rigtige alias, før du skriver nogen DNS-kommando:

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

Anvend overskrivningen i den rigtige rækkefølge

Rækkefølgen betyder mere end syntaksen. Adapteren skal være oppe, aliaset skal kunne opløses, og kontoen skal have lov til at ændre grænsefladeindstillinger. En forbindelse pr. bruger accepterer normalt ændringen fra den loggede bruger; en forbindelse for alle brugere oprettet med -AllUserConnection kræver normalt et forhøjet shell.

Selve cmdlet'en er en enkelt linje, dokumenteret i Microsofts reference for Set-DnsClientServerAddress:

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

To fejltilstande er værd at genkende på synet. Et forkert alias giver en fejl fra cmdlet'en, og det er det gode udfald, fordi tavshed ville være værre. En korrekt cmdlet uden synlig effekt betyder normalt, at du kigger på den forkerte adapter: en efterladt tunneladapter fra en anden klient, et fysisk NIC med en lignende beskrivelse eller en anden virtuel adapter oprettet af et sandbox-netværksværktøj.

Hvorfor en genopkobling kan annullere ændringen

Overskrivningen tilhører én grænsefladeinstans. Når klienten river adapteren ned og genopbygger den ved næste forbindelse, anvendes de sendte værdier igen, og din liste er væk. Nogle klienter genskaber grænsefladen ved hver forbindelse; andre genbruger den i hele sessionen. Sammenlign grænsefladeindekset i Get-NetAdapter over to forbindelser, og du ved, hvilken adfærd du har.

Der findes tre holdbare svar, og at stable dem skaber sine egne fejl. Et forbindelsesspecifikt DNS-suffiks plus en NRPT-regel sender kun det interne navneområde til den interne resolver og lader offentlige navne være. En Group Policy- eller MDM-indstilling anvendt på VPN-forbindelsen sætter DNS ved forbindelse uden noget script. En planlagt opgave, der reagerer på forbindelseshændelsen og kører cmdlet'en igen, er den grove løsning, men den virker og efterlader en log. Vælg én ejer til DNS, og skriv ned, hvilken det er.

Interne navne med en enkelt etiket har også brug for en suffikssøgeliste. Set-DnsClientGlobalSetting -SuffixSearchList gælder for hele maskinen, så det ændrer opløsningen for hver adapter på maskinen, inklusive Ethernet. Test det på en laboratoriemaskine, før det går i et image.

Verificér opløsningen, ikke kun indstillingen

En resolver, der er listet på en adapter, beviser kun, at en værdi er skrevet. Spørg den tilsigtede server direkte, og spørg derefter ad den normale vej:

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

Opdelingen fortæller, hvor fejlen sidder. Direkte forespørgsel svarer, og den almindelige forespørgsel fejler: adapterindstillingen eller suffikslisten er ikke i kraft. Begge fejler: resolveren er utilgængelig gennem tunnelen, så se på ruter og firewallregler, før du rører DNS igen. Direkte forespørgsel fejler, mens den almindelige forespørgsel svarer fra et andet sted: split DNS er forkert konfigureret, og et internt navn besvares af en offentlig resolver, hvilket er et politikproblem, før det er et forbindelsesproblem.

Kør testen to gange, én gang lige efter forbindelse og én gang efter en afbrydelse og genopkobling, og sammenlign Get-DnsClientServerAddress outputtet fra begge kørsler. Hvis den sendte værdi er tilbage på den anden forbindelse, levede overskrivningen og døde med adapteren, og kun NRPT- eller politikruten fra forrige afsnit holder. Gem begge transskriptioner og forbindelsestidsstemplerne; de afgør spørgsmålet om, hvorvidt det holder, hurtigere end endnu en runde redigeringer.