Endra VPN-en DNS-en min? Samanlikn før og etter

Du koplar til tunnelen, opnar eit privat dashbord, og namnet blir løyst til ein adresse du aldri har sett. Eller det motsette skjer: nettlesaren held fram med å verke medan eit kommandolinjeverktøy plutseleg ikkje løyser noko. Begge resultata kjem frå den same endringa, og folk forklarer det vanlegvis med éi setning om VPN-en som «brukar sin eigen DNS», noko som ikkje er presist nok til å feilsøkje eller verifisere. I den setninga skjuler det seg to spørsmål: kva oppslag skal denne profilen ta over, og sende maskina di dei faktisk til resolveren ho fekk utlevert? Å halde dei frå kvarandre er heile metoden, for ein test som blandar dei gir eit sjølvsikkert gale svar i begge retningar.

Kvifor ein profil i det heile leverer ein resolver

Inne i ein tunnel blir namn bak den fjerne enden vanlegvis løyste til adresser som berre finst i det nettet. Ei privat sone som corp.internal har inga offentleg delegering, så resolveren som svarar på henne, må vere tilgjengeleg frå innsida av tunnelen. Den same mekanismen tener eit andre føremål: når oppslag elles ville gå ut gjennom leverandøren din, held ein resolver på den fjerne sida førespurnaden inne i den krypterte vegen. Difor kjem DNS-serveradressa som ein del av policyen til sambandet og ikkje som ei global innstilling du valde éin gong for maskina.

Adressa åleine avgjer ingenting. Ein resolver kan berre svare om det finst ein rute til han, og den vanlegaste feilen er ein resolver som berre er tilgjengeleg medan tunnelen er oppe. Når tunnelen fell og policyen blir verande, går oppslag til ei adresse utan veg, og symptomet er tidsavbrot snarare enn ein rein feil. Den skilnaden betyr noko når du les neste testresultat, for eit tidsavbrot sender folk inn i transportinnstillingar som aldri var involverte.

Samanlikn dei to designa før du samanliknar svar

Full tunnel og delt DNS gir motsette forventningar, og ingen av dei er ein feil. Under ein full tunnel kan kvart oppslag flytte til leverandøren eller til resolveren til verksemda, så offentlege namn som svarar annleis etter tilkopling, er venta. Under delt DNS går berre dei oppførte domena til den private resolveren medan alt anna blir lokalt; på Windows bur domenelista i Name Resolution Policy Table, på macOS i dei samsvarande domena i DNS-innstillingane, og på ein systemd-resolved-vert i rutedomene per lenkje.

Det er samanlikninga som må gjerast først, fordi ho avgjer kva som blir rekna som ein feil. Med delt DNS er eit offentleg namn som svarar frå ein ny resolver, det som er verdt å undersøkje, medan eit internt namn som svarar rett, er systemet som gjer jobben sin. Med full tunnel er anomaliet eit offentleg namn som framleis svarar frå resolveren til leverandøren. Dokumentasjonen til Microsoft om VPN-namneoppslag skildrar Windows-rekkjefølgja for desse reglane, inkludert korleis ein samsvarande policyoppføring blir konsultert før dei eigne tenarane til adapteren.

Det finst ein tredje resolver i rommet som er lett å gløyme. Den sikre DNS-en til nettlesaren løyser namn på eiga hand og kan halde fram med å svare etter at tunnelen har endra policyen til operativsystemet, så ei side som blir lasta, beviser at resolveren til nettlesaren verka, ikkje at profilen vart brukt. Om du berre samanliknar det nettlesaren viser, testar du feil lag halve tida.

Registrer ei grunnlinje med berre éin variabel

Endre tunnelen. Ikkje endre også namnet, verktøyet eller søkebakstaven i same trinn. Vel eit namn du har lov til å spørje om, noter kva applikasjon du brukte, og skriv ned anten adressa som kom tilbake eller den nøyaktige feilen. På Windows skriv Get-DnsClientServerAddress -AddressFamily IPv4 ut tenarane per adapter, og Get-DnsClientNrptPolicy skriv ut policyoppføringane; på Linux med systemd-resolved viser resolvectl status DNS-tenarar og rutedomene per lenkje; på macOS skriv scutil --dns ut resolverrekkjefølgja systemet faktisk vil følgje.

