OpenVPN envió un servidor DNS, pero Linux lo ignora

El servidor DNS enviado está en el registro, el túnel está levantado y los nombres internos siguen fallando. Nada está roto en el envío mismo; el ajuste llegó y se detuvo allí. Una opción DNS enviada es un mensaje al cliente, no una instrucción al resolutor del sistema operativo, y la entrega entre ambos es donde terminan la mayoría de estos casos. Cinco comprobaciones, en orden, encuentran la entrega que no ocurrió.

Comprobación uno: cómo empieza la conexión

El dueño de la conexión determina quién puede aplicar los ajustes del resolutor. Un comando openvpn directo desde un shell no posee nada más que su propio proceso, mientras que una unidad systemd, NetworkManager o un cliente de fabricante tienen cada uno su propia forma de publicar DNS. Lea la lista de procesos y el nombre de la unidad antes de suponer cualquiera de ellos.

Un proceso de línea de comandos no es automáticamente una conexión de NetworkManager, y una conexión de NetworkManager no es automáticamente lo que escribió resolv.conf. Esas dos suposiciones explican la mayor parte de las horas perdidas en esta investigación. Pregunte qué componente publicaría DNS para la interfaz que realmente ve.

Anote el dueño antes de continuar. Cada comprobación posterior depende de él.

Comprobación dos: qué contiene realmente el enlace del resolutor

En un host con systemd-resolved, resolvectl status enumera cada enlace con sus servidores DNS y dominios. Encuentre el enlace del túnel y lea sus entradas, y no suponga que la interfaz se llama tun0, porque la numeración sigue el orden de creación. Si la dirección enviada no está en el enlace, lo que falló fue la entrega, no la consulta.

Si la dirección está presente, la siguiente pregunta es qué dominios reclama ese enlace. Un enlace sin lista de dominios solo responde los nombres por los que se le pregunta directamente, y eso rara vez es lo que quiere un despliegue split-DNS. La dirección sola es necesaria pero no suficiente.

Compare el nombre del enlace en la salida del resolutor con el nombre de la interfaz en el registro del VPN antes de sacar cualquier conclusión. Una discrepancia allí suele significar que la línea del registro vino de otro proceso.

Comprobación tres: si el espacio de nombres elige ese enlace

Un resolutor puede tener el servidor correcto y aun así no ser consultado. El dominio por enlace decide qué consultas van a qué enlace, y sin un dominio de enrutamiento el espacio de nombres privado recae en lo que dice el enlace predeterminado. Por eso resolvectl query puede tener éxito para el nombre interno mientras una aplicación sigue fallando. Puede que la aplicación use una ruta de resolutor completamente distinta.

Compruebe la asignación de dominio, no solo la dirección del servidor. Un dominio escrito como ~corp.example es un dominio de enrutamiento, y la tilde cambia cómo se hace coincidir el nombre.

Si la aplicación tiene su propio resolutor, pruebe con el mismo mecanismo que usa ella en lugar de con la herramienta del sistema. Una herramienta de consulta que evita el resolutor del sistema tendrá éxito independientemente del estado del enlace.

Comprobación cuatro: un dueño, no dos

Si NetworkManager ya gestiona el VPN y el estado del resolutor, añadir un script de gancho no relacionado crea escritores que compiten. El gancho que el paquete proporciona para systemd-resolved es una integración soportada y espera un ciclo de vida concreto: script-security 2, una ruta up, up-restart, una ruta down y down-pre. Esas opciones hacen que el registro y la retirada ocurran en los momentos correctos y no solo en la primera conexión.

Use la ruta instalada por el paquete en lugar de una ilustrativa copiada de una guía. Los permisos también importan, porque el gancho se ejecuta después de que caigan los privilegios.

Editar un script de resolutor de la distribución para cambiar su destino de salida registra una solución temporal de un solo host. No es una reparación general.

Comprobación cinco: el mismo resultado tras reconectar

Reconecte y vuelva a leer el enlace. Un registro que aparece una vez y desaparece en la siguiente transición es el fallo para el que existe toda esta lista. Pruebe tras una suspensión, tras una reconexión forzada y tras reiniciar el servicio del resolutor. Cada transición pone a prueba una suposición de orden distinta.

Solo cuando las cinco comprobaciones pasan en una reconexión puede decir que los ajustes enviados están en uso. Cualquier cosa anterior es una instantánea de un momento afortunado.