Por que meu WiFi de visitantes não está conectando? Resolução de problemas de Captive Portal

TITLE: Por que meu WiFi de visitantes não conecta? Solucionando problemas do Captive Portal FORMAT: Podcast Purple Technical Briefing VOICE: Inglês Britânico - 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 apresentador e hoje vamos abordar 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 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 olhar sob o capô. 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. --- SECTION 2: Mergulho Técnico Profundo - aproximadamente 5 minutos Para corrigir um problema no 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, 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 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 do dispositivo. 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 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 Assistente de Captive Portal - 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ê estiver realizando uma conferência com dois mil participantes em uma sub-rede padrão barra 24, você terá 254 endereços IP utilizáveis. Se o tempo de concessão 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 a sequência do Captive Portal começar. A correção é simples: configure o tempo de concessão do DHCP de visitantes para algo entre 15 e 30 minutos em ambientes com 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 uma consulta de 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 será executada. 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é-autorização - define quais domínios externos os visitantes não autenticados podem acessar. Se a splash page do seu portal carregar elementos de uma CDN que não está no walled garden, a página será exibida 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 de forma silenciosa hoje. Agende auditorias trimestrais de walled garden e use rastreamento 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 - o que 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á totalmente o redirecionamento. A solução correta é nunca tentar a interceptação de HTTPS. Seu gateway deve redirecionar apenas as sondagens de teste 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 e o Android 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 um túnel externo antes que ele chegue ao seu gateway. O seu gateway nunca vê a investigação 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 depois 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 de endereços 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 rotacionar. 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 para o 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. - 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 preveja mais de 200 dispositivos simultâneos, afaste-se de uma sub-rede única de 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 conferências 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 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. 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. Por fim, considere a direção estratégica de sua jornada. Os Captive Portals são uma tecnologia madura, mas carregam um atrito inerente. O OpenRoaming, baseado em Passpoint e 802.1X, permite que os 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 em nosso plano Connect. Locais como Premier Inn e Manchester Airports Group já estão implantando isso para eliminar o atrito de nova autenticação para visitantes recorrentes, mantendo a total conformidade com a GDPR e a captura de dados primários (first-party). - SEÇÃO 4: Perguntas e Respostas Rápidas - aproximadamente 1 minuto Vamos passar pelas perguntas mais comuns que ouvimos das equipes de TI dos estabelecimentos. 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 ficar online 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 revise 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 definem por padrão 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. - 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 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 walled garden em relação aos domínios OAuth atuais de seus provedores de login social e testar 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 nova autenticação de Captive Portal para visitantes recorrentes. A tecnologia está madura, os padrões estão estabelecidos sob IEEE 802.1X e WPA3, e a Purple a disponibiliza sem custo adicional de software no plano Connect. Para mais guias técnicos, estudos de caso e recursos de implementação, visite purple.ai. Obrigado por ouvir este boletim técnico da Purple. Mantenha suas redes confiáveis e seus visitantes conectados.