OpenVPN: la dirección local frente a la dirección del túnel: dos sockets distintos

El cliente se niega a arrancar y se queja de que no puede enlazar una dirección local, y la solución obvia parece apuntarlo a la dirección del túnel que espera recibir. Eso no puede funcionar, y conviene entender el motivo: antes de que exista el túnel no hay dirección interior, y el socket que contacta con el servidor tiene que existir primero. Hay dos direcciones distintas y solo una de ellas puede elegirse localmente.

El error de enlace nombra una dirección local

Cuando OpenVPN informa de que no puede enlazar una dirección local, habla del socket de transporte: el extremo UDP o TCP que lleva la conexión cifrada hasta el peer.

Una directiva local explícita pide al demonio que enlace ese socket a una dirección local concreta. La dirección debe existir en el espacio de nombres de red donde se ejecuta el proceso, y debe ser asignable en el momento en que arranca el cliente.

Una dirección pública traducida en un router o en el borde de la nube no es una dirección local que el demonio pueda enlazar, aunque sea la dirección que ve el servidor. Esa distinción explica por qué un perfil funciona en casa y falla en una instancia de nube. También explica por qué añadir la dirección pública a una interfaz de loopback no ayuda, ya que entonces el transporte saldría de una dirección a la que la red no puede devolver nada. Lee la lista de interfaces antes de editar el perfil.

Qué seleccionan realmente local y remote

remote nombra el peer con el que contactar. local enlaza el extremo cercano del mismo socket. nobind deja que el sistema operativo elija tanto la dirección local como el puerto, y por eso los clientes detrás de routers domésticos suelen funcionar sin ninguna de las dos directivas.

Ninguna de las dos directivas tiene nada que ver con la dirección dentro del túnel.

En un contenedor o un espacio de nombres de red se aplica la misma regla con límites más estrechos: las direcciones del anfitrión no están dentro, así que una línea local copiada de la configuración del anfitrión falla por un motivo totalmente distinto al de una dirección equivocada.

ip -brief address show
ip route get 203.0.113.10

La dirección interior viene del servidor

La dirección dentro del túnel se negocia o se asigna después de establecer el canal de control. Con un pool dinámico el servidor la decide al conectar, y con configuración específica del cliente puede estar fija por identidad.

Escribir local con una dirección interior no pide al servidor que asigne esa dirección. En el mejor caso el enlace falla; en el peor el cliente encuentra una dirección de anfitrión no relacionada con el mismo valor y empieza a usarla para el transporte.

Las interfaces que hay que leer también son distintas. Los parámetros de ifconfig y la configuración del pool describen el interior, mientras que remote, local, proto y nobind describen el exterior. Mantener las dos listas separadas explica casi todos los ejemplos confusos que encontrarás en un foro. El manual de OpenVPN 2.6 los documenta en secciones separadas por ese mismo motivo.

La trampa: un túnel completo que captura su propio transporte

Una vez que el túnel está levantado y transporta la ruta por defecto, los paquetes que lo sostienen no deben enrutarse hacia dentro. Es un problema de enrutamiento y no de direccionamiento, y el demonio lo resuelve instalando una ruta más específica hacia la dirección del propio servidor a través de la puerta de enlace original.

Si fijas el transporte a una dirección local concreta y después cambias el camino que usa esa dirección, la conexión exterior puede perderse mientras el interior sigue configurado. El túnel sigue informando de que está conectado porque el interior está bien. Solo el transporte está roto, y por eso los registros se leen como contradicciones.

Los síntomas entonces parecen un túnel que conecta y se congela, o uno que se reconecta en bucle sin un error útil. Comprueba la ruta hacia la dirección del peer antes de comprobar nada dentro del túnel, y confirma que la dirección local que enlazaste sigue perteneciendo a la interfaz que esperabas.

Un hábito que evita la confusión

Lee cada dirección de un perfil y decide a qué capa pertenece antes de editarla.

Si nombra el extremo lejano del transporte o enlaza su extremo cercano, es una dirección exterior y debe existir antes del arranque. Si describe lo que ocurre dentro del túnel, viene del servidor o de la topología, y ninguna directiva local puede sustituirla.

Escribe las dos listas en las notas de despliegue junto al perfil. La próxima sesión de diagnóstico empezará entonces por la capa en lugar de por una conjetura.