Teste um hotspot antes de deixar credenciais de trabalho se aproximarem

O hotspot distribui um endereço antes de distribuir a internet, e a confiança é decidida exatamente nessa lacuna. O dispositivo associa-se, pede um endereço, e então cada pedido de saída é interceptado até um portal dizer que a sessão está autorizada. Esse mecanismo explica por que uma página pode parecer carregar enquanto não existe nenhuma conexão real. Teste a lacuna com algo inofensivo antes de qualquer credencial de trabalho tocá-la.

O que o hotspot faz com o seu primeiro pedido

A associação dá ao dispositivo um link, e o DHCP dá a ele um endereço, um gateway e normalmente um servidor DNS pertencente ao local. Até a autorização terminar, o gateway descarta ou redireciona o tráfego de saída, e muitos portais respondem ao DNS de cada nome com o próprio endereço. É por isso que uma consulta parece funcionar: a resposta é o portal, não o site que você pediu. A rede comporta-se como projetada; ela simplesmente ainda não é a internet.

O primeiro pedido HTTP normalmente recebe um redirecionamento para o portal, que o sistema operacional pode abrir para você. HTTPS não pode ser redirecionado assim, então ele falha ou fica pendurado, e o navegador mostra um erro de certificado ou um tempo esgotado. A diferença é diagnóstica: um redirecionamento HTTP é o portal falando, enquanto uma falha de TLS para um host não relacionado é outra coisa. Um jardim murado, onde alguns domínios passam para pagamento ou login, produz um terceiro padrão.

Confirme a rede antes de iniciar sessão

Confirme o SSID e o método de login com o local por um canal que não seja a própria rede. Um portal que pede uma senha corporativa, um número de cartão e um endereço de e-mail faz três coisas diferentes, e apenas as duas últimas são normais para acesso de convidados. Prefira o aviso de portal cativo do sistema operacional, que deteta o redirecionamento através de um ponto final conhecido em vez de confiar em qualquer página que apareça. Se o local não consegue descrever o próprio portal, é motivo para esperar e não para improvisar.

Um aviso de certificado durante o login no portal não é um passo para clicar e seguir. O portal não precisa de se passar por um host não relacionado para o autenticar.

Faça a menor verificação que prova acesso

Conclua a autorização legítima, depois peça uma página HTTPS pública comum que não tenha carregado antes, para que a resposta não possa vir da cache. Anote o que realmente falhou se falhar: uma consulta de nome, um tempo de ligação esgotado, um erro de certificado ou uma recusa do serviço. Esses quatro pertencem a camadas diferentes, e anotá-los impede a pessoa seguinte de testar de novo por sensação. Depois ligue a VPN pretendida e peça um recurso que a exija.

Mantenha o teste pequeno. Um download de teste de velocidade em acesso limitado responde a uma pergunta que ninguém fez e pode custar dinheiro ao utilizador. Uma resposta com cabeçalhos basta para estabelecer a alcançabilidade, e não puxa megabytes por uma ligação que cobra por gigabyte.

Se o acesso comum funciona e o túnel não, é uma investigação diferente da de uma rede que nunca autorizou. Mantenha os dois resultados separados em vez de mudar várias definições de privacidade ao mesmo tempo.

Mantenha o trabalho privado fora da comparação

Cada aplicação no dispositivo é um observador potencial, e um portal cativo é o momento em que todas tentam alcançar os seus servidores. Feche as que puder, e trate um dispositivo gerido sempre ligado como uma questão de política e não técnica: use o método aprovado para a comparação em vez de remover a proteção que o torna gerido. Se o dispositivo proíbe completamente o tráfego fora do túnel, faça a verificação num outro dispositivo não sensível. O objetivo do exercício é aprender sobre a rede sem lhe expor credenciais.

Não capture o tráfego de outras pessoas para diagnosticar o local, e mantenha qualquer captura de diagnóstico dentro do seu próprio dispositivo e sessão. Reveja os campos de endereço e identificador antes de anexar uma captura a um ticket, porque a rede do local não é o seu armário de provas.

Decida o que o resultado lhe permite fazer

Três resultados são possíveis: acesso total com um túnel funcional, acesso apenas ao portal com um túnel falhado, ou nenhum acesso. Cada um tem um passo seguinte diferente, e o valor do teste é saber em qual está antes de mudar definições. Acesso total significa que o trabalho pode continuar pelo túnel; acesso apenas ao portal sugere que a porta ou o protocolo do túnel está bloqueado, por isso a resposta é outro transporte ou rede; nenhum acesso significa que o local hoje não pode suportar a tarefa. Um dispositivo que só experimenta um protocolo não consegue distingui-los.

Anote o SSID, o resultado e a hora, para que a pessoa seguinte no mesmo local comece com provas. O guia de redes cativas da Apple descreve o comportamento de deteção por trás do aviso, e é a parte que vale a pena entender antes de culpar a VPN.