VPN verbonden maar namen falen: waar DNS echt breekt

Tunnel staat, pictogram groen, en elk browsertabblad meldt een fout bij naamresolutie. Drie verschillende mechanismen veroorzaken dat beeld: de resolver is mogelijk onbereikbaar, de client vraagt misschien een resolver die u niet verwachtte, of alleen de privénamen falen. Scheid ze voordat u iets aan het tunnelprotocol verandert, want elk wordt op een andere plek gerepareerd. De volgorde hieronder begint met de observaties die de drie scheiden.

Wat een opzoeking echt nodig heeft

Een opzoeking heeft drie dingen nodig: een resolveradres, een route naar dat adres en een antwoord dat bij de vraag past. Elk kan op zichzelf falen, en het zichtbare symptoom is dezelfde pagina die niet laadt. Daarom vertelt de foutpagina u bijna niets tot u weet welke van de drie is gebroken.

De client leert zijn resolver uit het VPN-profiel, uit DHCP op de tunnel of uit zijn eigen configuratie, en welke bron wint hangt van het platform af. Op Windows toont ipconfig /all de DNS-servers per adapter, zodat u ziet of de gepushte waarde echt is aangekomen. Een gepushte waarde die het besturingssysteem nooit bereikte, is een stille en veelvoorkomende fout. Lees de geconfigureerde waarde voordat u het profiel aanraakt.

Linux en macOS beantwoorden dezelfde vraag met andere commando's, en het antwoord verdient dezelfde lezing: resolvectl status en scutil --dns beide tonen de servers per interface. Vergelijk die lijst met het adres dat het profiel zegt te pushen. Een afwijking hier verklaart alles stroomafwaarts, dus los die op voordat u namen test.

Test één openbare en één privénaam

Bevraag een gewone openbare hostnaam en de gedocumenteerde privé-hostnaam vanaf dezelfde machine, en noteer welke server op elk antwoordde. Als beide falen, is de resolver of zijn route stuk. Als alleen de privénaam faalt, heeft de resolver geantwoord en wordt de vraag de zone of de routing. Voer de twee zoekopdrachten binnen een minuut na elkaar uit, zodat een routewijziging het verschil niet kan verklaren.

Houd interne namen buiten openbare schermafbeeldingen en buiten openbare resolvers. Een timeout en een antwoord over een niet-bestaand domein zijn verschillende observaties: de eerste zegt dat er niets terugkwam, de tweede dat een autoriteit antwoordde dat de naam niet bestaat. Ze als één fout behandelen brengt u naar de verkeerde laag, en een certificaatwaarschuwing is weer iets anders, geen DNS-fout.

nslookup toont zowel de server die het vroeg als het antwoord dat het ontving, en dat is precies het paar dat u nodig hebt. Voer het twee keer uit in dezelfde shell en schrijf het antwoordende adres naast elk antwoord.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Controleer of de client die server echt kan bereiken

Een privé-resolver die het profiel pusht is alleen nuttig als de client hem kan bereiken terwijl de tunnel staat. Een adres dat er correct uitziet zonder route levert een timeout op, en de verbonden status van de tunnel zegt niets over die route. De controle is een routeopzoeking gericht op de resolver zelf, niet op het VPN-eindpunt.

Elk platform beantwoordt dat in één regel, en de interface die in de uitvoer wordt genoemd is het hele antwoord. Wijst die naar de fysieke adapter terwijl de resolver achter de tunnel zit, dan pusht het profiel geen prefix die hem dekt.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Bij een split-tunnelprofiel kan de resolver buiten de gepushte routes liggen, wat een profielprobleem is en geen serverprobleem. Vergelijk het resolveradres met de gepushte prefixen en bevestig dat een ervan hem dekt. Dezelfde afwijking verklaart waarom DNS op het ene netwerk werkt en op een ander met een identiek profiel faalt.

Onthoud dat browsers de systeemresolver kunnen omzeilen

Een browser met beveiligde DNS aan kan zoekopdrachten via HTTPS naar een provider van eigen keuze sturen en de resolver van het besturingssysteem volledig negeren. Dan lijkt het systeem correct terwijl de browser faalt, of omgekeerd. Dat is een beleidsvraag voor de browser, niet voor de tunnel.

Controleer de beveiligde-DNS-instelling van de browser en elk beheerd beleid dat die bestuurt, en probeer daarna een tweede applicatie of browser met de tunnel ongewijzigd. Als slechts één applicatie faalt, hoort de correctie in die applicatie. Een privévenster is geen schone vergelijking, omdat het in de ene browser standaard extensies kan uitschakelen en in de andere niet, en het omzeilt nooit een beheerd beleid. Gebruik in plaats daarvan een tweede browserprofiel of een andere applicatie.

Leeg de cache en test de echte taak opnieuw

Nadat u een instelling hebt gecorrigeerd, leegt u de lokale resolvercache zodat een oud antwoord de correctie niet overleeft. Een korte hersteldperiode gevolgd door opnieuw falen betekent dat de oorzaak er nog is, niet dat het legen mislukte. Kies de regel die bij de machine past waarop u zit, want de drie caches zijn gescheiden.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Herhaal daarna de oorspronkelijke taak in plaats van een synthetische opzoeking, want de taak is wat de gebruiker interesseert. Maak ook één keer opnieuw verbinding, zodat de hertest de toestand dekt waarin de gebruiker werkelijk zal zijn. De nslookup-referentie van Microsoft is de pagina die u wilt bewaren voor de argumenten van de opzoeking.

Als namen pas na het verbreken falen, heeft de client de vorige configuratie niet hersteld, wat een lifecyclefout is om te melden, niet een DNS-server om te vervangen. Een werkende opzoeking is ook geen lektest, want het uitgangsland zegt niets over welke resolver antwoordde.