Endret VPN-en DNS-en min? Sammenlign før og etter

Du kobler til tunnelen, åpner et privat dashbord, og navnet løses til en adresse du aldri har sett. Eller det motsatte skjer: nettleseren fortsetter å virke mens et kommandolinjeverktøy plutselig ikke løser noe. Begge resultatene kommer fra den samme endringen, og folk forklarer det vanligvis med én setning om VPN-en som «bruker sin egen DNS», noe som ikke er presist nok til å feilsøke eller verifisere. I den setningen skjuler det seg to spørsmål: hvilke oppslag skal denne profilen overta, og sendte maskinen din dem faktisk til resolveren den fikk utlevert? Å holde dem fra hverandre er hele metoden, for en test som blander dem gir et selvsikkert galt svar i begge retninger.

Hvorfor en profil i det hele tatt leverer en resolver

Inne i en tunnel løses navn bak den fjerne enden vanligvis til adresser som bare finnes i det nettverket. En privat sone som corp.internal har ingen offentlig delegering, så resolveren som svarer på den, må være tilgjengelig fra innsiden av tunnelen. Den samme mekanismen tjener et andre formål: når oppslag ellers ville gå ut gjennom leverandøren din, holder en resolver på den fjerne siden forespørselen inne i den krypterte veien. Derfor kommer DNS-serveradressen som en del av forbindelsens policy og ikke som en global innstilling du valgte én gang for maskinen.

Adressen alene avgjør ingenting. En resolver kan bare svare hvis det finnes en rute til den, og den vanligste feilen er en resolver som bare er tilgjengelig mens tunnelen er oppe. Når tunnelen faller og policyen blir værende, går oppslag til en adresse uten vei, og symptomet er tidsavbrudd snarere enn en ren feil. Den forskjellen betyr noe når du leser neste testresultat, for et tidsavbrudd sender folk inn i transportinnstillinger som aldri var involvert.

Sammenlign de to designene før du sammenligner svar

Full tunnel og delt DNS gir motsatte forventninger, og ingen av dem er en feil. Under en full tunnel kan hvert oppslag flytte til leverandøren eller til bedriftens resolver, så offentlige navn som svarer annerledes etter tilkobling, er forventet. Under delt DNS går bare de oppførte domenene til den private resolveren mens alt annet blir lokalt; på Windows bor domenelisten i Name Resolution Policy Table, på macOS i DNS-innstillingenes samsvarende domener, og på en systemd-resolved-vert i rutingdomener per lenke.

Det er sammenligningen som må gjøres først, fordi den avgjør hva som regnes som en feil. Med delt DNS er et offentlig navn som svarer fra en ny resolver, det som er verdt å undersøke, mens et internt navn som svarer riktig, er systemet som gjør jobben sin. Med full tunnel er anomaliet et offentlig navn som fortsatt svarer fra leverandørens resolver. Microsofts dokumentasjon om VPN-navneoppslag beskriver Windows-rekkefølgen for disse reglene, inkludert hvordan en samsvarende policyoppføring konsulteres før adapterens egne servere.

Det finnes en tredje resolver i rommet som er lett å glemme. Nettleserens sikre DNS løser navn på egen hånd og kan fortsette å svare etter at tunnelen har endret operativsystemets policy, så en side som lastes, beviser at nettleserens resolver virket, ikke at profilen ble brukt. Hvis du bare sammenligner det nettleseren viser, tester du feil lag halvparten av tiden.

Registrer en grunnlinje med bare én variabel

Endre tunnelen. Ikke endre også navnet, verktøyet eller søkebakstaven i samme trinn. Velg et navn du har lov til å spørre om, noter hvilken applikasjon du brukte, og skriv ned enten adressen som kom tilbake eller den nøyaktige feilen. På Windows skriver Get-DnsClientServerAddress -AddressFamily IPv4 ut serverne per adapter, og Get-DnsClientNrptPolicy skriver ut policyoppføringene; på Linux med systemd-resolved viser resolvectl status DNS-servere og rutingdomener per lenke; på macOS skriver scutil --dns ut resolverrekkefølgen systemet faktisk vil følge.

