DNS privat enfront de VPN: què cobreix realment cada capa

El teu telèfon té el DNS privat configurat amb un nom d’amfitrió de proveïdor i una aplicació VPN en marxa alhora. És raonable suposar que un dels dos ja s’encarrega de les consultes de noms. No ho fa cap dels dos, en el sentit que suggereix aquesta frase, i la manera més ràpida de veure per què és seguir una sola sol·licitud des del moment que toques un enllaç.

Aquestes dues funcions se situen en punts diferents del mateix recorregut. El DNS privat xifra la pregunta que fas a un resolutor. Una VPN canvia la ruta que pren la connexió de la resposta.

Així que recorre-ho per ordre, en un dispositiu on totes dues estiguin activades, i fixa’t en què pot veure encara cada capa.

Pas u: la consulta surt de l’aplicació

Toques un enllaç. Abans que res es connecti, l’aplicació necessita una adreça per a aquest nom d’amfitrió. A Android, la pantalla rellevant és Configuració, Xarxa i Internet, DNS privat. Si tries Nom d’amfitrió del proveïdor de DNS privat, el dispositiu passa al mode estricte: fa DNS sobre TLS cap a aquest nom d’amfitrió al port 853, i si l’intercanvi xifrat falla, la consulta falla en lloc de tornar silenciosament al text pla al port 53.

Això és una diferència important respecte d’Automàtic, que fa servir xifratge oportunista i no dubtarà a utilitzar un resolutor sense xifrar quan la xarxa interfereix. Si el teu objectiu és que les consultes no vagin mai en clar, el mode estricte amb un nom d’amfitrió de proveïdor és la configuració que hi encaixa.

Aquí tens la primera cosa que el recorregut deixa al descobert: la consulta està protegida contra la xarxa local, i el resolutor continua sabent el nom. El xifratge cobreix el salt. L’operador d’aquest resolutor veu la consulta perquè respondre-la és la seva feina.

Pas dos: la connexió pren una ruta diferent

El resolutor retorna una adreça i l’aplicació s’hi connecta. Aquest pas no es veu afectat per com es va xifrar la consulta. Sense túnel, la connexió surt de la teva adreça pública habitual, i la IP de destinació i l’aplec de mans TLS solen fer visible el nom d’amfitrió a la xarxa igualment, amb DNS xifrat o sense.

Activa la VPN i aquest és el pas que canvia. El trànsit que coincideix amb la política d’encaminament del client passa pel túnel, la xarxa local veu una connexió a l’extrem de la VPN, i el lloc normalment veu l’adreça de sortida. La resolució de noms també pot viatjar dins del túnel, segons què hi empenyi el client.

Aquesta separació és tota la comparació en una frase. El xifratge de DNS respon qui pot llegir la pregunta. Una VPN respon on va la conversa.

Pas tres: dins del túnel, el DNS esdevé una qüestió de política

Ara les dues funcions interactuen, i el navegador és la font habitual de sorpreses. Un navegador amb la seva pròpia configuració de DNS segur pot enviar consultes al resolutor que ha triat per HTTPS en lloc de preguntar el sistema operatiu. La configuració de DNS privat d’Android no arriba a aquesta decisió.

A Firefox l’interruptor és a Configuració, Privadesa i seguretat, Activa el DNS segur. A Chrome és a Configuració, Privadesa i seguretat, Utilitza el DNS segur. Tots dos es poden fixar en un proveïdor concret o deixar desactivats, i quan estan activats, la configuració de DNS del túnel se salta per a aquestes consultes tot i que el trànsit de la pàgina continua utilitzant el túnel.

Si la VPN empeny el seu propi resolutor i el navegador s’entesta a fer servir el seu, obtens una divisió: els noms es resolen, les pàgines carreguen, i les consultes que havien de passar pel túnel van sortir directament. Una adreça de resolutor diferent de l’extrem de la VPN no és prova d’una fuita per si sola, però un camí de consulta que contradiu la teva intenció declarada val la pena de corregir.

Pas quatre: els noms interns són on es trenca

Connecta’t a una VPN de feina i obre un amfitrió d’intranet. Si el DNS segur del navegador està activat i apunta a un resolutor públic, aquell nom no existeix per al navegador. El túnel està aixecat, tota la resta funciona, i un nom d’amfitrió falla amb un error que sembla que el lloc estigui caigut.

La mateixa fallada apareix a l’inrevés a Android. El DNS privat estricte amb un proveïdor públic no resoldrà noms que només coneix el resolutor intern, i el mode estricte no té cap alternativa. Repartir el DNS d’un telèfon entre un resolutor públic xifrat i un resolutor corporatiu no és una configuració; és una qüestió de política d’encaminament que ha de respondre qui gestiona la VPN.

Comprova-ho abans de culpar el túnel: consulta el nom intern, i després el mateix nom amb el DNS segur del navegador desactivat. Si es resol, la selecció de resolutor era el problema, no la connexió.

Què et diu el recorregut que has de canviar

Quatre pantalles en porten gairebé tot. Mira-les en aquest ordre i apunta què diu cadascuna, perquè la resposta normalment es veu en la combinació:

1. Configuració d’Android, Xarxa i Internet, DNS privat: Automàtic o un nom d’amfitrió de proveïdor, i quin nom d’amfitrió.
2. La configuració de DNS segur del navegador: desactivada, o fixada en un resolutor concret.
3. La política de DNS del client VPN: empeny un resolutor, i l’encaminament dividit exclou res que encara necessiti noms?
4. Una prova de nom d’amfitrió intern amb el túnel aixecat, feta dues vegades, una amb el DNS del navegador activat i una amb ell desactivat.

Després ajusta la solució al requisit, no a l’inrevés. Si el requisit és que les consultes surtin xifrades i vagin a un resolutor que hagis triat, configura el DNS privat estricte i fes que el navegador hi estigui d’acord. Si el requisit és que el trànsit surti en un altre lloc, configura el túnel i deixa d’esperar que una configuració de DNS mogui la teva adreça.

I tingues presents els límits. Cap de les dues funcions fa segur una destinació hostil, i cap no elimina una identitat amb què hagis iniciat sessió. El xifratge canvia qui pot llegir la pregunta; el túnel canvia on va la connexió; res de cap de les dues anonimitza el compte.