El pull-filter de OpenVPN coincide con más que la ruta que querías

Añades una línea para conservar tu ruta predeterminada local, y después el túnel ya no llega al servidor DNS interno. La línea era pull-filter ignore "route", que no significa "ignora esta ruta". Significa "descarta cualquier opción enviada cuyo texto empiece por esas cinco letras", y en un servidor normal eso incluye route-gateway, route-metric y route-ipv6 junto con las propias rutas. La lista de comprobación de abajo es lo que repaso antes de tocar un perfil que tiene que usar otra persona.

El filtro solo se aplica a las opciones enviadas

pull-filter actúa sobre las líneas de opción que el servidor envía una vez establecido el túnel, y sobre nada más. Las opciones escritas en tu archivo local no se ven afectadas, ni tampoco el tráfico de las aplicaciones. Si esperabas impedir que un proceso usara el túnel, esta es la herramienta completamente equivocada y ninguna combinación de filtros lo logrará.

Ese alcance es útil, porque significa que puedes dejar la configuración del servidor tranquila y aun así rechazar parte de ella localmente. También es un límite que conviene dejar escrito en el ticket: un filtro cambia lo que acepta este cliente, no lo que ofrece el servidor. No tiene efecto sobre otros usuarios del mismo perfil. Tampoco sobrevive a un cambio a otro cliente que no implemente la opción, algo que conviene saber antes de construir un flujo de trabajo sobre ella.

Confirma qué envía realmente el servidor antes de escribir el patrón. Con alta verbosidad el cliente imprime la cadena de opciones enviadas que recibió, y esa es la única fuente honesta para el texto exacto con el que comparas:

sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpn

Lee la línea enviada como una lista de opciones separadas por comas, y fíjate en que los nombres de opción y sus argumentos se separan con espacios. Tu texto de filtro se compara con ese flujo, por eso los espacios importan tanto en el paso siguiente.

La coincidencia es un prefijo, así que los espacios lo son todo

La comparación es un prefijo de cadena, no un nombre de opción analizado. Por eso "route" coincide con route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 y route-metric 100. Un espacio final lo estrecha a la familia que probablemente querías, y el prefijo completo lo estrecha aún más a un destino concreto.

La última fila es la que atrapa a la gente durante el trabajo con túnel dividido. Conservar tu propio resolutor es una opción legítima, y significa que cada nombre interno depende ahora de un resolutor que no puede ver la zona privada. Es una consecuencia que se acepta a propósito, no un efecto secundario que se descubre en producción.

La coincidencia por prefijo también significa que una regla puede ampliarse más tarde en silencio. Cuando el servidor añade una opción nueva que empieza por tu texto, tu filtro empieza a aplicarse a ella sin que nadie edite tu perfil. Ese es el modo de fallo contra el que hay que diseñar, y la mitigación es coincidir con tanta parte de la opción como puedas, no con tan poca como puedas.

Tres verbos con tres resultados distintos

accept, ignore y reject no son tres grafías de la misma idea. Difieren en qué hace el cliente con una coincidencia y en si alguien se entera.

ignore descarta la opción coincidente en silencio, que es lo que quieres para un ajuste que has sustituido deliberadamente. reject la descarta y hace que el cliente se queje, que es lo que quieres cuando su ausencia debe verse en un registro en lugar de descubrirse más tarde. accept es la forma positiva, se usa cuando construyes una lista de permitidos en vez de quitar opciones individuales.

Sea cual sea el verbo que uses, los filtros se aplican en el orden en que aparecen, así que dos reglas solapadas producen un resultado dependiente del orden y muy difícil de revisar. Ten una regla por intención y pon el texto más específico en cada una. Si necesitas una lista de permitidos, prefiere unas pocas reglas accept a un montón de reglas ignore que suman lo mismo. Así los revisores pueden leer el archivo de arriba abajo y predecir el resultado, y esa es la única prueba que escala.

Comprueba la ruta y el resolutor aplicados, no el perfil

Un filtro que parece correcto en el archivo todavía puede dejarte con un túnel que no encamina nada útil. Verifica el efecto en el sistema en marcha, donde las opciones enviadas ya se han aplicado o descartado:

ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/

Las dos primeras líneas te dicen si ha llegado la ruta predeterminada enviada y cuántas entradas estáticas sobrevivieron. La consulta al resolutor muestra qué servidor usa realmente la interfaz del túnel, y es normalmente donde aparece una sorpresa de DNS. La última línea responde a la única pregunta que importa a un usuario.

Prueba las dos direcciones mientras estés ahí. Una regla que mantiene tu internet local funcionando pero rompe en silencio la resolución de nombres interna pasa una comprobación superficial y falla la primera tarea real, así que incluye un recurso interno y un sitio público en la misma prueba.

Registra la excepción y quién es su dueño

Un filtro es una excepción al diseño del operador, así que déjalo escrito con un motivo y un punto de revisión. "Ignora las rutas enviadas para conservar la predeterminada local" es revisable; una línea desnuda en un perfil no lo es, y la siguiente persona la borrará o la ampliará a ciegas.

La versión también cuenta aquí. El comportamiento de coincidencia y la sintaxis aceptada exacta se han refinado a lo largo de OpenVPN 2.4, 2.5 y 2.6, así que confirma el patrón con el manual de la compilación que distribuyes y no con un mensaje de foro sobre una versión más antigua. El manual de OpenVPN 2.6 documenta la opción y su regla de coincidencia.

Por último, acuerda la excepción con quien gestiona el servidor. Un filtro del lado del cliente que contradice una política deliberada del servidor es un incidente de soporte esperando la próxima auditoría, y es mucho más barato resolverlo antes de que el perfil salga que después de que alguien note que faltan las rutas.