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

TITLE: Porque é que o meu WiFi de Convidados Não Liga? Resolução de Problemas de Captive Portal FORMAT: Podcast de Informação Técnica da Purple VOICE: Inglês do Reino Unido - tom de Arquiteto de Soluções Sénior DURATION: Aproximadamente 10 minutos --- SECTION 1: Introdução e Contexto - aproximadamente 1 minuto Olá e bem-vindo a esta sessão de informação técnica da Purple. Eu sou o vosso anfitrião e hoje vamos abordar um dos problemas mais persistentes e incompreendidos nas redes sem fios empresariais: o Captive Portal de WiFi de convidados que simplesmente se recusa a carregar. Já passou por isso. Um convidado chega ao seu hotel, à sua loja de retalho, ao seu estádio ou ao seu centro de conferências. Liga-se à rede WiFi. Nada acontece. Sem página de login. Sem internet. Apenas um ícone a rodar e uma sensação crescente de frustração. Para os diretores de operações de espaços e gestores de TI, esse momento não é apenas um pequeno inconveniente. Representa uma falha direta na experiência do seu convidado, um pico de chamadas de suporte na receção e uma oportunidade perdida de capturar os dados primários que justificam o investimento na sua infraestrutura sem fios. Nesta sessão, vamos analisar os bastidores. Vamos explicar exatamente como funciona a deteção de Captive Portal ao nível do sistema operativo, identificar as seis causas principais responsáveis pela grande maioria das falhas de ligação e fornecer-lhe uma estrutura de resolução de problemas prática e acionável que pode entregar à sua equipa de TI hoje mesmo. Vamos a isso. --- SECTION 2: Análise Técnica Detalhada - aproximadamente 5 minutos Para corrigir um problema de Captive Portal, primeiro precisa de compreender o que um Captive Portal realmente faz ao 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 interceção de tráfego ao nível da rede, e essa distinção é extremamente importante quando as coisas correm mal. Aqui está a sequência. O dispositivo de um convidado liga-se ao seu SSID de convidados e recebe um endereço IP via DHCP. Nesse momento, o sistema operativo não espera que o utilizador abra um navegador. Em segundo plano, um serviço do sistema envia imediatamente um pedido HTTP GET não encriptado para um URL de teste controlado pelo fabricante. Os dispositivos Apple consultam captive.apple.com. Os dispositivos Android consultam connectivitycheck.gstatic.com. Os dispositivos Windows consultam msftconnecttest.com. O Firefox tem o seu próprio teste em detectportal.firefox.com. Se a rede tiver acesso aberto à internet, estes testes devolvem as respostas esperadas e o sistema operativo conclui que está tudo bem. Mas numa rede de convidados, o seu gateway ou controlador sem fios intercepta esse teste HTTP antes que este chegue à internet. Em vez da resposta esperada, o gateway devolve um redirecionamento HTTP 302 que aponta para a página de entrada do seu Captive Portal. O sistema operativo deteta 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 formas como este processo falha. Causa raiz número um: esgotamento do pool de DHCP. Este é o assassino silencioso em eventos de alta densidade. Se estiver a realizar uma conferência com dois mil participantes numa sub-rede padrão slash-24, 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, esgotará esse pool poucos minutos após a abertura das portas. Cada tentativa de ligação subsequente falha antes mesmo de a sequência do Captive Portal começar. A solução é simples: defina os tempos de concessão de DHCP para convidados entre 15 e 30 minutos para ambientes de alta rotatividade e dimensione as suas sub-redes adequadamente para o pico de utilizadores simultâneos, e não apenas para o número total de pessoas. Causa raiz número dois: falha na interceção de DNS. O redirecionamento do Captive Portal depende de o gateway intercetar o probe HTTP. Mas o probe requer primeiro uma consulta de DNS. Se a sua configuração de DNS não permitir que clientes pré-autenticados resolvam nomes de domínio externos, o probe nunca é acionado. Certifique-se de que a sua política de firewall permite explicitamente consultas de DNS de clientes não autenticados e verifique se a sua interceção de DNS está a funcionar executando uma captura de pacotes num dispositivo de teste. Causa raiz número três: walled garden incompleto. O walled garden - também chamado de lista de controlo de acesso pré-autenticação - define quais os domínios externos que os convidados não autenticados podem aceder. Se a sua splash page do portal carregar recursos de uma CDN que não está no walled garden, a página será apresentada como um ecrã em branco. Se disponibilizar login social via Google, Apple ou Facebook, todos os domínios OAuth que esses fornecedores utilizam devem estar na lista de permissões. E aqui está o ponto crítico: os fornecedores de identidade social atualizam regularmente as suas gamas de IP de CDN e domínios de autenticação. Um walled garden que funcionava perfeitamente há seis meses pode estar silenciosamente inoperacional hoje. Agende auditorias trimestrais ao walled garden e utilize a deteção de domínios com caracteres universais (wildcard domain snooping) sempre que o seu hardware o suporte. No Cisco Meraki, HPE Aruba, Ruckus e Juniper Mist, isto está disponível nativamente. Causa raiz número quatro: HSTS a bloquear o redirecionamento. O HTTP Strict Transport Security, ou HSTS, é uma política de segurança do navegador que força ligações a domínios específicos apenas através de HTTPS. Se o dispositivo de um convidado tentar contactar um domínio pré-carregado com HSTS - o que inclui praticamente todos os principais websites - e o seu gateway tentar intercetar esse pedido HTTPS para redirecionar para o portal, o navegador deteta uma incompatibilidade de certificado. Apresenta um aviso de segurança incontornável e bloqueia totalmente o redirecionamento. A solução correta é nunca tentar a interceção de HTTPS. O seu gateway deve apenas redirecionar os probes canário HTTP não encriptados. A solução a longo prazo baseada em normas é a RFC 8910, que define a Opção DHCP 114. Esta opção permite que o seu servidor DHCP anuncie diretamente o URL do Captive Portal ao dispositivo cliente, eliminando totalmente a necessidade de redirecionamento HTTP. O iOS 14 e o Android 11 e superior suportam isto nativamente. Causa raiz número cinco: VPN ativa no dispositivo do visitante. Uma VPN encripta todo o tráfego do dispositivo e encaminha-o através de um túnel externo antes de este chegar ao seu gateway. O seu gateway nunca vê a sonda HTTP. A sequência de deteção do Captive Portal nunca é acionada. O visitante não vê nenhuma página de login nem internet. A solução para o visitante é simples: desativar a VPN, ligar-se ao portal e, em seguida, reativar a VPN. Para a sua equipa de atendimento ao público, esta deve ser a primeira pergunta a fazer quando um visitante reporta um problema de ligação. Causa raiz número seis: a aleatoriedade do endereço MAC quebra a persistência da sessão. Os dispositivos modernos iOS e Android utilizam endereços MAC aleatórios por predefinição como uma funcionalidade de privacidade. Cada vez que um dispositivo se liga a uma rede, pode apresentar um endereço MAC diferente. Uma vez que o estado da sessão do Captive Portal é monitorizado pelo endereço MAC, um visitante que se autenticou há uma hora pode deparar-se novamente com a página de login após a rotação do MAC do seu dispositivo. A solução do lado do visitante é desativar o Endereço Privado para o seu SSID específico nas definições de rede. A solução do lado do operador é implementar a autenticação baseada em perfis - como o OpenRoaming via Passpoint e 802.1X - que autentica na Camada 2 utilizando credenciais em vez de endereços MAC, tornando a aleatoriedade irrelevante. --- SECÇÃO 3: Recomendações de Implementação e Armadilhas - aproximadamente 2 minutos Agora que compreendemos as causas raiz, vamos falar sobre como é, na verdade, uma implementação de Captive Portal bem configurada. Comece pela sua arquitetura DHCP. Para qualquer espaço que preveja mais de 200 dispositivos simultâneos, afaste-se de uma sub-rede única slash-24. Utilize slash-22 ou superior, e defina os tempos de concessão (lease times) para corresponderem ao perfil de permanência do seu espaço. Um hotel define as concessões para 8 horas. Um estádio define as concessões para 3 horas. Um centro comercial 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 obrigatórias são: o FQDN do seu portal e todos os domínios CDN associados, os URLs de deteção de Captive Portal para a Apple, Google, Windows e Firefox, e os domínios OAuth para cada fornecedor de login social que suporte. Na plataforma da Purple, mantemos e atualizamos estas entradas de walled garden automaticamente como parte do nosso serviço gerido na nuvem, o que remove o fardo da manutenção manual da sua equipa. Para o certificado do seu portal, utilize um certificado TLS publicamente fidedigno de uma autoridade de certificação reconhecida. Os certificados autoassinados irão acionar avisos do browser em todos os dispositivos. Renove os certificados antes da expiração - um certificado expirado é uma das causas mais comuns de falhas repentinas do portal em todo o espaço. Um erro comum que afeta muitas equipas de TI: testar o portal a partir de um dispositivo que já se autenticou anteriormente. A sessão do seu dispositivo ainda está ativa, pelo que ignora o portal por completo e conclui que tudo está a funcionar. Teste sempre a partir de um dispositivo num estado novo e não autenticado - ou um dispositivo novo, ou um no qual tenha esquecido a rede e limpo o perfil de WiFi. Finalmente, considere a direção estratégica do percurso. Os Captive Portals são uma tecnologia madura, mas trazem consigo uma fricção inerente. O OpenRoaming, baseado em Passpoint e 802.1X, permite que os visitantes frequentes se liguem de forma automática e segura sem nunca verem uma página de login. A Purple atua como um fornecedor de identidade gratuito para OpenRoaming ao abrigo do nosso plano Connect. Locais como o Premier Inn e o Manchester Airports Group já estão a implementar isto para eliminar a fricção de reautenticação para visitantes recorrentes, mantendo a total conformidade com o GDPR e a recolha de dados primários (first-party data). --- SECÇÃO 4: Perguntas e Respostas Rápidas - aproximadamente 1 minuto Vamos analisar as perguntas mais comuns que ouvimos das equipas de TI dos locais. Pergunta: Porque é que o portal funciona em iPhones mas não em dispositivos Android? Resposta: O Android utiliza connectivitycheck.gstatic.com como o seu URL de teste. Se esse domínio estiver bloqueado pela sua firewall ou não estiver no seu walled garden, os dispositivos Android nunca ativam o portal. Adicione-o explicitamente. Pergunta: Um visitante diz que o portal carregou mas não consegue aceder à internet após iniciar sessão. Resposta: Isto é quase sempre uma falha de autorização RADIUS. Verifique se o seu servidor RADIUS está acessível a partir do controlador sem fios, verifique se o segredo partilhado coincide em ambos os lados e analise os registos RADIUS para mensagens de Access-Reject. Pergunta: Como lidamos com visitantes que continuam a ser desconectados após alguns minutos? Resposta: Verifique a sua definição de idle timeout. Muitos controladores têm como predefinição um idle timeout de 5 minutos, o que é demasiado agressivo para dispositivos móveis que entram em modo de suspensão entre interações. Defina o idle timeout para pelo menos 30 minutos para ambientes de hotelaria e retalho. --- SECÇÃO 5: Resumo e Próximos Passos - aproximadamente 1 minuto Em resumo: as falhas de Captive Portal de WiFi para visitantes dividem-se em seis categorias - esgotamento de DHCP, falha de interceção de DNS, walled garden incompleto, bloqueio de redirecionamento HSTS, VPN ativa no dispositivo do cliente e aleatorização de endereços MAC. Cada uma tem uma correção específica e testável. Para a sua equipa de TI, as ações imediatas são: auditar os tempos de concessão (lease times) de DHCP e o dimensionamento da sub-rede, validar o seu walled garden face aos domínios OAuth atuais dos seus fornecedores de login social e testar o seu portal a partir de um dispositivo novo não autenticado após cada alteração de configuração. Para o seu roteiro a longo prazo, avalie o OpenRoaming como o sucessor da reautenticação de Captive Portal para visitantes frequentes. A tecnologia é madura, os padrões estão estabelecidos sob IEEE 802.1X e WPA3-Enterprise, e a Purple disponibiliza-a sem custos adicionais de software ao abrigo do 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 as suas redes fiáveis e os seus convidados ligados.