Koble deretter til gjennom klientens vanlige kontroller og gjenta nøyaktig de samme kommandoene. Ta vare på den første utskriften i stedet for en erindring om den, fordi sammenligningen er hele poenget, og en andre lesning tatt etter tømming av hurtiglageret er allerede en annen måling. Hvis grunnlinjen ble tatt med nettleseren foran, og kjøringen etter tilkobling skjer i en terminal, sammenligner du to resolvere, ikke to tilstander av én resolver.

En eksplisitt spørring og et applikasjonsoppslag er forskjellige tester

Å spørre én bestemt server med nslookup name 10.20.0.1 eller dig @10.20.0.1 name beviser én enkelt ting: at serveren du navnga, svarer når du kan nå den. Det omgår valglogikken fullstendig, så det kan ikke fortelle om systemet ville ha valgt den serveren for dette navnet. Bruk det til å teste om den tildelte resolveren er tilgjengelig, og ikke bruk det til å teste policy.

Et oppslag gjennom den lokale resolveren utøver faktisk valg. resolvectl query name går gjennom de samme rutingdomene-reglene og rapporterer hvilken protokoll som svarte, Resolve-DnsName på Windows går gjennom policytabellen og klientens hurtiglager, og scutil --dns viser rekkefølgen et oppslag ville følge. Kjør begge slagene, og hold dem i separate kolonner i notatene dine. En vellykket eksplisitt spørring ved siden av et mislykket applikasjonsoppslag er et ruting- eller valgproblem, ikke en resolver som nekter å arbeide.

Hurtiglageret står mellom deg og svaret. Operativsystemet, den lokale stub-resolveren, nettleseren og negativ hurtiglagring holder alle resultater, så et oppslag kan lykkes uten at en eneste pakke forlater maskinen. Registrer resultatet før du tømmer noe: ipconfig /flushdns, resolvectl flush-caches eller sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder på macOS. Hopp over den brede nettverksnullstillingen på dette stadiet, fordi den ødelegger bevisene du fortsatt samler.

Hva forskjellen betyr

Sammenlign de to radene du registrerte, og klassifiser endringen før du rører en eneste innstilling.

Én rad fortjener vekt. Et navn som løses, er ikke en tjeneste som virker, og DNS-suksess sier bare at en adresse ble funnet. Det sier ingenting om videreformidling, brannmurregler eller om kontoen din i det hele tatt får bruke tjenesten, så avslutt med å teste den faktiske applikasjonen i stedet for å anta at feilen trakk seg tilbake av seg selv.

Gjenopprett grunnlinjen og verifiser den

Koble fra gjennom klientens egne kontroller i stedet for å drepe prosessen, og les deretter de samme tre kommandoene igjen. Serverne per lenke, policyoppføringene og svaret for testnavnet ditt skal komme tilbake til grunnlinjen du skrev ned tidligere. En gjenværende policyoppføring etter en ren frakobling er en reell feil som er verdt å registrere, og det er også derfor håndredigering av en generert resolverfil er en dårlig vane: filen skrives på nytt og redigeringen forsvinner, eller redigeringen overlever og fester en resolver som ikke lenger har en rute.

Gå gjennom denne listen én gang, i rekkefølge. Bestem hvilket design profilen implementerer før du vurderer noe resultat. Hold navn, verktøy og bakstav fast gjennom begge kjøringene. Skill den eksplisitte spørringen fra applikasjonsoppslaget. Les den effektive policyen, ikke bare svaret. Tøm hurtiglagerne sist, etter at sammenligningen er skrevet ned. Verifiser med den virkelige applikasjonen, start deretter på nytt én gang og bekreft at frakoblet tilstand fortsatt er ren.