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

Bem-vindo a esta sessão técnica da Purple. Hoje estamos a abordar um dos problemas mais persistentes e 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. Junta-se à rede WiFi. Não acontece nada. Sem página de login. Sem internet. Apenas um ícone a girar e uma sensação crescente de frustração. Para os diretores de operações de instalações 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 de recolher os dados primários que justificam o seu investimento na infraestrutura sem fios. Nesta sessão, vamos olhar sob o capô. 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 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. Aqui está a sequência. O dispositivo de um convidado junta-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 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 intercetará esse teste HTTP antes que ele 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 de Captive Network Assistant - para exibir a página de login. Esse é o caminho ideal. Agora vamos falar sobre as seis formas como ele falha. Causa raiz número um: exaustão do pool DHCP. Este é o assassino silencioso em eventos de alta densidade. Se estiver a gerir uma conferência com dois mil participantes numa sub-rede standard 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 em 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 elevada rotatividade, e dimensione as suas sub-redes adequadamente para o pico de utilizadores simultâneos, 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 sua política de 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: walled garden incompleto. O walled garden - também designado por lista de controlo de acesso pré-autenticação - define quais os domínios externos que os convidados não autenticados podem aceder. Se a página inicial do seu portal carregar elementos de uma CDN que não está no walled garden, a página será apresentada como um ecrã em branco. Se oferecer login social através da 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 a deteção de domínios com caracteres universais (wildcards) onde o seu hardware o permitir. 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 navegador que força 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 websites - e o seu gateway tentar intercetar esse pedido HTTPS para redirecionar para o portal, o navegador 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ários 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 chega a detetar o teste HTTP. A sequência de deteção do Captive Portal nunca é acionada. O visitante não vê nenhuma página de início de sessão 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 reporta um problema de ligação. Causa raiz número seis: a aleatoriedade do endereço MAC quebra a persistência da sessão. Os dispositivos modernos com iOS e Android utilizam endereços MAC aleatórios por predefinição como uma 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 através do endereço MAC, um visitante que se tenha autenticado há uma hora pode deparar-se novamente com a página de início de sessão após a rotação do MAC do seu dispositivo. A solução do lado do visitante passa por desativar o Endereço Privado para o seu SSID específico nas definições de rede. A solução do lado do operador consiste em 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. Agora vamos falar da implementação. Como é que se apresenta, na prática, uma implementação de um Captive Portal bem configurada? Comece pela sua arquitetura DHCP. Para qualquer espaço que preveja mais de 200 dispositivos simultâneos, afaste-se de uma sub-rede única slash-24. Utilize uma slash-22 ou superior, e configure os tempos de concessão (lease times) para corresponderem ao 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 jardim vedado (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 URL de deteção de Captive Portal para a Apple, Google, Windows e Firefox, e os domínios OAuth para cada fornecedor de início de sessão social que suporte. Na plataforma da Purple, mantemos e atualizamos estas entradas de jardim vedado de forma automática como parte do nosso serviço gerido na nuvem, o que elimina a carga de manutenção manual da sua equipa. Para o certificado do seu portal, utilize um certificado TLS publicamente fidedigno de uma autoridade de certificação reconhecida. Os certificados autoassinados irão acionar avisos do navegador em todos os dispositivos. Renove os certificados antes de expirarem - um certificado caducado é uma das causas mais comuns de falhas súbitas de portais em todo o espaço. Uma armadilha que apanha muitas equipas de TI: testar o portal a partir de um dispositivo que já se tenha autenticado anteriormente. A sessão do seu dispositivo continua ativa, pelo que ignora completamente o portal e conclui que está tudo a funcionar. Teste sempre a partir de um dispositivo num estado limpo e não autenticado - quer seja um dispositivo novo, quer seja um onde tenha esquecido a rede e limpado o perfil de WiFi.Deixe-me apresentar 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 /24 para o WiFi de convidados. Durante uma grande conferência, chegaram 400 delegados em simultâneo. Em menos de 20 minutos, o pool de DHCP esgotou-se. Os hóspedes relataram estar ligados, mas sem conseguir aceder ao Captive Portal ou à internet. A correção imediata foi expandir a sub-rede para /22, disponibilizando 1.022 endereços utilizáveis, e reduzir o tempo de concessã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 nas 48 horas seguintes à 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 no walled garden. Os clientes 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 (hardcode) 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 locais. Porque é que o portal funciona em iPhones mas não em dispositivos Android? O Android utiliza o connectivitycheck.gstatic.com como o seu URL de teste (probe URL). Se esse domínio estiver bloqueado pela sua firewall ou não estiver no seu walled garden, os dispositivos Android nunca ativam o portal. Adicione-o explicitamente. Um convidado diz que o portal carregou, mas que 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 analise 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 tempo 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-chave 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 na interceção de DNS, walled garden incompleto, bloqueio de redirecionamento HSTS, VPN ativa no dispositivo do cliente e aleatoriedade 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 concessão de DHCP e o dimensionamento da sub-rede, 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 roteiro de longo prazo, avalie o OpenRoaming como o sucessor da reautenticação via Captive Portal para os visitantes que regressam. A tecnologia é madura, os padrões estão estabelecidos sob o IEEE 802.1X e WPA3-Enterprise, e a Purple disponibiliza-a sem custos adicionais de software ao abrigo do 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 informativo - e desenvolvemos 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. Obrigado por nos ouvir.