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

En Windows VPN-tilkobling lagrer ikke DNS-servere i profilen du redigerer i Innstillinger. Når tunnelen kommer opp, forhandler klienten IP-konfigurasjon med gatewayen, gatewayen sender en liste med oppløsere, og Windows bruker den på tunneladapteren. Den adapteren er et eget grensesnitt fra Wi-Fi eller Ethernet, og listen tilhører grensesnittet, ikke profilen. Når du vet hvilket objekt som eier verdien, er overstyringen i PowerShell én kommando; å få overstyringen til å overleve en ny tilkobling er delen som krever en beslutning.

Hvilket objekt eier adressen

RAS oppretter tunneladapteren når tilkoblingen lykkes, og fjerner den når tilkoblingen faller. DNS-serverne du ser i ipconfig /all, kommer inn under den konfigurasjonsutvekslingen, ved siden av IPv4- og IPv6-adressene og rutene. Fordi verdien er festet til grensesnittet, skriver Set-DnsClientServerAddress til noe som bare finnes så lenge tilkoblingen gjør det.

Det ene faktumet forklarer det meste av forvirringen rundt VPN-DNS. En profil kan inspiseres 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. Det forklarer også en endring som ser ut til å reverseres: ingenting ble reversert, grensesnittet ble ødelagt og bygget opp igjen med verdiene gatewayen sendte.

Finn aliaset før du rører DNS

Profilnavn og grensesnittalias er vanligvis samme streng, men de er ikke samme objekt. Get-VpnConnection lister opp profiler; Get-NetAdapter lister opp grensesnittene Windows faktisk har. DNS-cmdlettene vil ha det andre, og de to spriker oftere enn folk forventer, særlig når klienten legger til en beskrivelse som "(RAS)" i adapternavnet.

Hvis profilen ikke finnes, kan PowerShell opprette en innebygd oppføring. Tunneltypen og autentiseringen må samsvare med det gatewayen tilbyr, fordi et avvik dukker opp ved tilkobling og ikke ved opprettelse:

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

Koble til én gang, og les deretter det virkelige aliaset før du skriver noen DNS-kommando:

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

Bruk overstyringen i riktig rekkefølge

Rekkefølgen betyr mer enn syntaksen. Adapteren må være oppe, aliaset må løses opp, og kontoen må ha lov til å endre grensesnittinnstillinger. En tilkobling per bruker godtar vanligvis endringen fra den påloggede brukeren; en tilkobling for alle brukere som er opprettet med -AllUserConnection, trenger vanligvis et forhøyet skall.

Selve cmdleten er én linje, dokumentert i Microsofts Set-DnsClientServerAddress-referanse:

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

To feilmoduser er verdt å kjenne igjen ved synet. Et feil alias gir en feil fra cmdleten, og det er det gode utfallet, fordi stillhet ville vært verre. En korrekt cmdlet uten synlig effekt betyr vanligvis at du ser på feil adapter: en gjenglemt tunneladapter fra en annen klient, et fysisk nettverkskort med lignende beskrivelse, eller en andre virtuell adapter laget av et nettverksverktøy i sandkasse.

Hvorfor en ny tilkobling kan oppheve endringen

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

Det finnes tre varige svar, og å stable dem skaper sine egne feil. Et tilkoblingsspesifikt DNS-suffiks pluss en NRPT-regel sender bare det interne navnerommet til den interne oppløseren og lar offentlige navn være i fred. En gruppepolicy- eller MDM-innstilling brukt på VPN-tilkoblingen setter DNS ved tilkobling uten noe skript. En planlagt oppgave som reagerer på tilkoblingshendelsen og kjører cmdleten på nytt, er det grove alternativet, men det virker og etterlater en logg. Velg én eier for DNS og skriv ned hvilken det er.

Interne navn med én etikett trenger også en suffikssøkeliste. Set-DnsClientGlobalSetting -SuffixSearchList gjelder for hele maskinen, så den endrer oppslag for hver adapter på boksen, inkludert Ethernet. Test den på en labmaskin 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. Spør den tiltenkte serveren direkte, og spør deretter gjennom den vanlige veien:

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

Delingen forteller deg hvor feilen sitter. Direkte spørring svarer og den vanlige spørringen feiler: adapterinnstillingen eller suffikslisten er ikke i kraft. Begge feiler: oppløseren er ikke nåbar 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 feilkonfigurert og et internt navn besvares av en offentlig oppløser, noe som 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 Get-DnsClientServerAddress-utdata fra begge kjøringene. Hvis den sendte verdien er tilbake på den andre tilkoblingen, levde og døde overstyringen med adapteren, og bare NRPT- 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 en ny runde med redigeringer.