Kvifor nslookup løyser opp over VPN, men nettlesaren ikkje kan

nslookup sender ei førespurnad til tenaren du nemner og skriv ut svaret, difor kan det lukkast medan kvar nettlesarfane feilar. Nettlesaren ber operativsystemet om å løyse opp, og operativsystemet veg resolvarar per grensesnitt, reglar for namneoppløysingspolitikk og nettverksplasseringa til adapteren. Deretter kan nettlesaren leggje sitt eige krypterte DNS oppå. Tre ulike vegar, eitt symptom, og tunnelen er vanlegvis ikkje den øydelagde delen.

Kontrollane nedanfor følgjer desse vegane frå systemet og utover. Ikkje endre VPN-profilen før du veit kva veg som svara og kva som feila.

Tre politikkar avgjer svaret

Kvart grensesnitt har si eiga resolvarliste og søkjeetternamn. Ein VPN-adapter legg til tenarar medan den fysiske adapteren held på sine eigne, og systemet kan ta den som svarar først, så eit oppslag kan bli tent utanfor tunnelen utan at nokon har valt det. Reglar i namneoppløysingspolitikktabellen kan sende utvalde domene til utvalde tenarar, og slik blir split DNS vanlegvis uttrykt på Windows. Og VPN-klienten eller gatewayen kan skyve inn ei resolveradresse som berre finst inne i det private nettet.

Desse tre samverkar på måtar som verkar vilkårlege frå ein nettlesar. Ein innskoten resolver på ei privat adresse utan rute gjennom splitt-tunnelen får kvart oppslag til å stoppe og deretter feile. Ein politikkregel som dekkjer det interne etternamnet og peikar på ein tenar som er nede, gir same synlege feil som ei manglande rute. Eit søkjeetternamn som manglar på VPN-adapteren gjer eit kort namn til ei offentleg førespurnad for feil domene. Kvar av dei treng ei anna reparasjon.

Kvifor nettlesaren stiller eit anna spørsmål

nslookup sender si eiga førespurnad til tenaren han vel og følgjer korkje namnromspolitikken eller nettlesarens innstilling for kryptert DNS. Difor svarar ei manuell førespurnad til ein offentleg resolver medan nettlesaren rapporterer at nettstaden ikkje finst. Du samanliknar to program, ikkje to tilstandar av eitt program.

Adressefamiliepreferanse forklarer forseinking snarare enn feil. Ein nettlesar som først ber om IPv6-poster på ein tunnel som berre fører IPv4, ventar på at tidsavbrotet skal gå ut før han fell tilbake. Firefox har hatt ein preferanse nettopp for dette, og å slå han av er eit diagnostisk steg, ikkje ein reparasjon.

Les resolvarlista og reglane

På Windows, dump det systemet held før du teoretiserer. Get-DnsClientServerAddress viser tenarane per grensesnitt, Get-DnsClientNrptRule listar namnromsreglane, og Resolve-DnsName svarar det nøyaktige namnet gjennom systemvegen. Samanlikn det svaret med ei direkte førespurnad til tenaren til VPN-en på adressa. Når Resolve-DnsName feilar og den direkte førespurnaden lukkast, er resolvarlista eller ein namnromsregel den mistenkte.

Sjekk namnet sjølv òg. Eit internt kort namn kan trenge det private etternamnet som berre VPN-adapteren leverer, medan det fullt kvalifiserte namnet løyser seg fint. Ei sertifikatåtvaring etter eit vellukka oppslag høyrer til eit anna problem.

Den utilgjengelege innskotne resolvaren

Gatewayen eller klienten kan skyve inn ei resolveradresse, og den adressa må vere tilgjengeleg gjennom tunnelen. På ein splitt-tunnel er det private området som held resolvaren kanskje ikkje blant dei inkluderte rutene, noko som gir eit oppslag som aldri får svar. Stadfest at ruta finst, og spør deretter den adressa spesifikt, gjennom tunnelen. Dette er feilen bak ein domenefeil i nettlesaren medan ein offentleg resolver framleis svarar.

Viss resolvaren er utilgjengeleg, er reparasjonen ei rute eller eit inkludert subnett, ikkje ein annan DNS-tenar.

Kryptert DNS går utanom heile vegen

Nettlesarar med DNS-over-HTTPS løyser opp namn sjølv over ei HTTPS-tilkopling til ein vald leverandør. Når det er på, blir systemresolvaren og splitt-DNS-reglane heilt omgått for desse oppslaga, så interne namn feilar i nettlesaren medan operativsystemet løyser dei rett opp. Det motsette skjer òg: interne namn lukkast i nettlesaren gjennom ein leverandør som aldri skulle sett dei, og det er eit politikkproblem snarare enn eit tilkoplingproblem.

Avgjer medvite om kryptert DNS er tillate på styrte einingar, og konfigurer det deretter via styringsflata til nettlesaren slik at valet er synleg. Å overlate det til individuell preferanse gir ein flåte der same VPN oppfører seg ulikt på kvar berbar datamaskin.

Reparasjonar som passar til feilen

Viss VPN-en skyv inn resolvaren sin, lat tunnelen føre trafikk til han og gjer same innstillinga synleg på adapterane som deltek i oppløysinga. Viss lokale nettstader sluttar å løyse seg opp medan du er tilkopla, legg til eksplisitte namnromsunntak eller ein vilkårleg videresendar i staden for å byte ut resolvaren heilt. Viss det krypterte DNS-et til nettlesaren går utanom politikken, er det innstillinga som må endrast. Legg aldri til ein offentleg resolver for å reparere eit internt namn: det lek private førespurnader og løyser ikkje namnet.

Skil deretter oppslag frå tilkopling. Eit namn som løyser seg til rett adresse men nektar tilkopling, er eit teneste-, brannmur- eller sertifikatproblem, og DNS-endringar rettar det ikkje.

Noter kva veg som svara, kva som feila og kva du endra. Den neste rapporten om same symptom tek då éin kommando i staden for ein ettermiddag.