OpenVPN atrás do stunnel: encaminhe o invólucro, não a porta 1194

Coloque um invólucro TLS à frente do OpenVPN e a implantação ganha um segundo ouvinte, dos quais apenas um deveria alguma vez olhar para a internet. Quando o túnel funciona a partir da mesma máquina e falha de fora, o encaminhamento costuma apontar para o errado dos dois. O que tem de se alinhar é uma cadeia: a regra pública chega ao invólucro, e a própria ligação de backend do invólucro chega ao socket VPN real. Quatro saltos transportam essa cadeia, e qualquer um deles pode terminar a investigação cedo.

Dois sockets, dois donos, um deles público

O invólucro termina o TLS para a ligação externa e passa o fluxo de bytes decifrado a um ouvinte OpenVPN TCP simples. São sockets separados com ficheiros de configuração separados, pelo que editar um deixa o outro intacto e ainda aparentemente saudável. Também significa que os dois podem divergir sempre que um muda sem o outro.

Trabalhar a partir da própria máquina prova, por isso, muito pouco sobre o caminho público. Uma ligação direta à porta nativa salta o invólucro, uma ligação ao invólucro no seu endereço LAN salta a tradução, e só a disposição completa do lado do cliente exercita o que faz um utilizador externo. Os nomes também têm de ser lidos com cuidado, porque localhost significa o anfitrião que executa esse componente concreto e não o anfitrião em que está por acaso a escrever. Guarde essa distinção nas suas notas, porque um teste registado sem o salto que cobria convida a comparar duas coisas diferentes.

Onde o encaminhamento realmente cai

A cadeia é mais fácil de guardar como quatro saltos do que como três números de porta, porque o mesmo número pode significar coisas diferentes em cada extremo. Leia a tabela linha a linha: cada linha é um socket que tem de aceitar uma ligação e depois abrir a seguinte. Quando uma linha aponta para o par errado, o sintoma da última coluna é o que o utilizador relata.

Uma regra que aponta para a porta VPN nativa em vez do invólucro salta por completo a terminação TLS, e é essa a versão mais comum deste erro: o cliente abre um handshake com um ouvinte que espera o enquadramento OpenVPN, pelo que a ligação pode abrir e depois encravar. Confirme a porta traduzida no ficheiro de configuração do invólucro e não na memória, porque a próxima pessoa a editar esse ficheiro pode ter escolhido outro número. Os dois comandos abaixo mostram os dois lados dessa questão ao mesmo tempo.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

O endereço de ligação que o recusa

Uma linha accept ligada a 127.0.0.1 só responde ao próprio host, pelo que um encaminhamento que chega ao endereço LAN não consegue ligar-se e o cliente vê uma recusa que soa a problema de filtro de pacotes. Olhe para o socket antes de tocar na firewall, porque o socket é a resposta mais barata. Ou liga o invólucro à interface para a qual o encaminhamento aponta, ou mantém-no em loopback e faz com que o encaminhamento chegue a loopback através de algo que funcione mesmo. São dois desenhos, e cada um precisa da sua própria regra.

Misturá-los é como um invólucro funcional acaba inalcançável de fora enquanto cada ficheiro parece correto. A verificação abaixo é um único comando, e responde a uma pergunta que uma revisão das regras da firewall não consegue. Se a saída mostrar um endereço loopback enquanto o encaminhamento aponta para o endereço LAN, a correção pertence à linha accept e não ao filtro de pacotes.

ss -lntp '( sport = :8443 )'

O que o teste local realmente provou

Um sucesso registado sem o salto que cobria não é prova sobre os outros saltos. Anote que endereço o teste usou e que processo respondeu. Depois repita de fora da rede e não de um telemóvel na mesma Wi-Fi, porque o comportamento de grampo varia entre routers e uma ligação que nunca saiu da LAN pode satisfazer um cliente sem o encaminhamento estar minimamente envolvido. Só essa segunda tentativa exercita o caminho que um desconhecido faz.

Quando a tentativa falha, siga uma única ligação nos dois registos: as linhas de aceitação e ligação do invólucro, depois o registo de sessão do daemon VPN. A primeira fronteira que não registe nada é onde pertence a alteração seguinte. Assim que o OpenVPN começa a comparar opções do par, julgue essas mensagens pelas regras dessa implementação. Um aviso de inconsistência de link-mtu não é automaticamente fatal, fixar o link-mtu em 1500 não prova que a fragmentação parou, e a negociação de cifra pertence à configuração interna do OpenVPN e não ao encaminhamento do router.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

Essas sondas cobrem o socket de backend e o registo do invólucro, o que separa um backend recusado de um handshake rejeitado. Execute-as enquanto uma única tentativa está em curso e não depois. As marcas temporais de uma única tentativa são o que torna a comparação fiável.

Duas identidades, duas ordens de falha

O certificado externo pertence ao invólucro e a identidade interna pertence ao OpenVPN, e podem vir de autoridades diferentes. Desativar qualquer das duas verificações para que um caminho pareça saudável troca uma proteção real por um resultado cosmético. Mantenha as duas verificações e depure-as por ordem, porque a sequência das mensagens nomeia a camada: um problema de certificado do invólucro aparece antes de qualquer opção VPN ser negociada, enquanto uma falha de identidade interna só aparece depois de o fluxo estar estabelecido.

O manual do stunnel define com precisão accept, connect e o modo cliente, e essas secções respondem à pergunta do socket mais depressa do que adivinhar. Quando ainda não consegue dizer que camada respondeu, leia o certificado que a porta pública apresenta com o comando abaixo. Um certificado de invólucro na saída significa que o encaminhamento chegou ao invólucro, e o silêncio ou um erro de protocolo significa que não. Essa única distinção poupa mais tempo do que qualquer outra verificação aqui.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer