Privat DNS kontra VPN: kva kvart lag eigentleg dekkjer

Telefonen din har privat DNS sett til eit vertsnamn frå ein leverandør og ein VPN-app som køyrer samstundes. Det er rimeleg å tru at ein av dei no styrer namneoppslaga. Ingen av dei gjer det, i den tydinga setninga antydar, og den raskaste måten å sjå kvifor på er å fylgje éi einskild førespurnad frå det augneblunken du trykkjer på ei lenkje.

Desse to funksjonane sit på ulike punkt i same reisa. Privat DNS krypterer spørsmålet du stiller ein resolver. Ein VPN endrar ruta som sambandet til svaret tek.

Gå derfor gjennom det i rekkjefølgje på eining der begge er slått på, og legg merke til kva kvart lag framleis kan sjå.

Trinn éin: oppslaget forlèt appen

Du trykkjer på ei lenkje. Før noko koplar til, treng appen ei adresse for det vertsnamnet. På Android er den relevante skjermen Innstillingar, Nettverk og internett, Privat DNS. Vel du Leverandøren sitt vertsnamn for privat DNS, set det eininga i streng modus: ho gjer DNS over TLS til det vertsnamnet på port 853, og viss den krypterte utvekslinga feilar, feilar oppslaget i staden for å falle stille tilbake til klartekst på port 53.

Det er ein betydeleg skilnad frå Automatisk, som brukar opportunistisk kryptering og gjerne brukar ein ukryptert resolver når nettverket blandar seg inn. Viss målet ditt er at oppslag aldri skjer i klartekst, er streng modus med eit leverandørvertsnamn innstillinga som passar.

Her er det første gjennomgangen avdekkjer: oppslaget er verna mot det lokale nettverket, og resolveren får likevel vite namnet. Krypteringa dekkjer hoppet. Operatøren av den resolveren ser førespurnaden fordi det er jobben hans å svare på han.

Trinn to: sambandet tek ei anna rute

Resolveren returnerer ei adresse, og appen koplar til henne. Dette trinnet vert ikkje påverka av korleis oppslaget vart kryptert. Utan tunnel forlèt sambandet den vanlege offentlege adressa di, og mål-IP-en og TLS-handtrykket gjer vanlegvis vertsnamnet synleg for nettverket likevel, med eller utan kryptert DNS.

Slå på VPN-en, og det er dette trinnet som endrar seg. Trafikk som samsvarar med ruteringspolicyen til klienten, går gjennom tunnelen, det lokale nettverket ser eit samband til VPN-endepunktet, og nettstaden ser vanlegvis utgangsadressa. Namneoppløysing kan òg reise inne i tunnelen, avhengig av kva klienten sender med.

Den separasjonen er heile samanlikninga i éi setning. DNS-kryptering svarar på kven som kan lese spørsmålet. Ein VPN svarar på kvar samtalen går.

Trinn tre: inne i tunnelen vert DNS eit spørsmål om policy

No samverkar dei to funksjonane, og nettlesaren er den vanlege kjelda til overraskingar. Ein nettlesar med eiga innstilling for sikker DNS kan sende oppslag til den resolveren han valde over HTTPS i staden for å spørje operativsystemet. Innstillinga for privat DNS i Android rekk ikkje inn i den avgjerda.

I Firefox ligg brytaren under Innstillingar, Personvern og tryggleik, Slå på sikker DNS. I Chrome ligg han under Innstillingar, Personvern og tryggleik, Bruk sikker DNS. Begge kan setjast til ein bestemd leverandør eller slåast av, og når dei er på, vert DNS-konfigurasjonen til tunnelen omgått for desse oppslaga sjølv om sidetrafikken framleis brukar tunnelen.

Viss VPN-en sender sin eigen resolver og nettlesaren insisterer på sin eigen, får du ei splitting: namn vert løyst, sider vert lasta, og oppslaga som skulle gå gjennom tunnelen, gjekk rett ut. Ei resolveradresse som avvik frå VPN-endepunktet er ikkje prov på ein lekkasje i seg sjølv, men ein oppslagsveg som motseier den uttalte hensikta di, er verdt å rette.

Trinn fire: interne namn er der det bryt

Kopla til ein jobb-VPN og opne ein intranettvert. Viss den sikre DNS-en til nettlesaren er på og peikar på ein offentleg resolver, finst ikkje det namnet for nettlesaren. Tunnelen er oppe, alt anna verkar, og eitt vertsnamn feilar med ein feil som ser ut som at nettstaden er nede.

Den same feilen viser seg omvendt på Android. Streng privat DNS med ein offentleg leverandør løyser ikkje namn som berre den interne resolveren kjenner, og streng modus har ingen tilbakefall. Å dele DNS-en til ein telefon mellom ein offentleg kryptert resolver og ein bedriftsresolver er ikkje ei innstilling; det er eit spørsmål om ruteringspolicy som må svarast på av den som driv VPN-en.

Sjekk dette før du gjev tunnelen skulda: spør etter det interne namnet, og deretter det same namnet med den sikre DNS-en til nettlesaren slått av. Viss det vert løyst, var resolvervalet problemet, ikkje sambandet.

Kva gjennomgangen seier du skal endre

Fire skjermar ber nesten alt. Sjå på dei i denne rekkjefølgja og skriv ned kva kvar seier, for svaret er vanlegvis synleg i kombinasjonen:

1. Android-innstillingar, Nettverk og internett, Privat DNS: Automatisk eller eit leverandørvertsnamn, og kva vertsnamn.
2. Innstillinga for sikker DNS i nettlesaren: av, eller låst til ein bestemd resolver.
3. DNS-policyen til VPN-klienten: sender han ein resolver, og utelukkar delt tunnel noko som framleis treng namn?
4. Ein test av eit internt vertsnamn med tunnelen oppe, køyrd to gonger, éin gong med nettlesar-DNS på og éin gong av.

Tilpass deretter rettinga til kravet, ikkje omvendt. Viss kravet er at oppslag skal gå ut kryptert og til ein resolver du har valt, set streng privat DNS og få nettlesaren til å vere einig. Viss kravet er at trafikken skal gå ut ein annan stad, konfigurer tunnelen og slutt å vente på at ei DNS-innstilling flyttar adressa di.

Og hald grensene i sikte. Ingen av funksjonane gjer ein fiendtleg destinasjon trygg, og ingen fjernar ein identitet du er logga inn med. Kryptering endrar kven som kan lese spørsmålet; tunnelen endrar kvar sambandet går; ingenting av det anonymiserer kontoen.