VPN-DNS kontra DoH i nettlesaren: kva ein lekkasjetest ikkje kan fortelje deg

Lekkasjetestsida seier at DNS-en din er i orden, netlesaren sitt merke seier trygt, og den interne wikien lastar framleis ikkje. Alle tre kan vere sanne samstundes, fordi adressa til ein resolver ikkje er det same som politikken som valde han, eller vegen spørjinga tok. Det folk kallar ein DNS-lekkasje, er eigentleg eitt spørsmål: kva resolver fekk namnet, og var valet medvite? Å rydde opp i det krev tre kontrollar, og berre den siste inneber å endre ei innstilling.

Myte éin: merket namngjev resolveren din

Ein lekkasjetest løyser eit testnamn og rapporterer adressa som svara. Han rapporterer ikkje politikken som valde resolveren, og når spørjinga er pakka inn i DNS over HTTPS, kan ein mellomboks på vegen ikkje sjå namnet i det heile. To svært ulike maskinar gjev det same beroligande merket: éin der VPN-en dytta inn 10.8.0.1 og netlesaren brukar han, og éin der netlesaren ignorerte systemlista og sende namnet gjennom tunnelen til sin eigen krypterte leverandør.

Skilnaden tel i det augneblikket eit privat namn feilar. I det første oppsettet svarar VPN-resolveren for bedriftsona; i det andre spurde netlesaren aldri, så det korte vertsnamnet blir ikkje løyst og feilen ser ut som ein øydelagd VPN. Kontrollen er ikkje nok ein lekkasjetest, det er eit oppslag på eit namn berre éin resolver kjenner.

Myte to: netlesaren forlèt tunnelen

DNS vel ei adresse, ruting ber sambandet, og det er to skilde lag. Ei spørjing send til ein offentleg DoH-leverandør er framleis TCP port 443 til ei rutbar adresse. Viss rutetabellen din sender standardruta inn i tunnelen, går den spørjinga òg gjennom tunnelen. Merket til resolveren avgjer ikkje vegen.

Det netlesaren sin DoH endrar, er mottakaren av namna. Det er eit reelt personvernval og eit reelt politikkval, men ikkje ei omgåing av ruting. Viss kravet ditt er at namn skal bli hos VPN-operatøren, oppfyller ikkje ei kryptert spørjing til nokon andre det kravet, medan ho framleis brukar tunnelen til det faktiske sambandet.

Myte tre: kvar VPN overstyrer kvar netlesar

Trygg DNS i ein netlesar har modusar, ikkje ein brytar: av, ein standardleverandør med fallback, ein eigen mal eller ein politikk som operativsystemet eller organisasjonen handhevar. Det er fallback-tilfellet som gjev dei periodiske rapportane. Når det krypterte endepunktet ikkje er tilgjengeleg, kan netlesaren falle tilbake til systemresolveren, så same berbare maskin løyser eit privat namn rett på måndag og ikkje på tysdag.

Samstundes set dei fleste VPN-klientar systemresolveren når sambandet kjem opp, og gjenopprettar den førre når det fell. Ein netlesar som held ein eigen kryptert resolver, merkar ikkje den gjenopprettinga i det heile. Derfor oppfører same profil seg ulikt på to berbare maskinar, og derfor ser resolv.conf rett ut medan netlesaren framleis spør nokon andre.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Køyr dei medan du er tilkopla, noter kva domene kvar resolver gjer krav på, og samanlikn med det netlesaren rapporterer om sin eigen modus. Mozilla si DoH-dokumentasjon er ei rimeleg skildring av korleis standard- og fallbackåtferda til ein netlesar skal fungere.

Avgjerda har tre inngangar, ikkje éin

Private namn, tillit til operatøren og tilgjenge avgjer rett oppsett. Namn som berre VPN-resolveren kjenner, tvingar delt DNS: det private suffikset går til den dytta resolveren, og alt anna følgjer politikken du valde for offentlege namn. Tillit til operatøren avgjer om offentlege namn òg skal gå til den resolveren eller til ein eigen teneste. Tilgjenge avgjer om den valde krypterte resolveren i det heile kan brukast på dette nettet.

Ingen av desse radene er ei universell tilråding. Ein resolver som VPN-en driv, konsentrerer observasjonar hos den operatøren; ein eigen teneste legg til ein mottakar til av dei spurte namna. Ingen av oppsetta beviser noko om lagring med mindre du les politikken.

Skriv avgjerda ned per profil, fordi desse innstillingane driv. Ein profil som dytta ein resolver i førre månad, dyttar kanskje ingenting i dag, og netlesaren held gjerne eit gammalt eigendefinert endepunkt som framleis svarar. Det som høyrer i notatet, er adressa til resolveren, suffiksa han eig og modusen til netlesaren, ikkje merket til tenesta.

Test politikken du trur du konfigurerte

Test etter namn, ikkje etter merke. Løys eit offentleg namn og eit privat namn gjennom systemresolveren, og gjenta det så i netlesaren med hans eigen trygge DNS-innstilling i modusen du har tenkt å bruke. Viss det private namnet berre feilar i netlesaren, har du funne mottakarmismatchen utan å røre éi einaste VPN-innstilling.

Kopla så til på nytt og kontroller gjenopprettinga, for det er der overføringsfeila bur: kopla frå, stadfest at den førre resolveren kom tilbake, kopla til på nytt, stadfest at den dytta kom tilbake. Test til slutt ein netlesar med styrt politikk viss du har ein, fordi den modusen kan avvise endringa di heilt og stille halde på den førre resolveren.

Byrja med namneromsspørsmålet, og du unngår det meste av dette. Viss maskina må nå interne namn, er den krypterte resolveren til netlesaren ei avgjerd berre om den offentlege halvdelen, og den private halvdelen blir hos det VPN-en enn har dytta.