Solucionando Problemas de WiFi Público: Resolvendo Falhas de 'Conectado, Sem Internet' e Redirecionamento de Splash Page

Bem-vindo a este briefing técnico da Purple. Hoje, estamos abordando um dos problemas mais persistentes e incompreendidos em redes sem fio corporativas: o captive portal de WiFi para convidados que simplesmente se recusa a carregar. Você já passou por isso. Um convidado 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 instalações e gerentes de TI, esse momento não é apenas um pequeno inconveniente. Ele representa uma falha direta na experiência do seu convidado, um aumento nas chamadas de suporte na recepção e uma oportunidade perdida de capturar os dados primários que justificam o investimento na sua infraestrutura sem fio. Neste briefing, 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 solução de problemas prática e aplicável que você pode entregar à sua equipe de TI hoje mesmo. Vamos começar com a 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 importa enormemente quando as coisas dão errado. Aqui está a sequência. O dispositivo de um convidado se conecta ao seu SSID de convidados e recebe um endereço IP via DHCP. Nesse ponto, o sistema operacional não espera o usuário abrir um navegador. Em segundo plano, um serviço do sistema envia 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 aberto à internet, esses testes retornam as respostas esperadas, e o sistema operacional conclui que está tudo bem. Mas em uma rede de convidados, o 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 página inicial do captive portal. O sistema operacional detecta 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 maneiras pelas quais isso falha. Causa raiz número um: exaustão 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 seu tempo de concessão (lease time) do DHCP estiver definido para o padrão de 24 horas, você esgotará esse pool minutos após a abertura das portas. Cada tentativa subsequente de conexão falha antes mesmo que a sequência do Captive Portal comece. A correção é simples: defina os tempos de concessão do DHCP de visitantes para 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 número total de pessoas. Causa raiz número dois: falha na interceptação de DNS. O redirecionamento do Captive Portal depende do gateway interceptar a investigação HTTP. Mas a investigação 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 investigação nunca é acionada. 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 pré-autenticação - define quais domínios externos os visitantes não autenticados podem acessar. Se a página inicial do seu portal carrega recursos de uma CDN que não está no walled garden, a página é renderizada como uma tela em branco. Se você oferece login social via Google, Apple ou Facebook, todos os domínios OAuth que esses provedores usam devem estar na lista de permissões. E aqui está o ponto crítico: os provedores de identidade social atualizam seus intervalos de IP de CDN e domínios de autenticação regularmente. Um walled garden que funcionava perfeitamente há seis meses pode estar silenciosamente quebrado hoje. Agende auditorias trimestrais de walled garden e use o monitoramento de domínio com caracteres curinga (wildcard) onde seu hardware suportar. 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 o 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á o redirecionamento por completo. A solução correta é nunca tentar a interceptação HTTPS. Seu gateway deve redirecionar apenas as investigações canário HTTP não criptografadas. A correção de longo prazo baseada em padrões é o RFC 8910, que define a Opção DHCP 114. Essa opção permite que o seu servidor DHCP anuncie diretamente a URL do Captive Portal para o dispositivo cliente, eliminando completamente a necessidade de redirecionamento HTTP. O iOS 14 e o Android 11 e superiores 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 através de um túnel externo antes que ele chegue ao seu gateway. Seu gateway nunca vê a sonda HTTP. A sequência de detecção do Captive Portal nunca é acionada. O visitante não vê a página de login e fica sem internet. A correção para o visitante é simples: desativar a VPN, conectar-se ao portal e, em seguida, reativar a VPN. Para a sua equipe de atendimento, esta deve ser a primeira pergunta a fazer quando um visitante relatar um problema de conexão. Causa raiz número seis: a randomização do endereço MAC interrompendo 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 rotacionar. A correção voltada para o visitante é desativar o Endereço Privado para o seu SSID específico nas configurações de rede. A correçã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 a implementação. Como realmente se parece uma implantação de Captive Portal bem configurada na prática? Comece com sua arquitetura DHCP. Para qualquer local que espere mais de 200 dispositivos simultâneos, afaste-se de uma única sub-rede barra 24. Use barra 22 ou maior, e defina os tempos de concessão para corresponder ao perfil de permanência do seu local. Um hotel define concessões para 8 horas. Um estádio define concessões para 3 horas. Um shopping center define concessões para 90 minutos. Um centro de conferências define concessões para 30 minutos. Em seguida, valide seu jardim murado 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, as URLs de detecção de Captive Portal para Apple, Google, Windows e Firefox, e os domínios OAuth para cada provedor de login social que você suporta. Na plataforma da Purple, mantemos e atualizamos essas entradas de jardim murado automaticamente como parte do nosso serviço gerenciado na nuvem, o que remove 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á se autenticou anteriormente. A sessão do seu dispositivo ainda está ativa, então você ignora o portal completamente e conclui que tudo está funcionando. Sempre teste a partir de um dispositivo em um estado novo e não autenticado - seja um dispositivo novo ou um onde 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 de convidados. Durante uma grande conferência, 400 participantes chegaram simultaneamente. Em 20 minutos, o pool de DHCP foi esgotado. Os hóspedes relataram estar conectados, mas incapazes de acessar o Captive 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 concessão 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 de 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 usava login social via Google e Facebook em seu portal de convidados. Depois que o Google atualizou sua infraestrutura de OAuth, os novos domínios de autenticação não estavam no jardim murado. 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 jardim murado. A correção levou 10 minutos após ser identificada. A lição: nunca codifique endereços IP rigidamente em seu jardim murado para provedores de OAuth baseados em nuvem. Use entradas de domínio com caracteres curinga e revise-as trimestralmente. Agora, algumas perguntas rápidas que ouvimos regularmente das equipes de TI dos locais. 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 estiver bloqueado pelo seu firewall ou não estiver no seu jardim murado, os dispositivos Android nunca acionarão o portal. Adicione-o explicitamente. Um convidado diz que o portal carregou, mas ele não consegue navegar após fazer o login. Isso quase sempre é uma falha de autorização RADIUS. Verifique se o seu servidor RADIUS está acessível a partir do controlador sem fio, confirme se a chave secreta compartilhada coincide em ambos os lados e revise os logs do RADIUS em busca de mensagens Access-Reject. Como lidamos com convidados que continuam sendo desconectados após alguns minutos? Verifique sua configuração de tempo limite de inatividade. Muitos controladores têm como padrão um tempo limite de inatividade de 5 minutos, o que é agressivo demais para dispositivos móveis que entram em suspensão entre as interações. Defina o tempo limite de inatividade para pelo menos 30 minutos em ambientes de hotelaria 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 de DHCP, falha de interceptação de DNS, jardim murado incompleto, bloqueio de redirecionamento HSTS, VPN ativa no dispositivo 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 concessão de DHCP e o dimensionamento da sub-rede, validar seu jardim murado em relação aos domínios OAuth atuais de seus provedores de login social e testar seu portal a partir de um novo dispositivo não autenticado após cada alteração de configuração. Para o seu planejamento de longo prazo, avalie o OpenRoaming como o sucessor da reautenticação via Captive Portal para visitantes que retornam. A tecnologia é madura, os padrões estão estabelecidos sob o IEEE 802.1X e WPA3-Enterprise, e a Purple o 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. Já vimos todos os modos de falha descritos neste informativo - e desenvolvemos as ferramentas para evitá-los. Se você deseja 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 conta. Obrigado por nos ouvir.