Stilltu DNS á Windows-VPN-tengi með PowerShell og staðfestu síðan

Windows-VPN-tenging geymir ekki DNS-þjóna í sniðinu sem þú breytir í Stillingum. Þegar göngin koma upp semur biðlarinn um IP-stillingu við gáttina, gáttin sendir lista yfir leysendur og Windows beitir honum á tengi göngunnar. Þetta tengi er sérstakt viðmót frá Wi-Fi eða Ethernet, og listinn tilheyrir viðmótinu, ekki sniðinu. Þegar þú veist hvaða hlutur á gildið er að yfirskrifa það í PowerShell ein skipun; að láta yfirskriftina lifa endurtengingu er sá hluti sem krefst ákvörðunar.

Hvaða hlutur á heimilisfangið

RAS býr til tengi göngunnar þegar tengingin tekst og fjarlægir það þegar tengingin dettur. DNS-þjónarnir sem þú sérð í ipconfig /all koma í þeirri stillingarskiptingu, við hlið IPv4- og IPv6-tölvanna og leiðanna. Þar sem gildið er fest við viðmótið skrifar Set-DnsClientServerAddress í eitthvað sem er aðeins til á meðan tengingin er til.

Þessi eina staðreynd útskýrir mestan hluta ruglingsins í kringum VPN-DNS. Hægt er að skoða snið án tengingar, en ekkert viðmót er til að benda á, svo innskráningarskript sem kallar á cmdletið á VPN-samheitið mistekst áður en einhver hefur tengst. Hún útskýrir líka breytingu sem virðist ganga til baka: ekkert fór til baka, viðmótið var eyðilagt og endurbyggt með gildunum sem gáttin sendi.

Finndu samheitið áður en þú snertir DNS

Sniðsheiti og samheiti viðmótsins eru venjulega sami strengurinn, en þau eru ekki sami hluturinn. Get-VpnConnection telur upp snið; Get-NetAdapter telur upp viðmótin sem Windows hefur í raun. DNS-cmdletin vilja það síðara, og þau tvö fara oftar sundur en fólk býst við, sérstaklega þegar biðlarinn bætir lýsingu eins og "(RAS)" við heiti tengisins.

Ef sniðið er ekki til getur PowerShell búið til upprunalega færslu. Göngutegundin og auðkenningin verða að passa við það sem gáttin býður, því ósamræmi kemur fram við tengingu en ekki við stofnun:

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

Tengdu einu sinni og lestu svo raunverulega samheitið áður en þú skrifar eina DNS-skipun:

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

Beittu yfirskriftinni í réttri röð

Röðin skiptir meira máli en setningafræðin. Tengið verður að vera uppi, samheitið verður að leysast og reikningnum verður að vera heimilt að breyta stillingum viðmótsins. Tenging fyrir hvern notanda tekur venjulega við breytingunni frá innskráðum notanda; tenging fyrir alla notendur sem búin er til með -AllUserConnection þarf yfirleitt skel með auknum réttindum.

Cmdletið sjálft er ein lína, skjalfest í Set-DnsClientServerAddress-tilvísun Microsoft:

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

Tvenns konar mistök er vert að þekkja við fyrstu sýn. Rangt samheiti veldur villu frá cmdletinu, og það er góð útkoma, því þögn væri verri. Rétt cmdlet án sýnilegs áhrifs þýðir venjulega að þú ert að skoða rangt tengi: afgangs göngutengi frá öðrum biðlara, raunverulegt netkort með svipaða lýsingu eða annað sýndartengi sem sandkassanettól bjó til.

Hvers vegna endurtenging getur afturkallað breytinguna

Yfirskriftin tilheyrir einu tilviki viðmótsins. Þegar biðlarinn rífur tengið niður og byggir það upp aftur við næstu tengingu eru sendu gildin beitt aftur og listinn þinn er horfinn. Sumir biðlarar búa til viðmótið að nýju við hverja tengingu; aðrir nota það alla líftíma lotunnar. Berðu saman viðmótsnúmerið í Get-NetAdapter milli tveggja tenginga og þá veistu hvaða hegðun þú hefur.

Þrjú varanleg svör eru til, og að stafla þeim skapar sínar eigin villur. DNS-viðskeyti sértækt fyrir tenginguna ásamt NRPT-reglu sendir aðeins innra nafnrýmið til innra leysandans og lætur opinber nöfn í friði. Stilling hófstefnu eða MDM sem beitt er á VPN-tenginguna stillir DNS við tengingu án nokkurs skripts. Tímasett verkefni sem bregst við tengingaratburðinum og keyrir cmdletið aftur er hráa lausnin, en hún virkar og skilur eftir sig annál. Veldu einn eiganda DNS og skrifaðu niður hver það er.

Innri nöfn með einu merki þurfa líka viðskeytaleitarlista. Set-DnsClientGlobalSetting -SuffixSearchList gildir fyrir alla vélina, svo það breytir upplausn fyrir hvert tengi í tölvunni, þar á meðal Ethernet. Prófaðu á tilraunavél áður en það fer inn í ímynd.

Staðfestu upplausnina, ekki bara stillinguna

Leysandi sem er skráður á tengi sannar aðeins að gildi hafi verið skrifað. Spurðu ætlaða þjóninn beint og spurðu svo venjulegu leiðina:

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

Skiptingin segir þér hvar gallinn liggur. Bein fyrirspurn svarar og venjulega fyrirspurnin mistekst: stilling tengisins eða viðskeytalistinn er ekki í gildi. Báðar mistekst: leysandinn er óaðgengilegur í gegnum göngin, svo skoðaðu leiðir og eldveggsreglur áður en þú snertir DNS aftur. Bein fyrirspurn mistekst á meðan venjulega fyrirspurnin svarar annars staðar frá: skipt DNS er rangt stillt og opinber leysandi svarar innra nafni, sem er stefnumál fyrir það er tengivandamál.

Keyrðu prófið tvisvar, einu sinni strax eftir tengingu og einu sinni eftir aftengingu og endurtengingu, og berðu saman útkomu Get-DnsClientServerAddress úr báðum keyrslum. Ef senda gildið er komið aftur við aðra tenginguna lifði yfirskriftin og dó með tenginu, og aðeins NRPT- eða stefnuleiðin úr fyrri hluta mun standa. Geymdu bæði uppritin og tímasetningar tengingarinnar; þau leysa spurninguna um hvort það haldist hraðar en önnur umferð breytinga.