¿openfortivpn sigue sobrescribiendo el DNS? Encuentre al propietario real

Siga la conexión desde el momento en que se levanta: el cliente se autentica, pppd negocia y luego algo escribe la configuración de DNS en el sistema operativo. Si lo único que sabe es que la VPN le cambió el resolutor, todavía no sabe cuál de esas etapas lo hizo. Dos de ellas pueden, y en un cliente que usa la integración documentada con pppd funcionan lo bastante cerca como para parecer un solo actor. Nombrar al escritor es el primer paso; elegir su reemplazo es el segundo, y es una decisión aparte con sus propios modos de fallo.

La secuencia de abajo sigue al cliente hacia fuera: qué cambió la conexión, qué interruptor suprime a qué escritor, quién debe hacerse cargo y cómo confirmar que el resultado sobrevive a una reconexión. Cada etapa deja un rastro distinto, y el rastro es lo que le dice si el traspaso ocurrió de verdad.

Empiece por lo que la conexión cambió realmente

Conéctese una vez con su invocación habitual y compare la resolución antes y después. En un host Linux con systemd-resolved, resolvectl status imprime los servidores DNS y los dominios de búsqueda por enlace, y un enlace tun o ppp nuevo que lleva sus propios servidores es la huella de una actualización del lado del cliente. En macOS, scutil --dns muestra la configuración del resolutor en el orden en que las aplicaciones la consultan.

Compare eso con el archivo que esperaba que cambiara. Una entrada vinculada a la conexión en la vista por enlace y un /etc/resolv.conf reescrito son dos resultados distintos, y el segundo puede ser un enlace simbólico que gestiona por completo otra cosa. Anote la dirección del resolutor, los dominios de búsqueda y el nombre de la interfaz en el mismo momento; un cambio en cualquiera de ellos apunta a un escritor distinto. Sin esa línea base, cada corrección posterior es una conjetura sobre cuál de tres componentes se movió.

Los dos interruptores y el escritor que silencia cada uno

openfortivpn documenta un fragmento de opciones que apaga ambos escritores que puede controlar, y cada interruptor tiene un equivalente escrito por completo que el manual trata como el mismo ajuste.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns impide que el cliente aplique los servidores DNS que aprendió de la puerta de enlace, mientras que --pppd-no-peerdns impide que pppd empuje el DNS del par al sistema. El manual de upstream advierte de que las actualizaciones de DNS por PPP pueden competir con las actualizaciones de DNS propias del cliente, y por eso ambos interruptores pertenecen al fragmento en lugar de tratar a cualquiera de los dos como suficiente.

Ningún interruptor nombra un resolutor de reemplazo, y ninguno impide que un gestor de red, un cliente DHCP o una integración de VPN aparte escriban la resolución después. Silenciar a dos escritores deja el campo abierto en lugar de poseído. Si un tercer componente ya gestiona el DNS, el fragmento no cambia nada que usted pueda observar; si nada lo gestiona, acaba de quitar la única fuente de resolución de nombres privados. Eso es una disposición válida solo cuando el propietario de reemplazo se eligió primero y se probó por su cuenta.

Elija al propietario antes de desactivar nada

Decida primero quién responde a las consultas de los nombres de trabajo, porque esa elección condiciona todo lo que viene después. Mantener el resolutor existente significa que la zona privada ya debe ser alcanzable desde donde esté el cliente, y un resolutor privado dentro de la oficina necesita una ruta que sobreviva al levantamiento del túnel. Enviar cada consulta a un solo servicio interno es una tercera política con un modo de fallo más afilado: cuando ese servicio no es alcanzable, los nombres públicos fallan junto con los privados.

La propiedad de las rutas se mantiene separada a propósito. Las opciones de ruta no son necesarias porque usted haya cambiado el DNS, y desactivar la instalación de rutas sin instalar un reemplazo puede dejar inalcanzable el resolutor que acaba de elegir. Revise la tabla de enrutamiento específicamente para la dirección del resolutor, no solo para la subred de la aplicación que probó por casualidad.

Compruebe la resolución por enlace, no por archivo

Un solo /etc/resolv.conf no es un inventario de lo que las aplicaciones usan realmente en un host con resolución limitada o por dominio, así que lea el estado del resolutor tal como la plataforma lo expone.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

Consulte un nombre privado y un nombre público una vez levantada la conexión, y anote qué enlace respondió a cada uno. Donde el enlace de la VPN lleva una lista de búsqueda por dominio, un nombre privado puede resolverse correctamente mientras un nombre público sigue yendo al resolutor local, y esa división es el diseño funcionando y no una avería. Si la consulta privada falla, inspeccione la ruta hacia el resolutor antes de tocar el DNS otra vez; si tiene éxito mientras una aplicación sigue fallando, puede que la aplicación esté leyendo un resolutor propio en caché o configurado aparte.

Reconecte y confirme el estado desconectado

Baje la conexión y repita ambas consultas. Lo que haya instalado el propietario elegido debe quitarlo o restaurarlo ese propietario, no dejarlo atrás el cliente que usted silenció. Una entrada por enlace obsoleta que sobrevive al túnel sigue enviando consultas privadas a una dirección que ya no es alcanzable.

Luego reconecte y lea otra vez los mismos tres valores: dirección del resolutor, dominios de búsqueda, interfaz.

Si coinciden con la política que anotó, el traspaso está completo y el cliente de la VPN ya no es uno de los escritores. Si un valor retrocede unos segundos después del levantamiento del enlace, algo más sigue aplicando configuración, y el paso siguiente es identificar ese componente en lugar de añadir otra marca. El estado final que usted quiere es sin sobresaltos: un propietario, una política documentada y un host desconectado que resuelve exactamente como lo hacía antes de que existiera el túnel.