Varför nslookup löser ut via VPN men webbläsaren inte kan

nslookup skickar en fråga till servern du anger och skriver ut svaret, därför kan det lyckas medan varje webbläsarflik misslyckas. Webbläsaren ber operativsystemet att lösa ut, och operativsystemet väger resolvers per gränssnitt, regler för namnupplösningspolicy och adapterns nätverksplats. Sedan kan webbläsaren lägga sitt eget krypterade DNS ovanpå. Tre olika vägar, ett symptom, och tunneln är oftast inte den trasiga delen.

Kontrollerna nedan följer dessa vägar från systemet och utåt. Ändra inte VPN-profilen förrän du vet vilken väg som svarade och vilken som misslyckades.

Tre policyer avgör svaret

Varje gränssnitt bär sin egen resolverlista och sökändelser. En VPN-adapter lägger till servrar medan den fysiska adaptern behåller sina egna, och systemet kan ta den som svarar först, så en uppslagning kan betjänas utanför tunneln utan att någon valt det. Regler i namnupplösningspolicytabellen kan skicka valda domäner till valda servrar, och så uttrycks split DNS vanligtvis i Windows. Och VPN-klienten eller gatewayen kan skjuta in en resolveradress som bara finns inne i det privata nätet.

Dessa tre samverkar på sätt som verkar godtyckliga från en webbläsare. En inskjuten resolver på en privat adress utan rutt genom delad tunnel får varje uppslagning att stanna och sedan misslyckas. En policyregel som täcker den interna ändelsen och pekar på en server som är nere ger samma synliga fel som en saknad rutt. En sökändelse som saknas på VPN-adaptern gör ett kort namn till en offentlig fråga för fel domän. Var och en kräver en annan reparation.

Varför webbläsaren ställer en annan fråga

nslookup skickar sin egen fråga till servern den väljer och följer varken namnrymdspolicyn eller webbläsarens inställning för krypterad DNS. Därför svarar en manuell fråga till en offentlig resolver medan webbläsaren rapporterar att webbplatsen inte finns. Du jämför två program, inte två tillstånd av ett program.

Adressfamiljspreferens förklarar fördröjning snarare än fel. En webbläsare som först frågar efter IPv6-poster på en tunnel som bara för IPv4 väntar på att tidsgränsen ska gå ut innan den faller tillbaka. Firefox har haft en preferens just för detta, och att stänga av den är ett diagnostiskt steg, inte en reparation.

Läs resolverlistan och reglerna

I Windows, dumpa det systemet håller innan du teoretiserar. Get-DnsClientServerAddress visar servrarna per gränssnitt, Get-DnsClientNrptRule listar namnrymdsreglerna, och Resolve-DnsName svarar det exakta namnet genom systemvägen. Jämför det svaret med en direkt fråga till VPN:ets server på adressen. När Resolve-DnsName misslyckas och den direkta frågan lyckas är resolverlistan eller en namnrymdsregel den misstänkta.

Kontrollera namnet själv också. Ett internt kort namn kan behöva den privata ändelsen som bara VPN-adaptern levererar, medan det fullt kvalificerade namnet löses ut fint. En certifikatvarning efter en lyckad uppslagning hör till ett annat problem.

Den onåbara inskjutna resolvern

Gatewayen eller klienten kan skjuta in en resolveradress, och den adressen måste vara nåbar genom tunneln. På en delad tunnel är det privata intervallet som håller resolvern kanske inte bland de inkluderade rutterna, vilket ger en uppslagning som aldrig får svar. Bekräfta att rutten finns och fråga sedan specifikt den adressen genom tunneln. Detta är felet bakom ett domänfel i webbläsaren medan en offentlig resolver fortfarande svarar.

Om resolvern är onåbar är reparationen en rutt eller ett inkluderat subnät, inte en annan DNS-server.

Krypterad DNS kringgår hela vägen

Webbläsare med DNS-over-HTTPS löser ut namn själva över en HTTPS-anslutning till en vald leverantör. När det är på kringgås systemresolvern och split-DNS-reglerna helt för dessa uppslagningar, så interna namn misslyckas i webbläsaren medan operativsystemet löser ut dem korrekt. Det motsatta händer också: interna namn lyckas i webbläsaren genom en leverantör som aldrig borde ha sett dem, och det är ett policyproblem snarare än ett anslutningsproblem.

Bestäm medvetet om krypterad DNS är tillåten på hanterade enheter och konfigurera den sedan via webbläsarens hanteringsyta så att valet syns. Att lämna det till individuella preferenser ger en flotta där samma VPN beter sig olika på varje bärbar dator.

Reparationer som passar felet

Om VPN:et skjuter in sin resolver, låt tunneln föra trafik till den och gör samma inställning synlig på adapterna som deltar i upplösningen. Om lokala webbplatser slutar lösas ut medan du är ansluten, lägg till uttryckliga namnrymdsundantag eller en villkorlig vidarebefordran i stället för att byta ut resolvern helt. Om webbläsarens krypterade DNS kringgår policyn är det inställningen som måste ändras. Lägg aldrig till en offentlig resolver för att reparera ett internt namn: det läcker privata frågor och löser inte namnet.

Skilj sedan uppslagning från anslutning. Ett namn som löses ut till rätt adress men nekar anslutning är ett tjänste-, brandväggs- eller certifikatproblem, och DNS-ändringar åtgärdar det inte.

Notera vilken väg som svarade, vilken som misslyckades och vad du ändrade. Nästa rapport om samma symptom tar då ett kommando i stället för en eftermiddag.