Why Is My Guest WiFi Not Connecting? Troubleshooting Captive Portal Issues

TITLE: Por que o meu Wi-Fi de visitantes não conecta? Solucionando problemas de Captive Portal FORMAT: Purple Technical Briefing Podcast VOICE: UK English - Tom de Arquiteto de Soluções Sênior DURATION: Aproximadamente 10 minutos --- SECTION 1: Introdução e Contexto - aproximadamente 1 minuto Olá e boas-vindas a este briefing técnico da Purple. Eu sou o seu anfitrião e hoje estamos abordando um dos problemas mais persistentes e incompreendidos em redes sem fio corporativas: o Captive Portal de Wi-Fi 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 Wi-Fi. 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 primários que justificam o investimento na sua infraestrutura sem fio. Neste briefing, vamos analisar os bastidores. Explicaremos exatamente como a detecção de Captive Portal funciona 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. --- SECTION 2: Mergulho Técnico Profundo - aproximadamente 5 minutos Para corrigir um problema de Captive Portal, primeiro você precisa entender o que um Captive Portal realmente faz no nível da rede. A maioria das pessoas pensa nele apenas 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 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 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 302 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 isolada (sandbox) - frequentemente chamada de Assistente de Captive Portal - para exibir a página de login. Esse é o caminho ideal. Agora vamos falar sobre as seis maneiras pelas quais 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 definido para o padrão de 24 horas, você esgotará esse pool em poucos minutos após a abertura das portas. Cada tentativa de conexão subsequente falhará antes mesmo de a sequência do Captive Portal começar. A solução é simples: defina os tempos de concessão do DHCP de convidados 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 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 uma consulta DNS primeiro. 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 pré-autenticação - define quais domínios externos os convidados 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 rastreamento de domínio curinga (wildcard domain snooping) onde seu hardware for compatível. 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 convidado 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á o redirecionamento por completo. A solução correta é nunca tentar a interceptação HTTPS. Seu gateway deve apenas redirecionar as sondagens canário 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 cliente, eliminando totalmente a necessidade de redirecionamento HTTP. O iOS 14 e o 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. 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 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 do endereço MAC quebrando a persistência da sessão. 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 o MAC do seu dispositivo rotacionar. 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 o OpenRoaming via Passpoint e 802.1X - que autentica na Camada 2 usando credenciais em vez de endereços MAC, tornando a randomização irrelevante. --- SEÇÃO 3: Recomendações de Implementação e Armadilhas - aproximadamente 2 minutos Agora que entendemos as causas raiz, vamos falar sobre como é, de fato, 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 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 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 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 para cada provedor de login social que você suporta. Na plataforma da Purple, mantemos e atualizamos essas entradas de walled garden automaticamente como parte de nosso serviço gerenciado na nuvem, o que remove a carga de manutenção manual de 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. Um erro comum que afeta 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 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 novo dispositivo ou um no qual você tenha esquecido a rede e limpado o perfil de WiFi. Finalmente, considere a direção estratégica do mercado. Os Captive Portals são uma tecnologia madura, mas trazem fricção inerente. O OpenRoaming, baseado em Passpoint e 802.1X, permite que visitantes recorrentes se conectem de forma automática e segura sem nunca ver uma página de login. A Purple atua como um provedor de identidade gratuito para OpenRoaming sob o nosso plano Connect. Locais como Premier Inn e Manchester Airports Group já estão implantando isso para eliminar a fricção de reautenticação para visitantes recorrentes, mantendo a total conformidade com a GDPR e a captura de dados primários (first-party data). --- SEÇÃO 4: Perguntas e Respostas Rápidas - aproximadamente 1 minuto Vamos repassar as perguntas mais comuns que ouvimos das equipes de TI dos locais. Pergunta: Por que o portal funciona em iPhones, mas não em dispositivos Android? Resposta: 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. Pergunta: Um visitante diz que o portal carregou, mas ele não consegue navegar após fazer o login. Resposta: Isso quase sempre é uma falha de autorização 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 de Access-Reject. Pergunta: Como lidamos com visitantes que continuam sendo desconectados após alguns minutos? Resposta: 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 repouso entre as interações. Defina o tempo limite de inatividade para pelo menos 30 minutos em ambientes de hospitalidade e varejo. --- SEÇÃO 5: Resumo e Próximos Passos - aproximadamente 1 minuto Para resumir: as falhas de Captive Portal de WiFi para visitantes se enquadram em seis categorias - esgotamento de DHCP, falha de interceptação de DNS, walled garden 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 sua equipe de TI, as ações imediatas são: auditar os tempos de concessão (lease times) do seu DHCP e o dimensionamento da sub-rede, validar seu walled garden em relação aos domínios OAuth atuais dos seus provedores de login social e testar seu portal a partir de um dispositivo novo e 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 de Captive Portal para visitantes recorrentes. A tecnologia é madura, os padrões estão estabelecidos sob o IEEE 802.1X e WPA3-Enterprise, e a Purple o disponibiliza sem custo de software adicional no plano Connect. Para mais guias técnicos, estudos de caso e recursos de implementação, visite purple.ai. Obrigado por ouvir este briefing técnico da Purple. Mantenha suas redes confiáveis e seus convidados conectados.