Agordi DNS ĉe Windows-VPN-adaptilo per PowerShell kaj poste kontroli

Windows-VPN-konekto ne konservas DNS-servilojn en la profilo, kiun vi redaktas en Agordoj. Kiam la tunelo supreniĝas, la kliento interkonsentas IP-agordon kun la enirejo, la enirejo puŝas liston de solviloj, kaj Windows aplikas ĝin al la tunela adaptilo. Tiu adaptilo estas aparta interfaco de via Wi-Fi aŭ Ethernet, kaj la listo apartenas al la interfaco, ne al la profilo. Post kiam vi scias, kiu objekto posedas la valoron, anstataŭigi ĝin en PowerShell estas unu komando; igi la anstataŭigon postvivi rekonekton estas la parto, kiu bezonas decidon.

Kiu objekto posedas la adreson

RAS kreas la tunelan adaptilon, kiam la konekto sukcesas, kaj forigas ĝin, kiam la konekto falas. La DNS-serviloj, kiujn vi vidas en ipconfig /all alvenas dum tiu agorda interŝanĝo, apud la adresoj IPv4 kaj IPv6 kaj la itineroj. Ĉar la valoro estas ligita al la interfaco, Set-DnsClientServerAddress skribas en ion, kio ekzistas nur dum la konekto ekzistas.

Tiu unu fakto klarigas la plej grandan parton de la konfuzo pri VPN-DNS. Profilon eblas inspekti dum malkonektite, sed ne estas interfaco por montri, do ensaluta skripto, kiu vokas la komandon kontraŭ la VPN-kaŝnomo, malsukcesas antaŭ ol iu ajn konektis. Ĝi ankaŭ klarigas ŝanĝon, kiu ŝajnas reiri: nenio reiris, la interfaco estis detruita kaj rekonstruita kun la valoroj, kiujn la enirejo puŝis.

Trovu la kaŝnomon antaŭ ol tuŝi DNS

Profila nomo kaj interfaca kaŝnomo kutime estas la sama ĉeno, sed ili ne estas la sama objekto. Get-VpnConnection listigas profilojn; Get-NetAdapter listigas la interfacojn, kiujn Windows efektive havas. La DNS-komandoj volas la duan, kaj la du malkongruas pli ofte ol homoj atendas, precipe kiam la kliento aldonas priskribon kiel "(RAS)" al la adaptila nomo.

Se la profilo ne ekzistas, PowerShell povas krei indiĝenan eron. La tunela tipo kaj aŭtentikigo devas kongrui kun tio, kion la enirejo proponas, ĉar malkongruo aperas ĉe konekto, ne ĉe kreado:

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

Konektu unufoje, poste legu la realan kaŝnomon antaŭ ol skribi ajnan DNS-komandon:

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

Apliku la anstataŭigon en la ĝusta ordo

Ordo gravas pli ol sintakso. La adaptilo devas esti supre, la kaŝnomo devas solviĝi, kaj la konto devas rajtas ŝanĝi interfacajn agordojn. Konekto por unu uzanto kutime akceptas la ŝanĝon de la ensalutinta uzanto; konekto por ĉiuj uzantoj kreita kun -AllUserConnection kutime bezonas altigitan ŝelon.

La komando mem estas unu linio, dokumentita en la referenco de Set-DnsClientServerAddress:

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

Du fiaskmanieroj indas rekoni per unu rigardo. Malĝusta kaŝnomo produktas eraron de la komando, kaj tio estas la bona rezulto, ĉar silento estus pli malbona. Ĝusta komando sen videbla efiko kutime signifas, ke vi rigardas la malĝustan adaptilon: restaĵa tunela adaptilo de alia kliento, fizika NIC kun simila priskribo, aŭ dua virtuala adaptilo kreita de sandboxa reta ilo.

Kial rekonekto povas nuligi la ŝanĝon

La anstataŭigo apartenas al unu interfaca kazo. Kiam la kliento malkonstruas la adaptilon kaj rekonstruas ĝin ĉe la sekva konekto, la puŝitaj valoroj denove aplikiĝas kaj via listo malaperas. Iuj klientoj rekreas la interfacon ĉe ĉiu konekto; aliaj reuzas ĝin dum la tuta sesio. Komparu la interfacan indekson en Get-NetAdapter inter du konektoj kaj vi scios, kiun konduton vi havas.

Ekzistas tri daŭraj respondoj, kaj stakigi ilin kreas proprajn cimojn. Konekto-specifa DNS-sufikso plus regulo NRPT sendas nur la internan nomspacon al la interna solvilo kaj lasas publikajn nomojn trankvile. Group Policy aŭ MDM-agordo aplikata al la VPN-konekto agordas DNS ĉe konekto sen ia skripto. Planita tasko, kiu reagas al la konekta okazaĵo kaj reruligas la komandon, estas la kruda opcio, sed ĝi funkcias kaj lasas protokolon. Elektu unu posedanton por DNS kaj skribu, kiu ĝi estas.

Internaj nomoj kun unu etikedo ankaŭ bezonas sufikso-serĉan liston. Set-DnsClientGlobalSetting -SuffixSearchList validas por la tuta maŝino, do ĝi ŝanĝas la solvon por ĉiu adaptilo en la maŝino, inkluzive Ethernet. Testu ĝin sur laboratoria maŝino antaŭ ol ĝi eniros bildon.

Kontrolu la solvon, ne nur la agordon

Solvilo listigita ĉe adaptilo pruvas nur, ke valoro estis skribita. Demande la celatan servilon rekte, poste demandu per la normala vojo:

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

La divido diras al vi, kie estas la paneo. Rekta demando respondas kaj la ordinara demando malsukcesas: la adaptila agordo aŭ la sufiksa listo ne efikas. Ambaŭ malsukcesas: la solvilo neatingeblas tra la tunelo, do rigardu itinerajn kaj fajroŝirmilajn regulojn antaŭ ol tuŝi DNS denove. La rekta demando malsukcesas dum la ordinara respondas de aliloke: split DNS estas misagordita kaj internan nomon respondas publika solvilo, kio estas politika problemo antaŭ ol konekteca.

Rulu la teston dufoje, unufoje tuj post konekto kaj unufoje post malkonekto kaj rekonekto, kaj komparu la Get-DnsClientServerAddress eligon de ambaŭ ruloj. Se la puŝita valoro revenas ĉe la dua konekto, la anstataŭigo vivis kaj mortis kun la adaptilo, kaj nur la NRPT- aŭ politika itinero el la antaŭa sekcio tenos. Konservu ambaŭ protokolojn kaj la konektajn tempindikojn; ili solvas la demandon, ĉu ĝi restas, pli rapide ol plia rondo da redaktoj.