DNS empujado por OpenVPN ignorado: qué componente lo aplica

El registro muestra la opción que el servidor empujó, el túnel está activo y los nombres internos siguen fallando. Una consulta directa al resolutor responde, así que el servidor está bien, pero cada aplicación sigue preguntando al enrutador local. Lo que llegó al cliente es una oferta, no un cambio en el resolutor, y el componente que posee la resolución de nombres difiere en Linux, Windows y macOS. Cuando separa la opción de su dueño, cuatro fallos cubren casi todos los informes: ningún hook, dos hooks en competencia, DNS dividido funcionando según el diseño, o un nombre corto que necesita un sufijo y no un servidor.

Una opción empujada es una oferta, no una instalación

En el servidor, dos directivas describen la intención, no el efecto:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

El cliente no recibe un resolutor configurado. Recibe variables de entorno, foreign_option_1 y siguientes, una por cada línea empujada, y algo local debe leerlas y reescribir el estado del resolutor del sistema operativo. En Linux nada lo hace por defecto, por eso un servidor correcto y un cliente conectado pueden seguir resolviendo por la LAN.

Hay tres etapas entre los dos extremos: el push debe viajar, el cliente debe exponerlo y un hook debe aplicarlo. Lea la etapa intermedia en el registro del cliente y la última en el estado del resolutor, nunca al revés, porque una línea de registro solo demuestra las dos primeras.

Confirme que el push llegó y encuentre al dueño

Empiece nombrando el lanzador: un comando openvpn desnudo, una instancia de systemd, NetworkManager o un cliente del proveedor. Eso decide dónde puede vivir un hook. En un host con systemd-resolved, resolvectl status enumera cada enlace con los servidores DNS y los dominios de búsqueda que realmente usa, y el enlace del túnel no siempre se llama tun0.

Si la dirección empujada aparece en el registro pero no en ningún enlace, falta la integración. Si aparece en el enlace y las consultas siguen saliendo por otro lado, el problema es qué consultas seleccionan ese enlace. NetworkManager dns=dnsmasq en el archivo /etc/NetworkManager/NetworkManager.conf ejecuta un reenviador local que implementa DNS dividido a propósito: los nombres dentro del dominio VPN van al resolutor VPN y todo lo demás conserva su ruta anterior. Ese comportamiento parece un fallo cuando esperaba que se moviera todo el tráfico; revise la configuración por conexión con nmcli connection show "My VPN", donde ipv4.dns y ipv4.dns-search guardan los valores detrás de lo que informa el dispositivo, antes de llamarlo roto. Si de verdad todas las consultas deben llegar al resolutor VPN, quite dns=dnsmasq de NetworkManager.conf y reinicie NetworkManager, lo que devuelve la resolución a la configuración de la conexión; de lo contrario, mantenga el DNS dividido y corrija la lista de dominios empujados.

Linux: entregue las opciones al resolutor

Los paquetes de las distribuciones incluyen un hook para esto, y debe permitirse al cliente ejecutarlo. Un montaje típico en un host sin systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Con systemd-resolved, el script antiguo de resolv.conf puede no cambiar nada importante, porque el resolutor stub mantiene estado por enlace. update-systemd-resolved el ayudante documenta una forma de hook que usa up-restart y down-pre, lo que importa cuando una interfaz sobrevive a un solo intento de conexión. Elija lo que elija, un componente debe poseer el estado. Añadir un hook ajeno junto a NetworkManager da dos escritores al mismo enlace, y entonces el resultado depende del orden y no de su configuración.

También existe el caso en que NetworkManager ignoró por completo la opción empujada hasta que la dirección del servidor se introdujo en la configuración IPv4 de la conexión, y después el estado del resolutor mostró que estaba en uso. Merece la pena probarlo antes de reescribir scripts, porque traslada el problema de un hook de shell al perfil de conexión que ya lleva el túnel.

Windows y macOS aplican partes distintas

