Set DNS på ein Windows VPN-adapter med PowerShell, og verifiser etterpå

Ei Windows VPN-tilkopling lagrar ikkje DNS-tenarar i profilen du redigerer i Innstillingar. Når tunnelen kjem opp, forhandlar klienten IP-konfigurasjon med gatewayen, gatewayen sender ei liste med oppløysarar, og Windows brukar ho på tunneladapteren. Den adapteren er eit eige grensesnitt frå Wi-Fi eller Ethernet, og lista høyrer til grensesnittet, ikkje til profilen. Når du veit kva objekt som eig verdien, er overstyringa i PowerShell éin kommando; å få overstyringa til å overleve ei ny tilkopling er delen som krev ei avgjerd.

Kva objekt eig adressa

RAS lagar tunneladapteren når tilkoplinga lykkast, og fjernar han når tilkoplinga fell. DNS-tenarane du ser i ipconfig /all, kjem inn under den konfigurasjonsutvekslinga, ved sida av IPv4- og IPv6-adressene og rutene. Fordi verdien er fest til grensesnittet, skriv Set-DnsClientServerAddress til noko som berre finst så lenge tilkoplinga gjer det.

Det eine faktumet forklarer det meste av forvirringa rundt VPN-DNS. Ein profil kan ein sjå på medan ein er fråkopla, men det finst ikkje noko grensesnitt å peike på, så eit påloggingsskript som kallar cmdleten mot VPN-aliaset, feilar før nokon har kopla til. Det forklarer òg ei endring som ser ut til å bli reversert: ingenting vart reversert, grensesnittet vart øydelagt og bygt opp att med verdiane gatewayen sende.

Finn aliaset før du rører DNS

Profilnamn og grensesnittalias er vanlegvis same streng, men dei er ikkje same objekt. Get-VpnConnection listar opp profilar; Get-NetAdapter listar opp grensesnitta Windows faktisk har. DNS-cmdletane vil ha det andre, og dei to sprikjer oftare enn folk ventar, særleg når klienten legg til ei skildring som "(RAS)" i adapternamnet.

Viss profilen ikkje finst, kan PowerShell lage ei innebygd oppføring. Tunnelenstypen og autentiseringa må samsvare med det gatewayen tilbyr, fordi eit avvik dukkar opp ved tilkopling og ikkje ved oppretting:

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

Kopla til éin gong, og les deretter det verkelege aliaset før du skriv nokon DNS-kommando:

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

Bruk overstyringa i rett rekkjefølgje

Rekkjefølgja tyder meir enn syntaksen. Adapteren må vere oppe, aliaset må løysast opp, og kontoen må ha løyve til å endre grensesnittinnstillingar. Ei tilkopling per brukar godtek vanlegvis endringa frå den pålogga brukaren; ei tilkopling for alle brukarar som er laga med -AllUserConnection, treng vanlegvis eit forhøgd skal.

Sjølve cmdleten er éi linje, dokumentert i Microsoft si Set-DnsClientServerAddress-referanse:

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

To feilmodus er verd å kjenne att ved synet. Eit feil alias gir ein feil frå cmdleten, og det er det gode utfallet, fordi stillheit ville vere verre. Ein korrekt cmdlet utan synleg verknad tyder vanlegvis at du ser på feil adapter: ein attgløymd tunneladapter frå ein annan klient, eit fysisk nettverkskort med liknande skildring, eller ein andre virtuell adapter laga av eit nettverksverktøy i sandkasse.

Kvifor ei ny tilkopling kan oppheve endringa

Overstyringa høyrer til éin førekomst av grensesnittet. Når klienten riv ned adapteren og byggjer han opp att ved neste tilkopling, blir dei sende verdiane brukte på nytt, og lista di er borte. Nokre klientar lagar grensesnittet på nytt ved kvar tilkopling; andre brukar det gjennom heile økta. Samanlikn grensesnittindeksen i Get-NetAdapter mellom to tilkoplingar, og du veit kva åtferd du har.

Det finst tre varige svar, og å stable dei skaper sine eigne feil. Eit tilkoplingsspesifikt DNS-suffiks pluss ein NRPT-regel sender berre det interne namnerommet til den interne oppløysaren og lèt offentlege namn vere i fred. Ei gruppepolicy- eller MDM-innstilling brukt på VPN-tilkoplinga set DNS ved tilkopling utan noko skript. Ein planlagd oppgåve som reagerer på tilkoplingshendinga og køyrer cmdleten på nytt, er det grove alternativet, men det verkar og lèt etter seg ein logg. Vel éin eigar for DNS og skriv ned kven det er.

Interne namn med éin etikett treng òg ei suffikssøkjeliste. Set-DnsClientGlobalSetting -SuffixSearchList gjeld for heile maskinen, så ho endrar oppslag for kvar adapter på boksen, inkludert Ethernet. Test ho på ein labmaskin før ho går inn i eit avtrykk.

Verifiser oppslaget, ikkje berre innstillinga

Ein oppløysar som står oppført på ein adapter, beviser berre at ein verdi er skriven. Spør den tiltenkte tenaren direkte, og spør deretter gjennom den vanlege vegen:

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

Delinga fortel deg kvar feilen sit. Direkte spørjing svarar og den vanlege spørjinga feilar: adapterinnstillinga eller suffikslista er ikkje i kraft. Begge feilar: oppløysaren er ikkje nåbar gjennom tunnelen, så sjå på ruter og brannmurreglar før du rører DNS igjen. Direkte spørjing feilar medan den vanlege spørjinga svarar frå ein annan stad: delt DNS er feilkonfigurert og eit internt namn blir svart av ein offentleg oppløysar, noko som er eit policyproblem før det er eit tilkoplingsproblem.

Køyr testen to gonger, éin gong rett etter tilkopling og éin gong etter fråkopling og ny tilkopling, og samanlikn Get-DnsClientServerAddress-utdata frå begge køyringane. Viss den sende verdien er tilbake på den andre tilkoplinga, levde og døydde overstyringa med adapteren, og berre NRPT- eller policyruta frå førre avsnitt vil halde. Ta vare på begge utskriftene og tidsstempla for tilkoplinga; dei avgjer spørsmålet om det held seg raskare enn ein ny runde med redigeringar.