Porta VPN muda? Listener, endereço de bind ou firewall do host

O VPN não responde nada na sua porta, e as duas causas possíveis exigem reparos opostos: ou nenhum processo abriu o socket, ou o socket existe e algo entre as máquinas está a parar os pacotes. Um único comando resolve a primeira metade dessa pergunta, por isso vem antes de qualquer regra de firewall ser tocada. A ordem abaixo remove uma explicação por passo em vez de acrescentar outra suposição. É o adivinhar entre as duas que transforma um diagnóstico de dez minutos numa noite inteira.

Assuma que consegue iniciar sessão no servidor e que o cliente é um perfil real e não um scanner. Ambas as suposições contam, porque uma sonda genérica não consegue responder a uma pergunta específica do protocolo.

O socket existe sequer

Comece pelo que o serviço diz de si mesmo: se arrancou e, mais útil, qual foi o seu primeiro erro de arranque. Uma falha de análise, uma chave em falta ou um erro de bind impedem o listener de existir, e o processo pode sair tão silenciosamente que a linha de estado se lê de forma ambígua. Uma unidade que se declara ativa não é prova por si só, porque o processo principal pode estar vivo enquanto o componente que devia ligar a porta já desistiu.

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

A listagem de sockets é o facto em que assenta o resto do diagnóstico. Leia a coluna do endereço local e não apenas a porta, porque é nessa coluna que aparecem as ligações a loopback e as ligações à interface errada. Um listener que existe em 127.0.0.1 funciona perfeitamente e continua invisível para o seu portátil.

Em que endereço e família o socket responde

Dois erros parecem iguais do lado do cliente e explicam a maioria dos relatos de "inacessível". Um servidor ligado ao endereço de loopback nunca aceita tráfego de outra máquina, e um servidor ligado apenas a um endereço IPv4 nunca responde a um cliente que marca o endereço IPv6 do mesmo host. Compare o endereço da tabela de sockets com o endereço que o cliente está realmente a marcar, carácter a carácter, antes de assumir qualquer coisa sobre a política.

Limitar a listagem a uma só porta mantém-na legível quando o host executa vários serviços. O filtro sport toma a porta juntamente com o transporte que está a testar:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

A coluna do protocolo muda toda a resposta

A tabela de sockets indexa tanto pelo protocolo como pela porta, e são duas entradas independentes. Um serviço que responde em TCP na 1194 não diz nada sobre se algo escuta em UDP na 1194, e o cliente só usará um dos dois. Confirme que transporte a configuração do servidor escolhe e qual o perfil do cliente envia, e depois procure exatamente essa linha.

O UDP tem uma segunda dobra: uma sonda não autenticada não é um erro a que o serviço tenha de responder. Uma análise que reporta a porta como muda mediu a discrição do serviço, não a sua disponibilidade, por isso teste com o cliente e o perfil reais.

Uma tentativa, três sítios onde olhar

A partir de um cliente aprovado faça exatamente uma tentativa e anote a hora ao segundo. Depois leia três fontes para essa janela: a regra de rede ou a consola do fornecedor, os contadores ou o registo do firewall do host e o registo do próprio serviço. Fazer isto uma vez é o que torna os três relatos comparáveis, e custa menos do que repetir uma tentativa cuja marca temporal ninguém registou.

Os dois resultados apontam em direções opostas. Se nenhum pacote chegou ao host, o caminho está a descartá-lo e o listener é irrelevante. Se o pacote chegou ao socket e o serviço o rejeitou, o caminho está bem e a resposta está no protocolo, na criptografia ou nas credenciais. Abrir uma porta para um serviço que já aceitou uma ligação torna o diagnóstico seguinte mais difícil, não mais fácil.

Nomeie a etapa antes de mudar uma regra

Uma negociação que começa e uma autenticação que falha são uma única falha, e um túnel que se estabelece enquanto o encaminhamento encrava é outra completamente diferente. Nomear a etapa primeiro mantém o reparo estreito: um problema de credenciais não se resolve com uma regra de firewall, e um problema de caminho de dados não se resolve com um reinício.

Use o diagnóstico mais estreito que responde à pergunta. Uma observação temporária de pacotes numa porta, sob o controlo de um administrador, é um instrumento razoável; desativar toda a firewall não é, porque o resultado se torna impossível de atribuir. A documentação do ss cobre os filtros usados acima, e é um primeiro passo mais barato do que qualquer captura. Registe qual dos dois ramos provou, e a ocorrência seguinte começa numa resposta conhecida.