Heeft de VPN mijn DNS gewijzigd? Vergelijk voor en na

U verbindt de tunnel, opent een privédashboard en de naam wordt omgezet naar een adres dat u nooit eerder hebt gezien. Of het omgekeerde gebeurt: de browser blijft werken terwijl een opdrachtregelprogramma plotseling niets meer omzet. Beide uitkomsten komen van dezelfde wijziging, en mensen leggen het meestal uit met één zin over de VPN die „zijn eigen DNS gebruikt”, wat niet precies genoeg is om te debuggen of te verifiëren. In die zin zitten twee vragen verborgen: welke opzoekingen moet dit profiel overnemen, en heeft uw machine ze werkelijk naar de resolver gestuurd die ze kreeg? Ze gescheiden houden is de hele methode, want een test die ze mengt, geeft in beide richtingen een zelfverzekerd fout antwoord.

Waarom een profiel überhaupt een resolver levert

Binnen een tunnel worden namen achter het verre uiteinde meestal omgezet naar adressen die alleen in dat netwerk bestaan. Een privézone zoals corp.internal heeft geen openbare delegatie, dus de resolver die erop antwoordt, moet van binnen de tunnel bereikbaar zijn. Hetzelfde mechanisme dient een tweede doel: wanneer opzoekingen anders via uw provider naar buiten zouden gaan, houdt een resolver aan de verre kant de query binnen het versleutelde pad. Daarom komt het DNS-serveradres als deel van het verbindingsbeleid en niet als een globale instelling die u één keer voor de machine koos.

Het adres alleen beslist niets. Een resolver kan alleen antwoorden als er een route naartoe is, en de meest voorkomende fout is een resolver die alleen bereikbaar is zolang de tunnel staat. Wanneer de tunnel valt en het beleid blijft, gaan opzoekingen naar een adres zonder pad, en het symptoom is een time-out in plaats van een schone fout. Dat verschil is belangrijk wanneer u het volgende testresultaat leest, want een time-out stuurt mensen naar transportinstellingen die nooit betrokken waren.

Vergelijk de twee ontwerpen voordat u antwoorden vergelijkt

Volledige tunnel en gesplitste DNS geven tegengestelde verwachtingen, en geen van beide is een storing. Onder een volledige tunnel kan elke opzoeking naar de provider of naar de bedrijfsresolver gaan, dus dat openbare namen na het verbinden anders antwoorden, is te verwachten. Onder gesplitste DNS gaan alleen de vermelde domeinen naar de privéresolver terwijl al het andere lokaal blijft; op Windows leeft de domeinlijst in de Name Resolution Policy Table, op macOS in de overeenkomende domeinen van de DNS-instellingen, en op een systemd-resolved-host in de routeringsdomeinen per verbinding.

Dat is de vergelijking die eerst moet worden gemaakt, want die bepaalt wat als een fout telt. Bij gesplitste DNS is een openbare naam die van een nieuwe resolver antwoordt, hetgeen onderzoek verdient, terwijl een interne naam die correct antwoordt, het systeem is dat zijn werk doet. Bij een volledige tunnel is de anomalie een openbare naam die nog steeds van de resolver van uw provider antwoordt. De documentatie van Microsoft over VPN-naamresolutie beschrijft de Windows-volgorde van deze regels, inclusief hoe een overeenkomend beleidsitem wordt geraadpleegd vóór de eigen servers van de adapter.

Er is een derde resolver in de kamer die gemakkelijk wordt vergeten. De beveiligde DNS van de browser zet namen zelf om en kan blijven antwoorden nadat de tunnel het beleid van het besturingssysteem heeft gewijzigd, dus een pagina die laadt, bewijst dat de resolver van de browser werkte, niet dat het profiel is toegepast. Als u alleen vergelijkt wat de browser toont, test u de helft van de tijd de verkeerde laag.

Leg een basislijn vast met slechts één variabele

