Por qué el DNS deja de funcionar tras conectar OpenVPN en Windows

Un ping al resolutor de la oficina sigue respondiendo después de que "OpenVPN" se conecte, y aun así cada consulta de nombre falla. La dirección es alcanzable mientras el puerto no lo es, una combinación que tiene sentido cuando sabe que Windows puede filtrar DNS por adaptador. Con block-outside-dns en el perfil, ese filtro es el primer sospechoso y la tabla de rutas es el lugar equivocado donde mirar. Las dos pruebas siguientes separan las capas en segundos.

Dirección alcanzable, puerto muerto

Un ping correcto demuestra que el host está activo y que existe una ruta. No dice nada sobre el permiso para llegar al puerto 53, porque el filtro en cuestión trabaja en otra capa y depende del adaptador. Por eso la misma máquina puede responder a ICMP y rechazar cada consulta enviada a la misma dirección. Ejecute ambas pruebas en la misma sesión antes de cambiar cualquier configuración.

ping <resolver-ip>
nslookup <name> <resolver-ip>

El par es el diagnóstico. El tráfico normal hacia la subred sigue funcionando mientras muere la resolución de nombres, y la gente concluye que el servidor está roto o que el DNS nunca se envió. Ambas explicaciones son caras de perseguir, y la evidencia apunta a algo más estrecho. Confirme el par antes de tocar cualquier ajuste.

La opción es una regla de la plataforma de filtrado

La referencia de OpenVPN describe block-outside-dns como una restricción de Windows Filtering Platform que impide que las aplicaciones lleguen al DNS en adaptadores fuera del túnel. Cubre TCP y UDP en el puerto 53. Como el filtro vive en WFP y no en la lista habitual de reglas del firewall, añadir una regla de permiso en otro lugar no cambia necesariamente el resultado. Por eso el consejo común de permitir DNS sigue fallando.

El ajuste puede llegar del perfil importado o del servidor, y el archivo que editó por última vez "no es prueba de lo que cargó el cliente". Lea la configuración efectiva y el registro de conexión en conjunto. La opción también es específica de Windows, y tratarla como portátil produce consejos que no se aplican.

Busque el componente de cliente que posee la restricción en lugar de añadir más reglas. El propietario es lo que realmente puede eliminarla.

Un filtro no es un resolutor

Bloquear el tráfico fuera del túnel no instala un resolutor funcional dentro de él. La opción elimina una ruta y deja la configuración DNS del túnel a quien montó el perfil. Un perfil que nunca envió un resolutor ahora no tiene ninguno.

Recorra tres comprobaciones en orden. Primero, qué resolutor usa realmente la aplicación que falla. Segundo, si el cliente aplicó los ajustes de DNS de la VPN. Tercero, qué interfaz lleva el tráfico a ese resolutor.

1. Resolutor en uso: compare Resolve-DnsName -Server <resolver-ip> <name> con los servidores DNS que enumera ipconfig /all.
2. DNS de la VPN aplicado: revise las entradas DNS del adaptador del túnel en la misma salida de ipconfig /all.
3. Interfaz utilizada: Find-NetRoute -RemoteIPAddress <resolver-ip> nombra la interfaz de salida para ese destino.

Un resolutor de LAN se vuelve inalcanzable por diseño con esta política, incluso mientras otro tráfico de LAN funciona. Eso es la opción haciendo su trabajo. Si el diseño necesita DNS por VPN, corrija el registro del resolutor y la ruta del túnel; si se requiere split DNS con excepciones locales, el propietario de la configuración debe expresar esas excepciones de una forma admitida.

Lo que la opción no cubre

El puerto 53 no es toda la resolución de nombres. DNS over HTTPS y DNS over TLS usan transportes distintos, y algunas aplicaciones ejecutan su propia lógica de resolutor con independencia de los ajustes del sistema. Un navegador puede por tanto resolver nombres mientras la línea de comandos no puede.

Trate esa diferencia como un diagnóstico y no como una contradicción. Compare ambas antes de decidir que el resolutor del sistema está roto.

Mantenga la conclusión estrecha al redactarla. Esta opción restringe un transporte en una plataforma, y el resto del camino de resolución es una cuestión de diseño aparte con su propio propietario.

Compruebe el estado antes y después de desconectar

Ejecute la misma consulta durante la conexión y de nuevo después de que el cliente propietario se desconecte. La primera debería fallar para un resolutor externo mientras el túnel está activo, y la segunda debería funcionar una vez eliminado el filtro. Si sigue fallando después de desconectar, el filtro no se limpió.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Reiniciar el servicio de cliente o la máquina suele limpiar un filtro antiguo. Eso confirma el diagnóstico sin demostrar una solución permanente. Anote lo que vio, porque un filtro que sobrevive a una desconexión lo hará otra vez, y la anotación es lo que justifica un informe de error.

Solo después de esas comprobaciones tiene sentido sustituir el resolutor o reconstruir la política del firewall. Ambas son cambios mayores de lo que la evidencia respalda.