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

Bem-vindo a esta apresentação técnica da Purple. Hoje estamos a abordar um dos problemas mais persistentes e mais incompreendidos nas redes sem fios empresariais: o Captive Portal de WiFi de convidados que simplesmente se recusa a carregar. Já passou por isso. Um convidado chega ao seu hotel, à sua loja de retalho, ao seu estádio ou ao seu centro de conferências. Associa-se à 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 seu convidado, um pico de chamadas de suporte na receção e uma oportunidade perdida para recolher os dados primários que justificam o seu investimento em infraestrutura sem fios. Nesta apresentação, vamos analisar os bastidores. Vamos explicar exatamente como funciona a deteção de Captive Portal ao nível do sistema operativo, identificar as seis causas principais responsáveis pela grande maioria das falhas de ligação e fornecer-lhe uma estrutura de resolução de problemas prática e acionável que pode entregar hoje mesmo à sua equipa de TI. Comecemos pelo funcionamento mecânico. A maioria das pessoas pensa num Captive Portal como sendo apenas uma página de login. Trata-se, na verdade, de um mecanismo de interceção de tráfego ao nível da rede, e essa distinção é extremamente importante quando algo corre mal. Eis a sequência. O dispositivo de um convidado associa-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 fabricante. Os dispositivos Apple consultam o captive.apple.com. Os dispositivos Android consultam o connectivitycheck.gstatic.com. Os dispositivos Windows consultam o 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 intercetará 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 página inicial 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 isolada - frequentemente chamada Captive Network Assistant - para apresentar a página de login. Esse é o caminho ideal. Agora vamos falar sobre as seis formas como este processo falha. Causa de origem 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 barra 24, tem 254 endereços IP utilizáveis. Se o tempo de lease do seu DHCP estiver definido para o padrão de 24 horas, esgotará esse pool poucos 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: defina os tempos de lease do DHCP de convidados para entre 15 e 30 minutos em ambientes de alta rotatividade 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 de origem número dois: falha de interceção de DNS. O redirecionamento do Captive Portal depende do gateway que intercepta o teste HTTP. Mas o teste requer primeiro uma consulta de DNS. Se a sua configuração de DNS não permitir que clientes pré-autenticados resolvam nomes de domínio externos, o teste nunca é acionado. Certifique-se de que a política da sua firewall permite explicitamente consultas de 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 de origem número três: walled garden incompleto. O walled garden - também chamado de lista de controlo de acesso de pré-autenticação - define quais os domínios externos que os convidados não autenticados podem aceder. Se a splash page do seu portal carregar recursos de uma CDN que não esteja no walled garden, a página será apresentada como um ecrã em branco. Se oferecer início de sessão social através da Google, Apple ou Facebook, todos os domínios OAuth que esses fornecedores utilizam devem constar da whitelist. 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 a deteção de domínios com caracteres wildcard sempre que o seu hardware o suporte. No Cisco Meraki, HPE Aruba, Ruckus e Juniper Mist, isto está disponível nativamente. Causa de origem 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 - o que inclui praticamente todos os principais sites - e o seu gateway tentar interceptar esse pedido HTTPS para redirecionar para o portal, o browser deteta uma incompatibilidade de certificado. Apresenta um aviso de segurança que não pode ser contornado e bloqueia totalmente o redirecionamento. A solução correta é nunca tentar a interceção de HTTPS. O seu gateway deve apenas redirecionar os testes canário de HTTP não encriptados. A solução a longo prazo baseada em normas é a 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 cliente, eliminando totalmente a necessidade de redirecionamento HTTP. O iOS 14 e o 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 do Captive Portal nunca é acionada. O visitante não vê nenhuma página de login nem internet. A solução para o visitante é simples: desativar a VPN, ligar-se ao portal e, em seguida, reativar a VPN. Para o seu pessoal de atendimento ao público, esta deve ser a primeira pergunta a fazer quando um visitante reportar um problema de ligação. Causa raiz número seis: a randomização do endereço MAC quebra a persistência da sessão. Os dispositivos modernos iOS e Android utilizam endereços MAC randomizados por predefinição como funcionalidade de privacidade. Cada vez que um dispositivo se liga a uma rede, pode apresentar um endereço MAC diferente. Como o estado da sessão do Captive Portal é monitorizado pelo endereço MAC, um visitante que se tenha autenticado há uma hora pode deparar-se novamente com a página de login após o MAC do seu dispositivo rodar. A solução do lado do visitante é desativar o Endereço Privado para o seu SSID específico nas definições de rede. A solução do lado do operador é 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 randomização irrelevante. Agora falemos de implementação. Como é que uma implementação de Captive Portal bem configurada se parece realmente na prática? 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) para corresponder ao perfil de permanência do seu local. 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. Em seguida, valide o seu jardim murado (walled garden) antes de cada grande evento. As entradas mínimas exigidas 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 Apple, Google, Windows e Firefox, e os domínios OAuth para cada fornecedor de login social que suporte. Na plataforma da Purple, mantemos e atualizamos estas entradas de jardim murado automaticamente como parte do nosso serviço gerido na nuvem, o que remove a carga de 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 navegador em todos os dispositivos. Renove os certificados antes do vencimento - um certificado expirado é uma das causas mais comuns de falhas repentinas do portal em todo o local. Uma armadilha que apanha muitas equipas de TI: testar o portal a partir de um dispositivo que se autenticou anteriormente. A sessão do seu dispositivo ainda está ativa, pelo que ignora completamente o portal e conclui que tudo está 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. Vou 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 utilizava uma única sub-rede slash-24 para o WiFi de convidados. Durante uma grande conferência, chegaram 400 delegados em simultâneo. Em 20 minutos, o pool de DHCP esgotou-se. Os convidados relataram que estavam ligados, mas não conseguiam aceder ao Captive Portal ou à internet. A correção imediata foi expandir a sub-rede para slash-22, disponibilizando 1022 endereços úteis, e reduzir o tempo de atribuição (lease time) de 24 horas para 8 horas. A soluçã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 ocorra o esgotamento. A taxa de falha do portal caiu para quase zero em 48 horas após a alteração. Cenário dois: uma grande cadeia de retalho com 200 lojas. A cadeia utilizava o 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 constavam do 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 falha no walled garden. A correção demorou 10 minutos após ser identificada. A lição: nunca codifique de forma rígida endereços IP no seu walled garden para fornecedores de OAuth baseados na nuvem. Utilize entradas de domínio com caracteres universais (wildcards) e reveja-as trimestralmente. Agora, algumas perguntas rápidas que ouvimos regularmente das equipas de TI dos espaços. 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 diz que o portal carregou, mas não consegue aceder à internet 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 reveja os registos RADIUS em busca de mensagens de Access-Reject. Como lidamos com convidados que continuam a ser desligados após alguns minutos? Verifique a sua configuração de limite de tempo de inatividade (idle timeout). Muitos controladores definem por predefinição um limite de inatividade de 5 minutos, o que é demasiado agressivo para dispositivos móveis que entram em modo de suspensão entre interações. Defina o limite de tempo de inatividade para pelo menos 30 minutos em ambientes de hotelaria e retalho. Para resumir os pontos principais da sessão 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 do 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 atribuição de DHCP e o dimensionamento da sub-rede, validar o seu walled garden face aos domínios de OAuth atuais dos seus fornecedores de login social e testar o seu portal a partir de um dispositivo novo não autenticado após cada alteração de configuração. Para o seu roteiro 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 o IEEE 802.1X e WPA3-Enterprise, e a Purple disponibiliza-a sem custos de software adicionais sob o plano Connect. A Purple opera em 80 000 locais e processou 440 milhões de inícios de sessão só em 2024. Já vimos todos os modos de falha descritos nesta sessão - e criámos as ferramentas para os evitar. Se deseja explorar como o overlay 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. Muito obrigado pela sua atenção.