Waarom Windows je VPN-namen naar een DNS-server stuurt die je nooit hebt ingesteld

Je stelt de DNS-server in op de VPN-adapter, maakt opnieuw verbinding, en de privénaam komt nog steeds van de kantoorresolver die niemand op deze laptop heeft geconfigureerd. Het resultaat ziet eruit alsof de instelling genegeerd is, en in zekere zin was dat ook zo, want de adapterlijst is een verzameling kandidaten en geen beslissing. Windows lost namen op via een naamruimtebeleid dat voor een bepaald achtervoegsel een andere server kan aanwijzen, en dat beleid wordt toegepast voordat de adapterinstelling wordt bekeken. De regel vinden die gewonnen heeft is een werk van vijf minuten als je weet welke tabel je moet lezen.

Wat je hebt gewijzigd, en wat werkelijk beslist

Het DNS-adres op een adapter vertelt de client waar die interface zoekopdrachten zou kunnen versturen. De Name Resolution Policy Table vertelt de client waar hij zoekopdrachten voor een bepaalde naamruimte moet versturen, en die wordt per naam beoordeeld, niet per adapter. Als een regel bij het achtervoegsel past dat je hebt getypt, worden de servers van die regel gebruikt en doet de adapterlijst er voor die opzoeking niet meer toe.

Daarom kunnen twee namen op dezelfde laptop op hetzelfde moment verschillende paden volgen. Een host onder het bedrijfsachtervoegsel volgt zijn regel; een openbare naam volgt het standaardpad, wat meestal de adapter betekent die het eerst antwoordt.

Hoe de tabel een naam koppelt

Regels zijn gesleuteld op naamruimte, en de meest specifieke overeenkomst wint. Een regel voor corp.example geldt voor vpn.corp.example en geldt niet voor example.net. Een regel met de naamruimte . dekt alles wat de andere regels niet dekken, wat hem de gevaarlijkste vermelding op de lijst maakt en degene die het controleren waard is wanneer een ongerelateerde site via de tunnel wordt opgelost.

Een regel kan ook een opmerking dragen, een beleid dat de vermelding uitschakelt, en beveiligingsinstellingen die niets met DNS-adressen te maken hebben. Een uitgeschakelde regel blijft zichtbaar in de configuratie zonder effect, dus een vermelding die op papier juist lijkt kan na een profielwijziging nog steeds werkeloos zijn.

Lees de werkende tabel, niet de verlanglijst

Geconfigureerde regels en werkende regels zijn twee verschillende vragen. Get-DnsClientNrptRule somt op wat er op de machine staat. Get-DnsClientNrptPolicy -Effective toont wat de client werkelijk gaat toepassen, met de waarden samengevoegd uit beleid en lokale instellingen.

Vergelijk het achtervoegsel in die uitvoer teken voor teken met de naam die je test. Een regel voor corp.example vangt geen naam die op corp.example.com eindigt, en een punt aan het eind op de ene plek en niet op de andere is genoeg om de overeenkomst te veranderen.

Zonder regel vraagt Windows meer dan één adapter

Als niets in de tabel de naam opeist, kan de client de zoekopdracht via meerdere interfaces versturen en het eerste antwoord nemen dat aankomt. Het resultaat hangt van de timing af: dezelfde naam kan op maandag via de bekabelde adapter en op dinsdag via de tunnel worden opgelost, en niets in de configuratie van beide adapters verklaart het verschil.

Er zijn twee uitwegen. Voeg een regel voor de naamruimte toe zodat de beslissing geen wedloop meer is, of schakel het parallelle gedrag uit via het DNS-clientbeleid en accepteer de langzamere, deterministische resolutie. De eerste past meestal beter bij een VPN met gesplitste tunnel, omdat die de bedoeling documenteert in plaats van op volgorde te vertrouwen.

Paden die de resolver volledig overslaan

Een browser met beveiligde DNS aan lost zelf op en geeft Windows alleen het adres, zodat de regeltabel de naam nooit ziet. Clients die op runtime-omgevingen met een eigen resolver zijn gebouwd, kunnen zich hetzelfde gedragen. Als een naam in de ene toepassing wel wordt opgelost en in een andere op dezelfde machine niet, vergelijk dan de twee oplospaden voordat je het beleid aanraakt.

Controleer ook of de app verbinding maakt met een gecachet adres uit een eerdere sessie. Clear-DnsClientCache en dan dezelfde opzoeking geeft een schoner antwoord dan afleiden uit een verouderd resultaat.

Test met de naam die faalde

Los de exacte hostnaam uit het rapport op, niet een openbaar snelheidstestdomein, en noteer welke server antwoordde. Wijzig daarna één ding: de regel, de adapterlijst of de beleidstoewijzing, en herhaal dezelfde opzoeking na opnieuw verbinden zodat de toegepaste toestand opnieuw wordt opgebouwd.

Als de naam wordt opgelost en de dienst weigert nog steeds, stop dan met DNS bewerken. De volgende nuttige stap is het adres en de route erheen, want naamresolutie heeft zijn werk al gedaan.