Wijzig de tunnel. Wijzig niet tegelijk de naam, het hulpmiddel of het zoekachtervoegsel in dezelfde stap. Kies een naam die u mag opvragen, noteer welke toepassing u gebruikte, en schrijf ofwel het adres dat terugkwam ofwel de exacte fout op. Op Windows drukt Get-DnsClientServerAddress -AddressFamily IPv4 de servers per adapter af en Get-DnsClientNrptPolicy de beleidsvermeldingen; op Linux met systemd-resolved toont resolvectl status de DNS-servers en routeringsdomeinen per verbinding; op macOS drukt scutil --dns de resolvervolgorde af die het systeem werkelijk volgt.

Verbind daarna via de normale bediening van de client en herhaal precies dezelfde opdrachten. Bewaar de eerste uitvoer in plaats van een herinnering eraan, want de vergelijking is het hele punt en een tweede lezing na het legen van de cache is al een andere meting. Als de basislijn is genomen met de browser op de voorgrond en de run na het verbinden in een terminal gebeurt, vergelijkt u twee resolvers, niet twee toestanden van één resolver.

Een expliciete query en een toepassingsopzoeking zijn verschillende tests

Eén bepaalde server vragen, met nslookup name 10.20.0.1 of dig @10.20.0.1 name, bewijst één ding: dat de server die u noemde antwoordt wanneer u hem kunt bereiken. Het omzeilt de selectielogica volledig, dus het kan niet zeggen of het systeem die server voor deze naam zou hebben gekozen. Gebruik het om te testen of de toegewezen resolver bereikbaar is, en gebruik het niet om beleid te testen.

Een opzoeking via de lokale resolver oefent wel selectie uit. resolvectl query name doorloopt dezelfde routeringsdomeinregels en meldt welk protocol antwoordde, Resolve-DnsName op Windows gaat via de beleidstabel en de cache van de client, en scutil --dns toont de volgorde die een opzoeking zou volgen. Voer beide soorten uit en houd ze in aparte kolommen van uw notities. Een geslaagde expliciete query naast een mislukte toepassingsopzoeking is een routerings- of selectieprobleem, geen resolver die weigert te werken.

De cache staat tussen u en het antwoord. Het besturingssysteem, de lokale stub-resolver, de browser en negatieve caching houden allemaal resultaten vast, dus een opzoeking kan slagen zonder dat één pakket de machine verlaat. Noteer het resultaat voordat u iets leegt: ipconfig /flushdns, resolvectl flush-caches of sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder op macOS. Sla de brede netwerkreset in deze fase over, want die vernietigt het bewijs dat u nog verzamelt.

Wat het verschil betekent

Vergelijk de twee vastgelegde rijen en classificeer de wijziging voordat u één instelling aanraakt.

Eén rij verdient nadruk. Een naam die wordt omgezet is geen dienst die werkt, en DNS-succes zegt alleen dat er een adres is gevonden. Het zegt niets over doorsturen, firewallregels of uw account de dienst überhaupt mag gebruiken, dus eindig met het testen van de werkelijke toepassing in plaats van aan te nemen dat de fout vanzelf is weggetrokken.

Herstel de basislijn en verifieer die

Verbreek de verbinding via de eigen bediening van de client in plaats van het proces te doden, en lees daarna dezelfde drie opdrachten opnieuw. De servers per verbinding, de beleidsvermeldingen en het antwoord voor uw testnaam moeten terugkeren naar de basislijn die u eerder opschreef. Een achtergebleven beleidsvermelding na een schone verbreking is een echt defect dat het noteren waard is, en daarom zijn handmatige bewerkingen van een gegenereerd resolverbestand een slechte gewoonte: het bestand wordt herschreven en de bewerking verdwijnt, of de bewerking overleeft en pint een resolver vast die geen route meer heeft.

Doorloop deze lijst één keer, in volgorde. Bepaal welk ontwerp het profiel implementeert voordat u een resultaat beoordeelt. Houd naam, hulpmiddel en achtervoegsel vast in beide runs. Scheid de expliciete query van de toepassingsopzoeking. Lees het effectieve beleid, niet alleen het antwoord. Leeg de caches als laatste, nadat de vergelijking is opgeschreven. Verifieer met de echte toepassing, herstart dan één keer en bevestig dat de verbroken toestand nog steeds schoon is.