Windows VPN DNS-läcka: varför metriken slår rutten
Windows väljer resolver efter gränssnittets metrik, inte bara efter rutten. En tunneladapter som rangordnas under Wi-Fi kan läcka uppslag medan varje paket fortfarande går genom tunneln.
En fråga lämnar maskinen och når hemroutern medan varje paket tunnlas. Den näraliggande slutsatsen är en saknad rutt, och rutten är oftast i ordning. Windows kan efter gränssnittets metrik välja vilket gränssnitts resolver som tillfrågas, och en tunneladapter förlorar ofta den jämförelsen mot den trådlösa.
Två förklaringar till en läcka
Ruttförklaringen säger att en del av trafiken läcker ut ur tunneln, så standardrutten eller listan för delad tunnel måste vara fel. Den förklaringen går att testa med ett enda kommando, och när standardrutten pekar in i tunneln är saken avgjord. Kontrollera det först eftersom det är billigt, och lägg det sedan åt sidan när det kommer tillbaka rent.
Rangordningsförklaringen säger att trafiken är helt i tunneln och att uppslaget ändå skickas till en annan resolver. Windows behandlar resolvervalet som en egenskap per gränssnitt med en ordning, så en fysisk adapter med bättre metrik kan leverera DNS för ett namn även om paketen till den uppslagna adressen går genom tunneln. Båda förklaringarna ger samma symptom på en läcktestsida, därför är testet inte diagnosen. Bara en av dem repareras genom att redigera rutter.
Jämför metriker och resolvers tillsammans
Notera gränssnitten, deras metriker och de konfigurerade servrarna medan tunneln är uppe. Läs dem som en tabell och inte som två separata listor, eftersom frågan är vilken resolver som kommer först, inte vilka resolvers som finns.
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses
Om tunneladaptern har ett högre nummer än den fysiska adaptern är dess resolver inte prioriterad, och ett internt namn går till det den fysiska sidan erbjuder. Den routern kan svara från cachen, vidarebefordra frågan eller avvisa den, och ingen av de utfallen är den design du hade tänkt dig. Rangordningen är en preferens, så den förlorar i tysthet i stället för att resa ett fel.
En tunneladapter helt utan konfigurerad resolver är en lika vanlig variant. Klienten tar upp gränssnittet utan att skjuta ut DNS, så rangfrågan uppstår inte ens.
Rangordna tunneln högre och kontrollera igen
Ge tunnelgränssnittet den lägsta metriken, eller höj värdet för den fysiska adaptern, i ett skal med förhöjda rättigheter. Båda är inställningar per gränssnitt och båda går att återställa, vilket spelar roll när du ändrar en maskin du kanske inte sitter framför.
Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric
Ändringen syns direkt, och DNS-klienten och andra konsumenter cachar det val de redan gjort. Anslut tunneln igen, eller starta om, innan du läser in något i ett uppslagsresultat. Ett test som körs för tidigt upprepar det gamla beteendet och ser ut som en misslyckad åtgärd.
Fråga sedan efter ett internt och ett offentligt namn och kontrollera vilken server som svarade. Microsofts referens om automatiska metriker förklarar varför det lägsta värdet föredras och hur den automatiska tilldelningen härleds.
Gör det hållbart över en återanslutning
En manuell metrik på en adapter som återskapas vid varje anslutning är en inställning som försvinner. Om klienten bygger upp gränssnittet igen behöver överstyrningen ett skript efter anslutningen, en policy eller en klientkonfiguration som äger DNS medan anslutningen varar.
Statiskt konfigurerade servrar på den fysiska adaptern har samma hållbarhetsproblem omvänt. De fortsätter att svara för det gränssnittet tills de tas bort, och DHCP fyller dem igen från nästa lease, så att ta bort dem är en mätning och inte en design. Den hållbara designen är en namnupplösningspolicy för det interna namnrummet, eller en klient som tar över DNS under anslutningens gång. Notera i vilket fall resolverlistan före och efter en återanslutning, återställ den ursprungliga metriken när du är klar med testandet, och bekräfta att det tidigare beteendet kom tillbaka.