Porque é que o meu WiFi de convidados não liga? Resolução de problemas de captive portal

TITLE: Porque é que o meu WiFi de convidados não se liga? Resolução de problemas com o Captive Portal FORMAT: Podcast do Briefing Técnico 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 este briefing técnico da Purple. 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 isto. Um convidado chega ao seu hotel, à sua loja de retalho, ao seu estádio ou ao seu centro de conferências. Junta-se à rede WiFi. Não acontece nada. 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 recolha dos dados primários que justificam o seu investimento em infraestrutura sem fios. Neste briefing, vamos espreitar o que se passa por baixo do capô. 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 prática e aplicável de resolução de problemas que poderá partilhar com a sua equipa de TI hoje mesmo. Vamos a isto. --- SECTION 2: Imersão Técnica - aproximadamente 5 minutos Para corrigir um problema de Captive Portal, primeiro precisa de compreender o que um Captive Portal faz realmente ao nível da rede. A maioria das pessoas pensa nele simplesmente como uma página de login. Na verdade, é um mecanismo de interseção de tráfego ao nível da rede - e essa distinção é extremamente importante quando as coisas correm mal. Eis a sequência. O dispositivo de um convidado junta-se ao seu SSID de convidados e recebe um endereço IP via DHCP. Nesse ponto, o sistema operativo não espera que o utilizador abra um browser. 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 a apontar para a página de splash 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 browser isolada - frequentemente chamada de Assistente do Captive Portal - para apresentar 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 barra 24, tem 254 endereços IP utilizáveis. Se o seu tempo de concessão de DHCP estiver definido para o padrão de 24 horas, irá 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 de convidados para entre 15 e 30 minutos em ambientes de alta rotatividade, e dimensione as suas sub-redes de forma adequada para o pico de utilizadores simultâneos, 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 do gateway intercetar a sondagem HTTP. Mas a sondagem requer primeiro uma pesquisa de 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 a política do seu 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: jardim murado incompleto. O jardim murado - também chamado de lista de controlo de acesso de pré-autorização - define quais os domínios externos a que os convidados não autenticados podem aceder. Se a página inicial do seu portal carregar recursos de uma CDN que não está no jardim murado, a página será apresentada como um ecrã em branco. Se oferecer início de sessão social através da Google, Apple ou Facebook, todos os domínios OAuth que esses fornecedores utilizam devem ser incluídos 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 jardim murado que funcionava perfeitamente há seis meses pode estar silenciosamente avariado hoje. Agende auditorias trimestrais ao jardim murado e utilize a deteção de domínios com caracteres universais onde o seu hardware o permitir. 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 - e isso 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 impossível de contornar e bloqueia totalmente o redirecionamento. A solução correta é nunca tentar a interceção de HTTPS. O seu gateway deve apenas redirecionar as sondagens canárias HTTP não encriptadas. A solução a longo prazo baseada em normas é o 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, ignorando 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 chega a ver a sonda HTTP. A sequência de deteção do Captive Portal nunca é acionada. O visitante não vê nenhuma página de login e não tem internet. A solução para o visitante é simples: desativar a VPN, ligar ao portal e, em seguida, voltar a ativar 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 randomização do endereço MAC quebra a persistência da sessão. Os dispositivos modernos iOS e Android utilizam endereços MAC randomizados 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 ver novamente a página de login após o MAC do seu dispositivo rodar. A solução do lado do visitante consiste em desativar o Endereço Privado para o seu SSID específico nas definições de rede. A solução do lado do operador passa por implementar a autenticação baseada em perfis - como o OpenRoaming através de Passpoint e 802.1X - que autentica na Camada 2 utilizando credenciais em vez de endereços MAC, tornando a randomização irrelevante. - SECÇÃO 3: Recomendações de Implementação e Erros Comuns - aproximadamente 2 minutos Agora que compreendemos as causas raiz, vamos falar sobre como deve ser uma implementação de Captive Portal bem configurada. Comece pela sua arquitetura DHCP. Para qualquer local 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) de acordo com o 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 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 suportar. Na plataforma da Purple, mantemos e atualizamos estas entradas do walled garden automaticamente como parte do nosso serviço gerido na nuvem, o que remove a carga de 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 de expirarem - um certificado caducado é uma das causas mais comuns de falhas súbitas de portal em todo o recinto. Uma armadilha que apanha muitas equipas de TI: testar o portal a partir de um dispositivo que já foi autenticado anteriormente. A sessão do seu dispositivo ainda está ativa, pelo que ignora completamente o portal e conclui que tudo está a funcionar. Teste sempre a partir de um dispositivo num estado limpo e não autenticado - ou um dispositivo novo, ou um onde tenha esquecido a rede e limpado o perfil de WiFi. Finalmente, considere a direção estratégica do percurso. Os portais cativos são uma tecnologia madura, mas trazem 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 verem uma única página de início de sessão. A Purple atua como um fornecedor de identidade gratuito para o OpenRoaming ao abrigo do nosso plano Connect. Locais como o Premier Inn e o Manchester Airports Group já estão a implementar esta solução para eliminar a fricção de reautenticação para visitantes recorrentes, mantendo a conformidade total com o GDPR e a captura de dados primários. - 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 o connectivitycheck.gstatic.com como o seu URL de teste. Se esse domínio estiver bloqueado pela sua firewall ou não estiver na sua walled garden, os dispositivos Android nunca acionam 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 Access-Reject. Pergunta: Como lidamos com visitantes que continuam a ser desligados após alguns minutos? Resposta: Verifique a sua configuração de limite de tempo de inatividade (idle timeout). Muitos controladores definem por predefinição um limite de tempo de inatividade de 5 minutos, o que é demasiado agressivo para dispositivos móveis que entram em modo de suspensão entre interações. Defina o limite de tempo de inatividade para pelo menos 30 minutos em ambientes de hotelaria e retalho. - SECÇÃO 5: Resumo e Próximos Passos - aproximadamente 1 minuto Para resumir: as falhas do Captive Portal de WiFi de visitantes dividem-se em seis categorias - exaustão de DHCP, falha de interceção de DNS, walled garden incompleta, bloqueio de redirecionamento HSTS, VPN ativa no dispositivo do cliente e aleatorização do endereço 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 de DHCP e o dimensionamento da sub-rede, validar a sua walled garden em relação aos domínios OAuth atuais dos seus fornecedores de início de sessão social e testar o seu portal a partir de um dispositivo fresco 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 por Captive Portal para visitantes frequentes. A tecnologia é madura, os padrões estão estabelecidos sob IEEE 802.1X e WPA3, 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 visitantes ligados.