Solucionando Problemas de WiFi Público: Corrigindo "Conectado, Sem Internet" e Falhas de Redirecionamento da 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 portal cativo de WiFi para 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 seu visitante, um pico de chamadas de suporte na recepção e uma oportunidade perdida de capturar os dados proprietários que justificam o investimento na sua infraestrutura sem fio. Neste informe técnico, iremos analisar os detalhes técnicos. Explicaremos exatamente como funciona a detecção do 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 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 simplesmente como uma página de login. Na verdade, trata-se de 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 envia imediatamente uma requisiçã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, 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 página inicial do seu 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 Assistente de Rede Cativa - 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: 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 do seu DHCP estiver definido para o padrão de 24 horas, você esgotará esse pool poucos minutos após a abertura das portas. Cada tentativa de conexão subsequente falhará antes mesmo que a sequência do Captive Portal comece. A correção é simples: defina 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 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 sondagem HTTP. Mas 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 de 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 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, cada domínio de OAuth que esses provedores utilizam deve 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 quebrado hoje de forma silenciosa. Agende auditorias trimestrais de walled garden e use a detecção de domínio curinga 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 virtualmente 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 de HTTPS. Seu gateway deve apenas redirecionar as sondagens canário de HTTP não criptografadas. A correção de longo prazo baseada em padrões é a RFC 8910, que define a Opção 114 do DHCP. Essa opção permite que o seu servidor DHCP anuncie diretamente a URL do Captive Portal para o dispositivo cliente, eliminando totalmente a necessidade de redirecionamento HTTP. O iOS 14, o Android 11 e versões superiores suportam isso nativamente. Causa raiz número cinco: VPN ativa no dispositivo do visitante. Uma VPN criptografa todo o tráfego do dispositivo e o direciona por um túnel externo antes que ele alcance o seu gateway. O seu gateway nunca vê a sondagem 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 soluçã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 ser feita quando um visitante relatar um problema de conexão. Causa raiz número seis: a randomização de endereços MAC quebrando a persistência da sessão. Os dispositivos modernos com 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 a rotação do MAC do seu dispositivo. A solução voltada 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, afaste-se de uma única sub-rede barra 24. Use barra 22 ou maior, e configure 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 shopping center define as concessões para 90 minutos. Um centro de convenções define as concessões para 30 minutos. Em seguida, 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, 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 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 certificadora 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 no 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 totalmente o portal 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 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 de convidados. Durante uma grande conferência, 400 delegados chegaram simultaneamente. Em 20 minutos, o pool DHCP estava esgotado. Os hóspedes relataram estar conectados, mas sem conseguir acessar o Captive Portal ou a internet. A soluçã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 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 ocorra o esgotamento. 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 convidados. Depois que o Google atualizou sua infraestrutura OAuth, os novos domínios de autenticação não estavam no walled garden. Os convidados 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 lacuna no walled garden. A correção levou 10 minutos uma vez identificada. A lição: nunca codifique endereços IP permanentemente no seu walled garden para provedores OAuth baseados em nuvem. Use entradas de domínio 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 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 navegar depois de 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, valide se o segredo compartilhado coincide em ambos os lados e revise os logs do RADIUS em busca de mensagens de Access-Reject. Como lidamos com convidados que continuam sendo desconectados após alguns minutos? Verifique sua configuração de timeout de inatividade. Muitos controladores têm como padrão um timeout 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 timeout de inatividade para pelo menos 30 minutos em ambientes de hotelaria e varejo. Para resumir os pontos principais do briefing de hoje. As falhas no Captive Portal de WiFi de 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 seu DHCP e o dimensionamento das sub-redes, 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 dispositivo não autenticado novo 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 frequentes. A tecnologia está madura, os padrões estã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. Já vimos todos os modos de falha descritos neste briefing - e construímos as ferramentas para preveni-los. Se você deseja explorar como a sobreposição em nuvem da Purple se integra com sua infraestrutura existente Cisco Meraki, HPE Aruba, Ruckus ou Juniper Mist, visite purple.ai ou fale com seu gerente de contas. Obrigado por nos ouvir.