Hvorfor nslookup løser opp over VPN, men nettleseren ikke kan

nslookup sender en forespørsel til serveren du angir og skriver ut svaret, derfor kan det lykkes mens hver nettleserfane feiler. Nettleseren ber operativsystemet om å løse opp, og operativsystemet veier resolvere per grensesnitt, regler for navneoppløsningspolicy og nettverksplasseringen til adapteret. Deretter kan nettleseren legge sitt eget krypterte DNS på toppen. Tre ulike veier, ett symptom, og tunnelen er vanligvis ikke den ødelagte delen.

Kontrollene nedenfor følger disse veiene fra systemet og utover. Ikke endre VPN-profilen før du vet hvilken vei som svarte og hvilken som feilet.

Tre policyer avgjør svaret

Hvert grensesnitt har sin egen resolverliste og søkeetternavn. En VPN-adapter legger til servere mens den fysiske adapteren beholder sine egne, og systemet kan ta den som svarer først, så et oppslag kan bli betjent utenfor tunnelen uten at noen har valgt det. Regler i navneoppløsningspolicytabellen kan sende utvalgte domener til utvalgte servere, og slik uttrykkes split DNS vanligvis på Windows. Og VPN-klienten eller gatewayen kan skyve inn en resolveradresse som bare finnes inne i det private nettverket.

Disse tre samspiller på måter som virker vilkårlige fra en nettleser. En innskutt resolver på en privat adresse uten rute gjennom splitt-tunnelen får hvert oppslag til å stoppe og deretter feile. En policyregel som dekker det interne etternavnet og peker på en server som er nede, gir samme synlige feil som en manglende rute. Et søkeetternavn som mangler på VPN-adapteren gjør et kort navn til en offentlig forespørsel for feil domene. Hver av dem trenger en annen reparasjon.

Hvorfor nettleseren stiller et annet spørsmål

nslookup sender sin egen forespørsel til serveren den velger og følger verken navneromspolicyen eller nettleserens innstilling for kryptert DNS. Derfor svarer en manuell forespørsel til en offentlig resolver mens nettleseren rapporterer at nettstedet ikke finnes. Du sammenligner to programmer, ikke to tilstander av ett program.

Adressefamiliepreferanse forklarer forsinkelse snarere enn feil. En nettleser som først ber om IPv6-poster på en tunnel som bare fører IPv4, venter på at tidsavbruddet skal utløpe før den faller tilbake. Firefox har hatt en preferanse nettopp for dette, og å slå den av er et diagnostisk trinn, ikke en reparasjon.

Les resolverlisten og reglene

På Windows, dump det systemet holder før du teoretiserer. Get-DnsClientServerAddress viser serverne per grensesnitt, Get-DnsClientNrptRule lister navneromsreglene, og Resolve-DnsName svarer det nøyaktige navnet gjennom systemveien. Sammenlign det svaret med en direkte forespørsel til VPN-ens server på adressen. Når Resolve-DnsName feiler og den direkte forespørselen lykkes, er resolverlisten eller en navneromsregel den mistenkte.

Sjekk navnet selv også. Et internt kort navn kan trenge det private etternavnet som bare VPN-adapteren leverer, mens det fullt kvalifiserte navnet løses fint. En sertifikatadvarsel etter et vellykket oppslag hører til et annet problem.

Den utilgjengelige innskutte resolveren

Gatewayen eller klienten kan skyve inn en resolveradresse, og den adressen må være tilgjengelig gjennom tunnelen. På en splitt-tunnel er det private området som inneholder resolveren kanskje ikke blant de inkluderte rutene, noe som gir et oppslag som aldri får svar. Bekreft at ruten finnes, og spør deretter den adressen spesifikt, gjennom tunnelen. Dette er feilen bak en domenefeil i nettleseren mens en offentlig resolver fortsatt svarer.

Hvis resolveren er utilgjengelig, er reparasjonen en rute eller et inkludert subnett, ikke en annen DNS-server.

Kryptert DNS omgår hele veien

Nettlesere med DNS-over-HTTPS løser opp navn selv over en HTTPS-forbindelse til en valgt leverandør. Når det er på, omgås systemresolveren og splitt-DNS-reglene helt for disse oppslagene, så interne navn feiler i nettleseren mens operativsystemet løser dem korrekt opp. Det motsatte skjer også: interne navn lykkes i nettleseren gjennom en leverandør som aldri skulle sett dem, og det er et policyproblem snarere enn et tilkoblingsproblem.

Bestem bevisst om kryptert DNS er tillatt på administrerte enheter, og konfigurer det deretter via nettleserens administrasjonsflate slik at valget er synlig. Å overlate det til individuell preferanse gir en flåte der samme VPN oppfører seg ulikt på hver bærbar.

Reparasjoner som passer til feilen

Hvis VPN-en skyver inn resolveren sin, la tunnelen føre trafikk til den og gjør samme innstilling synlig på adapterne som deltar i oppløsningen. Hvis lokale nettsteder slutter å løses opp mens du er tilkoblet, legg til eksplisitte navneromsunntak eller en betinget videresender i stedet for å bytte ut resolveren helt. Hvis nettleserens krypterte DNS omgår policyen, er det innstillingen som må endres. Legg aldri til en offentlig resolver for å reparere et internt navn: det lekker private forespørsler og løser ikke navnet.

Skill deretter oppslag fra tilkobling. Et navn som løses til riktig adresse men nekter en tilkobling, er et tjeneste-, brannmur- eller sertifikatproblem, og DNS-endringer retter det ikke.

Noter hvilken vei som svarte, hvilken som feilet og hva du endret. Den neste rapporten om samme symptom tar da én kommando i stedet for en ettermiddag.