El cliente OpenVPN se bloquea cuando su servidor se ejecuta en el mismo host

Tenía una máquina de laboratorio que aceptaba un túnel desde un sitio remoto y también marcaba hacia una red de proveedor. El perfil de salida había funcionado durante semanas. Después de añadir el servidor de entrada, el de salida se conectaba y luego dejaba de pasar tráfico en cuestión de segundos, o se negaba a arrancar con un error de dirección en uso. Los archivos de configuración no habían cambiado; el host simplemente había adquirido un segundo proceso de OpenVPN con su propia opinión sobre puertos y rutas.

El fallo no es aleatorio y no es un problema de autenticación. Dos demonios en una máquina compiten por el mismo socket local y por la misma tabla de rutas, y el que arranca o se reconecta en último lugar suele ganar. Saber cuál de estas dos colisiones tienes decide dónde mirar primero.

Lee el síntoma al revés

Empieza por cuándo muere el túnel. Un error de bind al arrancar apunta al lado que escucha: algo ya posee ese puerto, y OpenVPN se niega a arrancar en lugar de compartirlo. Un túnel que sube y luego se queda en silencio apunta al enrutamiento, porque una ruta instalada por la otra instancia puede sacar los paquetes de la conexión exterior de su camino.

Ambos casos producen la misma queja del usuario, por eso los bucles de reintento y los scripts de vigilancia no arreglan nada. Vuelven a conectar el cliente en el mismo conflicto. La primera pregunta útil es si el proceso sigue ejecutándose cuando se detiene el tráfico.

Un socket y un dispositivo por instancia

Un servidor que escucha enlaza su puerto; un cliente de salida también necesita un puerto local para su tráfico encapsulado. Cuando ambos viven en el mismo host, el comportamiento predeterminado del cliente puede chocar con el puerto del servidor. El puerto local del cliente se puede fijar, y el enlace se puede omitir donde el par no necesita un puerto de origen fijo:

lport 1195
nobind
dev tun1

Esos números son ejemplos, no un requisito. Lo importante es que el cliente deje de competir por el puerto del servidor y que cada instancia obtenga un dispositivo de túnel separado. Dos demonios que comparten tun0 sobrescriben el estado del dispositivo del otro incluso cuando sus puertos difieren, así que un dispositivo por túnel no es opcional.

nobind pertenece al lado del cliente. Un servidor todavía debe enlazar y escuchar, así que no copies la línea en la configuración del servidor ni desactives el enlace en un cliente cuyo par filtra por un puerto de origen fijo.

Elige un solo propietario para la ruta predeterminada

Solo una conexión puede instalar una ruta predeterminada. Si ambos perfiles redirigen todo el tráfico, la segunda conexión sustituye silenciosamente a la primera, y la primera parece romperse. O mantienes el túnel de salida dividido y empujas solo los prefijos del proveedor, o le das una tabla de rutas separada.

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

Las direcciones y el número de tabla anteriores son marcadores de posición. Inmediatamente después de añadir la regla, confirma que la dirección del propio servidor VPN todavía se resuelve a través de la tabla normal; una tabla que captura el transporte exterior rompe el túnel que debía proteger, y el bucle de reconexión que sigue parece un proveedor poco fiable.

Para una configuración que debe sobrevivir a reconexiones y reinicios, un espacio de nombres de red es la frontera más sólida. El segundo cliente se ejecuta dentro de su propio espacio de nombres con sus propias interfaces y rutas, y solo se exponen los servicios que deben cruzar. El host mantiene una ruta predeterminada, y una reconexión del espacio de nombres no puede reescribirla.

Verifica con la tabla, no con la línea de estado

Un cliente que informa que está conectado solo demuestra su canal de control. Captura el estado de enrutamiento antes y después de cada conexión, y luego pregunta al núcleo qué dispositivo usaría un destino real:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

Si el dispositivo seleccionado para la dirección del proveedor cambia cuando arranca el segundo túnel, tienes la colisión de rutas. Si ambos procesos aparecen en el mismo puerto local, tienes la colisión de sockets. Arreglar la primera sin la segunda solo traslada el fallo a la siguiente reconexión.

Escribe los puertos, dispositivos, tablas y propietario de la ruta en el runbook del host. De lo contrario, la siguiente persona que añada un tercer túnel redescubrirá la misma colisión, y la única evidencia visible será una conexión que funciona hasta que se reinicie el demonio de otra persona.