Windows-VPN-DNS-lek: waarom de metriek de route verslaat

Een query verlaat de machine en bereikt de thuisrouter terwijl elk pakket door de tunnel gaat. De voor de hand liggende conclusie is een ontbrekende route, en de route is meestal in orde. Windows kan op basis van de metriek van de interface kiezen welke resolver wordt bevraagd, en een tunneladapter verliest die vergelijking vaak van de draadloze.

Twee verklaringen voor één lek

De routeverklaring zegt dat een deel van het verkeer uit de tunnel ontsnapt, dus de standaardroute of de lijst voor split tunneling moet fout zijn. Die verklaring is met één opdracht te testen, en wanneer de standaardroute de tunnel in wijst, is het afgedaan. Controleer dat eerst omdat het goedkoop is, en leg het dan terzijde wanneer het schoon terugkomt.

De rangverklaring zegt dat het verkeer volledig door de tunnel gaat en de opzoeking toch naar een andere resolver wordt gestuurd. Windows behandelt de resolverkeuze als een eigenschap per interface met een volgorde, dus een fysieke adapter met een betere metriek kan DNS voor een naam leveren, ook al gaan de pakketten naar het opgeloste adres door de tunnel. Beide verklaringen geven hetzelfde symptoom op een lektestpagina, daarom is de test niet de diagnose. Slechts één ervan wordt gerepareerd door routes te bewerken.

Vergelijk metrieken en resolvers samen

Noteer de interfaces, hun metrieken en hun geconfigureerde servers terwijl de tunnel actief is. Lees ze als een tabel en niet als twee afzonderlijke lijsten, want de vraag is welke resolver eerst komt, niet welke resolvers bestaan.

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

Als de tunneladapter een hoger getal heeft dan de fysieke adapter, wordt zijn resolver niet verkozen, en een interne naam gaat naar wat de fysieke kant biedt. Die router kan uit de cache antwoorden, de query doorsturen of weigeren, en geen van die uitkomsten is het ontwerp dat je bedoelde. De rangorde is een voorkeur, dus hij verliest stil in plaats van een fout te melden.

Een tunneladapter zonder enige geconfigureerde resolver is een even gewone variant. De client brengt de interface omhoog zonder DNS te duwen, dus de rangvraag komt helemaal niet aan de orde.

Zet de tunnel hoger en controleer opnieuw

Geef de tunnelinterface de laagste metriek, of verhoog de waarde van de fysieke adapter, in een shell met verhoogde rechten. Beide zijn instellingen per interface en beide zijn omkeerbaar, wat telt wanneer je een machine wijzigt waar je misschien niet voor zit.

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

De wijziging is meteen zichtbaar, en de DNS-client en andere verbruikers cachen de keuze die ze al hebben gemaakt. Herverbind de tunnel, of herstart, voordat je iets uit een queryresultaat afleidt. Een test die te vroeg draait, herhaalt het oude gedrag en ziet eruit als een mislukte reparatie.

Vraag dan een interne en een openbare naam op en controleer welke server antwoordde. De referentie over automatische metrieken van Microsoft legt uit waarom de laagste waarde wordt verkozen en hoe de automatische toewijzing wordt afgeleid.

Maak het bestendig tegen een herverbinding

Een handmatige metriek op een adapter die bij elke verbinding opnieuw wordt gemaakt, is een instelling die verdwijnt. Als de client de interface opnieuw opbouwt, heeft de overschrijving een script na de verbinding, een beleid of een clientconfiguratie nodig die DNS bezit zolang de verbinding duurt.

Statisch geconfigureerde servers op de fysieke adapter hebben hetzelfde duurzaamheidsprobleem omgekeerd. Ze blijven voor die interface antwoorden tot ze worden verwijderd, en DHCP vult ze weer aan vanuit de volgende lease, dus ze verwijderen is een meting en geen ontwerp. Het duurzame ontwerp is een naamoplossingsbeleid voor de interne naamruimte, of een client die DNS overneemt voor de duur van de verbinding. Hoe dan ook, noteer de resolverslijst voor en na een herverbinding, herstel de oorspronkelijke metriek wanneer je klaar bent met testen, en bevestig dat het vroegere gedrag terugkeerde.