Sett opp DNS på en Windows VPN-adapter med PowerShell, og verifiser etterpå

En VPN-tilkobling i Windows lagrer ikke DNS-servere i profilen du redigerer i Innstillinger. Når tunnelen kommer opp, forhandler klienten om IP-konfigurasjonen med gatewayen, gatewayen sender en liste over oppløsere, og Windows legger den på tunneladapteren. Adapteren er et eget grensesnitt ved siden av Wi-Fi eller Ethernet, og listen hører til grensesnittet, ikke til profilen. Når du først vet hvilket objekt som eier verdien, er det å overstyre den i PowerShell én kommando; det å få overstyringen til å tåle en ny tilkobling er den delen som krever en avgjørelse.

Hvilket objekt eier adressen

RAS lager tunneladapteren når tilkoblingen lykkes, og fjerner den når tilkoblingen bryter. DNS-serverne du ser i ipconfig /all, kommer inn i løpet av den konfigurasjonsutvekslingen, ved siden av IPv4- og IPv6-adressene og rutene. Siden verdien henger på grensesnittet, skriver Set-DnsClientServerAddress til noe som bare eksisterer mens tilkoblingen gjør det.

Den ene detaljen forklarer det meste av forvirringen rundt DNS i VPN. En profil kan undersøkes mens du er frakoblet, men det finnes ikke noe grensesnitt å peke på, så et påloggingsskript som kaller cmdleten mot VPN-aliaset, feiler før noen har koblet til. Den forklarer også en endring som ser ut som den blir rullet tilbake: ingenting ble rullet tilbake, grensesnittet ble revet og bygget opp igjen med verdiene gatewayen sendte.

Finn aliaset før du tar i DNS

Profilnavn og grensesnittalias er som regel samme streng, men de er ikke samme objekt. Get-VpnConnection viser profiler; Get-NetAdapter viser grensesnittene Windows faktisk har. DNS-cmdlettene vil ha det siste, og de to går oftere fra hverandre enn folk regner med, særlig når klienten føyer til en beskrivelse som "(RAS)" i adapternavnet.

Finnes ikke profilen, kan PowerShell lage en innebygd oppføring. Tunneltypen og autentiseringen må stemme med det gatewayen tilbyr, fordi et avvik viser seg ved tilkobling og ikke ved oppretting:

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

Koble til én gang, og les så det virkelige aliaset før du skriver en eneste DNS-kommando:

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

Bruk overstyringen i riktig rekkefølge

Rekkefølgen er viktigere enn syntaksen. Adapteren må være oppe, aliaset må la seg slå opp, og kontoen må ha lov til å endre grensesnittinnstillinger. En tilkobling per bruker tar som regel imot endringen fra den innloggede brukeren; en tilkobling for alle brukere laget med -AllUserConnection trenger vanligvis et skall med forhøyede rettigheter.

Cmdleten selv er én linje, dokumentert i Microsofts referanse for Set-DnsClientServerAddress:

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

To feilmønstre er verd å kjenne igjen med det samme. Et galt alias gir en feil fra cmdleten, og det er det gode utfallet, for stillhet ville vært verre. En riktig cmdlet uten synlig virkning betyr som regel at du ser på feil adapter: en etterlatt tunneladapter fra en annen klient, et fysisk nettverkskort med liknende beskrivelse, eller en andre virtuell adapter laget av et nettverksverktøy i en sandkasse.

Hvorfor en ny tilkobling kan angre endringen

Overstyringen hører til én enkelt forekomst av grensesnittet. Når klienten river ned adapteren og bygger den opp igjen ved neste tilkobling, blir de sendte verdiene lagt på på nytt, og listen din er borte. Noen klienter lager grensesnittet på nytt for hver tilkobling; andre bruker det om igjen hele økten. Sammenlign grensesnittindeksen i Get-NetAdapter for to tilkoblinger, og du vet hvilken oppførsel du har.

Det finnes tre varige svar, og å stable dem oppå hverandre skaper sine egne feil. Et DNS-suffiks som gjelder selve tilkoblingen, pluss en NRPT-regel, sender bare det interne navnerommet til den interne oppløseren og lar offentlige navn være i fred. En innstilling fra gruppepolicy eller MDM lagt på VPN-tilkoblingen setter DNS ved tilkobling uten noe skript. En planlagt oppgave som lytter på tilkoblingshendelsen og kjører cmdleten igjen, er den grove varianten, men den virker og setter spor i en logg. Velg én eier av DNS og skriv ned hvem det er.

Interne navn med bare én etikett trenger også en suffikssøkeliste. Set-DnsClientGlobalSetting -SuffixSearchList gjelder hele maskinen, så den endrer oppslaget for hver adapter på maskinen, også Ethernet. Prøv den på en laboratoriemaskin før den går inn i et avtrykk.

Verifiser oppslaget, ikke bare innstillingen

En oppløser som står oppført på en adapter, beviser bare at en verdi er skrevet inn. Spør den tiltenkte serveren direkte, og spør så den vanlige veien:

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

Skillet forteller hvor feilen ligger. Direkte spørring svarer og den vanlige spørringen feiler: adapterinnstillingen eller suffikslisten er ikke i virksomhet. Begge feiler: oppløseren nås ikke gjennom tunnelen, så se på ruter og brannmurregler før du rører DNS igjen. Direkte spørring feiler mens den vanlige spørringen svarer fra et annet sted: delt DNS er satt opp feil og et internt navn blir besvart av en offentlig oppløser, og det er et policyproblem før det er et tilkoblingsproblem.

Kjør testen to ganger, én gang rett etter tilkobling og én gang etter frakobling og ny tilkobling, og sammenlign utdataene fra Get-DnsClientServerAddress i begge kjøringene. Er den sendte verdien tilbake på den andre tilkoblingen, levde og døde overstyringen sammen med adapteren, og bare NRPT-regelen eller policyruten fra forrige avsnitt vil holde. Ta vare på begge utskriftene og tidsstemplene for tilkoblingen; de avgjør spørsmålet om det holder seg raskere enn nok en runde med endringer.