VPN-DNS kontra DoH i nettleseren: hva en lekkasjetest ikke kan fortelle deg

Lekkasjetestsiden sier at DNS-en din er i orden, nettleserens merke sier sikkert, og den interne wikien lastes fortsatt ikke. Alle tre kan være sanne samtidig, fordi en resolvers adresse ikke er det samme som policyen som valgte den, eller veien spørringen tok. Det folk kaller en DNS-lekkasje, er egentlig ett spørsmål: hvilken resolver mottok navnet, og var valget bevisst? Å rydde opp i det krever tre kontroller, og bare den siste innebærer å endre en innstilling.

Myte én: merket navngir resolveren din

En lekkasjetest løser et testnavn og rapporterer adressen som svarte. Den rapporterer ikke policyen som valgte resolveren, og når spørringen er pakket inn i DNS over HTTPS, kan en mellomleddboks på veien ikke se navnet i det hele tatt. To svært forskjellige maskiner gir det samme beroligende merket: én der VPN-en dyttet inn 10.8.0.1 og nettleseren bruker den, og én der nettleseren ignorerte systemlisten og sendte navnet gjennom tunnelen til sin egen krypterte leverandør.

Forskjellen betyr noe i det øyeblikket et privat navn feiler. I det første oppsettet svarer VPN-resolveren for bedriftssoonen; i det andre spurte nettleseren aldri, så det korte vertsnavnet løses ikke og feilen ser ut som en ødelagt VPN. Kontrollen er ikke nok en lekkasjetest, det er et oppslag på et navn bare én resolver kjenner.

Myte to: nettleseren forlater tunnelen

DNS velger en adresse, ruting bærer forbindelsen, og det er to separate lag. En spørring sendt til en offentlig DoH-leverandør er fortsatt TCP port 443 til en rutbar adresse. Hvis rutetabellen din sender standardruten inn i tunnelen, går den spørringen også gjennom tunnelen. Resolverens merke avgjør ikke veien.

Det nettleserens DoH endrer, er mottakeren av navnene. Det er en reell personvernbeslutning og en reell policybeslutning, men ikke en omgåelse av ruting. Hvis kravet ditt er at navn skal bli hos VPN-operatøren, oppfyller ikke en kryptert spørring til noen andre det kravet, mens den fortsatt bruker tunnelen til den faktiske forbindelsen.

Myte tre: hver VPN overstyrer hver nettleser

Sikker DNS i en nettleser har moduser, ikke en bryter: av, en standardleverandør med fallback, en egendefinert mal eller en policy som operativsystemet eller organisasjonen håndhever. Det er fallback-tilfellet som gir de periodiske rapportene. Når det krypterte endepunktet ikke er tilgjengelig, kan nettleseren falle tilbake til systemets resolver, så samme bærbare maskin løser et privat navn riktig på mandag og ikke på tirsdag.

Samtidig setter de fleste VPN-klienter systemets resolver når forbindelsen kommer opp, og gjenoppretter den forrige når den faller. En nettleser som holder en egendefinert kryptert resolver, merker ikke den gjenopprettingen i det hele tatt. Derfor oppfører samme profil seg ulikt på to bærbare maskiner, og derfor ser resolv.conf riktig ut mens nettleseren fortsatt spør noen 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

Kjør dem mens du er tilkoblet, noter hvilke domener hver resolver gjør krav på, og sammenlign med det nettleseren rapporterer om sin egen modus. Mozillas DoH-dokumentasjon er en rimelig beskrivelse av hvordan en nettlesers standard- og fallbackatferd skal fungere.

Beslutningen har tre innganger, ikke én

Private navn, operatørtillit og tilgjengelighet avgjør riktig oppsett. Navn som bare VPN-resolveren kjenner, tvinger delt DNS: det private suffikset går til den dyttede resolveren, og alt annet følger policyen du valgte for offentlige navn. Operatørtillit avgjør om offentlige navn også skal gå til den resolveren eller til en egen tjeneste. Tilgjengelighet avgjør om den valgte krypterte resolveren i det hele tatt kan brukes på dette nettverket.

Ingen av disse radene er en universell anbefaling. En resolver som drives av VPN-en, konsentrerer observasjoner hos den operatøren; en egen tjeneste legger til én mottaker til av de spurte navnene. Ingen av oppsettene beviser noe om lagring med mindre du leser policyen.

Skriv beslutningen ned per profil, fordi disse innstillingene driver. En profil som dyttet en resolver i forrige måned, dyttet kanskje ingenting i dag, og nettleseren beholder gjerne et gammelt egendefinert endepunkt som fortsatt svarer. Det som hører i notatet, er resolverens adresse, suffiksene den eier og nettleserens modus, ikke tjenestens merke.

Test policyen du tror du konfigurerte

Test etter navn, ikke etter merke. Løs et offentlig navn og et privat navn gjennom systemets resolver, og gjenta det deretter i nettleseren med dens egen sikre DNS-innstilling i modusen du har tenkt å bruke. Hvis det private navnet bare feiler i nettleseren, har du funnet mottakermismatchen uten å røre én eneste VPN-innstilling.

Koble deretter til på nytt og kontroller gjenopprettingen, for det er der overleveringsfeilene bor: koble fra, bekreft at den forrige resolveren kom tilbake, koble til på nytt, bekreft at den dyttede kom tilbake. Test til slutt en nettleser med administrert policy hvis du har en, fordi den modusen kan avvise endringen din helt og stille beholde den forrige resolveren.

Begynn med navneromsspørsmålet, og du unngår det meste av dette. Hvis maskinen må nå interne navn, er nettleserens krypterte resolver en beslutning bare om den offentlige halvdelen, og den private halvdelen blir hos det VPN-en enn har dyttet.