¿Por qué no se puede acceder a la subred detrás de un cliente OpenVPN?

Los pings a la dirección del túnel del servidor funcionan, la tabla de rutas del cliente parece correcta y la LAN detrás de ese cliente sigue sin ser accesible. La tabla de enrutamiento del cliente parece correcta, el servidor tiene una ruta que apunta al túnel y los paquetes siguen desapareciendo. Es el síntoma clásico de un túnel layer-3 que no sabe que uno de sus clientes también es una puerta de enlace.

Una interfaz tun no tiene siguiente salto por cliente. El kernel ve una sola interfaz con muchos pares, así que la decisión de qué cliente debe recibir un paquete para una LAN remota debe tomarse dentro del proceso OpenVPN. Esa decisión se configura con iroute y, sin ella, el paquete no tiene adónde ir.

El servidor enruta por cliente, no por interfaz

Cuando el servidor necesita enviar un paquete a la dirección del túnel de un cliente, la respuesta es inequívoca: la dirección pertenece a la sesión de ese cliente. Cuando el destino es toda una subred detrás de ese cliente, la dirección no pertenece a nadie que el servidor conozca, y la ruta del kernel hacia el túnel solo dice "por esta interfaz", sin decir qué par.

OpenVPN lo resuelve con una tabla de enrutamiento interna que asigna un prefijo de destino a un cliente concreto. Esa tabla se construye con entradas iroute, por eso una ruta normal en el host del servidor no basta. La ruta del kernel lleva el paquete a la interfaz del túnel; la asignación interna decide qué sesión lo recibe. Por eso también la reparación nunca aparece en la salida de rutas del kernel.

Si falta la asignación, el paquete llega al servidor, coincide con la ruta del túnel y se descarta porque ningún cliente reclama el destino. Nada registra un error limpio, por eso el fallo parece un agujero negro silencioso en lugar de un bucle de enrutamiento.

Escribir la entrada iroute que nombra al cliente

iroute vive en un archivo de configuración específico del cliente, no en la configuración principal del servidor. Apunte el servidor a un directorio con la opción client-config-dir, luego cree un archivo cuyo nombre sea el nombre común del certificado del cliente y coloque el prefijo dentro.

Para una sucursal cuya LAN es 10.20.0.0/24 y cuyo nombre común de certificado es branch-router, el archivo en esa ruta contiene una línea como iroute 10.20.0.0 255.255.255.0. La configuración principal solo necesita la opción del directorio; el prefijo vive con el cliente.

El nombre común es la parte frágil. Un certificado emitido con otro sujeto, o un despliegue que autentica usuarios por nombre de usuario mientras el archivo se nombra por el certificado, produce un archivo que nunca se lee. Compruebe el nombre que el servidor informa realmente para la sesión y considere la opción que hace fallar a un cliente no coincidente en lugar de conectarse en silencio sin sus rutas. Renombrar el archivo para que coincida con el certificado es una corrección de cinco minutos que evita una noche muy larga.

Un cliente puede poseer varios prefijos. Añada una línea iroute por red y mantenga la lista junto al resto de la configuración de ese cliente para que la asignación siga siendo auditable.

Construir el camino de retorno en ambos sentidos

Llevar los paquetes a la LAN remota es la mitad del trabajo. El cliente también debe enviar el tráfico de esa LAN al túnel, lo que normalmente se hace empujando una ruta al cliente: una línea como push "route 10.8.0.0 255.255.255.0" dice a cada cliente cómo llegar a la red del lado del servidor. Para la sucursal, la ruta equivalente apunta al túnel para todo lo que deba alcanzar en el lado del servidor.

El sentido de retorno necesita un propietario en el lado remoto. En ese lado, alguien debe conocer el camino de vuelta: una ruta estática en el router de la LAN que apunte el pool de VPN al servidor, o traducción de direcciones en el servidor antes de que el tráfico entre en la LAN. La ruta estática mantiene las direcciones originales visibles en los registros y las reglas de acceso, pero exige la colaboración del propietario de la LAN; la traducción es autosuficiente pero oculta quién se conectó realmente.

El reenvío debe estar habilitado en el host del servidor. Sin él, el kernel acepta el paquete del túnel y se niega a pasarlo a la interfaz de la LAN, lo que desde el punto de vista del cliente parece idéntico a una iroute ausente.

Comprobar la accesibilidad con las sondas correctas

Pruebe por capas en lugar de hacer ping al extremo remoto y adivinar. Desde el servidor, compruebe que existe la asignación interna para el prefijo y que la ruta del kernel apunta al túnel. Desde el cliente, confirme que la ruta empujada está instalada y que su camino predeterminado para la dirección de la LAN es el túnel.

Luego observe los paquetes. Una captura en la interfaz del túnel muestra si el servidor transmite hacia el cliente, y una captura en la interfaz de la LAN muestra si reenvía. Si la primera muestra paquetes y la segunda no, el problema es el reenvío o un filtro; si ninguna muestra nada, la búsqueda falló antes.

Dos servidores unidos por un túnel repiten la misma regla en ambos lados: cada uno necesita una iroute para el pool del otro, y cada uno necesita la ruta y el reenvío que hacen simétrico el camino. Enrutamiento y política son asuntos separados aquí. El enrutamiento decide adónde puede ir un paquete, mientras que una regla FORWARD decide si puede, así que un cliente con dos líneas iroute alcanza ambos prefijos salvo que un filtro diga lo contrario.