A porta 1194 já está em uso: a quem pertence esse socket do OpenVPN?

Inicie o mesmo perfil de servidor duas vezes e o segundo processo termina com um erro de endereço em uso para a porta 1194. No caso comum, a inicialização de diagnóstico criou o conflito, e a instância original continua a servir os clientes perfeitamente. Esta história explica grande parte destes relatos, e vale a pena reconhecê-la antes de reiniciar qualquer coisa. Também é a versão mais barata de resolver.

O erro descreve uma ligação local e nada além disso. Não é prova de que um fornecedor bloqueia a porta, de que um cliente enviou a palavra-passe errada ou de que a cadeia de certificados está quebrada.

Leia o erro de ligação exato

Dois erros desta família significam coisas diferentes, e confundi-los envia-o para a camada errada. «Endereço já em uso» diz que outro socket detém o ponto final que pediu. «Endereço indisponível» diz que o endereço pedido ainda não existe neste host, o que é um problema de prontidão e não um duplicado.

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

Copie o texto do erro antes de mudar o que quer que seja, incluindo o endereço e a porta que menciona. Um serviço que espera que uma interface apareça registará o segundo erro repetidamente e depois ligar-se-á com sucesso quando o endereço existir; um serviço que registra o primeiro erro nunca terá sucesso até o duplicado ser resolvido. Anotar qual dos dois viu não custa nada e poupa uma procura de interfaces desperdiçada.

Inventarie o socket, não a porta

Um número de porta é um inventário incompleto. O ponto final é um transporte, uma família de endereços, um endereço local e uma porta, tudo dentro de um único espaço de nomes de rede. Um ouvinte UDP e um ouvinte TCP sobre o mesmo número são sockets diferentes, e dois processos sobre o mesmo número em espaços de nomes diferentes nunca se encontram.

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

Execute primeiro o transporte que o perfil realmente usa. Depois olhe para a coluna do endereço local em vez de apenas o número: uma ligação wildcard cobre todos os endereços locais, por isso um segundo processo que pede um endereço específico pode colidir com ela mesmo que as cadeias impressas sejam diferentes. As opções de reutilização de socket e as regras da plataforma decidem o resultado exato, e é por isso que isto deve ser uma observação e não uma regra que aplica a cada implementação.

Descubra que processo o detém

Os pontos finais numéricos mais a informação do processo identificam o proprietário quando os seus privilégios o permitem, e o proprietário é o que precisa, não o nome do programa. Dois processos do OpenVPN podem executar perfis diferentes, e o que detém o ouvinte pode ser o que menos suspeita.

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

Compare o que encontra com o gestor de serviços, um runtime de contentores ou um processo de terminal sobrante de um teste anterior. A ausência de detalhes do processo não é prova de que o socket não tem proprietário; normalmente significa que a consulta correu sem permissões suficientes. Da mesma forma, uma listagem apenas TCP não elimina um conflito UDP, por isso inspecione o transporte indicado no erro. O nome do processo por si só nunca diz qual perfil foi carregado, e é o perfil que decide o ponto final.

Um proprietário, ou duas instâncias concebidas

Se a implementação pretende um único servidor, mantenha um único proprietário do ciclo de vida e leia o diário dessa instância ou o log configurado em vez de lançar uma segunda cópia para a observar. Quando uma execução controlada em primeiro plano for realmente necessária, pare a instância gerida de forma deliberada e tenha em conta os clientes que ela serve antes de o fazer.

Se se pretendem duas instâncias, dê-lhes ouvintes distintos e tudo o mais distinto: pools de endereços, interfaces virtuais, política de encaminhamento e propriedade da configuração. Uma porta diferente por si só não separa nada além do socket, e os dois servidores continuarão a lutar pelo mesmo pool e pelas mesmas rotas.

Três atalhos merecem ser nomeados porque aparecem em todos os tópicos sobre este erro. Não mate um PID arbitrário que pareça o culpado. Não ative a partilha de sockets para silenciar a mensagem. Não mude um perfil de servidor para uma configuração não ligada ao estilo de cliente porque isso faz o erro de ligação desaparecer; o servidor deixa de estar acessível de uma forma mais difícil de diagnosticar do que o conflito original.

Mudar a porta é uma resposta legítima apenas quando o novo ouvinte faz parte de um desenho aprovado, que inclui a regra de encaminhamento e o ponto final do cliente. Se estes não foram atualizados, moveu o conflito para um lugar onde ninguém o consegue encontrar.

Verifique a ligação antes de tudo o resto

Após a correção delimitada, confirme que a instância pretendida está ativa, que o seu ouvinte aparece no transporte que espera e que um cliente se consegue ligar. Uma ligação bem-sucedida apenas completa a fase do socket local; não certifica nada sobre autenticação nem sobre tráfego depois de o túnel estar de pé.

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

Se o socket estiver presente e o cliente continuar a falhar, o problema restante está a jusante e o erro de ligação é agora história. Essa separação é todo o sentido de ler primeiro a mensagem exata: um erro, uma camada, um proprietário. Leia assim e o próximo sintoma começa a partir de um estado conhecido e não de um palpite.