VPN anslutet men namn misslyckas: där DNS faktiskt brister

Tunneln är uppe, ikonen grön och varje webbläsarflik rapporterar ett fel i namnuppslagningen. Tre olika mekanismer skapar bilden: resolvern kan vara onåbar, klienten kan fråga en resolver du inte förväntade dig, eller så kan bara de privata namnen misslyckas. Separera dem innan du ändrar något i tunnelprotokollet, eftersom var och en repareras på olika ställen. Ordningen nedan börjar med observationerna som skiljer de tre åt.

Vad ett uppslag egentligen behöver

Ett uppslag behöver tre saker: en resolveradress, en rutt till den adressen och ett svar som matchar frågan. Var och en kan misslyckas på egen hand, och det synliga symptomet är samma sida som inte laddas. Därför säger felsidan nästan ingenting förrän du vet vilken av de tre som gick sönder.

Klienten lär sig sin resolver från VPN-profilen, från DHCP på tunneln eller från sin egen konfiguration, och vilken källa som vinner beror på plattformen. I Windows listar ipconfig /all DNS-servrarna per adapter, så du ser om det skickade värdet verkligen kom fram. Ett skickat värde som aldrig nådde operativsystemet är ett tyst och vanligt fel. Läs det konfigurerade värdet innan du rör profilen.

Linux och macOS svarar på samma fråga med olika kommandon, och svaret förtjänar samma läsning: resolvectl status och scutil --dns båda listar servrarna per gränssnitt. Jämför listan med den adress som profilen påstår att den skickar. En avvikelse här förklarar allt nedströms, så lös den innan du testar namn.

Testa ett offentligt och ett privat namn

Fråga efter ett vanligt offentligt värdnamn och det dokumenterade privata värdnamnet från samma maskin, och notera vilken server som svarade på vardera. Om båda misslyckas är resolvern eller dess rutt trasig. Om bara det privata namnet misslyckas svarade resolvern, och frågan blir zonen eller routningen. Kör de två frågorna inom en minut från varandra så att en ruttändring inte kan förklara skillnaden.

Håll interna namn borta från offentliga skärmbilder och från offentliga resolvrar. En timeout och ett svar om en icke-existerande domän är olika observationer: den första säger att inget kom tillbaka, den andra att en auktoritet svarade att namnet inte finns. Om du behandlar dem som ett enda fel hamnar du i fel lager, och en certifikatvarning är återigen en tredje sak, inte ett DNS-fel.

nslookup visar både servern den frågade och svaret den fick, och det är exakt det par du behöver. Kör den två gånger i samma skal och skriv den svarande adressen bredvid varje svar.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Bekräfta att klienten verkligen kan nå den servern

En privat resolver som profilen skickar är bara användbar om klienten kan nå den medan tunneln är uppe. En adress som ser korrekt ut utan rutt ger en timeout, och tunnelns anslutna tillstånd säger ingenting om den rutten. Kontrollen är en ruttuppslagning riktad mot resolvern själv, inte mot VPN:s ändpunkt.

Varje plattform svarar på det med en rad, och gränssnittet som nämns i utdata är hela svaret. Om det pekar på den fysiska adaptern medan resolvern ligger bakom tunneln skickar profilen inte ett prefix som täcker 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

I en delad tunnelprofil kan resolvern ligga utanför de skickade rutterna, vilket är ett profilproblem och inte ett serverproblem. Jämför resolveradressen med de skickade prefixen och bekräfta att ett av dem täcker den. Samma avvikelse förklarar varför DNS fungerar i ett nätverk och misslyckas i ett annat med en identisk profil.

Kom ihåg att webbläsare kan kringgå systemets resolver

En webbläsare med säker DNS aktiverad kan skicka frågor över HTTPS till en leverantör den själv väljer och helt ignorera operativsystemets resolver. Då ser systemet korrekt ut medan webbläsaren misslyckas, eller tvärtom. Det är en policyfråga för webbläsaren, inte för tunneln.

Kontrollera webbläsarens inställning för säker DNS och alla hanterade principer som styr den, och prova sedan ett andra program eller en annan webbläsare med tunneln oförändrad. Om bara ett program misslyckas hör rättelsen till i det programmet. Ett privat fönster är inte en ren jämförelse, eftersom det kan inaktivera tillägg som standard i en webbläsare och inte i en annan, och det kringgår aldrig en hanterad princip. Använd i stället en andra webbläsarprofil eller ett annat program.

Töm cachen och testa den verkliga uppgiften igen

När du har rättat en inställning, töm den lokala resolvercachen så att ett gammalt svar inte överlever rättelsen. En kort återhämtning följd av ett nytt fel betyder att orsaken finns kvar, inte att tömningen misslyckades. Välj den rad som passar maskinen du sitter på, eftersom de tre cacharna är separata.

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

Upprepa sedan den ursprungliga uppgiften i stället för ett syntetiskt uppslag, eftersom uppgiften är det användaren bryr sig om. Anslut också en gång igen, så att omtestet täcker det tillstånd användaren faktiskt kommer att vara i. Microsofts nslookup-referens är sidan du bör behålla för frågeargumenten.

Om namn misslyckas först efter frånkoppling, återställde inte klienten den tidigare konfigurationen, vilket är ett livscykelfel att rapportera, inte en DNS-server att byta ut. Ett fungerande uppslag är inte heller ett läckagetest, eftersom utgångslandet inte säger vilken resolver som svarade.