A VPN conecta em casa mas expira no Wi-Fi do hotel

O portátil entra no Wi-Fi de casa, o cliente conecta em três segundos, e o mesmo perfil falha no hotel uma hora depois. Nada foi actualizado entretanto. Percorrer isto com um cliente à frente trata sobretudo de saber qual erro pertence a que fase, porque a informação útil está no código que o cliente imprime, não no facto de ter falhado. Siga os quatro passos abaixo por ordem e saberá se o recusou um nome, um pacote, uma porta ou uma política.

Leia o código de erro como uma fase, não como um veredito

O cliente atinge três marcos separados antes de existir um túnel. Resolve o nome do servidor, obtém uma resposta de algo na rede e negoceia uma associação de segurança. Cada marco tem a sua própria mensagem de falha, e o Windows em particular é generoso com códigos distintos assim que sabe a que fase pertencem.

Dois desses códigos significam que a rede é inocente. Um 789 significa que os pacotes fluíam e os dois lados não concordavam sobre a criptografia, o que é um problema de configuração que pode resolver em casa. Um 868 significa que nenhum pacote precisou de sair, por isso o desenho do túnel é irrelevante até o nome ser resolvido. Classificar o código na fase certa poupa mais tempo do que qualquer captura, porque diz qual dos três passos seguintes pode saltar.

Seja prudentemente cauteloso se o cliente não for Windows. Os clientes de terceiros reduzem a maior parte disto a "ligação falhada", e é por isso que os dois passos seguintes não dependem nada da mensagem.

Verifique o nome antes de culpar o túnel

As redes de hotéis e aeroportos interceptam o DNS constantemente, e um resolvedor que responde com um endereço de portal produz uma falha que parece exactamente um servidor morto. Compare o que diz o resolvedor local com o que diz um público:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

Se as duas respostas diferirem, está a ser conduzido e o resto do diagnóstico é desperdiçado até isso ser resolvido. Um endereço de portal, em particular, aceitará de bom grado a ligação TCP e depois ficará parado, e é por isso que pode parecer um bloqueio de firewall quando testa com um navegador.

Agora confirme que o endereço que quer alcançar é o que está a ser usado. Alguns clientes colocam em cache a resolução anterior durante toda a vida do perfil, por isso uma reconexão depois da mudança de DNS ainda vai para o endereço antigo. Feche o cliente por completo antes de testar de novo, em vez de premir desligar e ligar na mesma janela.

Descubra qual pacote exterior desaparece

O túnel tem um fluxo exterior que pertence inteiramente ao caminho entre si e o servidor, e é esse fluxo que os equipamentos intermédios classificam e descartam. Capture-o no cliente e depois compare uma rede que funciona com a que falha. No Windows a captura integrada chega para um primeiro olhar:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

O que quer ver é se os seus pacotes saem e se algo volta. Pacotes para fora sem nada de volta significa que o caminho ou o extremo remoto os descarta; se não sair nada de todo, o cliente nunca chegou a enviar, o que aponta para a resolução de nomes ou para uma política local de firewall.

Repita o mesmo teste num hotspot de telemóvel. É a comparação mais informativa de que dispõe, porque retira do caminho todas as caixas do hotel mantendo idênticos o portátil, o cliente e as credenciais. Se o túnel subir no hotspot, deixe de olhar para o servidor. Se também falhar ali, tem um problema de cliente ou de conta que a rede nunca estava a causar.

Mude um transporte e teste de novo

Depois de saber que o fluxo exterior é descartado, a pergunta prática é que fluxo a rede permite. A maioria das redes restritas permite TCP 443 de saída porque não conseguiria funcionar de outra forma, por isso mover o ouvinte para lá é a resposta habitual. No OpenVPN isso é um interruptor do lado do cliente até o servidor ser alterado:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

Os clientes IPsec têm um controlo equivalente nos seus próprios painéis de configurações, normalmente descrito como IPsec sobre TCP ou travessia NAT. Alterá-lo também é um diagnóstico: se o túnel subir sobre TCP e morrer sobre UDP, provou que a rede filtra UDP, e também encontrou a configuração de que vai precisar sempre que visitar esse local.

Resista à tentação de desactivar funções do router à primeira tentativa. Desligar a inspecção com estado ou a protecção contra inundações numa rede de hotel não está ao seu alcance de qualquer forma, e no seu próprio equipamento troca uma protecção real por um único portátil. Anote que configuração mudou o resultado, depois reponha-a e procure um transporte que a rede já permita.

Verifique o mesmo perfil na segunda rede

Antes de fechar o ticket, prove que a alteração sobreviveu a sair do edifício. Volte a ligar na rede original com as configurações originais, capture os primeiros trinta segundos e confirme que o cliente atinge o mesmo estado que atingiu no hotspot:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

A distinção que o último comando revela merece ser mantida: o perfil pode reportar um túnel ligado enquanto o encaminhamento lá dentro está errado, e isso produz "a VPN está ligada mas nada funciona", que é outro artigo. Se o tipo de túnel mudou depois da sua edição, o perfil não é o que testou.

Depois escreva a conclusão onde a próxima pessoa vai olhar. "O perfil da empresa precisa de TCP 443 neste local; o UDP 500 é filtrado pelo hotel" é uma frase sobre a qual um colega pode agir. "A VPN é instável em hotéis" não é, e garante que a mesma hora será gasta outra vez no próximo mês.