Porque é que o seu Captive Portal não está a carregar no iPhone

[Intro Music: Upbeat, modern electronic synth-pop with clean piano highlights, establishing a professional, tech-forward tone] **Host (Senior Consultant)**: Olá e bem-vindo ao Purple Technical Briefing. Eu sou o seu anfitrião e hoje vamos analisar em detalhe um dos problemas mais comuns — e, francamente, mais frustrantes — que os administradores de rede, gestores de TI e diretores de operações de espaços enfrentam atualmente. Todos nós já passámos por isso. Passou semanas a planear, configurar e implementar uma rede Wi-Fi de convidados topo de gama para o seu hotel, centro comercial ou estádio. Tem os pontos de acesso mais recentes, um controlador robusto e uma página de splash apelativa pronta para recolher dados dos convidados e impulsionar o engagement. Mas depois, os pedidos de suporte começam a chegar. E todos dizem exatamente o mesmo: "Liguei-me ao Wi-Fi de convidados no meu iPhone, mas a página de login não carrega." Para o convidado, o seu Wi-Fi está simplesmente avariado. Mas para nós, como engenheiros e arquitetos de rede, sabemos que há uma batalha técnica complexa a acontecer nos bastidores do iOS. Hoje, vamos desmistificar exatamente o motivo pelo qual o seu Captive Portal não está a carregar nos iPhones, como funciona a lógica de deteção em segundo plano da Apple e os caminhos de mitigação passo a passo que pode implementar na sua rede este trimestre. [Brief transitional musical swell] **Host**: Vamos começar com a análise técnica aprofundada. Porque é que um iPhone se liga ao Wi-Fi de convidados mas não mostra o ecrã de login? Para compreender isto, temos de olhar para o **Captive Network Assistant** da Apple, ou **CNA**. Quando um iPhone se associa a um SSID aberto e recebe um endereço IP via DHCP, não fica apenas à espera que o utilizador abra um navegador. Em vez disso, um daemon de sistema em segundo plano envia imediatamente um pedido HTTP GET simples para um URL muito específico: `http://captive.apple.com/hotspot-detect.html`. Esta verificação em segundo plano utiliza um User-Agent de sistema exclusivo chamado `CaptiveNetworkSupport`. O daemon CNA procura uma resposta muito específica. Se os servidores da Apple devolverem um código de estado HTTP **200 OK** com um corpo que contenha exatamente a palavra "Success", o iOS conclui que a rede tem acesso irrestrito à internet. Estabelece silenciosamente o Wi-Fi como a interface de encaminhamento principal e o utilizador continua o seu dia. No entanto, se o gateway da sua rede intercetar esse pedido HTTP e devolver qualquer outra coisa — como um redirecionamento HTTP 302 ou 307, ou uma página HTML personalizada — o iOS reconhece imediatamente que está atrás de um Captive Portal. Inicia instantaneamente a aplicação nativa **Websheet**. Esta é aquela conhecida janela modal deslizante que apresenta a sua página de login de convidados. Agora, aqui está o primeiro grande obstáculo de engenharia: **O Walled Garden**. Muitos engenheiros de rede cometem o erro de colocar os domínios de sucesso da Apple, como `captive.apple.com`, na lista de permissões (whitelist) das suas Listas de Controlo de Acesso de pré-autenticação. Pensam: "Bem, é um domínio da Apple, devo deixá-lo passar." Mas se o colocar na lista de permissões, a verificação em segundo plano chega com sucesso aos servidores da Apple, recebe a resposta "Success" e o iOS assume que não existe um Captive Portal. O Websheet nunca é ativado! Entretanto, o utilizador fica impedido de aceder a quaisquer outros websites. Portanto, regra número um: **Nunca coloque o captive.apple.com na lista de permissões do seu walled garden.** [Breve efeito sonoro de transição] **Apresentador**: Mas e quanto às funcionalidades modernas de privacidade do iOS? Mesmo com um walled garden perfeito, funcionalidades como o **iCloud Private Relay** e os **Endereços MAC Privados** estão a mudar as regras do jogo. Vamos falar sobre o iCloud Private Relay, introduzido no iOS 15. Esta funcionalidade encripta e encaminha o tráfego DNS e HTTP do Safari através de uma arquitetura de proxy de duplo salto. Quando um utilizador com o Private Relay ativo se liga ao seu Wi-Fi de convidados, a verificação HTTP em segundo plano é encapsulada dentro de um túnel encriptado. Como o seu gateway de rede não consegue inspecionar ou intercetar este pacote encriptado, não consegue injetar o redirecionamento. A verificação falha silenciosamente e o iPhone apresenta simplesmente um aviso de "Sem Ligação à Internet". Sem portal, sem início de sessão, apenas fricção. Felizmente, existe uma mitigação programática ao nível da rede para isto. A Apple concebeu o Private Relay para respeitar os bloqueios ao nível da rede. Se o seu servidor DNS local devolver uma resposta **NXDOMAIN** para os domínios do Private Relay da Apple — especificamente `mask.icloud.com` e `mask-h2.icloud.com` — o iOS reconhece que a rede é incompatível com o Private Relay. Irá apresentar imediatamente um aviso do sistema a perguntar ao utilizador se deseja "Utilizar Sem Private Relay" para esta rede. No momento em que tocam nessa opção, o túnel encriptado é contornado, a verificação HTTP é intercetada e o seu Captive Portal é carregado perfeitamente. Seguem-se os **Endereços MAC Privados** e os novos **Endereços MAC Rotativos** no iOS 18. Por predefinição, os iPhones randomizam o seu endereço MAC para cada SSID. No iOS 18, este endereço roda periodicamente mesmo estando ligado à mesma rede. Se o seu controlador sem fios monitorizar as sessões de convidados autenticadas exclusivamente pelo endereço MAC, uma rotação repentina fará com que o gateway trate o iPhone como um dispositivo totalmente novo e não autenticado. O convidado é abruptamente desligado e forçado a iniciar sessão novamente. Para mitigar isto, os espaços empresariais devem afastar-se da simples monitorização baseada em MAC. Plataformas como a **Purple** resolvem isto inserindo um cookie seguro e persistente na sessão do navegador ou, melhor ainda, fazendo a transição dos espaços para o **Passpoint**, também conhecido como Hotspot 2.0. O Passpoint utiliza perfis 802.1X seguros para autenticar automática e seguramente os convidados que regressam, sem nunca apresentar uma página de Captive Portal. É seguro, é fluido e contorna completamente as limitações do CNA. [Breve crescendo musical de transição] **Apresentador**: Agora, vamos abordar os perfis de DNS personalizados e as VPNs locais. Muitos utilizadores técnicos instalam perfis de DNS personalizados, como o NextDNS ou o AdGuard, que forçam o DNS-over-HTTPS encriptado. Como estes perfis contornam os servidores DNS atribuídos pelo seu DHCP local, o seu gateway não consegue simular a resolução de DNS para `captive.apple.com`. Da mesma forma, os perfis de VPN "Sempre Ativos" tentarão estabelecer um túnel encriptado no segundo em que um IP é atribuído. Se a VPN for bem-sucedida, contorna o seu redirecionamento; se for bloqueada, bloqueia a ligação. Para estes utilizadores, o último recurso manual é o truque do **neverssl.com**. Se um convidado estiver ligado ao seu Wi-Fi mas o Captive Portal não carregar, diga-lhe para abrir o Safari e digitar `neverssl.com` na barra de endereço. Como este domínio é estritamente HTTP não encriptado, o gateway tem a garantia de intercetar o tráfego da porta 80 e forçar o carregamento do redirecionamento, contornando qualquer interferência de DNS personalizado ou VPN. [Efeito sonoro: Sinal sonoro de transição rápida] **Apresentador**: Vamos passar por uma sessão rápida de perguntas e respostas sobre as dúvidas mais comuns que recebemos das equipas de suporte dos locais. *Pergunta um: Porque é que o meu iPhone mostra 'Sem Ligação à Internet' a cor de laranja por baixo do nome do Wi-Fi?* **Resposta**: Isto significa que o iPhone concluiu a associação ao Wi-Fi e obteve um endereço IP, mas a verificação de CNA em segundo plano não obteve resposta dos servidores de sucesso da Apple e não foi redirecionada com sucesso, frequentemente devido ao iCloud Private Relay ou a uma VPN ativa. *Pergunta dois: Podemos simplesmente desativar o mini-browser CNA por completo na nossa rede?* **Resposta**: Sim, a maioria dos Controladores de LAN Sem Fios empresariais tem uma definição chamada 'CNA Bypass' ou 'Captive Portal Bypass'. Quando ativada, o controlador simula a verificação de sucesso da Apple, dizendo ao iPhone que tem internet total. Isto evita que o Websheet apareça, mas depende de o utilizador abrir manualmente o Safari para acionar o redirecionamento, o que por vezes pode criar ainda mais confusão no utilizador. *Pergunta três: O que é o problema da verificação pós-autenticação?* **Resposta**: Após o login do convidado, o Websheet do CNA executa uma verificação secundária para verificar o acesso à internet. Se o seu gateway os redirecionar para uma página de destino mas continuar a bloquear os domínios de sucesso da Apple, o botão no canto superior direito permanece bloqueado em 'Cancelar'. Clicar em 'Cancelar' desliga-os do Wi-Fi. Deve garantir que os domínios de sucesso da Apple estão totalmente acessíveis pós-autenticação. [Breve subida musical de transição] **Apresentador**: Para terminar, vamos analisar o impacto comercial no mundo real. Otimizar o seu captive portal não se trata apenas de elegância técnica; trata-se de resultados financeiros. Recentemente, trabalhámos com um grupo de resorts de luxo de 5 estrelas que registava uma taxa de falha de 35% nas ligações Wi-Fi dos hóspedes, o que resultava em mais de 450 reclamações na receção todas as semanas. Ao reestruturar o seu walled garden, bloqueando domínios de Private Relay ao nível do DNS para forçar o encaminhamento local, e ao implementar a solução **Guest WiFi da Purple**, viram os pedidos de suporte de Wi-Fi na receção diminuir em **92%** em apenas 30 dias. As suas pontuações de satisfação dos hóspedes dispararam e capturaram milhares de perfis de hóspedes verificados. Se deseja garantir que a sua rede Wi-Fi de hóspedes interage na perfeição com o Captive Network Assistant da Apple, ao mesmo tempo que maximiza a captura de dados e minimiza os custos de suporte, aceda a **purple.ai**. A nossa plataforma foi concebida para lidar com todas estas nuances específicas do iOS de forma imediata. Obrigado por ouvir este Briefing Técnico da Purple. Implemente estas estratégias de walled garden e DNS esta semana e veja os seus pedidos de suporte desaparecerem. Até à próxima, mantenha as suas ligações seguras e a integração dos seus hóspedes simples. [Música de Encerramento: Synth-pop eletrónico animado desaparece lentamente]