O porto 1194 xa está en uso: quen posúe ese socket de OpenVPN?

Inicie o mesmo perfil de servidor dúas veces e o segundo proceso sae cun erro de enderezo en uso para o porto 1194. No caso habitual, o arranque de diagnóstico creou o conflito e a instancia orixinal segue a atender os clientes perfectamente. Esta historia explica unha gran parte destes informes e paga a pena recoñecela antes de reiniciar nada. Tamén é a versión máis barata de resolver.

O erro describe unha ligazón local e nada máis aló. Non é proba de que un provedor bloquee o porto, de que un cliente enviase o contrasinal incorrecto ou de que a cadea de certificados estea rota.

Lea o erro de ligazón exacto

Dous erros desta familia significan cousas distintas, e confundilos envíao á capa equivocada. «Enderezo xa en uso» di que outro socket posúe o punto final que solicitou. «Enderezo non dispoñible» di que o enderezo solicitado aínda non existe neste host, o que é un problema de preparación e non un duplicado.

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

Copie o texto do erro antes de cambiar nada, incluídos o enderezo e o porto que menciona. Un servizo que espera a que apareza unha interface rexistrará o segundo erro repetidamente e despois ligarase correctamente cando o enderezo exista; un servizo que rexistra o primeiro erro nunca terá éxito ata que se resolva o duplicado. Anotar cal dos dous viu non custa nada e aforra unha busca de interfaces desperdiciada.

Inventaríe o socket, non o porto

Un número de porto é un inventario incompleto. O punto final é un transporte, unha familia de enderezos, un enderezo local e un porto, todo dentro dun único espazo de nomes de rede. Un oínte UDP e un oínte TCP sobre o mesmo número son sockets distintos, e dous procesos sobre o mesmo número en espazos de nomes diferentes nunca se atopan.

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

Execute primeiro o transporte que o perfil realmente usa. Despois mire a columna do enderezo local en lugar de só o número: unha ligazón comodín cobre todos os enderezos locais, así que un segundo proceso que pide un enderezo concreto pode colidir con ela aínda que as cadeas impresas difiran. As opcións de reutilización de socket e as regras da plataforma deciden o resultado exacto, por iso isto debe ser unha observación e non unha regra que aplique a cada despregamento.

Averigüe que proceso o posúe

Os puntos finais numéricos máis a información do proceso identifican o propietario cando os seus privilexios o permiten, e o propietario é o que necesita, non o nome do programa. Dous procesos de OpenVPN poden executar perfís distintos, e o que ten o oínte pode ser o que menos sospeita.

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

Compare o que atope co xestor de servizos, un contorno de execución de contedores ou un proceso de terminal sobrante dunha proba anterior. A ausencia de detalles do proceso non é proba de que o socket non teña propietario; normalmente significa que a consulta se executou sen permisos suficientes. Do mesmo xeito, unha listaxe só TCP non descarta un conflito UDP, así que inspeccione o transporte nomeado no erro. O nome do proceso por si só nunca di que perfil se cargou, e o perfil é o que decide o punto final.

Un propietario, ou dúas instancias deseñadas

Se o despregamento pretende un só servidor, manteña un único propietario do ciclo de vida e lea o diario desa instancia ou o log configurado en lugar de lanzar unha segunda copia para observala. Cando unha execución controlada en primeiro plano sexa realmente necesaria, deteña a instancia xestionada de forma deliberada e teña en conta os clientes que atende antes de facelo.

Se se pretenden dúas instancias, déalles oíntes distintos e todo o demais distinto: grupos de enderezos, interfaces virtuais, política de encamiñamento e propiedade da configuración. Un porto distinto por si só non separa nada máis que o socket, e os dous servidores seguirán loitando polo mesmo grupo e as mesmas rutas.

Tres atallos merecen nomearse porque aparecen en todos os fíos sobre este erro. Non mate un PID arbitrario que pareza o culpable. Non active a compartición de sockets para silenciar a mensaxe. Non cambie un perfil de servidor a unha configuración non ligada de estilo cliente porque iso fai desaparecer o erro de ligazón; o servidor deixa de ser accesible dunha forma máis difícil de diagnosticar que o conflito orixinal.

Cambiar o porto é unha resposta lexítima só cando o novo oínte forma parte dun deseño aprobado, que inclúe a regra de reenvío e o punto final do cliente. Se non se actualizaron, trasladou o conflito a un lugar onde ninguén pode atopalo.

Verifique a ligazón antes que nada

Tras a corrección acoutada, confirme que a instancia prevista está activa, que o seu oínte aparece no transporte que espera e que un cliente pode conectarse. Unha ligazón correcta só completa a etapa do socket local; non certifica nada sobre a autenticación nin sobre o tráfico unha vez levantado o túnel.

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

Se o socket está presente e o cliente segue fallando, o problema restante está augas abaixo e o erro de ligazón xa é historia. Esa separación é todo o sentido de ler primeiro a mensaxe exacta: un erro, unha capa, un propietario. Léao así e o seguinte síntoma comezará desde un estado coñecido e non desde unha suposición.