La VPN tomó el control del DNS y rompió los nombres locales: arregla la lista

El túnel sube, la intranet carga y el nombre de la impresora deja de resolverse. O al revés: los nombres locales siguen funcionando mientras todo lo que hay dentro de la red corporativa agota el tiempo de espera. Ambos síntomas vienen del mismo sitio, una lista de resolutores que el cliente VPN reescribió al conectarse.

Repara la lista a propósito y luego ocúpate del mecanismo push por separado. Las rutas son un tercer tema y no es el que se arregla aquí.

Qué lista usan realmente las aplicaciones

Windows resuelve mediante ajustes a nivel de interfaz y no mediante lo que muestre un diálogo, así que empieza por las listas efectivas de cada interfaz. El alias importa más que el nombre mostrado, porque cada comando de abajo se dirige a una interfaz. Si te equivocas con el alias, la reparación caerá en el adaptador equivocado. Parecerá funcionar hasta la siguiente reconexión, cuando vuelva la entrada propia del túnel.

La pregunta es qué servidores acabaron delante y si llegaron como entradas estáticas o como concesión DHCP. Ambos hechos deciden qué reparación tienes disponible.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Lee la salida del adaptador del túnel y del físico, y anota cada dirección de cada uno. Una entrada estática puede eliminarse con una directiva o un script; una proporcionada por DHCP está ligada a la concesión y volverá, lo que cambia la reparación que debes elegir. Los nombres de la red remota los resuelve el resolutor anunciado, los de la LAN local el adaptador físico, y la consulta va a la lista que se consulte primero.

Elimina los servidores empujados o colócalos más abajo

Borra los servidores empujados cuando nada dentro del túnel los necesite, porque los resolutores propios del adaptador físico vuelven a tomar el relevo. Consérvalos solo si la red remota tiene zonas que únicamente sus servidores pueden responder, y en ese caso pon un resolutor local por delante. Los dos comandos de abajo cubren ambas opciones, así que elige el que encaje con la situación en vez de ejecutar los dos.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

El índice 1 se consulta primero, así que las direcciones empujadas siguen disponibles pero dejan de ser la respuesta predeterminada a cada consulta. El indicador validate=no omite una prueba de accesibilidad que a menudo falla mientras el túnel aún se asienta, así que confirma el resultado con el comando show en lugar de fiarte del código de salida.

Vale la pena conocer dos límites antes de fiarse de esto. Windows no borrará los servidores que llegaron por DHCP a través de netsh, y esos valores persisten como DhcpNameServer bajo la clave de registro de la interfaz, así que editar el registro es un último recurso que hay que volver a comprobar tras la siguiente concesión. El orden de enlace de los adaptadores tampoco es un mecanismo de clasificación fiable, porque un cliente VPN puede insertar su propia entrada en la parte superior de la lista.

Dónde se puede filtrar el push

Una reparación mejor quita la opción antes de que se aplique. El cliente Community OpenVPN puede filtrar una directiva empujada por nombre, lo que deja intacta la configuración del servidor.

pull-filter ignore "dhcp-option DNS "

El espacio final pertenece a la coincidencia y el filtro nombra la opción, no una dirección de servidor. Si el perfil también contiene una directiva block-outside-dns, quitarla cambia la protección contra fugas y no la resolución de nombres, así que decide eso por separado en vez de agrupar las dos ediciones.

Para un solo nombre de host testarudo, una línea en el archivo hosts de Windows es más estable que reordenar resolutores para toda la máquina. También es invisible para la siguiente persona, así que anótala donde se documente la configuración de la máquina.

Haz que la reparación sobreviva a una reconexión

La resolución debe probarse dos veces, una contra un servidor elegido y otra en la forma que usa una aplicación. Ese par separa un problema de orden de resolutores de un servidor que no responde en absoluto. Saltarse la primera prueba deja las dos causas enredadas.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Reconecta el túnel y repite ambos comandos. Lo que hayas cambiado a mano solo dura hasta la siguiente conexión, porque el cliente reconstruye su estado de resolutores mientras levanta el adaptador. Pon las líneas netsh en el script de conexión admitido de tu cliente, deja que ese script termine con éxito y añade una espera breve antes de que se ejecute. Un cliente que aplique DNS después del script sobrescribirá el resultado de todos modos.

Si los nombres públicos se resuelven y los internos siguen fallando tras la reparación, la lista de resolutores ha dejado de ser el sospechoso. La consulta probablemente no llega al servidor en absoluto, lo que apunta al enrutamiento o a una regla de cortafuegos y no a otro ajuste de DNS. Anota el alias de la interfaz y las direcciones con las que te quedaste, porque ambos difieren entre máquinas y ninguno sobrevive solo a una reconstrucción.