DNS dividido y VPN: las reglas de dominio no son rutas IP

Su portátil resuelve intranet.corp a través del túnel mientras gitlab.com sigue yendo al resolutor del proveedor, y esa es la disposición que funciona tal como se diseñó. Dos decisiones separadas la produjeron: una regla de coincidencia de nombres eligió el resolutor y una ruta trajo la respuesta de vuelta. Rompa cualquiera de las dos y el navegador muestra un fallo que desde fuera parece el mismo. La mayoría de los informes de DNS dividido describen el segundo fallo mientras citan pruebas sobre el primero.

Las dos mitades viven en sitios distintos y normalmente las editan personas distintas. Una es la política de DNS adjunta al perfil de VPN, la otra es una ruta que el túnel instala o retiene. La depuración se detiene cuando nadie establece qué mitad se movió realmente.

Dos decisiones escondidas en una petición

La mitad del nombre es un objeto de política, no una ruta. En Windows es una política de resolución de nombres en el perfil de VPN; en las plataformas de Apple, un conjunto de dominios de coincidencia en un objeto de ajustes de DNS; en Linux, un dominio de enrutamiento, una línea de resolutor dividido o el orden del conmutador de servicios de nombres. La mitad del camino es enrutamiento corriente, instalado por el túnel o a mano, y no tiene idea de qué es un nombre de host. Un perfil que admite un sufijo solo decide quién responde; nunca hace que la respuesta sea alcanzable.

Una prueba rápida de síntomas las separa: sustituya el nombre por una dirección. Si la dirección funciona, el camino está bien y la regla es incorrecta. Si la dirección también falla, la regla puede ser correcta y faltar el camino.

Cómo expresa cada plataforma la misma regla de nombres

La intención es idéntica y los nombres de campo no. Un ejemplo copiado de un cliente a otro se analiza limpiamente y nunca coincide. Las tres formas son así:

Un dominio de coincidencia o de enrutamiento es una prueba de sufijo, así que intranet.corp cubre git.intranet.corp y no cubre corp.intranet, e invertirlo es el error más común de toda la configuración. Windows lleva la asignación como una política de resolución de nombres adjunta al perfil, con su propio orden de precedencia frente a cualquier lista de sufijos que la interfaz ya tuviera. Las plataformas de Apple adjuntan los dominios de coincidencia al objeto de ajustes de DNS de la extensión de red, y el sistema los aplica por cada resolutor con ámbito. Ninguna de estas formas es una ruta, y ninguna puede hacer alcanzable una dirección inalcanzable. La referencia política de resolución de nombres de Windows enumera los nombres de campo y las reglas de precedencia para esa plataforma, y no son las que usan los documentos de Apple o systemd.

Una respuesta correcta aún necesita un camino

La respuesta de un resolutor solo es una dirección, y la aplicación todavía tiene que llegar a ella. Un diseño de túnel dividido suele empujar 10.20.0.0/16 y retener la ruta por defecto, así que el nombre interno se resuelve y la conexión se cuelga después. El caso contrario es igual de común: la ruta existe, un resolutor público responde al nombre privado con NXDOMAIN y el fallo se archiva como problema de enrutamiento. Probar el camino primero le deja mirando rutas para un nombre que nunca iba a resolverse.

También hay una tercera puerta que ninguna mitad cubre. Una ACL en la pasarela, una regla de cortafuegos o una política del lado del cliente pueden dejar caer la conexión después de que ambas decisiones fueran correctas. Cuando el nombre se resuelve, la ruta existe y la conexión sigue agotando el tiempo, deje de probar DNS.

Probar nombres y caminos en un orden fijo

Elija un orden y manténgalo, o perseguirá el paso que falló más recientemente. Resuelva el nombre interno completo documentado, confirme que la respuesta es una dirección que la tabla de rutas puede llevar, y luego repita con un nombre público para demostrar que el túnel no lo capturó todo. En un host systemd la consulta y el dominio de enrutamiento del resolutor están a un comando de distancia:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Un cliente de Windows hace las mismas dos preguntas con otros cmdlets. El segundo informa de la interfaz que el sistema usaría realmente:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

Si la búsqueda devuelve una dirección y la comprobación del camino nombra la interfaz física, la regla de nombres funcionó y la ruta no. Si el nombre corto falla mientras el nombre completo se resuelve, la lista de sufijos es incorrecta y no el resolutor.

Dónde suele ir mal la comparación

El primer error es preguntar a un resolutor público no relacionado por un nombre privado y leer el rechazo como prueba sobre la VPN. El segundo es suponer que una búsqueda pública que funciona demuestra el camino del resolutor del túnel. El tercero es tratar el túnel dividido y el DNS dividido como una sola decisión de diseño, cuando un despliegue puede ser correcto en uno y estar roto en el otro. Cada error produce conclusiones seguras a partir de una prueba que nunca ejercitó la parte acusada.

Un navegador con su propio DNS seguro también puede saltarse la regla del sistema, por eso que un navegador falle mientras otro funciona no es una contradicción. Compare el resolutor que respondió, no el navegador que se quejó.

Una vez que ambas mitades son visibles, la pregunta restante es de política y no técnica: qué espacios de nombres pertenecen a la organización, quién posee cada respuesta y cuáles de ellos deberían salir de la máquina. Escríbalo junto al perfil, porque la siguiente persona que toque la regla lo necesitará.