Kopla deretter til gjennom dei vanlege kontrollane til klienten og gjenta nøyaktig dei same kommandoane. Ta vare på den første utskrifta i staden for ei minning om ho, fordi samanlikninga er heile poenget, og ei andre lesing teken etter tømming av snøgglageret er allereie ei anna måling. Om grunnlinja vart teken med nettlesaren framme, og køyringa etter tilkopling skjer i ein terminal, samanliknar du to resolverar, ikkje to tilstandar av éin resolver.

Ei eksplisitt spørjing og eit applikasjonsoppslag er ulike testar

Å spørje éin bestemd tenar med nslookup name 10.20.0.1 eller dig @10.20.0.1 name beviser éin einaste ting: at tenaren du namngav, svarar når du kan nå han. Det omgår valglogikken fullstendig, så det kan ikkje fortelje om systemet ville ha valt den tenaren for dette namnet. Bruk det til å teste om den tildelte resolveren er tilgjengeleg, og ikkje bruk det til å teste policy.

Eit oppslag gjennom den lokale resolveren utøver faktisk val. resolvectl query name går gjennom dei same rutedomene-reglane og rapporterer kva protokoll som svara, Resolve-DnsName på Windows går gjennom policytabellen og snøgglageret til klienten, og scutil --dns viser rekkjefølgja eit oppslag ville følgje. Køyr begge slaga, og hald dei i separate kolonnar i notata dine. Ei vellukka eksplisitt spørjing ved sida av eit mislukka applikasjonsoppslag er eit ruting- eller valproblem, ikkje ein resolver som nektar å arbeide.

Snøgglageret står mellom deg og svaret. Operativsystemet, den lokale stub-resolveren, nettlesaren og negativ snøgglagring held alle resultat, så eit oppslag kan lukkast utan at ein einaste pakke forlèt maskina. Registrer resultatet før du tømmer noko: ipconfig /flushdns, resolvectl flush-caches eller sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder på macOS. Hopp over den breie nettverksnullstillinga på dette stadiet, fordi ho øydelegg prova du framleis samlar.

Kva skilnaden betyr

Samanlikn dei to radene du registrerte, og klassifiser endringa før du rører ei einaste innstilling.

Éi rad fortener vekt. Eit namn som blir løyst, er ikkje ein teneste som verkar, og DNS-suksess seier berre at ei adresse vart funnen. Det seier ingenting om vidaresending, brannmurreglar eller om kontoen din i det heile får bruke tenesta, så avslutt med å teste den faktiske applikasjonen i staden for å anta at feilen drog seg tilbake av seg sjølv.

Gjenopprett grunnlinja og verifiser ho

Kopla frå gjennom dei eigne kontrollane til klienten i staden for å drepe prosessen, og les deretter dei same tre kommandoane igjen. Tenarane per lenkje, policyoppføringane og svaret for testnamnet ditt skal kome tilbake til grunnlinja du skreiv ned tidlegare. Ei attverande policyoppføring etter eit reint fråkopling er ein reell feil som er verdt å registrere, og det er også difor handredigering av ei generert resolverfil er ein dårleg vane: fila blir skriven på nytt og redigeringa forsvinn, eller redigeringa overlever og festar ein resolver som ikkje lenger har ein rute.

Gå gjennom denne lista éin gong, i rekkjefølgje. Avgjer kva design profilen implementerer før du vurderer noko resultat. Hald namn, verktøy og bakstav fast gjennom begge køyringane. Skil den eksplisitte spørjinga frå applikasjonsoppslaget. Les den effektive policyen, ikkje berre svaret. Tøm snøgglageret sist, etter at samanlikninga er skriven ned. Verifiser med den verkelege applikasjonen, start deretter på nytt éin gong og stadfest at fråkopia tilstand framleis er rein.