Qué impide realmente route-nopull de OpenVPN que el servidor envíe

Pusiste route-nopull en un perfil de cliente para evitar que el túnel se tragara tu ruta predeterminada, y ahora la subred de la oficina es inalcanzable mientras el cliente sigue diciendo que está conectado. Ambas observaciones son ciertas y nada ha fallado. El indicador le dice al cliente que omita las rutas y las entradas DHCP que envía el servidor, una instrucción más estrecha de lo que la mayoría espera al añadirlo. Lo que queda es un túnel funcional sin opinión sobre qué destinos deben usarlo.

Ese hueco es toda la decisión de la que trata este artículo. O el servidor describe la red, o lo hace el cliente, y el indicador le entrega esa tarea al cliente sin hacer nada de ella por ti.

Qué apaga el indicador al conectar

Un cliente OpenVPN que tira normalmente recibe del servidor tras la autenticación un paquete: rutas, una redirección de la puerta de enlace predeterminada, servidores DNS y unas cuantas directivas de ajuste. Con route-nopull en vigor, el cliente sigue aceptando la sesión, sigue verificando certificados, sigue negociando cifrados y keepalives, y sigue levantando la interfaz. Lo que descarta es la aplicación de las líneas route enviadas y de las líneas dhcp-option enviadas, DNS incluido.

La confusión viene de un indicador verde junto a una aplicación muerta. El túnel existe; la correspondencia de destinos con ese túnel no. Nada en el panel de estado del cliente distingue «conectado y enrutando» de «conectado e inerte», porque desde el punto de vista del túnel ambos son el mismo estado.

Por qué un túnel vivo puede no enrutar nada

La interfaz aparece con su propia dirección y, en un enlace punto a punto, a menudo no tiene nada más específico que una ruta de host hacia el par. Una subred privada solo se vuelve alcanzable cuando alguna ruta apunta a esa interfaz con el prefijo correcto, y con el envío desactivado esa ruta nunca llega. El perfil descargado tampoco suele ayudar, porque se escribió asumiendo que el servidor proporcionaría exactamente esta información. Por eso la interfaz puede parecer sana mientras la subred sigue oscura.

Leer el perfil, por tanto, demuestra muy poco. Lee el estado en ejecución, en la máquina conectada:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Una dirección sin ruta de subred en el segundo comando es la firma de este problema. El tercer comando responde entonces la pregunta que de verdad importa a los usuarios, porque informa de la interfaz que el núcleo elegiría para un destino concreto en lugar de la lista que esperabas que usara. Si responde por tu enlace físico, el túnel no está en el camino en absoluto.

La resolución de nombres falla por un motivo relacionado, no por uno separado. Las entradas dhcp-option DNS enviadas se omiten con el mismo indicador, así que las consultas de hosts internos van al resolutor que haya proporcionado la red local. Ese resolutor no tiene zona para la oficina, así que la consulta falla o devuelve una respuesta pública, y el fallo parece un problema del servidor cuando es un problema de configuración del cliente. Probar una dirección antes que un nombre es lo que separa ambas cosas.

Elegir entre el indicador y un filtro de prefijo

Las dos opciones resuelven formas distintas de la misma queja, y elegir mal es lo que produce el estado de conectado pero inútil. Una sustituye la política enviada por completo, mientras que la otra la edita por prefijo. La tabla da la versión corta, y el párrafo siguiente cubre la parte que pilla a la gente.

pull-filter es un comparador de prefijos con tres verbos, así que puede aceptar una familia de líneas, ignorarlas en silencio o rechazar la conexión directamente cuando aparece un prefijo. Ese último comportamiento es el que merece conocerse: una regla de rechazo convierte un desacuerdo de política en un handshake fallido en lugar de una omisión silenciosa. El manual de OpenVPN 2.6 enumera los prefijos aceptados y la semántica exacta de cada verbo.

Un camino intermedio habitual es rechazar solo redirect-gateway y dejar que las rutas de la oficina y el DNS lleguen como se pretende. Eso mantiene el envío funcionando para las partes que el servidor entiende mejor que tú, al tiempo que evita la única línea que se haría con tu ruta predeterminada.

Añadir rutas y un resolutor a mano

Si mantienes el indicador, el perfil tiene que decir lo que habría dicho el servidor. Las directivas route del lado del cliente se aplican después de establecer la conexión, así que funcionan junto al indicador en lugar de quedar bloqueadas por él. Ponlas en el perfil, no en una línea de órdenes interactiva, o la próxima reconexión no reproducirá el estado funcional.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

La línea DNS está en una posición incómoda: es una directiva del lado del cliente, pero algunos clientes solo la aplican mediante la integración DNS de la plataforma, que puede sobrescribirla cuando cambia el enlace. En un host con systemd, fijar el resolutor directamente en la interfaz del túnel es más predecible que esperar que el cliente gane el concurso de prioridades:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

El dominio de enrutamiento importa tanto como la dirección. Sin él, las consultas de nombres públicos también pueden enviarse al resolutor interno, y cualquier resolutor interno que rechace la recursión romperá la navegación mientras deja la zona privada funcionando. Con él, solo los nombres bajo ese sufijo se enrutan al resolutor del túnel y todo lo demás sigue el enlace físico.

Comprobar el resultado: dirección, nombre y el camino exterior

Tres pruebas separan los fallos posibles. Obtén la dirección privada por IP, luego el mismo host por nombre, luego un sitio público corriente. Una IP que funciona con un nombre que falla apunta al resolutor; una IP que falla con un nombre que funciona apunta al enrutamiento; que fallen ambas suele significar que el túnel no está en el camino.

Luego mira hacia fuera en vez de hacia dentro. La ruta propia del extremo del túnel tiene que sobrevivir al cambio, y cualquier bloqueo de fallo debe limitarse al túnel sin capturar el extremo. Un cliente que sigue navegando tras caer el túnel es un problema de política, no de enrutamiento, y no aparecerá en ninguna de las tres pruebas anteriores.

Escribe la lista final en la documentación del perfil: las rutas, el resolutor, los dominios y el motivo por el que existe cada uno. Una reconexión que reproduzca la misma tabla es la única prueba de que la política local está completa. Si las aplicaciones siguen fallando con el túnel levantado y las tres pruebas superadas, el siguiente sitio donde mirar es la clase de problemas de conectado pero sin conexión, no certificados que ya se han verificado.