Hvorfor nslookup slår op over VPN, men browseren ikke kan

nslookup sender en forespørgsel til den server, du angiver, og udskriver svaret, og derfor kan det lykkes, mens hver browserfane fejler. En browser beder styresystemet om at slå op, og styresystemet afvejer resolvere pr. interface, regler for navneopløsningspolitik og adapterens netværksplacering. Derefter kan browseren lægge sin egen krypterede DNS ovenpå. Tre forskellige veje, ét symptom, og tunnelen er normalt ikke den ødelagte del.

Kontrollerne nedenfor følger de veje fra systemet og udad. Ret ikke VPN-profilen, før du ved hvilken vej der svarede, og hvilken der fejlede.

Tre politikker afgør svaret

Hvert interface har sin egen resolverliste og søgesuffikser. En VPN-adapter tilføjer servere, mens den fysiske adapter beholder sine egne, og systemet kan tage den, der svarer først, så et opslag kan blive besvaret uden for tunnelen, uden at nogen har valgt det. Regler i navneopløsningspolitikkens tabel kan sende udvalgte domæner til udvalgte servere, og det er sådan split DNS normalt udtrykkes på Windows. Og VPN-klienten eller gatewayen kan skubbe en resolveradresse ind, som kun findes inde i det private netværk.

De tre samspiller på måder, der ser vilkårlige ud fra en browser. En indskubbet resolver på en privat adresse uden rute gennem split-tunnelen får hvert opslag til at gå i stå og derefter fejle. En politikregel, der dækker det interne suffiks og peger på en server, der er nede, giver den samme synlige fejl som en manglende rute. Et søgesuffiks, der mangler på VPN-adapteren, gør et kort navn til en offentlig forespørgsel efter det forkerte domæne. Hver af dem kræver en anden reparation.

Hvorfor browseren stiller et andet spørgsmål

nslookup sender sin egen forespørgsel til den server, den vælger, og følger hverken navnerumspolitik eller browserens indstilling for krypteret DNS. Derfor svarer en manuel forespørgsel til en offentlig resolver, mens browseren rapporterer, at webstedet ikke findes. Du sammenligner to programmer, ikke to tilstande af ét program.

Adressefamiliepræference forklarer forsinkelse snarere end fejl. En browser, der først spørger efter IPv6-poster på en tunnel, der kun fører IPv4, venter på en timeout, før den falder tilbage. Firefox har haft en præference netop til dette, og at slå den fra er et diagnostisk skridt, ikke en reparation.

Læs resolverlisten og reglerne

På Windows skal du dumpe det, systemet holder, før du teoretiserer. Get-DnsClientServerAddress viser serverne pr. interface, Get-DnsClientNrptRule viser navnerumsreglerne, og Resolve-DnsName svarer på det præcise navn gennem systemets vej. Sammenlign det svar med en direkte forespørgsel til VPN'ens server på adressen. Når Resolve-DnsName fejler, og den direkte forespørgsel lykkes, er resolverlisten eller en navnerumsregel den mistænkte.

Kontroller også navnet selv. Et internt kort navn kan have brug for det private suffiks, som kun VPN-adapteren leverer, mens det fuldt kvalificerede navn slår fint op. En certifikatadvarsel efter et vellykket opslag hører til et andet problem.

Den utilgængelige indskubbede resolver

Gatewayen eller klienten kan skubbe en resolveradresse ind, og den adresse skal være tilgængelig gennem tunnelen. På en split-tunnel er det private interval, der rummer resolveren, måske ikke blandt de inkluderede ruter, hvilket giver et opslag, der aldrig får et svar. Bekræft, at ruten findes, og forespørg derefter den adresse specifikt gennem tunnelen. Det er fejlen bag en browserdomænefejl, mens en offentlig resolver stadig svarer.

Hvis resolveren ikke kan nås, er reparationen en rute eller et inkluderet subnet, ikke en anden DNS-server.

Krypteret DNS omgår hele vejen

Browsere med DNS-over-HTTPS slår selv navne op over en HTTPS-forbindelse til en valgt udbyder. Når det er slået til, omgås systemresolveren og split-DNS-reglerne helt for de opslag, så interne navne fejler i browseren, mens styresystemet slår dem korrekt op. Det omvendte sker også: interne navne lykkes i browseren gennem en udbyder, der aldrig burde se dem, og det er et politikproblem snarere end et forbindelsesproblem.

Beslut bevidst, om krypteret DNS må bruges på administrerede enheder, og konfigurer det derefter via browserens administrationsflade, så valget er synligt. At overlade det til individuelle præferencer giver en flåde, hvor den samme VPN opfører sig forskelligt på hver bærbar.

Reparationer, der matcher fejlen

Hvis VPN'en skubber sin resolver ind, så sørg for, at tunnelen fører trafik til den, og at den samme indstilling er synlig på de adaptere, der deltager i opløsningen. Hvis lokale websteder holder op med at slå op, mens du er forbundet, skal du tilføje udtrykkelige navnerumsundtagelser eller en betinget videresender i stedet for at udskifte resolveren helt. Hvis browserens krypterede DNS omgår politikken, er det den indstilling, der skal ændres. Tilføj aldrig en offentlig resolver for at rette et internt navn: det lækker private forespørgsler og slår ikke navnet op.

Adskil derefter opslag fra forbindelse. Et navn, der slår op på den rigtige adresse, men afviser en forbindelse, er et service-, firewall- eller certifikatproblem, og DNS-ændringer retter det ikke.

Noter, hvilken vej der svarede, hvilken der fejlede, og hvad du ændrede. Den næste rapport om det samme symptom tager så én kommando i stedet for en eftermiddag.