Ændrede VPN’en min DNS? Sammenlign før og efter

Du forbinder tunnelen, åbner et privat dashboard, og navnet opløses til en adresse, du aldrig har set før. Eller det modsatte sker: browseren bliver ved med at virke, mens et kommandolinjeværktøj pludselig ikke opløser noget. Begge udfald kommer fra den samme ændring, og folk forklarer det normalt med én sætning om, at VPN’en "bruger sin egen DNS", hvilket ikke er præcist nok til at fejlfinde eller verificere. Der er skjult to spørgsmål i den sætning: hvilke opslag skal denne profil overtage, og sendte din maskine dem faktisk til den resolver, den fik udleveret? At holde dem adskilt er hele metoden, for en test, der blander dem, giver et selvsikkert forkert svar i begge retninger.

Hvorfor en profil overhovedet leverer en resolver

Inde i en tunnel opløses navne bag den fjerne ende normalt til adresser, der kun findes i det netværk. En privat zone som corp.internal har ingen offentlig delegation, så den resolver, der svarer på den, skal være tilgængelig indefra tunnelen. Den samme mekanisme tjener et andet formål: når opslag ellers ville forlade gennem din udbyder, holder en resolver i den fjerne ende forespørgslen inde i den krypterede vej. Derfor kommer DNS-serveradressen som en del af forbindelsens politik og ikke som en global indstilling, du valgte én gang for maskinen.

Adressen alene afgør intet. En resolver kan kun svare, hvis der er en rute til den, og den mest almindelige fejl er en resolver, der kun er tilgængelig, mens tunnelen er oppe. Når tunnelen falder, og politikken bliver, går opslag til en adresse uden vej, og symptomet er en timeout snarere end en ren fejl. Den forskel betyder noget, når du læser det næste testresultat, for en timeout sender folk ind i transportindstillinger, der aldrig var involveret.

Sammenlign de to designs, før du sammenligner svar

Fuld tunnel og delt DNS giver modsatte forventninger, og ingen af dem er en fejl. Under en fuld tunnel kan hvert opslag flytte til udbyderen eller til virksomhedens resolver, så offentlige navne, der svarer anderledes efter forbindelsen, er forventeligt. Under delt DNS går kun de listede domæner til den private resolver, mens alt andet forbliver lokalt; på Windows bor domænelisten i Name Resolution Policy Table, på macOS i DNS-indstillingernes match domains, og på en systemd-resolved-vært i per-link routing domains.

Det er sammenligningen, der skal foretages først, fordi den afgør, hvad der tæller som en fejl. Med delt DNS er et offentligt navn, der svarer fra en ny resolver, det, der er værd at undersøge, mens et internt navn, der svarer korrekt, er systemet, der gør sit arbejde. Med en fuld tunnel er anomali et offentligt navn, der stadig svarer fra din udbyders resolver. Microsofts dokumentation om VPN-navneopløsning beskriver Windows’ rækkefølge af disse regler, herunder hvordan en matchende politikpost konsulteres før adapterens egne servere.

Der er en tredje resolver i lokalet, som er let at glemme. Browserens sikre DNS opløser navne på egen hånd og kan blive ved med at svare, efter at tunnelen har ændret operativsystemets politik, så en side, der indlæses, beviser, at browserens resolver virkede, ikke at profilen blev anvendt. Hvis du kun sammenligner det, browseren viser, tester du den forkerte lag halvdelen af tiden.

Registrér en basislinje med kun én variabel

Skift tunnelen. Skift ikke også navnet, værktøjet eller søgesuffikset i samme trin. Vælg et navn, du må slå op, noter hvilken applikation du brugte, og skriv enten den adresse, der kom tilbage, eller den præcise fejl. På Windows udskriver Get-DnsClientServerAddress -AddressFamily IPv4 serverne for hver adapter, og Get-DnsClientNrptPolicy udskriver politikposterne; på Linux med systemd-resolved viser resolvectl status DNS-servere og routingdomæner for hvert link; på macOS udskriver scutil --dns den resolverrækkefølge, systemet faktisk følger.

Forbind derefter gennem klientens normale kontroller, og gentag præcis de samme kommandoer. Behold den første udskrift i stedet for en erindring om den, fordi sammenligningen er hele pointen, og en anden aflæsning taget efter tømning af cachen er allerede en anden måling. Hvis basislinjen blev taget med browseren foran, og kørslen efter forbindelsen sker i en terminal, sammenligner du to resolvere, ikke to tilstande af én resolver.

En eksplicit forespørgsel og et applikationsopslag er forskellige tests

At spørge én bestemt server med nslookup name 10.20.0.1 eller dig @10.20.0.1 name beviser én enkelt ting: at serveren, du navngav, svarer, når du kan nå den. Det omgår valglogikken fuldstændigt, så det kan ikke fortælle, om systemet ville have valgt den server til dette navn. Brug det til at teste, om den tildelte resolver er tilgængelig, og brug det ikke til at teste politik.

Et opslag gennem den lokale resolver udøver faktisk valg. resolvectl query name går gennem de samme routingdomæneregler og rapporterer, hvilken protokol der svarede, Resolve-DnsName på Windows går gennem politiktabellen og klientcachen, og scutil --dns viser den rækkefølge, et opslag ville følge. Kør begge slags, og hold dem i separate kolonner i dine notater. En vellykket eksplicit forespørgsel ved siden af et mislykket applikationsopslag er et routing- eller valgproblem, ikke en resolver, der nægter at arbejde.

Cachen står mellem dig og svaret. Operativsystemet, den lokale stub-resolver, browseren og negativ caching holder alle resultater, så et opslag kan lykkes, uden at en enkelt pakke forlader maskinen. Registrér resultatet, før du tømmer noget: ipconfig /flushdns, resolvectl flush-caches eller sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder på macOS. Spring den brede netværksnulstilling over på dette stadium, fordi den ødelægger de beviser, du stadig samler.

Hvad forskellen betyder

Sammenlign de to rækker, du registrerede, og klassificér ændringen, før du rører en enkelt indstilling.

Én række fortjener eftertryk. Et navn, der opløses, er ikke en tjeneste, der virker, og DNS-succes siger kun, at en adresse blev fundet. Det siger intet om videresendelse, firewallregler eller om din konto overhovedet må bruge tjenesten, så afslut med at teste den faktiske applikation i stedet for at antage, at fejlen flyttede sig af sig selv.

Gendan basislinjen, og verificér den

Afbryd gennem klientens egne kontroller i stedet for at dræbe processen, og læs derefter de samme tre kommandoer igen. Serverne for hvert link, politikposterne og svaret for dit testnavn bør vende tilbage til den basislinje, du skrev ned tidligere. En efterladt politikpost efter en ren afbrydelse er en reel fejl, der er værd at registrere, og det er også derfor, håndredigering af en genereret resolverfil er en dårlig vane: filen bliver skrevet igen, og redigeringen forsvinder, eller redigeringen overlever og fastlåser en resolver, der ikke længere har en rute.

Gå gennem denne liste én gang, i rækkefølge. Beslut, hvilket design profilen implementerer, før du bedømmer noget resultat. Hold navn, værktøj og suffiks fast gennem begge kørsler. Adskil den eksplicitte forespørgsel fra applikationsopslaget. Læs den effektive politik, ikke kun svaret. Tøm cachen sidst, efter at sammenligningen er skrevet ned. Verificér med den rigtige applikation, og genstart derefter én gang og bekræft, at afbrudt tilstand stadig er ren.