OpenVPN não conecta no Wi-Fi do hotel? Tente TCP 443

Abra o cliente, pressione Conectar e leia a linha de status em vez da caixa de diálogo que vem depois. Um perfil que trava em Conectando ou Aguardando servidor depois de uma rede de hotel, campus ou móvel normalmente perdeu o transporte em algum ponto do caminho, não as credenciais. O próximo passo útil é descobrir o que aquela rede transporta antes de tocar no servidor. Não mude nada até o mesmo perfil ter funcionado em outro lugar.

Teste primeiro a partir de um hotspot do celular. Se o túnel subir ali, o servidor, o certificado e a conta estão todos bem, e a única variável restante é a rede à sua frente.

Comece pelo cliente: leia a linha de status

A linha de status diz qual etapa falhou. Um cliente preso em Conectando ainda está resolvendo o host ou abrindo o socket externo; um que chega a Aguardando servidor tem caminho mas não tem resposta; um que autentica e depois cai tem um problema completamente diferente. O log do cliente e os próprios campos remote e proto do perfil mostram o que o cliente tenta fazer, e --verb 4 num cliente de linha de comando imprime o mesmo detalhe. Comparar isso com a rede à sua frente é o que transforma 'a VPN está bloqueada' numa afirmação concreta.

Depois sonde a rede com ferramentas que você já tem. nc -vzu 203.0.113.10 1194 envia um datagrama UDP, curl -v telnet://203.0.113.10:443 informa se o aperto de mão TCP se completa, e um navegador que carrega uma página HTTPS só prova que a saída 443 alcança aquele único host. Sondagens pequenas respondem o que o cliente VPN não consegue: que porta e que protocolo saem desta rede afinal.

Três comportamentos de rede parecem iguais a partir do cliente e exigem respostas diferentes. A saída 443 pode estar aberta, só um proxy pode ser permitido, ou 443 pode ser encaminhada de forma transparente para uma caixa de inspeção que não consegue ler o que transporta. O primeiro é corrigido pela mudança de perfil abaixo, o segundo pelas configurações de proxy, e o terceiro pode completar o aperto de mão e depois travar quando o inspetor decide que não gosta do fluxo. Saber qual dos três você enfrenta é a diferença entre uma mudança de dez minutos e uma tarde reinstalando clientes.

Mova o listener e o perfil juntos

No lado do servidor, ajuste o listener ao que a rede permite: port 443 e proto tcp na configuração do servidor, depois reinicie o serviço e confirme o socket com ss -lntp. No lado do cliente, o perfil tem de concordar, porque transporte e porta ficam fora do túnel: proto tcp e port 443 no .ovpn, ou os campos correspondentes na tela de configurações do aplicativo. Um perfil ainda apontado para UDP 1194 falha exatamente como antes, e a tentação é culpar um firewall que já foi corrigido. Se o mesmo host também responde HTTPS na 443, os dois listeners não podem compartilhar esse endereço e protocolo; dê à VPN um segundo endereço ou coloque um demultiplexador à frente.

Acompanhe a primeira conexão com tcpdump -ni any port 443 nas duas pontas. Pacotes que saem do cliente e nunca chegam significam que a rede filtra afinal, ou que o endereço do perfil não é o que você supõe. Pacotes que chegam sem resposta devolvem você ao log do servidor, onde uma incompatibilidade de protocolo aparece imediatamente como pacote descartado.

Quando só um proxy sai da rede

Algumas redes de hóspedes não permitem nada além de um proxy HTTP, o que é uma restrição diferente de uma porta fechada e exclui mais do que o OpenVPN. Clientes que falam apenas PPTP, L2TP/IPsec ou IPsec puro não têm como passar por ele, porque esses projetos esperam que o protocolo externo deles chegue diretamente ao servidor. O OpenVPN consegue, com http-proxy proxy.example.net 8080 no perfil do cliente, desde que o proxy permita o método CONNECT para a sua porta. Um proxy SOCKS é ainda mais fácil, porque encaminha o fluxo sem se importar com o que há dentro.

Onde o cliente não tem suporte a proxy, um túnel SSH sobre 443 costuma ser o que resta. Ele acrescenta uma segunda camada, e o operador da rede pode ter opinião sobre isso, então trate-o como uma ponte para uma viagem e não como arquitetura.

Precifique o recurso antes de mantê-lo

TCP dentro de TCP tem um custo conhecido. Quando a conexão externa é TCP e a carga útil também é TCP, um segmento perdido provoca retransmissão nas duas camadas, e a conexão interna recua diante de uma perda que não consegue ver. A navegação sobrevive; sessões interativas e chamadas sentem. Mantenha o listener TCP 443 como recurso para redes que o exigem, e deixe UDP como padrão para tudo o que ainda o deixa passar.

Registre a escolha no nome do perfil e nas notas de suporte: qual porta, qual protocolo e qual rede a motivou. Depois pergunte ao administrador da rede se aquela porta continuará aberta depois da próxima troca de equipamento, porque um recurso que desaparece em silêncio é pior do que nenhum recurso.