Itakda ang DNS sa isang Windows VPN adapter gamit ang PowerShell, pagkatapos ay i-verify

Ang koneksyon ng VPN sa Windows ay hindi nag-iimbak ng mga DNS server sa profile na ine-edit mo sa Mga Setting. Kapag bumangon ang tunnel, nakikipag-usap ang client sa gateway tungkol sa IP configuration, nagpapadala ang gateway ng listahan ng mga resolver, at inilalapat ito ng Windows sa adapter ng tunnel. Ang adapter na iyon ay hiwalay na interface mula sa iyong Wi-Fi o Ethernet, at ang listahan ay pag-aari ng interface, hindi ng profile. Kapag alam mo kung aling object ang may-ari ng halaga, ang pag-override dito sa PowerShell ay isang utos lang; ang gawing makaligtas ang override sa isang muling pagkonekta ang bahaging nangangailangan ng desisyon.

Aling object ang may-ari ng address

Gumagawa ang RAS ng adapter ng tunnel kapag nagtagumpay ang koneksyon at tinatanggal ito kapag bumagsak ang koneksyon. Ang mga DNS server na nakikita mo sa ipconfig /all ay dumarating sa panahon ng palitang iyon ng configuration, katabi ng IPv4 at IPv6 address at ng mga ruta. Dahil nakakabit ang halaga sa interface, nagsusulat ang Set-DnsClientServerAddress sa isang bagay na umiiral lamang habang umiiral ang koneksyon.

Ang nag-iisang katotohanang iyon ang nagpapaliwanag sa karamihan ng kalituhan tungkol sa DNS ng VPN. Maaaring siyasatin ang profile habang nakadiskonekta, ngunit walang interface na matutukoy, kaya nabibigo ang script sa pag-login na tumatawag sa cmdlet laban sa alias ng VPN bago pa may makakonekta. Ipinapaliwanag din nito ang isang pagbabagong tila bumabalik: walang bumalik, sinira ang interface at itinayong muli gamit ang mga halagang ipinadala ng gateway.

Hanapin ang alias bago hawakan ang DNS

Ang pangalan ng profile at alias ng interface ay karaniwang parehong string, ngunit hindi sila parehong object. Naglilista ang Get-VpnConnection ng mga profile; naglilista ang Get-NetAdapter ng mga interface na talagang mayroon ang Windows. Ang mga cmdlet ng DNS ay gusto ang pangalawa, at mas madalas maghiwalay ang dalawa kaysa inaasahan ng mga tao, lalo na kapag nagdaragdag ang client ng deskriptor tulad ng "(RAS)" sa pangalan ng adapter.

Kung wala ang profile, makakagawa ang PowerShell ng native na entry. Dapat tumugma ang uri ng tunnel at authentication sa inaalok ng gateway, dahil lumilitaw ang pagkakaiba sa oras ng pagkonekta at hindi sa oras ng paggawa:

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

Kumonekta nang isang beses, pagkatapos ay basahin ang tunay na alias bago magsulat ng anumang utos ng DNS:

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

Ilapat ang override sa tamang pagkakasunod-sunod

Mas mahalaga ang pagkakasunod-sunod kaysa sa syntax. Dapat nakataas ang adapter, dapat malutas ang alias, at dapat pinapayagan ang account na baguhin ang mga setting ng interface. Ang koneksyon ng bawat user ay karaniwang tumatanggap ng pagbabago mula sa naka-log in na user; ang koneksyon ng lahat ng user na ginawa gamit ang -AllUserConnection ay karaniwang nangangailangan ng elevated na shell.

Ang cmdlet mismo ay isang linya, nakadokumento sa reference ng Set-DnsClientServerAddress ng Microsoft:

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

Dalawang paraan ng pagpalya ang sulit makilala sa isang sulyap. Ang maling alias ay gumagawa ng error mula sa cmdlet, at iyon ang mabuting resulta, dahil mas masahol ang katahimikan. Ang tamang cmdlet na walang nakikitang epekto ay karaniwang nangangahulugang tinitingnan mo ang maling adapter: isang naiwang tunnel adapter mula sa ibang client, isang pisikal na NIC na may katulad na paglalarawan, o isang pangalawang virtual adapter na ginawa ng isang tool sa network sa sandbox.

Bakit maaaring bawiin ng muling pagkonekta ang pagbabago

Ang override ay pag-aari ng isang instance lang ng interface. Kapag giniba ng client ang adapter at itinayong muli ito sa susunod na koneksyon, inilalapat muli ang mga ipinadalang halaga at mawawala ang iyong listahan. May mga client na gumagawa muli ng interface sa bawat koneksyon; ang iba ay ginagamit ito sa buong buhay ng session. Ihambing ang index ng interface sa Get-NetAdapter sa dalawang koneksyon at malalaman mo kung anong pag-uugali ang mayroon ka.

May tatlong matibay na sagot, at ang pagsasama-sama ng mga ito ay gumagawa ng sariling bug. Ang suffix ng DNS na partikular sa koneksyon kasama ang isang panuntunan ng NRPT ay nagpapadala lamang ng panloob na namespace sa panloob na resolver at hinahayaan ang mga pampublikong pangalan. Ang setting ng Group Policy o MDM na inilapat sa koneksyon ng VPN ay nagtatakda ng DNS sa oras ng pagkonekta nang walang anumang script. Ang naka-iskedyul na gawain na tumutugon sa event ng koneksyon at muling nagpapatakbo ng cmdlet ay ang magaspang na opsyon, ngunit gumagana ito at nag-iiwan ng log. Pumili ng isang may-ari para sa DNS at isulat kung alin ito.

Ang mga panloob na pangalang may isang label ay nangangailangan din ng listahan ng paghahanap ng suffix. Ang Set-DnsClientGlobalSetting -SuffixSearchList ay para sa buong makina, kaya binabago nito ang resolusyon para sa bawat adapter sa computer, kasama ang Ethernet. Subukan ito sa isang makina sa laboratoryo bago ito mapunta sa isang image.

I-verify ang resolusyon, hindi lang ang setting

Ang resolver na nakalista sa isang adapter ay nagpapatunay lamang na may naisulat na halaga. Tanungin nang direkta ang inilaan na server, pagkatapos ay tanungin sa normal na ruta:

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

Sinasabi sa iyo ng paghahati kung saan naroon ang sira. Sumasagot ang direktang query at nabibigo ang ordinaryong query: hindi umiiral ang setting ng adapter o ang listahan ng suffix. Parehong nabibigo: hindi maabot ang resolver sa pamamagitan ng tunnel, kaya tingnan ang mga ruta at panuntunan ng firewall bago muling hawakan ang DNS. Nabibigo ang direktang query habang ang ordinaryong query ay sumasagot mula sa ibang lugar: mali ang configuration ng split DNS at may pampublikong resolver na sumasagot sa isang panloob na pangalan, na isang isyu ng patakaran bago maging isyu ng koneksyon.

Patakbuhin ang pagsubok nang dalawang beses, isang beses agad pagkatapos kumonekta at isang beses pagkatapos ng pagdiskonekta at muling pagkonekta, at ihambing ang output ng Get-DnsClientServerAddress mula sa parehong pagtakbo. Kung bumalik ang ipinadalang halaga sa pangalawang koneksyon, namuhay at namatay ang override kasama ng adapter, at ang panuntunan ng NRPT o ruta ng patakaran mula sa nakaraang seksyon lang ang mananatili. Itago ang dalawang transcript at ang mga timestamp ng koneksyon; mas mabilis nilang lutasin ang tanong kung nananatili ito kaysa sa isa pang pag-ikot ng mga pag-edit.