Ställ in DNS på en Windows VPN-adapter med PowerShell och verifiera sedan

En Windows VPN-anslutning lagrar inte DNS-servrar i profilen du redigerar i Inställningar. När tunneln kommer upp förhandlar klienten IP-konfigurationen med gatewayen, gatewayen skickar en lista med resolvers och Windows tillämpar den på tunneladaptern. Den adaptern är ett separat gränssnitt från din Wi-Fi eller Ethernet, och listan tillhör gränssnittet, inte profilen. När du vet vilket objekt som äger värdet är överstyrningen i PowerShell ett enda kommando; att få överstyrningen att överleva en återanslutning är delen som kräver ett beslut.

Vilket objekt äger adressen

RAS skapar tunneladaptern när anslutningen lyckas och tar bort den när anslutningen faller. DNS-servrarna du ser i ipconfig /all kommer in under det konfigurationsutbytet, bredvid IPv4- och IPv6-adresserna och rutterna. Eftersom värdet sitter på gränssnittet skriver Set-DnsClientServerAddress till något som bara finns så länge anslutningen gör det.

Det enda faktumet förklarar det mesta av förvirringen kring VPN-DNS. En profil kan inspekteras medan du är frånkopplad, men det finns inget gränssnitt att peka på, så ett inloggningsskript som anropar cmdleten mot VPN-aliaset misslyckas innan någon har anslutit. Det förklarar också en ändring som ser ut att rullas tillbaka: ingenting rullades tillbaka, gränssnittet förstördes och byggdes upp igen med värdena som gatewayen skickade.

Hitta aliaset innan du rör DNS

Profilnamn och gränssnittsalias är oftast samma sträng, men de är inte samma objekt. Get-VpnConnection listar profiler; Get-NetAdapter listar de gränssnitt som Windows faktiskt har. DNS-cmdletarna vill ha det andra, och de två går isär oftare än folk väntar sig, särskilt när klienten lägger till en beskrivning som "(RAS)" i adapternamnet.

Om profilen inte finns kan PowerShell skapa en inbyggd post. Tunnellypen och autentiseringen måste matcha det gatewayen erbjuder, eftersom en avvikelse dyker upp vid anslutning och inte vid skapandet:

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

Anslut en gång och läs sedan det verkliga aliaset innan du skriver något DNS-kommando:

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

Tillämpa överstyrningen i rätt ordning

Ordningen är viktigare än syntaxen. Adaptern måste vara uppe, aliaset måste gå att slå upp och kontot måste ha tillstånd att ändra gränssnittsinställningar. En anslutning per användare accepterar oftast ändringen från den inloggade användaren; en anslutning för alla användare som skapats med -AllUserConnection kräver vanligtvis ett förhöjt skal.

Själva cmdleten är en enda rad, dokumenterad i Microsofts referens för Set-DnsClientServerAddress:

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

Två felmoder är värda att känna igen vid första anblicken. Ett felaktigt alias ger ett fel från cmdleten, och det är det goda utfallet, för tystnad vore värre. En korrekt cmdlet utan synlig effekt betyder oftast att du tittar på fel adapter: en kvarlämnad tunneladapter från en annan klient, ett fysiskt nätverkskort med liknande beskrivning, eller en andra virtuell adapter skapad av ett nätverksverktyg i en sandlåda.

Varför en återanslutning kan ångra ändringen

Överstyrningen tillhör en enda instans av gränssnittet. När klienten river adaptern och bygger upp den igen vid nästa anslutning tillämpas de skickade värdena på nytt och din lista är borta. Vissa klienter återskapar gränssnittet vid varje anslutning; andra återanvänder det under hela sessionens livstid. Jämför gränssnittsindexet i Get-NetAdapter mellan två anslutningar och du vet vilket beteende du har.

Det finns tre hållbara svar, och att stapla dem skapar egna buggar. Ett anslutningsspecifikt DNS-suffix plus en NRPT-regel skickar bara det interna namnområdet till den interna resolvern och lämnar offentliga namn i fred. En grupprincip- eller MDM-inställning som tillämpas på VPN-anslutningen ställer in DNS vid anslutning utan något skript. En schemalagd uppgift som reagerar på anslutningshändelsen och kör cmdleten igen är det grova alternativet, men det fungerar och lämnar en logg. Välj en ägare för DNS och skriv ner vilken det är.

Interna namn med en enda etikett behöver också en suffixsöklista. Set-DnsClientGlobalSetting -SuffixSearchList gäller hela maskinen, så den ändrar uppslagningen för varje adapter på datorn, inklusive Ethernet. Testa den på en labbmaskin innan den hamnar i en avbildning.

Verifiera uppslagningen, inte bara inställningen

En resolver som står på en adapter bevisar bara att ett värde har skrivits. Fråga den avsedda servern direkt och fråga sedan via den vanliga vägen:

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

Uppdelningen berättar var felet sitter. Direktfrågan svarar och den vanliga frågan misslyckas: adapterinställningen eller suffixlistan är inte i kraft. Båda misslyckas: resolvern går inte att nå genom tunneln, så titta på rutter och brandväggsregler innan du rör DNS igen. Direktfrågan misslyckas medan den vanliga frågan svarar från någon annanstans: delad DNS är felkonfigurerad och ett internt namn besvaras av en offentlig resolver, vilket är ett policyproblem innan det är ett anslutningsproblem.

Kör testet två gånger, en gång direkt efter anslutning och en gång efter frånkoppling och återanslutning, och jämför utdata från Get-DnsClientServerAddress i båda körningarna. Om det skickade värdet är tillbaka på den andra anslutningen levde och dog överstyrningen med adaptern, och bara NRPT- eller policyrutten från föregående avsnitt håller. Spara båda utskrifterna och tidsstämplarna för anslutningen; de avgör frågan om det håller sig snabbare än ännu en runda redigeringar.