DNS-i seadistamine Windowsi VPN-adapteril PowerShelliga ja seejärel kontrollimine

Windowsi VPN-ühendus ei salvesta DNS-serverid profiili, mida te Seadetes muudate. Kui tunnel tõuseb, läbiräägib klient lüüsiga IP-konfiguratsiooni, lüüs saadab resolverite nimekirja ja Windows rakendab selle tunnel-adapterile. See adapter on eraldi liides teie Wi-Fi või Etherneti liidesest ning nimekiri kuulub liidesele, mitte profiilile. Kui teate, milline objekt väärtust omab, on selle ülekirjutamine PowerShellis üks käsk; teha nii, et ülekirjutus jääb taasühendamisele vastu, on osa, mis nõuab otsust.

Milline objekt aadressi omab

RAS loob tunnel-adapteri, kui ühendus õnnestub, ja eemaldab selle, kui ühendus katkeb. DNS-serverid, mida näete käsus ipconfig /all saabuvad selle konfiguratsioonivahetuse ajal, IPv4 ja IPv6 aadresside ning marsruutide kõrval. Kuna väärtus on liidesega seotud, Set-DnsClientServerAddress kirjutab millessegi, mis eksisteerib ainult seni, kuni ühendus eksisteerib.

See üks fakt selgitab suuremat osa VPN-i DNS-i segadusest. Profiili saab ühenduseta uurida, kuid pole liidest, millele osutada, nii et sisselogimisskript, mis kutsub käsu VPN-i aliase vastu, ebaõnnestub enne, kui keegi on ühendunud. See selgitab ka muudatust, mis näib tagasi pöörduvat: miski ei pöördunud tagasi, liides hävitati ja ehitati uuesti lüüsi saadetud väärtustega.

Leidke alias enne, kui DNS-i puutute

Profiili nimi ja liidese alias on tavaliselt sama string, kuid need ei ole sama objekt. Get-VpnConnection loetleb profiile; Get-NetAdapter loetleb liidesed, mis Windowsil tegelikult on. DNS-käsud tahavad teist ja need kaks lahknevad sagedamini, kui inimesed ootavad, eriti kui klient lisab adapteri nimele kirjeldaja nagu "(RAS)".

Kui profiili pole, saab PowerShell luua omase kirje. Tunnelitüüp ja autentimine peavad vastama sellele, mida lüüs pakub, sest lahknevus ilmneb ühendamise ajal, mitte loomise ajal:

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

Ühendage üks kord, seejärel lugege tegelik alias enne mis tahes DNS-käsu kirjutamist:

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

Rakendage ülekirjutus õiges järjekorras

Järjekord on tähtsam kui süntaks. Adapter peab olema üleval, alias peab lahenema ja kontol peab olema luba liidese seadeid muuta. Ühe kasutaja ühendus võtab tavaliselt muudatuse sisse sisenenud kasutajalt; kõigi kasutajate ühendus, mis on loodud parameetriga -AllUserConnection , vajab tavaliselt kõrgendatud shelli.

Käsk ise on üks rida, dokumenteeritud Microsofti viites Set-DnsClientServerAddress:

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

Kaht ebaõnnestumisviisi tasub pealtnäha ära tunda. Vale alias tekitab käsult vea ja see on hea tulemus, sest vaikimine oleks hullem. Õige käsk ilma nähtava mõjuta tähendab tavaliselt, et vaatate vale adapterit: teise kliendi järelejäänud tunnel-adapter, sarnase kirjeldusega füüsiline NIC või teine virtuaaladapter, mille on loonud sandbox-võrgutööriist.

Miks taasühendamine võib muudatuse tühistada

Ülekirjutus kuulub ühele liidese eksemplarile. Kui klient adapteri maha võtab ja järgmisel ühendamisel uuesti ehitab, rakendatakse saadetud väärtused uuesti ja teie nimekiri on kadunud. Mõned kliendid loovad liidese igal ühendamisel uuesti; teised kasutavad seda kogu sessiooni jooksul. Võrrelge liidese indeksit käsus Get-NetAdapter kahe ühenduse vahel ja teate, milline käitumine teil on.

On kolm püsivat vastust ja nende kuhjamine loob omad vead. Ühendusepõhine DNS-sufiks pluss NRPT-reegel saadab ainult sisemise nimeruumi sisemisele resolverile ja jätab avalikud nimed rahule. VPN-ühendusele rakendatud Group Policy või MDM seade määrab DNS-i ühendamise ajal ilma ühegi skriptita. Ühendussündmusele reageeriv ja käsu uuesti käivitav ajastatud ülesanne on töökindel variant, kuid see töötab ja jätab logi. Valige DNS-ile üks omanik ja kirjutage üles, milline see on.

Ühe sildiga sisemised nimed vajavad ka sufiksi otsingunimekirja. Set-DnsClientGlobalSetting -SuffixSearchList kehtib kogu masinale, seega muudab see lahendust iga adapteri jaoks masinas, sealhulgas Etherneti. Testige seda laborimasinas enne, kui see pildile läheb.

Kontrollige lahendust, mitte ainult seadet

Adapteril loetletud resolver tõestab ainult, et väärtus on kirjutatud. Küsige kavandatud serverilt otse, seejärel küsige tavalisel teel:

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

Jaotus ütleb teile, kus viga on. Otsene päring vastab ja tavaline päring ebaõnnestub: adapteri seade või sufiksi nimekiri ei kehti. Mõlemad ebaõnnestuvad: resolver ei ole tunnelist kättesaadav, seega vaadake marsruute ja tulemüüri reegleid enne, kui DNS-i uuesti puutute. Otsene päring ebaõnnestub, samal ajal kui tavaline päring vastab kuskilt mujalt: split DNS on valesti seadistatud ja sisemisele nimele vastab avalik resolver, mis on poliitikaprobleem enne, kui see on ühenduvusprobleem.

Käivitage test kaks korda, üks kord kohe pärast ühendamist ja üks kord pärast katkestamist ja taasühendamist, ning võrrelge Get-DnsClientServerAddress mõlema jooksu väljundit. Kui saadetud väärtus on teisel ühendusel tagasi, elas ülekirjutus ja suri koos adapteriga ning vastu peab ainult eelmise jaotise NRPT või poliitika marsruut. Hoidke mõlemad transkriptsioonid ja ühendamise ajatemplid; need lahendavad küsimuse, kas see püsib, kiiremini kui veel üks redigeerimisvoor.