Privaat DNS teenoor VPN: wat elke laag werklik dek

Jou foon het Privaat DNS op ’n verskaffer-gasheernaam gestel en terselfdertyd ’n VPN-program wat loop. Dit is redelik om aan te neem dat een van hulle nou in beheer is van naamsoektogte. Nie een is nie, in die sin wat daardie sin voorgee nie, en die vinnigste manier om te sien hoekom is om ’n enkele navraag te volg vanaf die oomblik wat jy op ’n skakel tik.

Hierdie twee funksies sit op verskillende plekke in dieselfde reis. Privaat DNS versleutel die vraag wat jy aan ’n resolver stel. ’n VPN verander die roete wat die verbinding van die antwoord volg.

Gaan dit dus in volgorde deur op ’n toestel waar albei geaktiveer is, en let op wat elke laag nog kan sien.

Stap een: die opsoeking verlaat die program

Jy tik op ’n skakel. Voordat enigiets verbind, het die program ’n adres vir daardie gasheernaam nodig. Op Android is die betrokke skerm Instellings, Netwerk en internet, Privaat DNS. As jy Privaat DNS-verskaffer-gasheernaam kies, sit dit die toestel in streng modus: dit doen DNS oor TLS na daardie gasheernaam op poort 853, en as die versleutelde uitruiling misluk, misluk die opsoeking eerder as om stilweg na gewone teks op poort 53 terug te val.

Dit is ’n betekenisvolle verskil van Outomaties, wat opportunistiese versleuteling gebruik en graag ’n onversleutelde resolver sal gebruik wanneer die netwerk inmeng. As jou doel is dat opsoektings nooit in die oopte is nie, is streng modus met ’n verskaffer-gasheernaam die instelling wat daarby pas.

Hier is die eerste ding wat die deurloop blootlê: die opsoeking is teen die plaaslike netwerk beskerm, en die resolver leer steeds die naam. Versleuteling dek die sprong. Die operateur van daardie resolver sien die navraag omdat dit sy werk is om dit te beantwoord.

Stap twee: die verbinding neem ’n ander roete

Die resolver gee ’n adres terug en die program verbind daarmee. Hierdie stap word nie beïnvloed deur hoe die opsoeking versleutel is nie. Sonder ’n tonnel verlaat die verbinding jou gewone publieke adres, en die bestemming-IP en die TLS-handdruk maak die gasheernaam gewoonlik tog vir die netwerk sigbaar, met of sonder versleutelde DNS.

Skakel die VPN aan en dit is die stap wat verander. Verkeer wat by die kliënt se roetebeleid pas, gaan deur die tonnel, die plaaslike netwerk sien ’n verbinding na die VPN-eindpunt, en die webwerf sien gewoonlik die uitgangsadres. Naamopsoeking kan ook deur die tonnel reis, afhangend van wat die kliënt stuur.

Daardie skeiding is die hele vergelyking in een sin. DNS-versleuteling beantwoord wie die vraag kan lees. ’n VPN beantwoord waarheen die gesprek gaan.

Stap drie: binne die tonnel word DNS ’n beleidsvraag

Nou werk die twee funksies saam, en die blaaier is die gewone bron van verrassing. ’n Blaaier met sy eie veilige DNS-instelling kan opsoektings oor HTTPS na sy gekose resolver stuur in plaas daarvan om die bedryfstelsel te vra. Android se Privaat DNS-instelling reik nie in daardie besluit in nie.

In Firefox is die skakelaar onder Instellings, Privaatheid en sekuriteit, Aktiveer veilige DNS. In Chrome is dit Instellings, Privaatheid en sekuriteit, Gebruik veilige DNS. Albei kan op ’n spesifieke verskaffer gestel of afgeskakel word, en wanneer hulle aan is, word die tonnel se DNS-opset vir daardie opsoektings omseil, al gebruik die bladsyverkeer steeds die tonnel.

As die VPN sy eie resolver stuur en die blaaier hou by sy eie, kry jy ’n splitsing: name los op, bladsye laai, en die opsoektings wat deur die tonnel moes gaan, het direk uitgegaan. ’n Resolver-adres wat van die VPN-eindpunt verskil is op sigself nie bewys van ’n lek nie, maar ’n opsoekingspad wat jou verklaarde bedoeling weerspreek, is die moeite werd om reg te maak.

Stap vier: interne name is waar dit breek

Koppel aan ’n werk-VPN en open ’n intranet-gasheer. As die blaaier se veilige DNS aan is en na ’n publieke resolver wys, bestaan daardie naam nie vir die blaaier nie. Die tonnel is op, alles anders werk, en een gasheernaam misluk met ’n fout wat lyk of die webwerf af is.

Dieselfde mislukking verskyn omgekeerd op Android. Streng Privaat DNS met ’n publieke verskaffer sal nie name oplos wat net die interne resolver ken nie, en streng modus het geen terugval nie. Om ’n foon se DNS tussen ’n publieke versleutelde resolver en ’n korporatiewe resolver te verdeel is nie ’n instelling nie; dit is ’n roetebeleidsvraag wat deur wie ook al die VPN bedryf beantwoord moet word.

Toets dit voordat jy die tonnel blameer: vra die interne naam, dan dieselfde naam met die blaaier se veilige DNS afgeskakel. As dit oplos, was die resolver-keuse die probleem, nie die verbinding nie.

Wat die deurloop jou sê om te verander

Vier skerms dra byna alles daarvan. Kyk in hierdie volgorde daarna en skryf neer wat elkeen sê, want die antwoord is gewoonlik in die kombinasie sigbaar:

1. Android-instelling, Netwerk en internet, Privaat DNS: Outomaties of ’n verskaffer-gasheernaam, en watter gasheernaam.
2. Die blaaier se veilige DNS-instelling: af, of vasgepen op ’n spesifieke resolver.
3. Die VPN-kliënt se DNS-beleid: stuur dit ’n resolver, en sluit verdeelde tonneling iets uit wat nog name nodig het?
4. ’n Interne gasheernaam-toets met die tonnel op, twee keer uitgevoer, een keer met blaaier-DNS aan en een keer af.

Pas dan die regstelling by die vereiste aan, nie omgekeerd nie. As die vereiste is dat opsoektings versleutel uitgaan en na ’n resolver van jou keuse, stel streng Privaat DNS en maak die blaaier daarmee saamstem. As die vereiste is dat verkeer elders uitgaan, stel die tonnel op en hou op om te verwag dat ’n DNS-instelling jou adres sal verskuif.

En hou die grense in sig. Nie een van die funksies maak ’n vyandige bestemming veilig nie, en nie een verwyder ’n identiteit waarmee jy aangemeld is nie. Versleuteling verander wie die vraag kan lees; die tonnel verander waarheen die verbinding gaan; niks aan enige van die twee anonimiseer die rekening nie.