OpenVPN na 443 ainda bloqueado? Veja o que a rede inspeciona

O túnel conecta a partir de uma linha doméstica e trava numa rede de hotel ou escritório, e mover o servidor para a porta 443 não mudou nada. Esse resultado é comum o bastante para ter uma forma: a porta era a parte fácil, e o resto da decisão pertence a tudo o que fica entre o cliente e o servidor. Duas perguntas resolvem a maioria dos casos, e nenhuma delas trata de cifras. A rede aceita um handshake TLS para esse endereço, e o cliente mantém uma rota para o próprio invólucro enquanto o túnel está de pé?

O handshake revela mais do que o número

Um ouvinte VPN nativo em TCP 443 fala o próprio protocolo desde o primeiro pacote. Um ClientHello tem um campo de versão, um valor aleatório e uma lista de extensões, e um dispositivo que lê algumas centenas de bytes percebe a diferença sem descriptografar nada. Números de porta são baratos de satisfazer, e é a forma do protocolo que o filtro realmente verifica. As regras costumam ser escritas também por protocolo, então uma política que inspeciona TLS não diz nada sobre UDP.

Um proxy transparente que exige uma sessão TLS válida derruba a conexão durante a configuração, muitas vezes depois que o handshake TCP termina. Esse detalhe importa mais adiante, porque significa que o log do cliente para depois que o socket é estabelecido.

Envolver o fluxo cria dois pontos de falha

Um invólucro TLS como o stunnel restaura a forma esperada: o cliente conecta a um ouvinte local, o invólucro abre uma sessão TLS real até o servidor na 443, e um segundo invólucro no servidor encaminha os bytes descriptografados ao daemon VPN. A sessão externa agora parece qualquer outra conexão HTTPS. O daemon VPN no servidor deveria escutar apenas no loopback, porque nada fora do invólucro precisa alcançá-lo.

Três coisas separadas precisam se alinhar nesse desenho. O perfil do cliente aponta para o ouvinte local, o certificado do servidor corresponde ao nome que o cliente verifica, e o encaminhamento do lado do servidor mira a porta que o daemon realmente usa. Erre em qualquer uma delas e a conexão morre antes de chegar à camada VPN. Uma divergência de certificado aparece então como erro do invólucro e não como erro de VPN, e é por isso que vale ler os dois logs lado a lado.

A rota até o invólucro é a armadilha

Assim que o túnel sobe, a rota padrão aponta para dentro dele, e a sessão TLS externa precisa de um caminho que não entre no túnel que ela carrega. Um cliente VPN comum protege o endereço que disca; um cliente encapsulado disca para o próprio loopback, então o endereço de destino do invólucro é invisível para essa proteção.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

Os endereços exatos você preenche, e a rota precisa existir por toda a vida da conexão, não só na inicialização. Um pequeno script de invólucro que adiciona a rota antes do cliente e a remove depois é mais confiável do que um comando memorizado.

No Android, o equivalente dessa exceção é um ajuste por aplicativo: exclua o aplicativo do invólucro do túnel para que o tráfego dele saia pela conexão móvel. Sem a exclusão, o invólucro é roteado para dentro do túnel que está tentando construir, e o ciclo de reconexão parece um problema do servidor.

Leia os tempos antes de mudar qualquer coisa

Uma sessão que morre após o mesmo intervalo todas as vezes é uma assinatura de política e não uma falha criptográfica, e limites de fluxo de longa duração produzem exatamente esse padrão. Uma conexão que é reiniciada logo após o handshake sugere um proxy que não gostou da cadeia de certificados.

Compare o emissor do certificado de um site HTTPS comum nas duas redes. Se o emissor for diferente na rede restrita, algo está terminando TLS no meio, e nenhum invólucro sobrevive a essa interceptação sem mudanças. A mesma comparação diz se o bloqueio mira o nome do seu servidor ou cada sessão TLS naquele endereço.

Anote o comportamento observado: quanto durou a sessão, se o socket abriu, se o invólucro registrou um handshake. Cada um desses pontos estreita o próximo teste.

Teste uma variável de cada vez

Verifique UDP primeiro, porque algumas redes o descartam por completo e uma falha de UDP não diz nada sobre a 443. Depois tente TCP 443 sem o invólucro, em seguida o invólucro na 443. Leia o log do cliente em cada passo e pare assim que o comportamento mudar.

Mude um elemento por tentativa. Uma porta nova, um invólucro novo e uma cifra nova na mesma rodada deixam você sem poder dizer qual dos três importou.