VPN tilkoblet, men navn feiler: hvor DNS faktisk bryter sammen

Tunnelen er oppe, ikonet grønt, og hver nettleserfane rapporterer en navneoppløsningsfeil. Tre ulike mekanismer skaper dette bildet: resolveren kan være utilgjengelig, klienten kan spørre en resolver du ikke forventet, eller bare de private navnene kan feile. Skill dem fra hverandre før du endrer noe i tunnelprotokollen, fordi hver av dem repareres på et annet sted. Rekkefølgen nedenfor starter med observasjonene som skiller de tre.

Hva et oppslag egentlig trenger

Et oppslag trenger tre ting: en resolveradresse, en rute til den adressen og et svar som passer til spørsmålet. Hver av dem kan feile alene, og det synlige symptomet er den samme siden som ikke lastes. Derfor forteller feilsiden deg nesten ingenting før du vet hvilken av de tre som er brutt.

Klienten lærer resolveren sin fra VPN-profilen, fra DHCP på tunnelen eller fra sin egen konfigurasjon, og hvilken kilde som vinner avhenger av plattformen. På Windows viser ipconfig /all DNS-serverne per adapter, så du kan se om den utsendte verdien faktisk kom frem. En utsendt verdi som aldri nådde operativsystemet er en stille og vanlig feil. Les den konfigurerte verdien før du rører profilen.

Linux og macOS svarer på det samme spørsmålet med forskjellige kommandoer, og svaret fortjener samme lesing: resolvectl status og scutil --dns viser begge serverne per grensesnitt. Sammenlign den listen med adressen profilen påstår at den sender. En uoverensstemmelse her forklarer alt nedstrøms, så avklar den før du tester navn.

Test ett offentlig og ett privat navn

Slå opp et vanlig offentlig vertsnavn og det dokumenterte private vertsnavnet fra samme maskin, og noter hvilken server som svarte på hvert av dem. Hvis begge feiler, er resolveren eller ruten dens brutt. Hvis bare det private navnet feiler, svarte resolveren, og spørsmålet blir sonen eller rutingen. Kjør de to spørringene innen ett minutt av hverandre, så en ruteendring ikke kan forklare forskjellen.

Hold interne navn unna offentlige skjermbilder og unna offentlige resolvere. En timeout og et svar om et ikke-eksisterende domene er forskjellige observasjoner: det første sier at ingenting kom tilbake, det andre at en autoritet svarte at navnet ikke finnes. Behandler du dem som én feil, sendes du til feil lag, og en sertifikatadvarsel er igjen en tredje ting, ikke en DNS-feil.

nslookup viser både serveren den spurte og svaret den fikk, og det er nøyaktig paret du trenger. Kjør den to ganger i samme skall, og skriv den svarande adressen ved hvert svar.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Bekreft at klienten faktisk kan nå den serveren

En privat resolver som profilen sender ut, er bare nyttig hvis klienten kan nå den mens tunnelen er oppe. En adresse som ser riktig ut uten en rute gir en timeout, og tunnelens tilkoblede tilstand sier ingenting om den ruten. Kontrollen er et ruteoppslag rettet mot resolveren selv, ikke mot VPN-endepunktet.

Hver plattform svarer på det med én linje, og grensesnittet som nevnes i utdataene, er hele svaret. Hvis det peker på den fysiske adapteren mens resolveren ligger bak tunnelen, sender ikke profilen ut et prefiks som dekker 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 delt tunnel-profil kan resolveren ligge utenfor de utsendte rutene, noe som er et profilproblem og ikke et serverproblem. Sammenlign resolveradressen med de utsendte prefiksene og bekreft at ett av dem dekker den. Den samme uoverensstemmelsen forklarer hvorfor DNS virker på ett nettverk og feiler på et annet med en identisk profil.

Husk at nettlesere kan omgå systemets resolver

En nettleser med sikker DNS aktivert kan sende spørringer over HTTPS til en leverandør den selv velger, og ignorere operativsystemets resolver helt. Da ser systemet riktig ut mens nettleseren feiler, eller omvendt. Det er et politisk spørsmål for nettleseren, ikke for tunnelen.

Kontroller nettleserens innstilling for sikker DNS og enhver administrert policy som styrer den, og prøv deretter en annen applikasjon eller nettleser med tunnelen uendret. Hvis bare én applikasjon feiler, hører rettelsen til i den applikasjonen. Et privat vindu er ikke en ren sammenligning, fordi det kan deaktivere utvidelser som standard i én nettleser og ikke i en annen, og det omgår aldri en administrert policy. Bruk i stedet en annen nettleserprofil eller en annen applikasjon.

Tøm cachen og test den ekte oppgaven på nytt

Når du har rettet en innstilling, tøm den lokale resolvercachen slik at et gammelt svar ikke overlever rettelsen. En kort bedring etterfulgt av en ny feil betyr at årsaken fortsatt er der, ikke at tømmingen feilet. Velg linjen som passer til maskinen du er på, fordi de tre cacheene er separate.

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

Gjenta deretter den opprinnelige oppgaven i stedet for et syntetisk oppslag, fordi oppgaven er det brukeren bryr seg om. Koble til på nytt én gang også, slik at retesten dekker tilstanden brukeren faktisk vil være i. Microsofts nslookup-referanse er siden du bør beholde for spørringsargumentene.

Hvis navn feiler bare etter frakobling, gjenopprettet ikke klienten den forrige konfigurasjonen, noe som er en livssyklusfeil du bør rapportere, ikke en DNS-server du bør bytte ut. Et fungerende oppslag er heller ikke en lekkasjetest, fordi utgangslandet ikke forteller deg hvilken resolver som svarte.