Pogrešan DNS server u Windows VPN-u: metrika, redoslijed povezivanja ili sufiks

Windows klijent može imati tunel koji radi, nositi korporativni resolver i ipak slati interna imena na kućni ruter. Tri različita mehanizma odlučuju koji server odgovara, i oni padaju na različite načine. Ne morate popraviti sva tri: simptom vam kaže koji je u igri. Stablo odlučivanja ispod traje nekoliko minuta i sprječava uobičajeni ishod, gdje promjena metrike, preslaganje registra i NRPT pravilo stignu zajedno i niko ne zna šta je od toga šta uradilo.

Tri mehanizma odlučuju, a obično je jedan pogrešan

Metrika interfejsa poreda adaptere za datu familiju adresa. Redoslijed povezivanja pod Tcpip\Linkage je lista identifikatora interfejsa na nivou mašine koju stariji kodni putevi još konsultuju. Tabela politike razrješavanja imena (NRPT) veže imenski prostor za određene servere, a lista sufiksa odlučuje da li se kratko ime uopće proširuje. Nezavisni su, i zato ispravan resolver na VPN adapteru gubi od zastarjele preferencije negdje drugdje.

Nijedan od ovih mehanizama nije ona strana tunela. Ako server koji VPN gura ne može razriješiti ime, svaka postavka na strani klijenta je samo ukras, pa je prva odluka može li sam resolver odgovoriti kada ga pitate direktno.

Odluka prva: može li gurnuti resolver uopće odgovoriti?

Pitajte server eksplicitno i uporedite to s običnom pretragom. Razlika između odgovora razdvaja problem izbora od problema dostupnosti, i ovdje je najbrže račvanje:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Ako prvi uspije a drugi ne, resolver je dostupan i Windows bira loše; prijeđite na odluke o imenskom prostoru i redoslijedu ispod. Ako i prvi ne uspije, ništa na klijentu neće pomoći: provjerite da UDP i TCP 53 stignu do servera kroz tunel, da host firewall na serveru ne odbacuje pool i da su vlastiti prosljeđivači servera zdravi.

Zaustavite se na ovom račvanju. Primjena NRPT pravila na resolver do kojeg ne možete doći daje istu grešku s više konfiguracije za vraćanje i skriva pravi kvar iza pravila koje izgleda autoritativno.

Odluka druga: jedan imenski prostor ili svaki upit?

Obim određuje alat. Kada padaju samo korporativna imena, vežite imenski prostor umjesto preslaganja mašine: NRPT pravilo šalje taj sufiks resolveru tunela i ostavlja sve ostalo na miru. Kada je pogođena svaka pretraga, problem je globalna preferencija adaptera, a metrika je mjesto za početak jer ne mijenja nijednu postavku servera.

Postavite metriku po familiji adresa, na oba interfejsa, i zatim potvrdite redoslijed:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Zamijenite 11 sa ifIndex adaptera tunela iz reda iznad; ako je 11 LAN adapter, ista komanda spušta pogrešan put. Podizanje LAN adaptera postiže isti redoslijed s druge strane: netsh int ip set interface interface="Ethernet" metric=15, i netsh int ipv6 set interface interface="Ethernet" metric=15 za drugu familiju, jer int ip dira samo IPv4.

Redoslijed povezivanja je posljednje sredstvo, a ne prvi potez. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage drži Bind listu identifikatora uređaja, i premještanje identifikatora tunela naprijed zaista mijenja koji se adapter pita prvi, ali to je vrijednost registra na nivou mašine bez obima po imenskom prostoru. Izvezite je prije uređivanja i zatim ponovo povežite tunel da bi redoslijed važio u stanju koje klijent očekuje.

Za jedan imenski prostor dajte prednost užem instrumentu:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Odluka treća: preživljava li popravka ponovno povezivanje?

Metrika koja radi do sljedećeg ponovnog povezivanja dial-up vezom nikada nije bila sačuvana. L2TP/IPsec i drugi profili veze se ponovo stvaraju kada veza počne, pa sačuvana vrijednost živi u unosu telefonskog imenika kao IpInterfaceMetric, a ne samo na živom interfejsu. Neka okruženja skriptuju to polje upravo zbog toga; druga guraju preferenciju iz politike upravljanja i ostavljaju krajnju tačku na miru.

Keš i registracija su odvojen sloj. Pokretanje ovoga nakon što tunel podigne popravlja zastarjele unose i ponovo registruje klijenta, ali nijedno od toga ne preslaže adapter:

ipconfig /registerdns
ipconfig /flushdns

U istom sloju postoji prekidač. Isključivanje dinamičke registracije na fizičkom adapteru sprječava klijenta da oglašava svoju adresu s VPN strane pod pogrešnim imenom, što je druga popravka od osvježavanja iznad.

IPv6 zaslužuje svoj red u odluci. Ako fizički adapter ima globalnu IPv6 adresu dok tunel nosi samo IPv4, Windows može preferirati put bez tunela za razrješavanje imena. Provjerite tu familiju odvojeno, jer metrika postavljena za IPv4 ne govori ništa o njoj:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

Isključivanje IPv6 na LAN adapteru uklanja taj put i protokol s njim; promjena metrike na IPv6 interfejsu ili NRPT pravilo za korporativni imenski prostor zadržava familiju i popravlja preferenciju. Odaberite uže rješenje osim ako niste odlučili da ta veza ne treba imati IPv6.

Provjeravajte s navedenim izvorom i držite jednog vlasnika

Provjeravajte alatima koji izvještavaju koji je izvor na snazi, a ne samo da li se stranica učitava:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Zatim razdvojite filtriranje od izbora, jer iz aplikacije izgledaju identično. block-outside-dns u OpenVPN blokira port 53 na drugim adapterima; ne bira resolver. Ako sada svaki upit pada, filter možda blokira jedini dostupni server; ako se konfigurisani resolver ignorira, redoslijed ili pravilo imenskog prostora je pogrešno. Mijenjanje obojeg odjednom čini blokirani upit i ignorisani upit nerazlučivim.

Držite jednog vlasnika DNS politike: VPN profil, politiku upravljanja ili NRPT pravilo, ne dva od toga. Prije nego što to zatvorite:

• Gurnuti resolver odgovara kada se imenuje eksplicitno, a obična pretraga ga koristi.
• Pravilo ili metrika koju ste promijenili pokriva familiju adresa koja zaista nosi upite.
• Postavka preživljava prekid i ponovno povezivanje, ili ste je premjestili u sačuvani profil.
• Tačno jedan mehanizam je autoritativan, a ostali su ostavljeni kakvi su bili.

Tretirajte redoslijed kao stanje okruženja, a ne kao stvar koju završavate. Provjerite ga ponovo nakon ponovnog povezivanja i nakon Windows ažuriranja koje dira mrežni stog, jer svako od toga može vratiti fizički adapter naprijed.