El puerto 1194 ya está en uso: ¿quién posee ese socket de OpenVPN?

Inicie el mismo perfil de servidor dos veces y el segundo proceso termina con un error de dirección en uso para el puerto 1194. En el caso habitual, el arranque de diagnóstico creó el conflicto y la instancia original sigue atendiendo a los clientes perfectamente. Esta historia explica una gran parte de estos informes y merece reconocerse antes de reiniciar nada. También es la versión más barata de resolver.

El error describe un enlace local y nada más allá. No es prueba de que un proveedor bloquee el puerto, de que un cliente enviara la contraseña incorrecta o de que la cadena de certificados esté rota.

Lea el error de enlace exacto

Dos errores de esta familia significan cosas distintas, y confundirlos lo envía a la capa equivocada. «Dirección ya en uso» dice que otro socket posee el punto final que solicitó. «Dirección no disponible» dice que la dirección solicitada aún no existe en este host, lo que es un problema de preparación y no un duplicado.

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

Copie el texto del error antes de cambiar nada, incluida la dirección y el puerto que menciona. Un servicio que espera a que aparezca una interfaz registrará el segundo error repetidamente y luego se enlazará correctamente cuando la dirección exista; un servicio que registra el primer error nunca tendrá éxito hasta que se resuelva el duplicado. Anotar cuál de los dos vio no cuesta nada y ahorra una búsqueda de interfaces desperdiciada.

Inventaríe el socket, no el puerto

Un número de puerto es un inventario incompleto. El punto final es un transporte, una familia de direcciones, una dirección local y un puerto, todo dentro de un único espacio de nombres de red. Un oyente UDP y un oyente TCP sobre el mismo número son sockets distintos, y dos procesos sobre el mismo número en espacios de nombres diferentes nunca se encuentran.

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

Ejecute primero el transporte que el perfil realmente usa. Luego mire la columna de la dirección local en lugar de solo el número: un enlace comodín cubre todas las direcciones locales, así que un segundo proceso que pide una dirección concreta puede colisionar con él aunque las cadenas impresas difieran. Las opciones de reutilización de socket y las reglas de la plataforma deciden el resultado exacto, por lo que esto debe ser una observación y no una regla que aplique a cada despliegue.

Averigüe qué proceso lo posee

Los puntos finales numéricos más la información del proceso identifican al propietario cuando sus privilegios lo permiten, y el propietario es lo que necesita, no el nombre del programa. Dos procesos de OpenVPN pueden ejecutar perfiles distintos, y el que tiene el oyente puede ser el que menos sospecha.

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

Compare lo que encuentre con el gestor de servicios, un entorno de ejecución de contenedores o un proceso de terminal sobrante de una prueba anterior. La ausencia de detalles del proceso no es prueba de que el socket no tenga propietario; normalmente significa que la consulta se ejecutó sin permisos suficientes. Del mismo modo, un listado solo TCP no descarta un conflicto UDP, así que inspeccione el transporte nombrado en el error. El nombre del proceso por sí solo nunca dice qué perfil se cargó, y el perfil es lo que decide el punto final.

Un propietario, o dos instancias diseñadas

Si el despliegue pretende un solo servidor, mantenga un único propietario del ciclo de vida y lea el diario de esa instancia o el log configurado en lugar de lanzar una segunda copia para observarla. Cuando una ejecución controlada en primer plano sea realmente necesaria, detenga la instancia gestionada de forma deliberada y tenga en cuenta a los clientes que atiende antes de hacerlo.

Si se pretenden dos instancias, déles oyentes distintos y todo lo demás distinto: grupos de direcciones, interfaces virtuales, política de enrutamiento y propiedad de la configuración. Un puerto distinto por sí solo no separa nada más que el socket, y los dos servidores seguirán peleando por el mismo grupo y las mismas rutas.

Tres atajos merecen nombrarse porque aparecen en todos los hilos sobre este error. No mate un PID arbitrario que parezca el culpable. No active el uso compartido de sockets para silenciar el mensaje. No cambie un perfil de servidor a una configuración no vinculada de estilo cliente porque eso hace desaparecer el error de enlace; el servidor deja de ser accesible de una forma más difícil de diagnosticar que el conflicto original.

Cambiar el puerto es una respuesta legítima solo cuando el nuevo oyente forma parte de un diseño aprobado, que incluye la regla de reenvío y el punto final del cliente. Si no se actualizaron, ha trasladado el conflicto a un lugar donde nadie puede encontrarlo.

Verifique el enlace antes que nada

Tras la corrección acotada, confirme que la instancia prevista está activa, que su oyente aparece en el transporte que espera y que un cliente puede conectarse. Un enlace correcto solo completa la etapa del socket local; no certifica nada sobre la autenticación ni sobre el tráfico una vez levantado el túnel.

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

Si el socket está presente y el cliente sigue fallando, el problema restante está aguas abajo y el error de enlace ya es historia. Esa separación es todo el sentido de leer primero el mensaje exacto: un error, una capa, un propietario. Léalo así y el siguiente síntoma empezará desde un estado conocido y no desde una suposición.