Windows VPN DNS-lekkasje: hvorfor metrikken vinner over ruten
Windows velger navneserver ut fra metrikken til grensesnittet, ikke bare ut fra ruten. En tunneladapter som rangeres lavere enn Wi-Fi, kan lekke oppslag selv om hver pakke går i tunnelen.
Et oppslag forlater maskinen og kommer til hjemmeruteren mens hver pakke går gjennom tunnelen. Den opplagte forklaringen er at en rute mangler, men ruten er som oftest i orden. Windows kan bruke metrikken til grensesnittet for å avgjøre hvilken resolver som blir spurt, og en tunneladapter taper ofte denne kampen mot det trådløse grensesnittet.
To måter å forklare én lekkasje på
Ruteforklaringen sier at noe av trafikken går utenom tunnelen, og da må standardruten eller listen over delt tunnel være feil. Det kan etterprøves med én kommando, og når standardruten peker inn i tunnelen, er punktet avklart. Sjekk det først fordi det er billig, og legg det bort når svaret er rent.
Rangeringsforklaringen sier at trafikken går fullt ut i tunnelen og at oppslaget likevel sendes til en annen resolver. Windows ser på resolvervalget som en egenskap ved hvert grensesnitt, med en rekkefølge, så en fysisk adapter med bedre metrikk kan svare med DNS for et navn selv om pakkene til den oppslåtte adressen går gjennom tunnelen. Begge forklaringene gir samme bilde på en side som tester lekkasje, derfor er testen ikke diagnosen. Bare den ene lar seg rette ved å endre ruter.
Se metrikker og resolvere sammen
Skriv ned grensesnittene, metrikkene deres og de oppsatte navneserverne mens tunnelen er oppe. Les det som en tabell, ikke som to atskilte lister, fordi spørsmålet er hvilken resolver som kommer 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
Har tunneladapteren et høyere tall enn den fysiske adapteren, er resolveren dens ikke foretrukket, og et internt navn går til det den fysiske siden tilbyr. Ruteren kan svare fra hurtiglageret, sende oppslaget videre eller avslå det, og ingen av delene er det designet du hadde tenkt. Rangeringen er en preferanse, og derfor taper den uten å si fra.
En tunneladapter uten noen oppsatt resolver i det hele tatt er en like vanlig variant. Klienten tar opp grensesnittet uten å dytte ut DNS, så spørsmålet om rangering oppstår ikke.
Flytt tunnelen oppover og kontroller igjen
Gi tunnelgrensesnittet den laveste metrikken, eller øk verdien for den fysiske adapteren, i et shell med utvidede rettigheter. Begge er innstillinger per grensesnitt, og begge kan tilbakestilles, 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 synes umiddelbart, og DNS-klienten og andre brukere har lagret valget de allerede tok. Koble tunnelen til på nytt, eller start maskinen på nytt, før du tolker noe ut av et oppslag. En test som kjøres for tidlig, vil gjenta den gamle oppførselen og se ut som en mislykket retting.
Spør så etter ett internt og ett offentlig navn og sjekk hvilken navneserver som svarte. Microsofts referanse om automatiske metrikker forklarer hvorfor den laveste verdien foretrekkes, og hvordan den automatiske tildelingen blir utledet.
Sørg for at det holder etter en ny tilkobling
En manuell metrikk på en adapter som gjenskapes ved hver tilkobling, er en innstilling som forsvinner. Bygger klienten grensesnittet på nytt, trenger overstyringen et skript som kjører etter tilkobling, en policy eller en klientoppsett som eier DNS mens tilkoblingen varer.
Navneservere som er satt statisk på den fysiske adapteren, har det samme holdbarhetsproblemet speilvendt. De fortsetter å svare for det grensesnittet til de blir fjernet, og DHCP fyller dem ut igjen ved neste leieavtale, så å fjerne dem er en måling og ikke et design. Det holdbare designet er en policy for navneoppslag for det interne navnerommet, eller en klient som tar over DNS mens tilkoblingen varer. Uansett bør du skrive ned resolverlisten før og etter en ny tilkobling, sette tilbake den opprinnelige metrikken når du er ferdig med å teste, og bekrefte at den tidligere oppførselen er tilbake.