Resolução de Problemas em WiFi Público: Como Corrigir 'Ligado, Sem Internet' e Falhas de Redirecionamento da Página Splash

Bem-vindo a este briefing técnico da Purple. Hoje abordamos um dos problemas mais persistentes e incompreendidos nas redes sem fios empresariais: o captive portal de WiFi para convidados que simplesmente se recusa a carregar. Já passou por isso. Um convidado chega ao seu hotel, loja de retalho, estádio ou centro de conferências. Adere à rede WiFi. Nada acontece. Sem página de login. Sem internet. Apenas um ícone a rodar e uma sensação crescente de frustração. Para os diretores de operações de espaços e gestores de TI, esse momento não é apenas um pequeno inconveniente. Representa uma falha direta na experiência do convidado, um pico de chamadas de suporte na receção e uma oportunidade perdida de recolher os dados primários que justificam o seu investimento na infraestrutura sem fios. Neste briefing, vamos analisar os bastidores. Explicaremos exatamente como funciona a deteção de captive portal ao nível do sistema operativo, identificaremos as seis causas raiz responsáveis pela grande maioria das falhas de ligação e forneceremos uma estrutura de resolução de problemas prática e acionável que pode entregar hoje mesmo à sua equipa de TI. Comecemos pela mecânica. A maioria das pessoas pensa num captive portal simplesmente como uma página de login. Na verdade, trata-se de um mecanismo de interceção de tráfego ao nível da rede, e essa distinção é extremamente importante quando as coisas correm mal. Eis a sequência. O dispositivo de um convidado liga-se ao seu SSID de convidados e recebe um endereço IP via DHCP. Nesse momento, o sistema operativo não espera que o utilizador abra um navegador. Em segundo plano, um serviço do sistema envia imediatamente um pedido HTTP GET não encriptado para um URL de teste controlado pelo fornecedor. Os dispositivos Apple consultam captive.apple.com. Os dispositivos Android consultam connectivitycheck.gstatic.com. Os dispositivos Windows consultam msftconnecttest.com. O Firefox tem o seu próprio teste em detectportal.firefox.com. Se a rede tiver acesso aberto à internet, estes testes devolvem as respostas esperadas e o sistema operativo conclui que está tudo bem. Mas numa rede de convidados, o seu gateway ou controlador sem fios intercepta esse teste HTTP antes que este chegue à internet. Em vez da resposta esperada, o gateway devolve um redirecionamento HTTP 307 que aponta para a sua splash page do captive portal. O sistema operativo deteta o redirecionamento inesperado, percebe que está atrás de um captive portal e abre uma janela de navegador em sandbox - frequentemente chamada Captive Network Assistant - para apresentar a página de login. Este é o caminho ideal. Agora, vamos falar sobre as seis formas como este processo pode falhar. Causa raiz número um: esgotamento do pool DHCP. Este é o assassino silencioso em eventos de alta densidade. Se estiver a organizar uma conferência com dois mil participantes numa sub-rede padrão slash-24, tem 254 endereços IP utilizáveis. Se o tempo de lease do DHCP estiver configurado para o padrão de 24 horas, esgotará esse pool minutos após a abertura das portas. Todas as tentativas de ligação subsequentes falham antes mesmo de a sequência do Captive Portal começar. A solução é simples: configure os tempos de lease de DHCP para convidados entre 15 e 30 minutos em ambientes de alta rotação, e dimensione as suas sub-redes adequadamente para o pico de utilizadores simultâneos, e não apenas para o número total de pessoas. Causa raiz número dois: falha na interceção de DNS. O redirecionamento do Captive Portal depende de o gateway intercetar o probe HTTP. Mas o probe requer primeiro uma consulta DNS. Se a sua configuração de DNS não permitir que clientes pré-autenticados resolvam nomes de domínio externos, o probe nunca é acionado. Certifique-se de que a política da sua firewall permite explicitamente consultas DNS de clientes não autenticados, e verifique se a sua interceção de DNS está a funcionar executando uma captura de pacotes num dispositivo de teste. Causa raiz número três: jardim murado (walled garden) incompleto. O walled garden - também designado por lista de controlo de acessos pré-autenticação - define quais os domínios externos que os convidados não autenticados podem aceder. Se a sua página de splash do portal carregar recursos de uma CDN que não está no walled garden, a página será apresentada como um ecrã em branco. Se disponibilizar login social via Google, Apple ou Facebook, todos os domínios OAuth que esses fornecedores utilizam devem estar na lista de permissões. E aqui está o ponto crítico: os fornecedores de identidade social atualizam regularmente as suas gamas de IP de CDN e domínios de autenticação. Um walled garden que funcionava perfeitamente há seis meses pode estar silenciosamente avariado hoje. Agende auditorias trimestrais ao walled garden e utilize o snooping de domínios com wildcards sempre que o seu hardware o suporte. No Cisco Meraki, HPE Aruba, Ruckus e Juniper Mist, isto está disponível nativamente. Causa raiz número quatro: HSTS a bloquear o redirecionamento. O HTTP Strict Transport Security, ou HSTS, é uma política de segurança do browser que força as ligações a domínios específicos apenas através de HTTPS. Se o dispositivo de um convidado tentar contactar um domínio pré-carregado com HSTS - e isso inclui praticamente todos os principais websites - e o seu gateway tentar intercetar essa solicitação HTTPS para redirecionar para o portal, o browser deteta uma incompatibilidade de certificado. Apresenta um aviso de segurança impossível de contornar e bloqueia totalmente o redirecionamento. A solução correta é nunca tentar a interceção de HTTPS. O seu gateway deve apenas redirecionar os probes canário HTTP não encriptados. A solução a longo prazo baseada em normas é o RFC 8910, que define a Opção DHCP 114. Esta opção permite que o seu servidor DHCP anuncie diretamente o URL do Captive Portal ao dispositivo do cliente, eliminando totalmente a necessidade de redirecionamento HTTP. O iOS 14 e Android 11 e superior suportam isto nativamente. Causa raiz número cinco: VPN ativa no dispositivo do visitante. Uma VPN encripta todo o tráfego do dispositivo e encaminha-o através de um túnel externo antes de este chegar ao seu gateway. O seu gateway nunca vê a sonda HTTP. A sequência de deteção de Captive Portal nunca é acionada. O visitante não vê a página de login nem tem internet. A correção para o visitante é simples: desativar a VPN, ligar-se ao portal e, em seguida, voltar a ativar a VPN. Para o seu pessoal de atendimento ao público, esta deve ser a primeira pergunta a fazer quando um visitante reporta um problema de ligação. Causa raiz número seis: a aleatoriedade de endereços MAC quebra a persistência da sessão. Os dispositivos iOS e Android modernos utilizam endereços MAC aleatórios por predefinição como funcionalidade de privacidade. Sempre que um dispositivo se liga a uma rede, pode apresentar um endereço MAC diferente. Uma vez que o estado da sessão do Captive Portal é monitorizado pelo endereço MAC, um visitante que se autenticou há uma hora pode ver novamente a página de login após a rotação do MAC do seu dispositivo. A correção do lado do visitante consiste em desativar o Endereço Privado para o seu SSID específico nas definições de rede. A correção do lado do operador passa por implementar a autenticação baseada em perfis - como o OpenRoaming através de Passpoint e 802.1X - que autentica na Camada 2 utilizando credenciais em vez de endereços MAC, tornando a aleatoriedade irrelevante. Falemos agora da implementação. Qual é o aspeto prático de uma implementação de Captive Portal bem configurada? Comece pela sua arquitetura DHCP. Para qualquer local que preveja mais de 200 dispositivos simultâneos, afaste-se de uma sub-rede única slash-24. Utilize slash-22 ou superior, e defina os tempos de concessão (lease times) de acordo com o perfil de permanência do seu espaço. Um hotel define as concessões para 8 horas. Um estádio define as concessões para 3 horas. Um centro comercial define as concessões para 90 minutos. Um centro de conferências define as concessões para 30 minutos. Depois, valide o seu walled garden antes de cada grande evento. As entradas mínimas necessárias são: o nome de domínio totalmente qualificado do seu portal e todos os domínios CDN associados, os URLs de deteção de Captive Portal para a Apple, Google, Windows e Firefox, e os domínios OAuth para cada fornecedor de login social que suporta. Na plataforma da Purple, mantemos e atualizamos estas entradas do walled garden automaticamente como parte do nosso serviço gerido na cloud, o que remove o fardo da manutenção manual da sua equipa. Para o certificado do seu portal, utilize um certificado TLS publicamente confiável de uma autoridade de certificação reconhecida. Os certificados autoassinados irão acionar avisos do browser em todos os dispositivos. Renove os certificados antes da expiração - um certificado caducado é uma das causas mais comuns de falhas repentinas do portal em todo o espaço. Uma armadilha que apanha muitas equipas de TI: testar o portal a partir de um dispositivo que já se autenticou anteriormente. A sessão do seu dispositivo ainda está ativa, pelo que ignora o portal por completo e conclui que está tudo a funcionar. Teste sempre a partir de um dispositivo num estado limpo e não autenticado - ou um dispositivo novo, ou um no qual tenha esquecido a rede e limpado o perfil de WiFi. Deixe-me dar-lhe dois cenários do mundo real que ilustram estes princípios. Cenário um: um hotel de 350 quartos no centro de Londres. A propriedade operava uma única sub-rede barra-24 para WiFi de convidados. Durante uma grande conferência, 400 delegados chegaram simultaneamente. Em 20 minutos, o pool de DHCP esgotou-se. Os convidados relataram estar ligados, mas sem conseguir aceder ao portal ou à internet. A correção imediata foi estender a sub-rede para barra-22, disponibilizando 1.022 endereços utilizáveis, e reduzir o tempo de lease de 24 horas para 8 horas. A correção a longo prazo foi implementar o Captive Portal gerido na nuvem da Purple, que monitoriza a utilização do pool de DHCP em tempo real e alerta a equipa de rede antes que o esgotamento ocorra. A taxa de falha do portal caiu para perto de zero dentro de 48 horas após a alteração. Cenário dois: uma grande cadeia de retalho com 200 lojas. A cadeia utilizava login social via Google e Facebook no seu portal de convidados. Após a Google atualizar a sua infraestrutura de OAuth, os novos domínios de autenticação não estavam no walled garden. Os convidados conseguiam aceder à página do portal, mas os botões de login social apresentavam ecrãs em branco. A equipa de TI da cadeia passou dois dias a diagnosticar o problema antes de identificar a lacuna no walled garden. A correção demorou 10 minutos após ser identificada. A lição: nunca codifique rigidamente endereços IP no seu walled garden para fornecedores de OAuth baseados na nuvem. Utilize entradas de domínio wildcard e reveja-as trimestralmente. Agora, algumas perguntas rápidas que ouvimos regularmente das equipas de TI dos locais. Porque é que o portal funciona em iPhones, mas não em dispositivos Android? O Android utiliza connectivitycheck.gstatic.com como o seu URL de teste. Se esse domínio estiver bloqueado pela sua firewall ou não estiver no seu walled garden, os dispositivos Android nunca acionam o portal. Adicione-o explicitamente. Um convidado refere que o portal carregou, mas não consegue ficar online após iniciar sessão. Isto é quase sempre uma falha de autorização RADIUS. Verifique se o seu servidor RADIUS está acessível a partir do controlador sem fios, confirme se o segredo partilhado coincide em ambos os lados e analise os registos RADIUS em busca de mensagens Access-Reject. Como lidamos com convidados que continuam a ser desconectados após alguns minutos? Verifique a sua definição de idle timeout. Muitos controladores têm como predefinição um idle timeout de 5 minutos, o que é demasiado agressivo para dispositivos móveis que entram em modo de suspensão entre interações. Defina o idle timeout para pelo menos 30 minutos para ambientes de hotelaria e retalho. Para resumir os pontos-chave do briefing de hoje. As falhas do Captive Portal de WiFi de convidados dividem-se em seis categorias: esgotamento do pool de DHCP, falha de interceção de DNS, walled garden incompleto, bloqueio de redirecionamento HSTS, VPN ativa no dispositivo cliente e aleatorização de endereços MAC. Cada uma tem uma correção específica e testável. Para a sua equipa de TI, as ações imediatas são: auditar os tempos de lease de DHCP e o dimensionamento das sub-redes, validar o seu walled garden em relação aos domínios OAuth atuais dos seus fornecedores de login social e testar o seu portal a partir de um dispositivo não autenticado limpo após cada alteração de configuração. Para o seu roadmap a longo prazo, avalie o OpenRoaming como o sucessor da reautenticação via Captive Portal para visitantes frequentes. A tecnologia é madura, os padrões estão estabelecidos sob IEEE 802.1X e WPA3-Enterprise, e a Purple disponibiliza-a sem custos adicionais de software no plano Connect. A Purple opera em 80.000 locais e processou 440 milhões de logins apenas em 2024. Já vimos todos os modos de falha descritos neste briefing - e construímos as ferramentas para os evitar. Se deseja explorar como a sobreposição de nuvem da Purple se integra com a sua infraestrutura existente Cisco Meraki, HPE Aruba, Ruckus ou Juniper Mist, visite purple.ai ou fale com o seu gestor de conta. Obrigado por ouvir.