VPN bloqueada numa rede só web? Trabalhe as camadas

Uma rede de campus ou hotel onde o navegador funciona e cada túnel morre não é um problema, são quatro empilhados. O caminho pode permitir apenas TCP 443, exigir um proxy autenticado, inspecionar o handshake ou simplesmente proibir o acesso remoto por política. Tratá-los em ordem evita que compre um cliente novo para corrigir uma regra de rede. O roteiro abaixo leva cerca de dez minutos e termina com uma resposta escrita sobre qual camada o recusou.

Prove qual camada recusa a conexão

Não comece pelo cliente VPN. Comece com um pedido HTTPS simples ao mesmo host e leia as fases de tempo, porque a fase que falha diz qual dispositivo é o responsável:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Sem resposta e sem tempo connect significa que o TCP nunca foi concluído, portanto há uma firewall, uma exigência de proxy ou um destino errado em jogo. Um tempo connect sem tempo tls significa que algo no meio aceitou a conexão e depois travou o handshake, e é exatamente assim que um proxy inspetor se vê do lado do cliente.

Agora inspecione o certificado que realmente recebe. É a forma mais rápida de saber se fala com o servidor ou com uma caixa intermédia que voltou a assinar a sessão:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Leia a linha do emissor. A sua própria CA significa que chegou ao serviço; um emissor empresarial ou de dispositivo significa que um filtro terminou a conexão e está a decidir o que acontece a seguir. Registe ambas as saídas com um carimbo temporal, porque o mesmo teste uma hora depois na rede de hóspedes pode dar outra resposta.

Um cliente consciente do proxy muda o primeiro pacote, não a política

Se a rede exige CONNECT através de um proxy autenticado, é preciso dizê-lo ao cliente VPN, senão ele tentará abrir um socket para um endereço que não consegue encaminhar. Teste o proxy separadamente do cliente, para que uma falha tenha uma só explicação:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

O primeiro comando prova que o proxy transporta o destino. O segundo pede ao cliente que use TCP no 443, o único transporte que a maioria dos caminhos só web deixa passar. Se o primeiro comando funciona e o segundo continua a falhar, o proxy não é o obstáculo.

Alguns clientes leem o proxy do sistema operativo em vez de uma substituição, e alguns não leem nenhum dos dois. Verifique a documentação da aplicação antes de assumir que uma definição global se aplica. Um cliente que resolve o endpoint através de um resolvedor que o proxy não serve também falhará aqui, e é por isso que uma alteração de DNS pode parecer uma correção quando é apenas um desvio.

Repare também no padrão de encaminhamento. Uma rede filtrada pode responder ao nome de deteção de um fornecedor com algo seu, o que muda qual perfil de proxy o cliente escolhe. Não construa um processo em torno dessa esquisitice. Varia por local, muda sem aviso e não é algo que possa suportar para mais ninguém.

A porta 443 é alcançável, não permitida

Envolver um túnel em TLS no 443 resolve a alcançabilidade e nada mais. Um filtro que verifica a porta deixa-o passar; um filtro que recolhe a impressão digital do handshake não, e o client hello cifrado só esconde o nome do servidor quando ambos os extremos o suportam. Execute o teste e descubra atrás de que tipo de filtro está em vez de esperar.

Há também um custo de desempenho que as pessoas descobrem mais tarde. Um transporte fiável dentro de outro transporte fiável amplifica a perda, porque a pilha interior retransmite segmentos que a pilha exterior já retransmitiu. Numa ligação limpa ninguém nota. Numa rede sem fios de campus congestionada o túnel torna-se inutilizável exatamente quando precisa dele, e o gráfico parece perda de pacotes embora nada seja descartado de propósito.

O UDP é normalmente a primeira vítima, e vale a pena confirmá-lo em vez de deduzi-lo. Se o WireGuard ou o OpenVPN por omissão nunca completa um handshake enquanto o TCP 443 funciona, a rede está a descartar UDP, e nenhuma regeneração de chaves o mudará:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Um carimbo temporal de handshake vazio junto a um par que ontem funcionava é a resposta do UDP. As duas consultas DNS respondem a outra pergunta: se o resolvedor local e um resolvedor público discordam sobre o endereço do endpoint, está a ser encaminhado e o argumento do transporte é o errado.

Verifique o que realmente saiu da máquina

Os registos do cliente descrevem o que o cliente acredita. Uma captura descreve o que a rede viu, e a diferença entre as duas é onde a maioria destes casos se resolve:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

Se vir pacotes SYN e nenhum SYN-ACK, o bloqueio está a montante e o cliente é inocente. Se vir um handshake concluído para um endereço que não é o do servidor, está a falar com um proxy ou um intercetor. Se não vir nada, verifique se capturou na interface correta antes de concluir algo.

A lista de sockets apanha um caso mais subtil: um segundo túnel que já detém a rota predefinida. Dois clientes a lutar pela tabela de rotas produzem falhas intermitentes que parecem exatamente uma rede bloqueada, e a captura mostrará tráfego a sair por uma interface que não esperava.

Reversão, e a nota que vale a pena guardar

Desfaça as alterações na ordem inversa àquela em que as fez. Remova as variáveis de proxy, pare o cliente que iniciou à mão e retire qualquer substituição de rota ou resolvedor que tenha adicionado:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

Deixar um cliente iniciado à mão a correr é como um portátil acaba com a rede avariada na visita seguinte ao escritório. As variáveis de proxy deixadas num perfil de shell quebram ferramentas não relacionadas semanas depois, e quem as depura não ligará os dois acontecimentos.

Depois escreva quatro linhas: a rede, o carimbo temporal, a fase que falhou e o emissor que viu. Um caminho que funciona num campus e falha no seguinte é normal, e a pessoa seguinte precisa saber se a diferença era o proxy, o resolvedor ou o filtro. Se a resposta for que a rede proíbe o acesso remoto, pare aí e peça ao administrador a rota suportada em vez de levar um desvio para uma política que não leu.