DNS privado fronte a VPN: que cobre realmente cada capa

O teu teléfono ten o DNS privado configurado cun nome de host do provedor e unha aplicación VPN en execución ao mesmo tempo. É razoable supor que un dos dous xa se encarga das consultas de nomes. Ningún o fai, no sentido que suxire esa frase, e a forma máis rápida de ver por que é seguir unha única solicitude desde o momento en que tocas unha ligazón.

Estas dúas funcións sitúanse en puntos distintos da mesma viaxe. O DNS privado cifra a pregunta que lle fas a un resolutor. Unha VPN cambia a ruta que toma a conexión da resposta.

Así que recórreo en orde, nun dispositivo onde ambas estean activadas, e fixa en que pode ver aínda cada capa.

Paso un: a consulta sae da aplicación

Tocas unha ligazón. Antes de que nada se conecte, a aplicación necesita un enderezo para ese nome de host. En Android, a pantalla relevante é Axustes, Rede e Internet, DNS privado. Se escolletes Nome de host do provedor de DNS privado, o dispositivo pasa ao modo estrito: fai DNS sobre TLS cara a ese nome de host no porto 853, e se o intercambio cifrado falla, a consulta falla en lugar de volver en silencio ao texto plano no porto 53.

Esa é unha diferenza importante respecto de Automático, que emprega cifrado oportunista e non dubidará en usar un resolutor sen cifrar cando a rede interfire. Se o teu obxectivo é que as consultas nunca vaian en claro, o modo estrito cun nome de host de provedor é a configuración que encaixa.

Aquí está o primeiro que revela o percorrido: a consulta está protexida contra a rede local, e o resolutor segue coñecendo o nome. O cifrado cobre o salto. O operador dese resolutor ve a consulta porque respondela é o seu traballo.

Paso dous: a conexión toma outra ruta

O resolutor devolve un enderezo e a aplicación conéctase a el. Este paso non se ve afectado por como se cifrou a consulta. Sen túnel, a conexión sae do teu enderezo público habitual, e o IP de destino e o apretón de mans TLS adoitan facer visible o nome de host para a rede de todos os xeitos, con DNS cifrado ou sen el.

Activa a VPN e este é o paso que cambia. O tráfico que coincide coa política de encamiñamento do cliente pasa polo túnel, a rede local ve unha conexión ao extremo da VPN, e o sitio adoita ver o enderezo de saída. A resolución de nomes tamén pode viaxar dentro do túnel, dependendo do que empuxe o cliente.

Esa separación é toda a comparación nunha frase. O cifrado de DNS responde quen pode ler a pregunta. Unha VPN responde cara a onde vai a conversa.

Paso tres: dentro do túnel, o DNS convértese nunha cuestión de política

Agora as dúas funcións interactúan, e o navegador é a fonte habitual de sorpresas. Un navegador coa súa propia configuración de DNS seguro pode enviar consultas ao resolutor que escolleu por HTTPS en lugar de preguntarlle ao sistema operativo. A configuración de DNS privado de Android non chega a esa decisión.

En Firefox o interruptor está en Axustes, Privacidade e seguridade, Activar DNS seguro. En Chrome está en Axustes, Privacidade e seguridade, Usar DNS seguro. Ambos poden fixarse a un provedor concreto ou deixarse desactivados, e cando están activados, a configuración de DNS do túnel omítese para esas consultas aínda que o tráfico da páxina segue usando o túnel.

Se a VPN empuxa o seu propio resolutor e o navegador insiste no seu, obtés unha división: os nomes resólvense, as páxinas cargan, e as consultas que debían pasar polo túnel saíron directamente. Un enderezo de resolutor distinto do extremo da VPN non é proba dunha fuga por si só, pero un camiño de consulta que contradí a túa intención declarada merece corrixirse.

Paso catro: os nomes internos son onde se rompe

Conéctate a unha VPN de traballo e abre un host de intranet. Se o DNS seguro do navegador está activado e apunta a un resolutor público, ese nome non existe para o navegador. O túnel está levantado, todo o demais funciona, e un nome de host falla cun erro que parece que o sitio está caído.

O mesmo fallo aparece ao revés en Android. O DNS privado estrito cun provedor público non resolverá nomes que só coñece o resolutor interno, e o modo estrito non ten alternativa. Repartir o DNS dun teléfono entre un resolutor público cifrado e un resolutor corporativo non é unha configuración; é unha cuestión de política de encamiñamento que debe responder quen xestiona a VPN.

Comproba isto antes de culpar o túnel: consulta o nome interno, e despois o mesmo nome co DNS seguro do navegador desactivado. Se se resolve, a selección de resolutor era o problema, non a conexión.

Que che di o percorrido que cambies

Catro pantallas levan case todo. Míraas nesta orde e anota o que di cada unha, porque a resposta adoita estar visible na combinación:

1. Axustes de Android, Rede e Internet, DNS privado: Automático ou un nome de host de provedor, e que nome de host.
2. A configuración de DNS seguro do navegador: desactivada, ou fixada a un resolutor concreto.
3. A política de DNS do cliente VPN: empuxa un resolutor, e o túnel dividido exclúe algo que aínda necesita nomes?
4. Unha proba de nome de host interno co túnel levantado, executada dúas veces, unha co DNS do navegador activado e outra desactivado.

Logo axusta a corrección ao requisito, non ao revés. Se o requisito é que as consultas saian cifradas e vaian a un resolutor que escolliches, configura o DNS privado estrito e fai que o navegador estea de acordo. Se o requisito é que o tráfico saia noutro sitio, configura o túnel e deixa de esperar que unha configuración de DNS mova o teu enderezo.

E ten presentes os límites. Ningunha das dúas funcións fai seguro un destino hostil, e ningunha elimina unha identidade coa que iniciaches sesión. O cifrado cambia quen pode ler a pregunta; o túnel cambia cara a onde vai a conexión; nada diso anonimiza a conta.