El cliente de Windows sí define los servidores DNS del adaptador VPN, pero Windows sigue eligiendo la interfaz por métrica y sigue necesitando un sufijo para expandir un nombre corto. Confirme el estado del adaptador y no el perfil:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Si falta la dirección, defínala con Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, después añada el sufijo a las propiedades IPv4 del adaptador para que fileserver se convierta en fileserver.corp.example. Un valor SearchList de todo el equipo bajo Tcpip\Parameters hace lo mismo. Donde el nombre largo resuelve y el desnudo no, el resolutor ya es correcto y la culpa es de la lista de búsqueda. Las correcciones, en orden: empuje un DOMAIN para que el cliente aprenda el sufijo, añada ese sufijo a la lista de búsqueda del adaptador o de la conexión, y como medida temporal fije el nombre en hosts, o LMHOSTS en Windows; la exploración NetBIOS no cruza un enrutador, así que la difusión que encuentra un nombre corto en la LAN de la oficina nunca llega a un cliente de túnel.

block-outside-dns block-outside-dns es un comportamiento del cliente de Windows, no una línea de perfil portátil, y copiarlo a un perfil de Linux o macOS no lo reproduce allí. Si los nombres públicos funcionan y los internos fallan en Windows, compare el orden de adaptadores en Configuración avanzada con ipconfig /all. En macOS el orden de resolutores por servicio pertenece al sistema, así que use scutil --dns para ver qué resolutor se consulta para qué dominio, y trate cualquier corrección de perfil reportada como dependiente del cliente y no como general.

Una máquina virtual en el mismo portátil no hereda nada de esto. Dé al invitado su propia entrada de resolutor para el dominio interno, o deje que el NAT del hipervisor reenvíe sus consultas a través del host, lo que solo es correcto mientras el túnel del host está activo.

El historial es la tercera causa. Servidores DNS o ajustes de sufijo de un perfil anterior pueden sobrevivir a reconexiones, así que cuando el adaptador parece correcto y las búsquedas siguen fallando, compare el adaptador vivo con Get-VpnConnection y borre o sobrescriba la entrada obsoleta antes de tocar el servidor.

Demuestre adónde fue la consulta

Una captura durante una búsqueda zanja la discusión: tcpdump -ni eth0 port 53 muestra consultas en la interfaz física, lo que significa que salen fuera del túnel y que el resolutor nunca se cambió. dig @10.8.0.1 name.corp.example luego separa los dos casos restantes. Si la consulta directa responde, el resolutor funciona y el cliente no lo usa; si expira, el resolutor es inalcanzable por el túnel y ningún cambio local ayudará.

Si el resolutor que aún se usa es el que repartió el proveedor, el túnel cifra el tráfico mientras los nombres siguen visibles para ese proveedor. Es una cuestión de fuga y no de funcionamiento, y la misma captura la responde: una consulta en la interfaz física va a alguien fuera del túnel.

La accesibilidad incluye el cortafuegos del host VPN, que debe permitir UDP y TCP 53 desde el grupo. Un puerto bloqueado parece exactamente un push roto, y también un resolutor que solo responde desde dentro de la red del túnel. Repita la captura tras desconectar y reconectar una vez, porque los ajustes que aparecen en la primera conexión y desaparecen en la segunda son un fallo del ciclo de vida del hook, no una opción ausente.

Mantenga un solo dueño y verifique en orden

Un script que reescribe el DNS del adaptador a partir de un estado de túnel supuesto duplica configuración que el perfil ya lleva, y falla en silencio la primera vez que la suposición es errónea. Prefiera la configuración DNS propia de la conexión o un solo hook documentado, y anote cuál eligió para que la siguiente persona no añada un segundo.

Cierre el bucle con cuatro comprobaciones: la dirección empujada presente en el enlace del túnel, el nombre interno resolviéndose como nombre plenamente cualificado, el mismo nombre resolviéndose sin el sufijo, y ambas aún ciertas tras una reconexión. Una captura le dice cuál de las cuatro falló. El manual de OpenVPN 2.6 enumera dhcp-option y las directivas de script con sus notas de plataforma.