Wi-Fi do hotel: a VPN falha antes mesmo de chegar ao servidor

O cliente VPN roda, depois informa que não consegue alcançar o servidor, e todos concluem que o hotel bloqueia VPNs. Normalmente nada tão dramático aconteceu: a rede ainda não o deixou sair. Um portal cativo retém cada ligação até iniciar sessão, e um túnel não se completa enquanto uma página de acesso interceta os seus pacotes. Faça o início de sessão antes de culpar o túnel.

O mito: o hotel bloqueia VPNs

A maioria das redes de hotel não filtra túneis especificamente. Intercetam o tráfego web até o hóspede se autenticar, e podem também limitar dispositivos, expirar sessões ou reduzir a largura de banda. Cada uma dessas coisas produz uma falha que, de dentro de um cliente VPN, parece um bloqueio.

O túnel é aqui um mau diagnóstico, porque é a única aplicação que falha com certeza enquanto o portal não está autenticado. O acesso web normal é o melhor indicador, porque pode mostrar-lhe a própria página de acesso.

Essa ordem importa por outra razão: um cliente com interruptor de segurança ou modo sempre ativo recusará carregar o portal, e o utilizador concluirá que a rede está avariada e não a definição. Ambos os factos são verdadeiros ao mesmo tempo, e só um deles pode ser alterado no hotel. Desative a proteção através do controlo do próprio cliente, inicie sessão e volte a ativá-la. Qualquer outra coisa é um contorno que esconde a sequência real.

Termine primeiro o portal e depois teste o HTTPS normal

Pergunte ao pessoal o nome oficial da rede e o método de acesso. Um SSID convincente não é prova de propriedade, e uma segunda rede com nome semelhante é um truque comum em locais públicos. Use o pedido de acesso do próprio sistema operativo quando existir, ou a página documentada do hotel.

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

O primeiro pedido consulta um ponto de deteção de portal cativo conhecido por HTTP simples; um redirecionamento ou corpo inesperado significa que ainda está atrás do portal. O segundo testa um site HTTPS normal. Se o primeiro mostra interceção e o segundo falha, o início de sessão está incompleto e a VPN não tem nada a ver.

Num dispositivo pessoal pode ser necessário desativar o interruptor de segurança ou a VPN sempre ativa através do controlo suportado do cliente para que o portal carregue. Feche as aplicações sensíveis nesse intervalo e reative a proteção imediatamente depois. Num dispositivo gerido, siga o procedimento aprovado pelo administrador em vez de remover uma política por si.

Nunca contorne um aviso de certificado nem instale um certificado desconhecido ou aplicação auxiliar para ficar online. Se o portal exigir algo inesperado, confirme com o pessoal, e com o administrador se o dispositivo for de uma entidade empregadora.

Guarde o perfil original e o respetivo erro

Quando o acesso normal funcionar, ligue o perfil original e registe o erro exato. Uma rejeição de autenticação é um problema de conta, um tempo limite durante a negociação é um problema de caminho, e um túnel que se estabelece mas não transporta nada é um problema de encaminhamento ou de política.

Estes três exigem passos seguintes diferentes, e uma captura do erro vale mais do que uma descrição. Registe também a hora, porque os limites de sessão do hotel podem expirar numa hora e produzir uma falha que parece aleatória. Se o cliente oferecer um registo, guarde a secção em torno da primeira falha e não o ficheiro inteiro. Esse excerto costuma bastar a quem possui o perfil para identificar a fase.

Se o acesso normal funcionar e a negociação continuar a expirar, pergunte ao hotel se suporta esse tráfego, e compare com um hotspot de confiança mantendo o dispositivo e o perfil constantes. Trabalhar no hotspot estreita a atenção para o caminho do hotel sem provar nada sobre o perfil.

Use apenas as alternativas fornecidas pelo operador

Um perfil TCP correspondente pode ter sucesso onde o caminho UDP oferecido não funciona, mas apenas se o servidor escutar realmente nesse transporte e porta. A porta TCP 443 não é tratada automaticamente como HTTPS normal, e não é garantia de passagem por uma rede restritiva.

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

Executar o perfil fornecido com maior detalhe mantém visível o primeiro erro útil em vez de o comprimir numa caixa de falha genérica. Use o ficheiro que o operador forneceu em vez de editar portas ou protocolos por si, porque uma alteração local não pode criar um ouvinte correspondente do outro lado.

Se o túnel se reiniciar repetidamente, anote se o portal reaparece ou se o sinal local cai, e siga as verificações de estabilidade em vez de trocar vários protocolos ao mesmo tempo. Depois teste a aplicação de que realmente precisa e reponha os controlos de privacidade habituais. Uma ligação que transporta um site mas não outro é uma questão de encaminhamento ou de política, não do portal.

Por fim, verifique a recuperação depois de o portátil dormir. A autorização do portal pode expirar independentemente do túnel, pelo que um dispositivo que se reconecta sozinho pode voltar a uma rede que já se esqueceu dele. Reabrir a página do portal é um passo normal, não um sinal de que a VPN está avariada.