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

Lekkasjetestsiden sier at DNS-en din er i orden, nettlesermerket sier at det er sikkert, og den interne wikien vil fortsatt ikke laste. 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 det valget tilsiktet? Å rydde opp i det krever tre kontroller, og bare den siste innebærer å endre en innstilling.

Myte én: merket oppgir hvilken resolver du bruker

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

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

Myte to: nettleseren forlater tunnelen

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

Det nettleserens DoH endrer, er mottakeren av navnene. Det er en reell personvernbeslutning og en reell policybeslutning, men det er ikke en rutingomgåelse. Hvis kravet ditt er at navnene skal bli hos VPN-operatøren, bryter en kryptert spørring til noen andre det kravet selv om den fortsatt bruker tunnelen for selve 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 håndhevet av operativsystemet eller organisasjonen. Fallback-tilfellet er det som gir sporadiske rapporter. Når det krypterte endepunktet ikke er tilgjengelig, kan nettleseren falle tilbake til systemets resolver, så samme laptop slår opp et privat navn riktig på mandag og ikke på tirsdag.

Samtidig setter de fleste VPN-klienter systemresolveren 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 laptoper, 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 domenene 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 er ment å 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 pushede resolveren, 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 er brukbar 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 en mottaker av spurte navn. Ingen av ordningene beviser noe om lagring med mindre du leser policyen.

Skriv ned beslutningen per profil, fordi disse innstillingene driver. En profil som pushet en resolver i forrige måned, pusher kanskje ingenting i dag, og nettleseren beholder gjerne et gammelt egendefinert endepunkt som fortsatt svarer. Det som hører i notatet, er resolveradressen, suffiksene den eier og nettlesermodusen, ikke merkevaren til tjenesten.

Test policyen du tror du konfigurerte

Test ved navn, ikke ved merke. Slå opp et offentlig og et privat navn gjennom systemresolveren, og gjenta deretter inne i nettleseren med dens egen sikre DNS-innstilling i modusen du har tenkt å bruke. Hvis det private navnet feiler bare i nettleseren, har du funnet mottakermismatchen uten å røre en eneste VPN-innstilling.

Koble så til igjen og sjekk gjenopprettingen, for det er der overleveringsfeilene bor: koble fra, bekreft at den forrige resolveren kom tilbake, koble til, bekreft at den pushede kom tilbake. Test til slutt en nettleser med administrert policy hvis du har en, siden den modusen kan avvise endringen din helt og stille beholde den forrige resolveren.

Start med navneroms-spørsmålet, så unngår du 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 pushet.