¿A quién corresponde la ruta en OpenVPN: al cliente o al servidor?

Añade route 10.60.0.0 255.255.255.0 a la configuración del servidor, reinicia, vuelve a conectar un portátil y la subred sigue sin ser accesible desde ese portátil. La línea se aceptó, el servicio arrancó limpiamente y nada en el registro parece incorrecto. Lo que ocurrió es que la ruta se instaló en la máquina que editó: la puerta de enlace ahora cree que puede alcanzar ese prefijo, mientras que al cliente nunca se le dijo nada. La ubicación es toda la cuestión, y hay cuatro lugares donde la misma línea puede vivir.

Los cuatro lugares y quién recibe cada uno

Una ruta puede añadirse con la configuración propia del cliente, ofrecerse a todos los clientes mediante un push global, ofrecerse a un solo cliente mediante un archivo específico de cliente, o escribirse en el propio contexto de enrutamiento del servidor.

Esos cuatro casos usan una sintaxis casi idéntica y producen resultados completamente distintos. Los tres primeros afectan a lo que un cliente envía al túnel; el cuarto afecta a cómo llega el servidor a una red, lo cual es útil cuando el propio servidor necesita una ruta y perjudicial cuando se confunde con una distribución.

Decida cuál de los cuatro quiere antes de escribir la línea y luego confirme el receptor.

Por qué la ruta simple en el servidor sorprende a la gente

La configuración del servidor es donde los administradores miran primero, y una directiva de ruta allí se lee como una afirmación sobre la red VPN. No lo es. OpenVPN la trata como una instalación local de ruta en la máquina donde se ejecuta el demonio, que es exactamente el mismo tipo de cambio que haría con ip route y luego olvidaría.

La distribución exige que la ruta se envíe mediante push, y el push exige que el cliente la extraiga. Un cliente iniciado con las opciones extraídas desactivadas ignora la oferta por completo. Compruebe ambos extremos de ese apretón de manos antes de reescribir el archivo del servidor, porque el registro del servidor no se quejará: por su parte, la oferta se envió. Una ruta aceptada también entra en vigor solo en la próxima conexión, nunca en la sesión en la que ya está.

Cuando vea las dos operaciones como separadas, el fallo deja de ser misterioso: el servidor alcanza el prefijo, el cliente no, y ambas afirmaciones son ciertas a la vez.

Archivos por cliente y la identidad con la que coinciden

Un archivo específico de cliente se nombra según la identidad que el servidor autenticó, que por defecto es el nombre común del certificado. Un nombre de conexión amigable en un cliente de escritorio no es ese valor, y una discrepancia produce un archivo que nunca se lee.

Compruebe el directorio que el servidor usa realmente y luego confirme que el nombre del archivo coincide exactamente con la identidad autenticada, incluidas las mayúsculas y minúsculas.

grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/

Dentro de ese archivo la ruta todavía debe enviarse mediante push, porque el contexto por cliente es un conjunto de opciones aplicadas a la sesión de ese cliente, no una tabla de enrutamiento local. Una ruta simple allí tiene el mismo problema que una ruta simple en el archivo global.

El archivo propio del cliente y la herramienta que lo gestiona

Una ruta colocada en la configuración del cliente se instala cuando ese cliente se conecta y se elimina cuando se desconecta, que es el ciclo de vida correcto para un destino estático.

Si un gestor de red es dueño del perfil, puede importar esas opciones una vez y luego conservar su propia copia. Editar después el archivo descargado no cambia nada, lo que es una causa habitual de "la ruta está ahí pero no se aplica".

Compruebe el perfil activo en lugar del archivo que descargó, y compruebe la configuración importada que muestra el gestor. Luego conéctese y pregunte al sistema qué camino usa una dirección concreta, en lugar de suponer que ganó el túnel porque la ruta existía en un archivo de texto.

Verifique en el cliente y luego compruebe el camino de vuelta

Pregunte a la tabla de enrutamiento propia del cliente por el destino, no a la del servidor. Una consulta para un solo host dentro del prefijo basta para mostrar la interfaz y el siguiente salto que se usarán.

ip route get 10.60.0.10

Si la consulta apunta al túnel, la distribución funcionó y el problema restante está en otro lugar. Si apunta a la puerta de enlace predeterminada, la ruta no se instaló, fue filtrada por una opción del lado del cliente o pertenece a un perfil que el cliente no usa.

Suponga que la distribución funcionó y aun así nada responde: entonces compruebe el reenvío en la puerta de enlace, la ruta de vuelta del otro lado y cualquier cortafuegos entre ellos. Una ruta elige un camino, no concede acceso.