Adónde va el DNS cuando combinas Tor y una VPN

Hay dos herramientas de privacidad en marcha, una página no carga y una prueba de resolución dice que algo fuera del navegador recibió un nombre. Antes de que eso se convierta en un informe de fuga, nombra el intercambio del que provino. Una configuración de Tor más VPN contiene al menos tres consultas de nombres distintas con tres responsables distintos, y recorrerlas en el orden en que ocurren es la forma más rápida de ver cuál se está comportando mal.

Nombra cada intercambio antes de llamarlo fuga

El primer intercambio resuelve el propio extremo de la VPN y ocurre antes de que exista protección alguna. El segundo resuelve un destino para el navegador Tor, que puede entregar el nombre al proxy en lugar de resolverlo localmente. El tercero cubre todo lo demás en la máquina, incluidas las comprobaciones de actualizaciones, los clientes de correo y las consultas de servicio del propio sistema operativo. Solo el primero puede ocurrir sin que participen los otros dos.

Cada uno puede seguir una ruta distinta, y una única prueba en el navegador solo observa su propia solicitud. Tomar un resultado como el estado de los tres es donde empieza la mayor parte de la confusión.

Anota qué nombres pertenecen a qué capa antes de cambiar nada. Los nombres organizativos privados, un destino público y el propio extremo del túnel no tienen el mismo requisito, y una política que los trate como una sola categoría romperá algo.

La consulta de arranque ocurre antes del túnel

Un cliente configurado con un nombre de host tiene que resolver ese nombre para abrir el túnel, y en ese momento no existe ningún túnel que lleve la consulta. Responde cualquier resolutor que el sistema operativo ofrezca en la red actual, que puede ser un portal cautivo, un resolutor de hotel o uno público. Eso no es una fuga en el túnel, porque todavía no hay túnel.

Cambiar el ajuste de DNS seguro del navegador tampoco afecta a esta consulta, ya que pertenece a un servicio que se ejecuta fuera del navegador y arranca antes de que se abra cualquier página. Si el nombre del extremo no se resuelve, ninguna política dentro del túnel ayudará, porque el fallo ocurre una etapa antes de todo lo que describe la configuración.

Este es el único lugar donde usar una dirección literal para el extremo, si el proveedor lo admite, elimina una dependencia en lugar de añadir una. También elimina la capacidad de seguir a un proveedor que rota direcciones, así que el intercambio es real y debería decidirse en lugar de descubrirse.

El navegador y el resto de la máquina difieren

La interfaz SOCKS de Tor admite pasar un nombre de host de destino al proxy, lo que significa que el extremo remoto realiza la resolución y la máquina local nunca pregunta. Una aplicación genérica que admite un proxy puede resolver el nombre localmente primero y luego conectarse a la dirección obtenida, lo que produce una consulta local para un destino que el usuario creía proxificado. Por tanto, las dos aplicaciones pueden filtrar en lugares distintos mientras comparten un único ajuste de proxy. Nada en una dirección de proxy compartida le dice cuál de los dos comportamientos está en uso.

Los navegadores añaden otra capa cuando el DNS seguro está activado, porque el navegador puede elegir su propio proveedor y saltarse por completo el resolutor del sistema. El cliente del túnel, mientras tanto, puede empujar un resolutor por el túnel para toda la máquina. Esos dos ajustes pueden ser correctos a la vez y describir aun así comportamientos distintos para programas distintos.

Comprueba el programa que hizo la solicitud en lugar de extrapolar desde una página de prueba. La distinción entre una consulta llevada dentro del túnel y una que nunca llegó a Tor es exactamente la distinción que una sola dirección de resolutor no puede mostrar.

Comprueba cada programa y luego compáralo con la intención

Realiza las observaciones por separado: qué usaría el sistema, para qué está configurado el navegador y si la conexión SOCKS lleva un nombre o una dirección. Esto último es la diferencia entre resolución remota y local, y especificación de extensiones de SOCKS describe cómo se pasa un nombre de host en lugar de resolverlo primero.

resolvectl status | grep -E "Current DNS Server|DNS Servers"
ss -tnp '( dport = :9050 )'
dig +short dev.internal.example
getent hosts vpn-endpoint.example.net

Luego compara lo observado con lo que pretendías. Un nombre público resuelto a través del túnel por un resolutor que elegiste no es el mismo hallazgo que un nombre privado entregado a un resolutor público durante una caída, y normalmente solo el segundo requiere acción. El primero es una configuración que funciona según lo diseñado, aunque parezca poco familiar en un informe.

Registra las excepciones que aceptas, incluida la consulta de arranque que no se puede proteger. Una excepción escrita es una decisión de diseño, mientras que la misma excepción descubierta más tarde parece un defecto. Quien la encuentre la tratará como tal, y pasarás la reunión explicando por qué no lo es.