Špatný server DNS ve Windows VPN: metrika, pořadí vazeb nebo přípona

Klient Windows může mít funkční tunel, nést podnikový resolver a přesto posílat interní názvy do domácího routeru. Který server odpoví, rozhodují tři různé mechanismy a každý selhává jinak. Nemusíte opravovat všechny tři: symptom vám řekne, který je ve hře. Rozhodovací strom níže zabere pár minut a zabrání obvyklému výsledku, kdy změna metriky, přeřazení registru a pravidlo NRPT přistanou společně a nikdo neví, co z toho co udělalo.

Rozhodují tři mechanismy a obvykle je jeden špatný

Metrika rozhraní řadí adaptéry pro danou rodinu adres. Pořadí vazeb pod Tcpip\Linkage je seznam identifikátorů rozhraní platný pro celý stroj, který starší cesty v kódu stále čtou. Tabulka zásad překladu názvů (NRPT) váže jmenný prostor na konkrétní servery a seznam přípon rozhoduje, zda se krátký název vůbec rozšíří. Jsou nezávislé, a proto správný resolver na adaptéru VPN prohrává se zastaralou preferencí jinde.

Žádný z těchto mechanismů není druhá strana tunelu. Pokud server, který VPN protlačuje, nedokáže název přeložit, je každé nastavení na straně klienta jen dekorace, takže prvním rozhodnutím je, zda samotný resolver dokáže odpovědět, když se ho zeptáte přímo.

Rozhodnutí první: dokáže protlačený resolver vůbec odpovědět?

Zeptejte se serveru výslovně a porovnejte to s běžným dotazem. Rozdíl mezi odpověďmi odděluje problém volby od problému dostupnosti a tady je to nejrychlejší rozcestí:

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

Pokud první uspěje a druhý selže, resolver je dostupný a Windows volí špatně; přejděte k rozhodnutím o jmenném prostoru a pořadí níže. Pokud selže i první, nic na klientovi nepomůže: zkontrolujte, zda se UDP a TCP 53 dostanou tunelem na server, zda hostitelský firewall na serveru nezahazuje fond a zda jsou zdravé vlastní forwardery serveru.

Zastavte se na tomto rozcestí. Aplikace pravidla NRPT na resolver, na který nedosáhnete, vyrobí stejnou poruchu s více konfigurací k vrácení a schová skutečnou závadu za pravidlo, které vypadá autoritativně.

Rozhodnutí druhé: jeden jmenný prostor, nebo každý dotaz?

Rozsah určuje nástroj. Když selhávají jen podnikové názvy, svažte jmenný prostor místo přeřazování stroje: pravidlo NRPT pošle tuto příponu resolveru tunelu a zbytek nechá být. Když je zasažen každý dotaz, problémem je globální preference adaptérů a metrika je místo, kde začít, protože nemění žádné nastavení serveru.

Nastavte metriku pro každou rodinu adres na obou rozhraních a poté pořadí potvrďte:

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

Nahraďte 11 hodnotou ifIndex adaptéru tunelu z řádku výše; pokud je 11 adaptér LAN, stejný příkaz sníží špatnou cestu. Zvednutí adaptéru LAN dosáhne stejného pořadí z druhé strany: netsh int ip set interface interface="Ethernet" metric=15 a pro druhou rodinu netsh int ipv6 set interface interface="Ethernet" metric=15, protože int ip se dotýká jen IPv4.

Pořadí vazeb je poslední možnost, ne první krok. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage drží seznam Bind identifikátorů zařízení a přesun identifikátoru tunelu dopředu opravdu změní, který adaptér se ptá první, ale je to hodnota registru platná pro celý stroj bez rozsahu pro jednotlivé jmenné prostory. Před úpravou ji exportujte a poté tunel znovu připojte, aby pořadí platilo ve stavu, který klient očekává.

Pro jediný jmenný prostor dejte přednost užšímu nástroji:

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

Rozhodnutí třetí: přežije oprava opětovné připojení?

Metrika, která funguje do dalšího připojení vytáčenou linkou, nebyla nikdy uložena. L2TP/IPsec a další profily připojení se při startu spojení znovu vytvářejí, takže uložená hodnota žije v záznamu telefonního seznamu jako IpInterfaceMetric, ne jen na živém rozhraní. Některá prostředí ten údaj skriptují právě proto; jiná protlačí preferenci ze zásad správy a koncový bod nechají být.

Mezipaměť a registrace jsou samostatná vrstva. Spuštění těchto kroků po nahození tunelu opraví zastaralé záznamy a znovu zaregistruje klienta, ale ani jedno nepřeřadí adaptér:

ipconfig /registerdns
ipconfig /flushdns

Ve stejné vrstvě je vypínač. Vypnutí dynamické registrace na fyzickém adaptéru zabrání klientovi hlásit svou adresu na straně VPN pod špatným názvem, což je jiná oprava než obnovení výše.

IPv6 si v rozhodnutí zaslouží vlastní řádek. Pokud fyzický adaptér drží globální adresu IPv6, zatímco tunel nese jen IPv4, Windows může pro překlad názvů preferovat cestu bez tunelu. Zkontrolujte tuto rodinu zvlášť, protože metrika nastavená pro IPv4 o ní nic neříká:

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

Vypnutí IPv6 na adaptéru LAN odstraní tu cestu i protokol s ní; změna metriky na rozhraní IPv6 nebo pravidlo NRPT pro podnikový jmenný prostor rodinu zachová a preferenci opraví. Vyberte užší variantu, pokud jste nerozhodli, že ten spoj IPv6 mít nemá.

Ověřujte s pojmenovaným zdrojem a udržte jednoho vlastníka

Ověřujte nástroji, které hlásí, který zdroj je v platnosti, ne jen zda se načte stránka:

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

Pak oddělte filtrování od volby, protože z aplikace vypadají stejně. block-outside-dns v OpenVPN blokuje port 53 na ostatních adaptérech; resolver nevybírá. Pokud teď selže každý dotaz, filtr může blokovat jediný dostupný server; pokud se konfigurovaný resolver ignoruje, je špatné pořadí nebo pravidlo jmenného prostoru. Změna obojího najednou udělá z blokovaného dotazu a ignorovaného dotazu nerozlišitelné případy.

Udržte jednoho vlastníka zásad DNS: profil VPN, zásadu správy nebo pravidlo NRPT, ne dvě z nich. Než to uzavřete:

• Protlačený resolver odpovídá, když se na něj výslovně zeptáte, a běžný dotaz ho používá.
• Pravidlo nebo metrika, kterou jste změnili, pokrývá rodinu adres, která dotazy skutečně nese.
• Nastavení přežije odpojení a opětovné připojení, nebo jste ho přesunuli do uloženého profilu.
• Autoritativní je právě jeden mechanismus a ostatní zůstaly, jak byly.

Berte pořadí jako stav prostředí, ne jako věc, kterou dokončíte. Zkontrolujte ho znovu po opětovném připojení a po aktualizaci Windows, která zasáhne síťový stack, protože kterákoli z nich může fyzický adaptér vrátit dopředu.