El túnel dividido excluye el navegador, no sus consultas DNS

Navegador excluido del túnel, la página de IP pública confirma que su tráfico sale por la conexión de casa, y la wiki interna sigue sin abrirse. La resolución de nombres se fue a otro sitio, y ese otro sitio suele ser el resolutor que configuró la VPN. La ruta de datos y la ruta del resolutor son decisiones separadas en la mayoría de diseños de túnel dividido. Compruebe cuál usó realmente el navegador antes de llamar rota a la exclusión.

La ruta de datos y la ruta del resolutor se separan

Una exclusión saca los paquetes de una aplicación del túnel, lo que es una decisión de enrutamiento y cortafuegos en la ruta de datos. La resolución de nombres es otra consulta: un proceso pregunta al resolutor del sistema, y ese resolutor decide qué servidor recibe la pregunta.

Ambas pueden ser intencionadas y distintas. Un despliegue de trabajo puede mantener los espacios de nombres internos en el resolutor corporativo mientras envía la navegación pública seleccionada fuera del túnel, precisamente porque los nombres internos no se resuelven en ningún otro sitio. El caso confuso es el contrario: un sitio público falla porque el navegador nunca preguntó al resolutor que el despliegue esperaba. Anote la ruta y el resolutor por separado, y la mitad de las discusiones desaparece.

Averigüe qué proceso hace la pregunta

Un navegador puede usar el resolutor del sistema, su propio servicio de DNS cifrado, o un resolutor que el sistema operativo asigna por red. El primero sigue la política de la plataforma, el segundo evita esa política por completo, y el tercero depende de a qué enlace se enruta la consulta.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Lea la configuración efectiva antes de probar: qué enlaces llevan servidores DNS, qué espacios de nombres reclaman, y si una política por nombre sustituye el valor predeterminado. En Linux, el DNS dividido usa dominios de enrutamiento; en Windows, la tabla de políticas de resolución de nombres hace lo mismo para los espacios de nombres. Ninguna de las dos se ve desde una página de prueba de fugas.

Decida qué resolutor debe ver cada nombre

Escriba la asignación prevista antes de cambiar nada: nombres internos al resolutor corporativo, nombres públicos al servicio que la política permita, y excepciones con un responsable. Sin esa lista, cada etiqueta de la prueba de fugas se convierte en una discusión de política que nadie puede zanjar.

Luego revise la configuración propia del navegador, porque el DNS cifrado del navegador se aplica antes de que el sistema operativo reciba la consulta. Un usuario que lo activó para saltarse un portal cautivo ha sustituido en silencio el resolutor que eligió el despliegue. Eso es una decisión de configuración y no una fuga, y merece una decisión en lugar de una lista de bloqueo.

No reescriba todos los campos DNS para que una etiqueta de prueba se ponga verde. La etiqueta describe una consulta de un proceso en un momento.

Verifique consulta y conexión por separado

Pruebe las dos rutas por separado. La prueba de conexión muestra la ruta de datos, y la prueba del resolutor muestra quién recibió el nombre.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

Pregunte también al resolutor de forma explícita, para que un fallo se pueda atribuir al servidor y no a la ruta. Después reinicie el navegador y repita, porque las aplicaciones guardan en caché las respuestas negativas y un fallo antiguo parece persistente.

Tras un cambio aprobado, anote la ruta de datos y el destinatario del resolutor como dos líneas separadas con la fecha. Si el comportamiento vuelve en la próxima reconexión, el perfil que lo proporciona es lo que hay que corregir, no el navegador.