OpenVPN iroute frente a la ruta del núcleo: ¿cuál falta?

Un paquete para 10.77.20.0/24 toma dos decisiones separadas en un servidor OpenVPN: el sistema operativo debe entregarlo a la interfaz VPN, y OpenVPN debe saber qué cliente conectado posee ese prefijo. Una ruta del núcleo ausente lo descarta antes del túnel, y una ruta del par ausente lo descarta después. Los dos fallos se ven idénticos desde la LAN remota, y diagnosticar cuál tiene requiere un comando en cada lado.

En la ruta de datos clásica en espacio de usuario, la ruta del núcleo lleva el paquete al proceso del túnel y iroute dice a ese proceso qué par debe recibirlo. Ninguna sustituye a la otra, y una configuración que solo lleve una de ellas parecerá razonable hasta el primer ping.

Dos decisiones, no una ruta

Imagine un enlace entre sedes donde 10.77.20.0/24 está detrás de un solo cliente. La ruta del núcleo del servidor, por ejemplo ip route add 10.77.20.0/24 dev tun0, envía los paquetes coincidentes al dispositivo del túnel. Después OpenVPN consulta su propia tabla interna, construida a partir de las entradas iroute del directorio de configuración del cliente, para decidir qué conexión de par los recibe. Sin la ruta del núcleo el paquete nunca llega al proceso, y sin la ruta del par llega al proceso y no va a ninguna parte.

Esa división se olvida con facilidad, porque una sola línea de ruta en un perfil de cliente puede parecer que hace ambos trabajos. No los hace: empujar una ruta dice a los clientes qué enviar por el túnel, mientras que iroute dice al servidor quién posee un rango de direcciones detrás de un cliente. Viven en archivos distintos, los leen lados distintos y fallan en direcciones opuestas.

Dónde va iroute y qué dice

La entrada va en un archivo por cliente nombrado según el common_name del cliente, dentro de client-config-dir, como iroute 10.77.20.0/24. La coincidencia del nombre del archivo no es cosmética: OpenVPN busca la identidad autenticada y lee el archivo con exactamente ese nombre, así que un archivo llamado site-a solo surte efecto para un cliente cuyo nombre común sea site-a. Añada ccd-exclusive si los clientes sin ese archivo deben rechazarse de plano, que es la configuración correcta cuando cada cliente es una puerta de enlace de sede. Mantenga un archivo por puerta de enlace y nómbrelo según el sujeto del certificado que realmente emite.

Pruebe la entrada desde el servidor antes de culpar a la LAN remota. El archivo de estado lista los clientes conectados con sus nombres comunes, y un servidor que se ejecuta con --verb 4 registra la instalación de iroute cuando el par se conecta. Si no aparece nada al conectar, el archivo está en el directorio equivocado o nombra la identidad equivocada.

La trampa: archivo presente, identidad equivocada

Un iroute de aspecto correcto ligado al par equivocado pierde más tiempo que un archivo ausente, porque todo en el disco parece correcto. El cambio de nombre de certificados, los nombres comunes duplicados y username-as-common-name cambiando la identidad efectiva lo producen todo. Compruebe qué identidad autenticó el servidor en lugar de la que esperaba: la salida de estado es autoritativa, mientras que el nombre del archivo solo es una clave de búsqueda.

Una ruta también puede sobrevivir a su propietario. Las rutas estáticas y las entradas iroute describen un prefijo, no una garantía de disponibilidad, así que el tráfico puede seguir encaminándose hacia un par que ahora mismo está desconectado.

Complete el camino más allá del par

La propiedad del par es la mitad del camino, no el final. El cliente debe reenviar paquetes del túnel a su LAN, lo que significa reenvío IP activado en ese equipo y una regla de cortafuegos que permita el tránsito. Los equipos de la LAN remota necesitan un camino de vuelta para la dirección del túnel: o una ruta que apunte de nuevo a la puerta de enlace, o un diseño de NAT deliberado en el lado del cliente. Confirme el ajuste de reenvío en el cliente con sysctl net.ipv4.ip_forward en lugar de suponer un valor por defecto de la distribución.

Si otros clientes VPN deben llegar a esa subred, el arreglo vuelve a crecer: el servidor necesita client-to-client, y esos clientes deben encaminar el prefijo por el túnel. Nada de eso se deduce de la propia tabla de rutas del servidor.

Verifique un destino desde una fuente real en lugar de desde el propio servidor. Un ping desde un equipo LAN no relacionado hasta un equipo detrás del cliente ejercita el camino de vuelta, la regla de reenvío y la propiedad del par en un solo movimiento, mientras que un handshake correcto solo demuestra identidad. Luego desconecte el par propietario y anote qué hace la ruta, porque esa respuesta es su modo de fallo.