OpenVPN envía DNS, pero tu resolutor puede no verlo nunca

El registro del cliente muestra el servidor DNS enviado, el túnel está conectado y un nombre interno sigue sin resolverse. Nada está roto en el envío. La opción llegó y el resolutor del sistema operativo nunca la usó, porque en la mayoría de clientes Unix OpenVPN entrega el valor y deja la aplicación a la plataforma.

El síntoma: el registro muestra DNS y los nombres siguen fallando

OpenVPN dhcp-option transporta información de DNS y de dominio, y el cliente registra lo que recibió. En algunas implementaciones el cliente aplica esos ajustes internamente; en otras los exporta para que los consuma un script de integración o un servicio de red. La línea del registro describe solo la primera mitad de la historia. La segunda mitad ocurre en un lugar que el cliente no controla. Ahí suele vivir el fallo.

Por eso un túnel conectado y un nombre interno que falla coexisten tan a menudo. El valor está presente, el consumidor falta o está mal configurado, y el resolutor sigue usando en silencio el servidor público que usaba antes de la conexión.

Recibir no es aplicar

Un cliente puede registrar un valor DNS enviado mientras el resolutor del sistema sigue siendo propiedad de otro servicio. Un navegador también puede tener su propia política de DNS cifrado que omita por completo el resolutor del sistema, lo que produce la memorable situación en la que una aplicación resuelve nombres internos y otra no.

Comprueba la integración admitida de la implementación en lugar de suponer que todos los clientes Unix reescriben el mismo archivo. Esa suposición es la razón por la que la gente edita una configuración de resolutor que nada lee.

Encuentra el propietario del resolutor en cada plataforma

En Windows, la tabla de directivas de resolución de nombres puede dirigir sufijos concretos a servidores concretos, y el cliente VPN puede instalar reglas allí. Comprueba la directiva, no solo la lista DNS del adaptador. En Linux, NetworkManager o systemd-resolved pueden ser dueños de la configuración, y cuál de los dos lo sea determina qué conservará una reconexión.

Lee el estado efectivo con la herramienta que de verdad responde consultas: resolvectl query internal.example.net en un host con systemd-resolved, o el equivalente de la plataforma. Después compara esa respuesta con el servidor DNS que el registro del cliente dice haber enviado.

Evita ejecutar varios servicios que sobrescriban la configuración del resolutor sin coordinación. Dos propietarios producen un resultado que parece intermitente, y cada reconexión parece arreglarlo o romperlo al azar.

Scripts y foreign_option

OpenVPN exporta las opciones enviadas a los scripts mediante variables llamadas foreign_option_N, y un script puede traducirlas en comandos de resolutor. Ese arreglo es una integración admitida, no un comportamiento automático, y debe instalarse e invocarse en el cliente.

Si dependes de un script, registra su ejecución y su estado de salida. Un script que se ejecuta pero falla en silencio deja el mismo síntoma que no tener script, y es más difícil de notar porque la configuración parece completa. Comprueba la salida del script, no el archivo del script. Un archivo que existe no es un script que se ejecutó.

Prueba el nombre, no el registro

Consulta un nombre de host solo interno desde el cliente después de conectar, luego consulta un nombre público y después comprueba qué servidor respondió. En una configuración que funciona, las dos respuestas vienen de lugares distintos y ambas deberían coincidir con el diseño.

Si el nombre se resuelve pero el servicio falla, pasa a el enrutamiento y el acceso de aplicaciones en lugar de cambiar el DNS otra vez. El manual de OpenVPN documenta dhcp-option y el entorno de scripts; úsalo para confirmar qué se espera que aplique tu cliente antes de editar otro archivo de resolutor.