Windows VPN-DNS-lekkasje: hvorfor metrikken slår ruten

Et oppslag forlater maskinen og når hjemmeruteren mens hver pakke tunneleres. Den nærliggende konklusjonen er en manglende rute, og ruten er som regel i orden. Windows kan velge hvilket grensesnitt sin resolver som spørres, ut fra grensesnittmetrikken, og en tunneladapter taper ofte denne sammenligningen mot den trådløse.

To forklaringer på én lekkasje

Ruteforklaringen sier at noe av trafikken slipper ut av tunnelen, så standardruten eller split-tunnel-listen må være feil. Den forklaringen kan testes med én kommando, og når standardruten peker inn i tunnelen, er saken avgjort. Sjekk den først fordi den er billig, og legg den så til side når den kommer tilbake ren.

Rangforklaringen sier at trafikken er fullt tunnellert og at oppslaget likevel sendes til en annen resolver. Windows behandler resolvervalget som en egenskap per grensesnitt med en rekkefølge, så en fysisk adapter med bedre metrikk kan levere DNS for et navn selv om pakkene til den oppslåtte adressen går gjennom tunnelen. Begge forklaringene gir samme symptom på en lekktestside, derfor er testen ikke diagnosen. Bare én av dem repareres ved å redigere ruter.

Sammenlign metrikker og resolvere samlet

Noter grensesnittene, metrikkene deres og de konfigurerte serverne mens tunnelen er oppe. Les dem som en tabell og ikke som to separate lister, fordi spørsmålet er hvilken resolver som rangerer først, ikke hvilke resolvere som finnes.

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

Hvis tunneladapteren har et høyere tall enn den fysiske adapteren, er resolveren ikke foretrukket, og et internt navn går til det den fysiske siden tilbyr. Den ruteren kan svare fra hurtigbufferen, videresende oppslaget eller avvise det, og ingen av disse utfallene er designet du hadde tenkt deg. Rangeringen er en preferanse, så den taper i stillhet i stedet for å reise en feil.

En tunneladapter helt uten konfigurert resolver er en like vanlig variant. Klienten reiser grensesnittet uten å skyve DNS, så rangspørsmålet oppstår ikke engang.

Ranger tunnelen høyere og sjekk på nytt

Gi tunnelgrensesnittet den laveste metrikken, eller øk verdien til den fysiske adapteren, i et shell med forhøyede rettigheter. Begge er innstillinger per grensesnitt, og begge kan rulles tilbake, noe som betyr noe når du endrer en maskin du kanskje ikke sitter foran.

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

Endringen vises med en gang, og DNS-klienten og andre forbrukere bufrer valget de allerede har tatt. Koble tunnelen til på nytt, eller start på nytt, før du leser noe inn i et oppslagsresultat. En test som kjøres for tidlig, vil gjenta den gamle atferden og se ut som en mislykket retting.

Spør så om ett internt og ett offentlig navn og sjekk hvilken server som svarte. Microsofts referanse om automatiske metrikker forklarer hvorfor den laveste verdien foretrekkes og hvordan den automatiske tildelingen utledes.

Gjør det holdbart over en gjenoppkobling

En manuell metrikk på en adapter som gjenopprettes ved hver tilkobling, er en innstilling som forsvinner. Hvis klienten bygger grensesnittet på nytt, trenger overstyringen et skript etter tilkobling, en policy eller en klientkonfigurasjon som eier DNS mens tilkoblingen varer.

Statisk konfigurerte servere på den fysiske adapteren har det samme holdbarhetsproblemet omvendt. De fortsetter å svare for det grensesnittet til de fjernes, og DHCP vil fylle dem på nytt fra neste leie, så å fjerne dem er en måling og ikke et design. Det holdbare designet er en navneoppløsningspolicy for det interne navnerommet, eller en klient som tar over DNS så lenge tilkoblingen varer. Uansett bør du notere resolverlisten før og etter en gjenoppkobling, gjenopprette den opprinnelige metrikken når du er ferdig med å teste, og bekrefte at den tidligere atferden er tilbake.