Solucionando problemas de WiFi público: corrigindo 'Conectado, sem internet' e falhas de redirecionamento de splash page

Bem-vindo a este informe técnico da Purple. Hoje estamos abordando um dos problemas mais persistentes e incompreendidos nas redes sem fio corporativas: o captive portal de WiFi de visitantes que simplesmente se recusa a carregar. Você já passou por isso. Um visitante chega ao seu hotel, à sua loja de varejo, ao seu estádio ou ao seu centro de convenções. Ele se conecta à rede WiFi. Nada acontece. Nenhuma página de login. Sem internet. Apenas um ícone girando e uma sensação crescente de frustração. Para diretores de operações de locais e gerentes de TI, esse momento não é apenas um pequeno inconveniente. Ele representa uma falha direta na experiência do visitante, um pico de chamadas de suporte na recepção e uma oportunidade perdida de capturar os dados primários (first-party data) que justificam o investimento na sua infraestrutura sem fio. Neste informe, vamos analisar os detalhes técnicos. Explicaremos exatamente como funciona a detecção de captive portal no nível do sistema operacional, identificaremos as seis causas raiz responsáveis pela grande maioria das falhas de conexão e forneceremos uma estrutura de resolução de problemas prática e acionável que você pode entregar à sua equipe de TI hoje mesmo. Vamos começar com a parte mecânica. A maioria das pessoas pensa em um captive portal apenas como uma página de login. Na verdade, ele é um mecanismo de interceptação de tráfego no nível da rede, e essa distinção é extremamente importante quando as coisas dão errado. Aqui está a sequência. O dispositivo de um visitante se conecta ao seu SSID de visitantes e recebe um endereço IP via DHCP. Nesse ponto, o sistema operacional não espera que o usuário abra um navegador. Em segundo plano, um serviço do sistema dispara imediatamente uma solicitação HTTP GET não criptografada para uma URL de teste controlada pelo fabricante. Dispositivos Apple consultam captive.apple.com. Dispositivos Android consultam connectivitycheck.gstatic.com. Dispositivos Windows consultam msftconnecttest.com. O Firefox tem seu próprio teste em detectportal.firefox.com. Se a rede tiver acesso livre à internet, esses testes retornam as respostas esperadas e o sistema operacional conclui que está tudo bem. Mas em uma rede de visitantes, seu gateway ou controladora sem fio intercepta esse teste HTTP antes que ele chegue à internet. Em vez da resposta esperada, o gateway retorna um redirecionamento HTTP 307 apontando para a sua splash page de captive portal. O sistema operacional detecta o redirecionamento inesperado, percebe que está atrás de um captive portal e abre uma janela de navegador em sandbox — frequentemente chamada de Captive Network Assistant — para exibir a página de login. Esse é o fluxo ideal. Agora, vamos falar sobre as seis maneiras como ele falha. Causa raiz número um: esgotamento do pool DHCP. Este é o assassino silencioso em eventos de alta densidade. Se você está realizando uma conferência com dois mil participantes em uma sub-rede padrão barra-24, você tem 254 endereços IP utilizáveis. Se o tempo de concessão (lease time) do seu DHCP estiver configurado para o padrão de 24 horas, você esgotará esse pool poucos minutos após a abertura das portas. Cada tentativa subsequente de conexão falhará antes mesmo de iniciar a sequência do Captive Portal. A correção é simples: configure os tempos de concessão de DHCP para visitantes entre 15 e 30 minutos em ambientes de alta rotatividade e dimensione suas sub-redes adequadamente para o pico de usuários simultâneos, não apenas para o total de participantes. Causa raiz número dois: falha na interceptação de DNS. O redirecionamento do Captive Portal depende do gateway interceptar a sondagem HTTP. No entanto, a sondagem 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, a sondagem nunca é disparada. Certifique-se de que sua política de firewall permita explicitamente consultas DNS de clientes não autenticados e verifique se a interceptação de DNS está funcionando executando uma captura de pacotes em um dispositivo de teste. Causa raiz número três: walled garden incompleto. O walled garden - também chamado de lista de controle de acesso de pré-autenticação - define quais domínios externos os visitantes não autenticados podem acessar. Se a página de login do seu portal carregar ativos de uma CDN que não está no walled garden, a página será exibida como uma tela em branco. Se você oferece login social via Google, Apple ou Facebook, cada domínio OAuth usado por esses provedores deve estar na lista de permissões. E aqui está o ponto crítico: os provedores de identidade social atualizam suas faixas de IP de CDN e domínios de autenticação regularmente. Um walled garden que funcionava perfeitamente há seis meses pode estar quebrado silenciosamente hoje. Agende auditorias trimestrais de walled garden e use snooping de domínio wildcard onde seu hardware oferecer suporte. No Cisco Meraki, HPE Aruba, Ruckus e Juniper Mist, isso está disponível nativamente. Causa raiz número quatro: HSTS bloqueando o redirecionamento. O HTTP Strict Transport Security, ou HSTS, é uma política de segurança do navegador que força conexões para domínios específicos apenas via HTTPS. Se o dispositivo de um visitante tentar entrar em contato com um domínio pré-carregado com HSTS - e isso inclui praticamente todos os principais sites - e seu gateway tentar interceptar essa solicitação HTTPS para redirecionar para o portal, o navegador detectará uma incompatibilidade de certificado. Ele apresentará um aviso de segurança que não pode ser ignorado e bloqueará totalmente o redirecionamento. A solução correta é nunca tentar a interceptação HTTPS. Seu gateway deve redirecionar apenas as sondagens HTTP não criptografadas. A correção de longo prazo baseada em padrões é a RFC 8910, que define a Opção DHCP 114. Essa opção permite que seu servidor DHCP anuncie diretamente a URL do Captive Portal para o dispositivo do cliente, eliminando totalmente a necessidade de redirecionamento HTTP. O iOS 14 e Android 11 ou superior oferecem suporte nativo a isso. Causa raiz número cinco: VPN ativa no dispositivo do visitante. Uma VPN criptografa todo o tráfego do dispositivo e o roteia por meio de um túnel externo antes que ele chegue ao seu gateway. Seu gateway nunca vê a sondagem HTTP. A sequência de detecção do Captive Portal nunca é acionada. O visitante não vê nenhuma página de login e fica sem internet. A solução para o visitante é simples: desativar a VPN, conectar-se ao portal e reativar a VPN. Para a sua equipe de atendimento, esta deve ser a primeira pergunta a ser feita quando um visitante relata um problema de conexão. Causa raiz número seis: a randomização do endereço MAC quebrando a persistência da sessão. Dispositivos modernos iOS e Android usam endereços MAC randomizados por padrão como um recurso de privacidade. Cada vez que um dispositivo se conecta a uma rede, ele pode apresentar um endereço MAC diferente. Como o estado da sessão do Captive Portal é rastreado pelo endereço MAC, um visitante que se autenticou há uma hora pode se deparar com a página de login novamente após o MAC do seu dispositivo mudar. A solução para o visitante é desativar o Endereço Privado para o seu SSID específico nas configurações de rede. A solução do lado do operador é implementar a autenticação baseada em perfil — como OpenRoaming via Passpoint e 802.1X —, que autentica na Camada 2 usando credenciais em vez de endereços MAC, tornando a randomização irrelevante. Agora vamos falar sobre implementação. Como é, na prática, uma implantação de Captive Portal bem configurada? Comece com a sua arquitetura DHCP. Para qualquer local que espere mais de 200 dispositivos simultâneos, evite usar uma única sub-rede barra-24. Use barra-22 ou maior e configure o tempo de concessão (lease time) para corresponder ao perfil de permanência do seu local. Um hotel define concessões de 8 horas. Um estádio define concessões de 3 horas. Um shopping center define concessões de 90 minutos. Um centro de convenções define concessões de 30 minutos. Em seguida, valide seu walled garden antes de cada grande evento. As entradas mínimas necessárias são: o nome de domínio totalmente qualificado (FQDN) do seu portal e todos os domínios CDN associados, as URLs de detecção de Captive Portal para Apple, Google, Windows e Firefox, e os domínios OAuth de cada provedor de login social que você suporta. Na plataforma da Purple, mantemos e atualizamos essas entradas de walled garden de forma automática como parte do nosso serviço gerenciado na nuvem, o que elimina a carga de manutenção manual da sua equipe. Para o certificado do seu portal, use um certificado TLS publicamente confiável de uma autoridade de certificação reconhecida. Certificados autoassinados acionarão avisos do navegador em todos os dispositivos. Renove os certificados antes do vencimento — um certificado expirado é uma das causas mais comuns de falhas repentinas de portal em todo o local. Uma armadilha que pega muitas equipes de TI: testar o portal a partir de um dispositivo que já foi autenticado anteriormente. A sessão do seu dispositivo ainda está ativa, então você ignora totalmente o portal e conclui que tudo está funcionando. Sempre teste a partir de um dispositivo em um estado limpo e não autenticado — seja um dispositivo novo ou um no qual você tenha esquecido a rede e limpado o perfil de WiFi. Deixe-me apresentar dois cenários do mundo real que ilustram esses princípios. Cenário um: um hotel de 350 quartos no centro de Londres. A propriedade operava uma única sub-rede barra 24 para o WiFi dos hóspedes. Durante uma grande conferência, 400 delegados chegaram simultaneamente. Em 20 minutos, o pool DHCP foi esgotado. Os hóspedes relataram estar conectados, mas sem conseguir acessar o portal ou a internet. A solução imediata foi estender a sub-rede para barra 22, fornecendo 1.022 endereços utilizáveis, e reduzir o tempo de lease de 24 horas para 8 horas. A solução de longo prazo foi implementar o Captive Portal gerenciado em nuvem da Purple, que monitora a utilização do pool DHCP em tempo real e alerta a equipe de rede antes que o esgotamento ocorra. A taxa de falha do portal caiu para quase zero em até 48 horas após a mudança. Cenário dois: uma grande rede de varejo com 200 lojas. A rede utilizava login social via Google e Facebook em seu portal de visitantes. Depois que o Google atualizou sua infraestrutura OAuth, os novos domínios de autenticação não estavam no walled garden. Os clientes conseguiam acessar a página do portal, mas os botões de login social exibiam telas em branco. A equipe de TI da rede passou dois dias diagnosticando o problema antes de identificar a falha no walled garden. A correção levou 10 minutos após a identificação. A lição: nunca codifique endereços IP de forma fixa (hardcode) em seu walled garden para provedores de OAuth baseados em nuvem. Use entradas de domínio curinga (wildcard) e revise-as trimestralmente. Agora, algumas perguntas rápidas que ouvimos regularmente das equipes de TI de locais físicos. Por que o portal funciona em iPhones, mas não em dispositivos Android? O Android usa connectivitycheck.gstatic.com como sua URL de teste. Se esse domínio for bloqueado pelo seu firewall ou não estiver no seu walled garden, os dispositivos Android nunca acionarão o portal. Adicione-o explicitamente. Um convidado diz que o portal carregou, mas ele não consegue ficar online após fazer o login. Isso é quase sempre uma falha de autorização do RADIUS. Verifique se o seu servidor RADIUS está acessível a partir do controlador sem fio, verifique se o segredo compartilhado coincide em ambos os lados e analise os logs do RADIUS em busca de mensagens Access-Reject. Como lidamos com hóspedes que continuam sendo deslogados após alguns minutos? Verifique sua configuração de tempo limite de inatividade (idle timeout). Muitos controladores vêm por padrão com um tempo limite de inatividade de 5 minutos, o que é agressivo demais para dispositivos móveis que entram em modo de suspensão entre as interações. Defina o tempo limite de inatividade para pelo menos 30 minutos em ambientes de hospitalidade e varejo. Para resumir os pontos principais do briefing de hoje: As falhas do Captive Portal de WiFi para convidados dividem-se em seis categorias: esgotamento do pool DHCP, falha de interceptação de DNS, walled garden incompleto, bloqueio de redirecionamento HSTS, VPN ativa no dispositivo do cliente e randomização de endereço MAC. Cada uma tem uma correção específica e testável. Para a sua equipe de TI, as ações imediatas são: auditar os tempos de lease do DHCP e o dimensionamento da sub-rede, validar o seu walled garden em relação aos domínios OAuth atuais dos seus provedores de login social e testar o seu portal a partir de um novo dispositivo não autenticado após cada alteração de configuração. Para o seu roadmap de longo prazo, avalie o OpenRoaming como o sucessor da reautenticação via captive portal para visitantes recorrentes. A tecnologia é madura, os padrões são estabelecidos sob o IEEE 802.1X e WPA3-Enterprise, e a Purple a disponibiliza sem custo adicional de software no plano Connect. A Purple opera em 80.000 locais e processou 440 milhões de logins apenas em 2024. Vimos todos os modos de falha descritos neste briefing — e desenvolvemos as ferramentas para evitá-los. Se quiser explorar como a sobreposição em nuvem da Purple se integra à sua infraestrutura existente Cisco Meraki, HPE Aruba, Ruckus ou Juniper Mist, visite purple.ai ou fale com seu gerente de contas. Obrigado pela atenção.