DNS dividido sobre OpenVPN: qué debe hacer un dominio de enrutamiento en cada sistema operativo

Toda solicitud de DNS dividido empieza con la misma frase: los nombres de la empresa van al DNS de la empresa y todo lo demás sigue funcionando. Convertir esa frase en una configuración significa responder tres preguntas por sistema operativo, y las respuestas usan mecanismos distintos en cada uno. Los perfiles que funcionan en un portátil con Linux suelen fallar en Windows por motivos que no tienen nada que ver con el túnel. La diferencia suele ser un ajuste del resolutor confundido con una ruta.

Primero nombre la política y luego elija la primitiva de la plataforma que la expresa.

Tres ajustes que se confunden con facilidad

Un sufijo de búsqueda amplía un nombre corto: escribir files se convierte en files.corp.example cuando el resolutor prueba los sufijos en orden. Un dominio de enrutamiento selecciona qué resolutor responde las consultas dentro de un espacio de nombres. Una ruta IP solo hace accesible el resolutor elegido. Esos tres viven en capas distintas, e intercambiar uno por otro produce una configuración que parece correcta y no resuelve nada.

La confusión tiene un coste: añadir un sufijo de búsqueda envía todos los nombres cortos al resolutor de la empresa, incluidos nombres que pertenecen a otro sitio. Elegir un dominio de enrutamiento mantiene las consultas ajenas en el resolutor local mientras sigue enviando *.corp.example por el túnel.

Linux: un dominio solo de enrutamiento, no un sufijo de búsqueda

En systemd-resolved, un dominio con una tilde delante es un dominio solo de enrutamiento, es decir, las consultas de ese espacio de nombres van al resolutor vinculado sin convertirse también en sufijo de búsqueda. resolvectl domain tun0 '~corp.example' lo establece, y resolvectl dns tun0 10.8.0.1 nombra el servidor. Ambos ajustes pertenecen a la interfaz, así que desaparecen con ella. La tilde es la parte que la gente omite, y sin ella los nombres cortos empiezan a resolverse mediante el resolutor de la empresa.

No instale también el mismo dominio como sufijo de búsqueda global. Los dos ajustes no son redundantes; uno enruta y el otro reescribe lo que usted escribió.

Windows necesita una política de espacio de nombres, no un sufijo

Windows guarda la política de DNS dividido en la Name Resolution Policy Table, no en el sufijo DNS del adaptador. Una regla asigna un espacio de nombres a servidores concretos: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Establecer solo el sufijo cambia el aspecto de los nombres cortos; no dirige la consulta a otro servidor.

Compruebe la política efectiva con Get-DnsClientNrptPolicy después de conectar, porque una regla de una conexión anterior puede sobrevivir al túnel. Elimine las reglas por nombre cuando el túnel caiga y mantenga estable el nombre visible para que la limpieza acierte con la entrada correcta.

Mantenga un solo dueño del resolutor por plataforma

Un gestor de escritorio, un script up de OpenVPN y un demonio de resolutor local pueden intentar escribir la misma configuración. Cuando no coinciden, gana el último que escribe y el resultado depende del orden de desmontaje. Elija un componente que sea dueño del estado del resolutor, deje que los demás informen en lugar de escribir, y pruebe una reconexión: la política debería sobrevivir sin duplicar reglas. Pruebe también una desconexión, porque el estado sobrante es lo que hace que la siguiente conexión se comporte distinto.

Las aplicaciones que traen su propio resolutor cifrado ignoran por completo la política del sistema operativo. Eso es una propiedad de la aplicación, no un defecto del túnel.

Verifique el resultado, no el texto del perfil

Resuelva un nombre que debe ir por el túnel y otro que no, en cada plataforma, y confirme qué servidor respondió. resolvectl query host.corp.example y Resolve-DnsName host.corp.example informan ambos del servidor que respondió. Repítalo tras una reconexión. Después confirme que el resolutor del túnel es accesible en la dirección que impone el perfil, porque una política correcta que apunta a un servidor inaccesible falla igual que no tener ninguna.

Anote el comportamiento previsto en las notas del perfil: qué sufijo se enruta, qué servidor lo responde y qué ocurre con todo lo demás. La próxima plataforma que soporte necesitará esa frase más que el archivo de configuración.