Únik DNS u VPN ve Windows: proč metrika poráží trasu

Dotaz opouští počítač a dorazí do domácího routeru, zatímco každý paket prochází tunelem. Přirozený závěr je chybějící trasa, a trasa bývá v pořádku. Windows může podle metriky rozhraní zvolit, na který resolver se zeptá, a tunelový adaptér v tomto srovnání často prohrává s bezdrátovým.

Dvě vysvětlení jednoho úniku

Vysvětlení přes trasy říká, že část provozu uniká z tunelu, takže výchozí trasa nebo seznam rozděleného tunelu musí být špatně. To se dá ověřit jediným příkazem, a když výchozí trasa míří do tunelu, je hotovo. Zkontrolujte ji nejdřív, protože je levná, a pak ji odložte, když se vrátí čistá.

Vysvětlení přes pořadí říká, že provoz je celý v tunelu a dotaz se přesto posílá jinému resolveru. Windows bere volbu resolveru jako vlastnost každého rozhraní s pořadím, takže fyzický adaptér s lepší metrikou může dodat DNS pro jméno, i když pakety k přeložené adrese jdou tunelem. Obě vysvětlení dávají na testovací stránce úniku stejný příznak, proto test není diagnóza. Jen jedno z nich se opravuje úpravou tras.

Porovnejte metriky a resolvery společně

Zapište rozhraní, jejich metriky a nakonfigurované servery, dokud je tunel aktivní. Čtěte je jako tabulku, ne jako dva oddělené seznamy, protože otázkou je, který resolver stojí první, ne které resolvery existují.

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

Má-li tunelový adaptér vyšší číslo než fyzický, jeho resolver není preferovaný a interní jméno půjde tam, co nabídne fyzická strana. Ten router může odpovědět z mezipaměti, dotaz přeposlat nebo ho odmítnout, a žádný z těchto výsledků není návrh, který jste zamýšleli. Pořadí je preference, takže tiše prohrává, místo aby vyhodilo chybu.

Tunelový adaptér bez jakéhokoli nakonfigurovaného resolveru je stejně častá varianta. Klient rozhraní zvedne, aniž by protlačil DNS, takže otázka pořadí vůbec nevznikne.

Posuňte tunel nahoru a zkontrolujte znovu

Dejte tunelovému rozhraní nejnižší metriku, nebo zvyšte hodnotu fyzického adaptéru ve zvýšeném shellu. Obojí je nastavení pro jednotlivé rozhraní a obojí je vratné, což je důležité, když měníte stroj, u kterého možná nesedíte.

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

Změna je vidět okamžitě a klient DNS i další konzumenti si ukládají volbu, kterou už udělali. Připojte tunel znovu nebo restartujte, než z výsledku dotazu cokoli vyvodíte. Test spuštěný příliš brzy zopakuje staré chování a bude vypadat jako neúspěšná oprava.

Pak se zeptejte na jedno interní a jedno veřejné jméno a zjistěte, který server odpověděl. Microsoftí referenční dokumentace k automatickým metrikám vysvětluje, proč je nejnižší hodnota preferovaná a jak se automatické přiřazení odvozuje.

Ať to přežije opětovné připojení

Ruční metrika na adaptéru, který se při každém připojení vytváří znovu, je nastavení, které zmizí. Pokud klient rozhraní znovu postaví, přepsání potřebuje skript po připojení, zásadu nebo konfiguraci klienta, která vlastní DNS po dobu připojení.

Staticky nakonfigurované servery na fyzickém adaptéru mají stejný problém trvanlivosti obráceně. Odpovídají za to rozhraní, dokud je neodeberete, a DHCP je znovu naplní z dalšího pronájmu, takže odebrání je měření, ne návrh. Trvanlivý návrh je zásada překladu jmen pro interní jmenný prostor, nebo klient, který převezme DNS na dobu připojení. Ať tak či tak, zapište seznam resolverů před opětovným připojením a po něm, po skončení testování obnovte původní metriku a potvrďte, že se vrátilo dřívější chování.