Únik DNS pri VPN vo Windows: prečo metrika poráža trasu

Dopyt opúšťa počítač a dorazí do domáceho routera, pričom každý paket prechádza tunelom. Prirodzený záver je chýbajúca trasa, a trasa býva v poriadku. Windows môže podľa metriky rozhrania vybrať, ktorý resolver sa opýta, a tunelový adaptér v tomto porovnaní často prehráva s bezdrôtovým.

Dve vysvetlenia jedného úniku

Vysvetlenie cez trasy hovorí, že časť prevádzky uniká z tunela, takže predvolená trasa alebo zoznam rozdeleného tunela musia byť nesprávne. To sa dá overiť jediným príkazom, a keď predvolená trasa ukazuje do tunela, je hotovo. Skontrolujte ju najprv, lebo je lacná, a potom ju odložte, keď sa vráti čistá.

Vysvetlenie cez poradie hovorí, že prevádzka je celá v tuneli a dopyt sa napriek tomu posiela inému resolveru. Windows berie voľbu resolvera ako vlastnosť každého rozhrania s poradím, takže fyzický adaptér s lepšou metrikou môže dodať DNS pre meno, aj keď pakety k preloženej adrese idú tunelom. Obe vysvetlenia dávajú na testovacej stránke úniku rovnaký príznak, preto test nie je diagnóza. Len jedno z nich sa opravuje úpravou trás.

Porovnajte metriky a resolvery spoločne

Zapíšte rozhrania, ich metriky a nakonfigurované servery, kým je tunel aktívny. Čítajte ich ako tabuľku a nie ako dva oddelené zoznamy, pretože otázkou je, ktorý resolver je prvý, nie ktoré resolvery existujú.

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

Ak má tunelový adaptér vyššie číslo než fyzický, jeho resolver nie je preferovaný a interné meno pôjde tam, čo ponúka fyzická strana. Ten router môže odpovedať z pamäte, dopyt poslať ďalej alebo ho odmietnuť, a žiadny z tých výsledkov nie je návrh, ktorý ste zamýšľali. Poradie je preferencia, takže ticho prehráva, namiesto toho aby vyhodilo chybu.

Tunelový adaptér bez akéhokoľvek nakonfigurovaného resolvera je rovnako častá varianta. Klient zdvihne rozhranie bez pretlačenia DNS, takže otázka poradia vôbec nevznikne.

Posuňte tunel nahor a skontrolujte znova

Dajte tunelovému rozhraniu najnižšiu metriku, alebo zvýšte hodnotu fyzického adaptéra v prostredí so zvýšenými právami. Oboje sú nastavenia pre jednotlivé rozhranie a oboje je vratné, čo je dôležité, keď meníte stroj, pri ktorom možno nesedíte.

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

Zmena je viditeľná okamžite a klient DNS aj ďalší konzumenti si ukladajú voľbu, ktorú už urobili. Pripojte tunel znova alebo reštartujte, skôr než z výsledku dopytu niečo vyvodíte. Test spustený príliš skoro zopakuje staré správanie a bude vyzerať ako neúspešná oprava.

Potom sa opýtajte na jedno interné a jedno verejné meno a zistite, ktorý server odpovedal. referencia o automatických metrikách od Microsoftu vysvetľuje, prečo je preferovaná najnižšia hodnota a ako sa odvodzuje automatické priradenie.

Urobte to odolné voči opätovnému pripojeniu

Ručná metrika na adaptéri, ktorý sa pri každom pripojení vytvára znova, je nastavenie, ktoré zmizne. Ak klient rozhranie znovu postaví, prepísanie potrebuje skript po pripojení, pravidlo alebo konfiguráciu klienta, ktorá vlastní DNS počas pripojenia.

Staticky nakonfigurované servery na fyzickom adaptéri majú ten istý problém trvanlivosti opačne. Odpovedajú za to rozhranie, kým ich neodstránite, a DHCP ich znova naplní z ďalšieho prenájmu, takže ich odstránenie je meranie a nie návrh. Trvanlivý návrh je pravidlo prekladu mien pre interný menný priestor, alebo klient, ktorý prevezme DNS na čas pripojenia. Tak či tak, zapíšte zoznam resolverov pred opätovným pripojením a po ňom, po skončení testovania obnovte pôvodnú metriku a potvrďte, že sa vrátilo predchádzajúce správanie.