VPN tilkopla, men namn feilar: kvar DNS faktisk bryt saman

Tunnelen er oppe, ikonet grønt, og kvar nettlesarfane rapporterer ein namneoppløysingsfeil. Tre ulike mekanismar skapar dette bildet: resolvaren kan vere utilgjengeleg, klienten kan spørje ein resolvar du ikkje venta, eller berre dei private namna kan feile. Skil dei frå kvarandre før du endrar noko i tunnelprotokollen, fordi kvar av dei blir reparert på ein annan stad. Rekkjefølgja nedanfor startar med observasjonane som skil dei tre.

Kva eit oppslag eigentleg treng

Eit oppslag treng tre ting: ei resolvaradresse, ei rute til den adressa og eit svar som passar til spørsmålet. Kvar av dei kan feile åleine, og det synlege symptomet er den same sida som ikkje lastar. Difor fortel feilsida deg nesten ingenting før du veit kva av dei tre som er brote.

Klienten lærer resolvaren sin frå VPN-profilen, frå DHCP på tunnelen eller frå si eiga konfigurasjon, og kva kjelde som vinn avheng av plattforma. På Windows viser ipconfig /all DNS-tenarane per adapter, så du kan sjå om den utsende verdien faktisk kom fram. Ein utsend verdi som aldri nådde operativsystemet er ein stille og vanleg feil. Les den konfigurerte verdien før du rører profilen.

Linux og macOS svarar på det same spørsmålet med ulike kommandoar, og svaret fortener same lesing: resolvectl status og scutil --dns viser begge tenarane per grensesnitt. Samanlikn den lista med adressa profilen påstår at han sender. Ein uoverenskomst her forklarar alt nedstraums, så avklar han før du testar namn.

Test eitt offentleg og eitt privat namn

Slå opp eit vanleg offentleg vertsnamn og det dokumenterte private vertsnamnet frå same maskin, og noter kva tenar som svara på kvar av dei. Viss begge feilar, er resolvaren eller ruta hans broten. Viss berre det private namnet feilar, svara resolvaren, og spørsmålet blir sona eller rutinga. Køyr dei to spørjingane innan eitt minutt av kvarandre, så ei ruteendring ikkje kan forklare skilnaden.

Hald interne namn unna offentlege skjermbilde og unna offentlege resolverar. Ein timeout og eit svar om eit ikkje-eksisterande domene er ulike observasjonar: det første seier at ingenting kom tilbake, det andre at ein autoritet svara at namnet ikkje finst. Handsamer du dei som éin feil, blir du send til feil lag, og eit sertifikatvarsel er igjen ein tredje ting, ikkje ein DNS-feil.

nslookup viser både tenaren han spurde og svaret han fekk, og det er nøyaktig paret du treng. Køyr han to gonger i same skal, og skriv den svarande adressa ved kvart svar.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Stadfest at klienten faktisk kan nå den tenaren

Ein privat resolvar som profilen sender ut, er berre nyttig viss klienten kan nå han medan tunnelen er oppe. Ei adresse som ser rett ut utan ei rute gir ein timeout, og den tilkopla tilstanden til tunnelen seier ingenting om den ruta. Kontrollen er eit ruteoppslag retta mot resolvaren sjølv, ikkje mot VPN-endepunktet.

Kvar plattform svarar på det med éi linje, og grensesnittet som blir nemnt i utdataa, er heile svaret. Viss det peikar på den fysiske adapteren medan resolvaren ligg bak tunnelen, sender ikkje profilen ut eit prefiks som dekkjer han.

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å ein delt tunnel-profil kan resolvaren ligge utanfor dei utsende rutene, noko som er eit profilproblem og ikkje eit tenarproblem. Samanlikn resolvaradressa med dei utsende prefiksa og stadfest at eitt av dei dekkjer henne. Den same uoverenskomsten forklarar kvifor DNS verkar på eitt nettverk og feilar på eit anna med ein identisk profil.

Hugs at nettlesarar kan omgå systemresolvaren

Ein nettlesar med sikker DNS slått på kan sende spørjingar over HTTPS til ein leverandør han sjølv vel, og ignorere resolvaren til operativsystemet heilt. Då ser systemet rett ut medan nettlesaren feilar, eller omvendt. Det er eit politisk spørsmål for nettlesaren, ikkje for tunnelen.

Kontroller innstillinga for sikker DNS i nettlesaren og kvar administrert policy som styrer henne, og prøv deretter ein annan applikasjon eller nettlesar med tunnelen uendra. Viss berre éin applikasjon feilar, høyrer rettinga til i den applikasjonen. Eit privat vindauge er ikkje ein rein samanlikning, fordi det kan slå av utvidingar som standard i éin nettlesar og ikkje i ein annan, og det omgår aldri ein administrert policy. Bruk i staden ein annan nettlesarprofil eller ein annan applikasjon.

Tøm bufferen og test den ekte oppgåva på nytt

Når du har retta ei innstilling, tøm den lokale resolvarbufferen slik at eit gammalt svar ikkje overlever rettinga. Ei kort betring etterfølgd av ein ny feil betyr at årsaka framleis er der, ikkje at tømminga feila. Vel linja som passar til maskinen du er på, fordi dei tre bufferane er separate.

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

Gjenta deretter den opphavlege oppgåva i staden for eit syntetisk oppslag, fordi oppgåva er det brukaren bryr seg om. Kople til på nytt éin gong òg, slik at retesten dekkjer tilstanden brukaren faktisk vil vere i. Microsofts nslookup-referanse er sida du bør halde på for spørjeargumenta.

Viss namn feilar berre etter fråkopling, gjenoppretta ikkje klienten den førre konfigurasjonen, noko som er ein livssyklusfeil du bør rapportere, ikkje ein DNS-tenar du bør bytte ut. Eit fungerande oppslag er heller ikkje ein lekkasjetest, fordi utgangslandet ikkje fortel deg kva resolvar som svara.