VPN forbundet, men navne fejler: hvor DNS reelt bryder sammen

Tunnelen er oppe, ikonet grønt, og hver browserfane rapporterer en navneopløsningsfejl. Tre forskellige mekanismer skaber det billede: resolveren kan være utilgængelig, klienten kan spørge en resolver, du ikke forventede, eller kun de private navne kan fejle. Skil dem ad, før du ændrer noget ved tunnelprotokollen, for hver af dem repareres et andet sted. Rækkefølgen nedenfor begynder med de observationer, der skiller de tre ad.

Hvad et opslag egentlig kræver

Et opslag kræver tre ting: en resolveradresse, en rute til den adresse og et svar, der passer til spørgsmålet. Hver af dem kan fejle alene, og det synlige symptom er den samme side, der ikke indlæses. Derfor fortæller fejlsiden dig næsten intet, før du ved, hvilken af de tre der er brudt.

Klienten lærer sin resolver fra VPN-profilen, fra DHCP på tunnelen eller fra sin egen konfiguration, og hvilken kilde der vinder, afhænger af platformen. På Windows viser ipconfig /all DNS-serverne for hver adapter, så du kan se, om den udstukne værdi faktisk nåede frem. En udstukket værdi, der aldrig nåede operativsystemet, er en stille og almindelig fejl. Læs den konfigurerede værdi, før du rører profilen.

Linux og macOS svarer på det samme spørgsmål med forskellige kommandoer, og svaret fortjener samme læsning: resolvectl status og scutil --dns viser begge serverne for hvert interface. Sammenlign den liste med den adresse, som profilen påstår at udstikke. En uoverensstemmelse her forklarer alt nedstrøms, så afklar den, før du tester navne.

Test ét offentligt og ét privat navn

Slå et almindeligt offentligt værtsnavn og det dokumenterede private værtsnavn op fra samme maskine, og noter, hvilken server der svarede på hver. Fejler begge, er resolveren eller dens rute brudt. Fejler kun det private navn, svarede resolveren, og spørgsmålet bliver zonen eller routing. Kør de to forespørgsler inden for et minut af hinanden, så en ruteændring ikke kan forklare forskellen.

Hold interne navne ude af offentlige skærmbilleder og ude af offentlige resolvere. En timeout og et svar om et ikke-eksisterende domæne er forskellige observationer: det første siger, at intet kom tilbage, det andet, at en autoritet svarede, at navnet ikke findes. Behandler du dem som én fejl, sendes du til det forkerte lag, og en certifikatadvarsel er igen en tredje ting, ikke en DNS-fejl.

nslookup viser både den server, den spurgte, og det svar, den fik, og det er præcis det par, du har brug for. Kør den to gange i samme shell, og skriv den svarerende adresse ved hvert svar.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Bekræft, at klienten faktisk kan nå den server

En privat resolver, som profilen udstikker, er kun nyttig, hvis klienten kan nå den, mens tunnelen er oppe. En adresse, der ser korrekt ud, men som mangler en rute, giver en timeout, og tunnelens forbundne tilstand siger intet om den rute. Kontrollen er et ruteopslag rettet mod resolveren selv, ikke mod VPN-endepunktet.

Hver platform svarer på det med én linje, og det interface, der nævnes i outputtet, er hele svaret. Peger det på den fysiske adapter, mens resolveren ligger bag tunnelen, udstikker profilen ikke et præfiks, der dækker den.

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

På en split-tunnel-profil kan resolveren ligge uden for de udstukne ruter, hvilket er et profilproblem og ikke et serverproblem. Sammenlign resolveradressen med de udstukne præfikser, og bekræft, at et af dem dækker den. Den samme uoverensstemmelse forklarer, hvorfor DNS virker på ét netværk og fejler på et andet med en identisk profil.

Husk, at browsere kan omgå systemets resolver

En browser med sikker DNS aktiveret kan sende forespørgsler over HTTPS til en udbyder efter eget valg og ignorere operativsystemets resolver helt. Så ser systemet korrekt ud, mens browseren fejler, eller omvendt. Det er et politikspørgsmål for browseren, ikke for tunnelen.

Kontrollér browserens indstilling for sikker DNS og enhver administreret politik, der styrer den, og prøv derefter en anden applikation eller browser med tunnelen uændret. Fejler kun én applikation, hører rettelsen til i den applikation. Et privat vindue er ikke en ren sammenligning, fordi det kan deaktivere udvidelser som standard i én browser og ikke i en anden, og det omgår aldrig administrerede politikker. Brug i stedet en anden browserprofil eller en anden applikation.

Ryd cachen, og test den rigtige opgave igen

Når du har rettet en indstilling, skal du rydde den lokale resolvercache, så et gammelt svar ikke overlever rettelsen. En kort bedring efterfulgt af en ny fejl betyder, at årsagen stadig er der, ikke at oprydningen fejlede. Vælg den linje, der passer til den maskine, du er på, fordi de tre caches er adskilte.

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

Gentag derefter den oprindelige opgave i stedet for et syntetisk opslag, fordi opgaven er det, brugeren går op i. Genopret forbindelsen én gang, så gentestningen dækker den tilstand, brugeren faktisk vil være i. Microsofts nslookup-reference er den side, du bør beholde til forespørgselsargumenterne.

Hvis navne kun fejler efter afbrydelse, gendannede klienten ikke den forrige konfiguration, hvilket er en livscyklusfejl, du bør rapportere, frem for en DNS-server, du bør udskifte. Et fungerende opslag er heller ikke en lækagetest, fordi udgangslandet ikke fortæller dig, hvilken resolver der svarede.