Saltar para o conteúdo principal
Português

Por que o seu captive portal não está a carregar no iPhone: Corrigir erros de CNA da Apple

Resolva e corrija falhas no popup do captive portal no iPhone e iOS. Saiba como o CNA da Apple, o iCloud Private Relay e a randomização de MAC quebram os inícios de sessão em redes WiFi, e como resolvê-los.

Por Tom HackettPublicado
📖 10 min de leitura1,888 palavras2 exemplos práticos3 perguntas de prática6 definições principais

Video overview

Ouça este guia

Ver transcrição do podcast
[Música de Introdução: Sintetizador eletrónico moderno e ritmado com notas de piano limpas, estabelecendo um tom profissional e tecnológico] **Apresentador (Consultor Sénior)**: 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 — enfrentados atualmente por administradores de rede, gestores de TI e diretores de operações de recintos. Todos nós já passamos por isto. Passou semanas a planear, configurar e implementar uma rede WiFi de convidados topo de gama para o seu hotel, centro comercial ou estádio. Dispõe dos pontos de acesso mais recentes, de um controlador robusto e de uma excelente splash page pronta para captar dados de convidados e impulsionar o envolvimento. Mas depois, os pedidos de suporte começam a chegar. E todos dizem exatamente o mesmo: "Liguei-me ao WiFi de convidados no meu iPhone, mas a página de início de sessão não carrega." Para o convidado, o seu WiFi está simplesmente avariado. Mas para nós, como engenheiros e arquitetos de rede, sabemos que está a decorrer uma batalha técnica complexa nos bastidores do iOS. Hoje, vamos explicar exatamente por que razão 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. [Breve transição musical] **Apresentador**: Vamos começar com a análise técnica aprofundada. Por que razão um iPhone se liga ao WiFi de convidados mas não mostra o ecrã de início de sessão? 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 se limita a esperar 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 sonda 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 diz exatamente a palavra "Success", o iOS conclui que a rede tem acesso irrestrito à Internet. Estabelece discretamente o WiFi como a interface de encaminhamento primária e o utilizador continua o seu dia. No entanto, se o seu gateway de 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 app**. Esta é aquela janela modal familiar que desliza para cima e apresenta a sua página de início de sessão de convidados. Agora, aqui está o primeiro grande obstáculo de engenharia: **O Jardim Fechado (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 das suas listas de controlo de acesso pré-autenticação. Pensam: "Bem, é um domínio da Apple, devo deixá-lo passar." Mas se o colocar na lista de permissões, a sonda em segundo plano chega com sucesso aos servidores da Apple, recebe a resposta "Success", e o iOS assume que não existe nenhum Captive Portal. O Websheet nunca é ativado! Entretanto, o utilizador está impedido de aceder a quaisquer outros websites. Portanto, regra número um: **Nunca coloque captive.apple.com na lista de permissões do seu walled garden.** [Breve efeito sonoro de transição] **Apresentador**: Mas e as funcionalidades de privacidade modernas do iOS? Mesmo com um walled garden perfeito, funcionalidades como o **iCloud Private Relay** e os **Private MAC Addresses** 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 WiFi de convidados, a sonda 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 sonda 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 isso. A Apple concebeu o Private Relay para respeitar os bloqueios ao nível da rede. Se o seu servidor DNS local retornar 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. Apresentará imediatamente um aviso do sistema a perguntar ao utilizador se deseja "Utilizar Sem o Private Relay" nesta rede. No momento em que tocam nessa opção, o túnel encriptado é ignorado, a sonda HTTP é intercetada e o seu Captive Portal carrega perfeitamente. A seguir, temos os **Private MAC Addresses** e os novos **Rotating MAC Addresses** no iOS 18. Por predefinição, os iPhones utilizam endereços MAC aleatórios para cada SSID. No iOS 18, este endereço roda periodicamente, mesmo quando ligado à mesma rede. Se o seu controlador sem fios monitorizar as sessões de convidados autenticadas exclusivamente pelo endereço MAC, uma rotação súbita fará com que o gateway trate o iPhone como um dispositivo novo e não autenticado. O convidado é abruptamente desligado e forçado a iniciar sessão novamente. Para mitigar esta situação, os locais 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 browser ou, melhor ainda, transitando os locais 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, é contínuo e contorna completamente as limitações do CNA. [Breve crescendo musical de transição] **Apresentador**: Agora, vamos falar sobre os perfis de DNS personalizados e 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 seus servidores DNS locais atribuídos por DHCP, o seu gateway não consegue falsificar a pesquisa de DNS para `captive.apple.com`. Da mesma forma, os perfis de VPN "Always-On" tentarão estabelecer um túnel encriptado no segundo em que um IP é atribuído. Se a VPN for bem-sucedida, ela contorna o seu redirecionamento; se for bloqueada, bloqueia completamente a ligação. Para estes utilizadores, o último recurso manual é o truque do **neverssl.com**. Se um convidado estiver ligado ao seu WiFi mas o portal não carregar, diga-lhe para abrir o Safari e digitar `neverssl.com` na barra de endereços. 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 para 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 laranja sob o nome do WiFi?* **Resposta**: Isto significa que o iPhone concluiu a associação ao WiFi e obteve um endereço IP, mas a verificação de CNA em segundo plano não conseguiu obter uma resposta dos servidores de sucesso da Apple e não foi redirecionada com êxito, muitas vezes devido ao iCloud Private Relay ou a uma VPN ativa. *Pergunta dois: Podemos simplesmente desativar o mini-navegador 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 ativado, o controlador falsifica a verificação de sucesso da Apple, dizendo ao iPhone que este tem internet total. Isto impede a abertura do Websheet, mas depende do utilizador abrir manualmente o Safari para acionar o redirecionamento, o que por vezes pode gerar ainda mais confusão no utilizador. *Pergunta três: O que é o problema da verificação pós-autenticação?* **Resposta**: Depois de o convidado iniciar sessão, 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 superior direito permanece bloqueado em "Cancelar". Clicar em "Cancelar" desliga-os do WiFi. 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 rentabilidade. Recentemente, trabalhámos com um grupo de resorts de luxo de 5 estrelas que registava uma taxa de falha de 35% nas ligações de WiFi 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 de **Guest WiFi da Purple**, registaram uma redução de **92%** nos pedidos de suporte de WiFi na receção em apenas 30 dias. As 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 de WiFi para hóspedes interage na perfeição com o Captive Network Assistant da Apple, ao mesmo tempo que maximiza a recolha de dados e minimiza os custos de suporte, visite **purple.ai**. A nossa plataforma está concebida para lidar com todas estas nuances específicas do iOS de forma nativa. 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 ritmado desaparece gradualmente]

Parte da nossa série principal: Guia do Captive Portal →

Resumo Executivo

A falha de início de sessão no Captive Portal em dispositivos iOS (iPhone e iPad) é uma das principais causas de reclamações de ligação ao WiFi de convidados em ambientes de hotelaria, retalho, saúde e empresariais. Quando um dispositivo iOS se associa a uma rede sem fios aberta ou com autenticação web, o daemon Captive Network Assistant (CNA) da Apple inicia uma série de sondagens HTTP em segundo plano. Se estas sondagens forem bloqueadas, mal encaminhadas ou intercetadas incorretamente, a página inicial do Captive Portal não carrega, deixando o utilizador sem acesso à Internet e sem uma forma óbvia de iniciar sessão.

Este guia técnico detalha o funcionamento subjacente da deteção do CNA da Apple, analisa as principais funcionalidades de privacidade do iOS - incluindo o iCloud Private Relay, Private WiFi Addresses (randomização de MAC) e DNS encriptado - e fornece estratégias de mitigação passo a passo para engenheiros de rede e operadores de locais.

Dificuldades com Desconexões de WiFi de Convidados no iOS?

A plataforma de WiFi de convidados gerida na nuvem da Purple processa as sondagens do CNA da Apple, o iCloud Private Relay e a randomização de MAC automaticamente - proporcionando uma integração contínua no Captive Portal em todos os dispositivos iOS e Android.

Explorar Purple Guest WiFi →

Análise Técnica Detalhada

Lógica de Deteção e Mecanismo de Sondagem da Apple

Quando um iPhone se liga a um ponto de acesso sem fios, a pilha de rede do iOS envia imediatamente um daemon chamado captivenetworkd. Este daemon emite pedidos HTTP GET simples para URLs de verificação predefinidos da Apple, incluindo:

  • http://captive.apple.com/hotspot-detect.html
  • http://www.apple.com/library/test/success.html
  • http://gsp1.apple.com/pep/gcc
+-------------------+       HTTP GET captive.apple.com       +----------------------+
|   iPhone (iOS)    | -------------------------------------> |  Network Controller  |
+-------------------+                                        +----------------------+
          |                                                             |
          | <--- HTTP 302 Redirect (https://portal.purple.ai) ---------+
          |
          v
[ Launch CNA Websheet ] ---> [ Render Purple Captive Portal ]

O daemon avalia o estado e o corpo da resposta HTTP:

  1. Resposta de Sucesso (HTTP 200 com <HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>"): O sistema operativo conclui que a rede fornece acesso irrestrito à Internet. Nenhuma página splash é apresentada.
  2. Resposta de Redirecionamento (HTTP 302 / 307): O gateway de rede intercepta o pedido HTTP do Porto 80 e redireciona o cliente para o URL do Captive Portal. O iOS reconhece o redirecionamento e inicia o CNA Websheet (uma janela de navegação modal especializada).
  3. Tempo Limite ou Reset de Ligação: Se o gateway rejeitar pacotes do Porto 80 ou falhar ao responder a consultas DNS, o teste expira. O iOS apresenta um aviso de "Sem Ligação à Internet" sob o nome do SSID nas Definições, mas não consegue apresentar a página de início de sessão.

Testes Pós-Autenticação (O Desafio do Botão "Concluído")

Depois de um utilizador submeter as suas credenciais ou aceitar os termos de serviço na página splash, o controlador LAN sem fios (WLC) atualiza o estado ACL do cliente para "autenticado". O daemon CNA emite imediatamente um teste HTTP de seguimento para captive.apple.com.

Se o segundo teste retornar HTTP 200 "Success", o botão superior direito no CNA Websheet muda de "Cancelar" para "Concluído". Se a rede falhar em permitir o acesso HTTP fora de banda imediatamente após a autenticação, o botão permanece bloqueado em "Cancelar" e tocar nele pode desligar totalmente o dispositivo da rede WiFi.

Fatores de Interferência Específicos do iOS

1. iCloud Private Relay

Introduzido no iOS 15, o iCloud Private Relay é um serviço da Apple concebido para proteger a privacidade da navegação na web. Quando ativado, o Safari e o tráfego HTTP não encriptado são encriptados e encaminhados através de dois relays de Internet separados:

[ iPhone ] === Encriptado QUIC/TLS ===> [ Apple Ingress Proxy ] ---> [ Egress Proxy ] ---> [ Destino Web ]
  • O Problema: O Private Relay encripta pedidos DNS através de Oblivious DNS-over-HTTPS (ODoH) e canaliza o tráfego HTTP através de QUIC (Porto UDP 443). Como os routers de gateway locais não conseguem inspecionar ou interceptar tráfego QUIC encriptado, não conseguem injetar o redirecionamento HTTP 302 padrão.
  • Impacto: O teste HTTP inicial para captive.apple.com é canalizado para fora do gateway local, resultando em tempos limite de ligação e páginas splash em falta.

2. Endereços MAC Privados e Identificadores Rotativos

A partir do iOS 14 e expandido no iOS 18, a Apple ativa o Endereço WiFi Privado por predefinição. Em vez de utilizar o endereço MAC de hardware permanente do dispositivo, o iOS gera um endereço MAC aleatório para cada SSID.

  • O Problema: Em redes que utilizam autorização de sessão baseada em MAC (onde os utilizadores autenticados têm direito a 24 horas de acesso com base no endereço MAC), a rotação de MAC faz com que o gateway de rede veja os dispositivos que regressam como clientes novos e não autenticados.
  • Impacto: Os utilizadores deparam-se repetidamente com a página splash do Captive Portal, resultando numa má experiência de utilizador e em pedidos de suporte na receção.

3. Perfis de DNS Encriptados (DoH / DoT)

Utilizadores com perfis de configuração iOS personalizados (tais como NextDNS, Cloudflare 1.1.1.1 ou definições de DNS de MDM corporativo) transmitem todas as consultas DNS através de HTTPS encriptado (DoH) ou TLS (DoT) diretamente para resolvedores externos.

  • O Problema: O servidor DNS da rede local não consegue intercetar ou falsificar pedidos DNS para captive.apple.com ou domínios não existentes.
  • Impacto: A resolução inicial de DNS ignora completamente o controlador local, impedindo que o redirecionamento do portal seja acionado.

Guia de Implementação e Mitigação

Desenho de Walled Garden (ACL Pré-Autenticação)

Para garantir uma composição fiável do Captive Portal no iOS, os engenheiros de rede devem configurar a Lista de Controlo de Acesso (ACL) do Walled Garden de pré-autenticação com precisão:

Tipo de Regra Destino / Domínio Finalidade
Permitir *.purple.ai, *.purpleshield.com Permite que clientes não autenticados alcancem a infraestrutura e os recursos do portal Purple.
Intercetar HTTP (Porta TCP 80) para qualquer destino Interceta o tráfego web HTTP simples para acionar o redirecionamento 302.
Bloquear / NXDOMAIN mask.icloud.com, mask-h2.icloud.com Retorna NXDOMAIN para sinalizar que o Private Relay está indisponível na rede local.
NÃO Colocar na Lista Branca captive.apple.com, www.apple.com NÃO deve ser colocado na lista branca. A colocação na lista branca faz com que as sondagens tenham sucesso sem iniciar o portal.

Configuração Passo a Passo do WLC (Exemplo Cisco Catalyst / Meraki)

  1. Configurar Interceção de DNS: Configure o servidor DHCP para atribuir o endereço IP do gateway como o servidor DNS principal para clientes não autenticados.
  2. Configurar Sinalização de Private Relay: Adicione uma regra de reescrita de DNS nos servidores DNS locais:
    mask.icloud.com      IN A 0.0.0.0 (ou NXDOMAIN)
mask-h2.icloud.com   IN A 0.0.0.0 (ou NXDOMAIN)
    Quando o iOS recebe NXDOMAIN para estes nomes de anfitrião, apresenta a mensagem do sistema: "Esta rede bloqueia o iCloud Private Relay. Deseja utilizar esta rede sem o Private Relay?" Tocar em Utilizar Sem Private Relay restaura o redirecionamento padrão do portal.
  3. Configurar Limite de Tempo da Sessão: Defina o limite de tempo da sessão do gateway com base em pares de IP/MAC ou elimine cookies de autorização persistentes.

Tem dúvidas sobre a sua configuração específica?

A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área o resolveram.

Melhores Práticas e Padrões do Setor

Gerir a adesão de convidados à rede sem fios em grande escala exige a conformidade com os padrões de rede modernos:

  • Transição para WPA3-Personal (OWE): Os portais de convidados antigos são executados em SSIDs abertos e não encriptados. Os locais empresariais devem adotar a Opportunistic Wireless Encryption (OWE) (IEEE 802.11aq) para fornecer encriptação individualizada sem palavras-passe.
  • Conformidade com PCI-DSS e GDPR: Os portais de convidados devem isolar o tráfego de convidados das redes de pagamento PCI-DSS. Ao recolher dados de contacto, os portais devem apresentar caixas de seleção de consentimento explícitas e não agregadas do GDPR - geridas facilmente através de uma plataforma de WiFi Analytics.
  • Implementar Passpoint (Hotspot 2.0): Para eliminar totalmente a fricção do Captive Portal, os locais de atendimento podem implementar o Passpoint (Hotspot 2.0). O Passpoint utiliza uma autenticação semelhante à rede móvel para ligar dispositivos iOS de forma segura e automática através de um perfil pré-instalado, contornando completamente o daemon do CNA.

Resolução de Problemas e Mitigação de Riscos

Caminho de Autorresolução para o Utilizador Final

  1. Desativar a Retransmissão Privada do iCloud para a Rede: Abra Definições > WiFi, toque no ícone (i) ao lado do nome da rede e desative a opção Limitar Monitorização do Endereço IP.
  2. Desativar o Endereço WiFi Privado: No mesmo menu de definições de rede, desative a opção Endereço WiFi Privado se for necessário o acesso baseado em MAC.
  3. Forçar o Redirecionamento do Portal via Safari: Abra o Safari e introduza o endereço HTTP simples: http://neverssl.com Como o neverssl.com não utiliza HTTPS, o router local irá intercetar o pedido com fiabilidade e carregar o portal.

Caminho de Diagnóstico para Engenheiros de Rede

                  [ iPhone liga-se ao SSID de convidados ]
                                  |
                                  v
                        [ IP de DHCP atribuído? ]
                        /                   \
                     (Não)                  (Sim)
                      /                       \
        [ Verificar Pool de DHCP ]     [ Resolve captive.apple.com? ]
                                        /                             \
                                     (Não)                            (Sim)
                                      /                                 \
                         [ Verificar ACL de DNS ]            [ Apple está na Whitelist? ]
                                                             /                       \
                                                          (Sim)                      (Não)
                                                           /                           \
                                              [ REMOVER do Walled Garden ]     [ Redireciona na Porta 80? ]
                                                                               /                   \
                                                                            (Não)                  (Sim)
                                                                             /                       \
                                                                 [ Corrigir Redirecionamento WLC ] [ Carrega CNA Websheet ]

Retorno do Investimento e Impacto Comercial

Otimizar a experiência de integração de convidados em iOS no WiFi tem um impacto direto e mensurável nas operações do local e nas métricas de negócio.

Estudo de Caso de Hotelaria: Grupo de Resorts de Cinco Estrelas

  • Desafio: Um grupo de hotéis de luxo com 12 propriedades sofria de uma taxa de falha de ligação de convidados ao WiFi de 35%, o que gerava mais de 450 reclamações na receção por semana.
  • Implementação: A equipa de TI reestruturou o seu walled garden, desativou a monitorização de sessões baseada em MAC e implementou a solução de Guest WiFi da Purple com gestão otimizada de CNA.
  • Resultados: As reclamações relacionadas com WiFi na receção diminuíram 92% em 30 dias. As pontuações de satisfação do cliente (CSAT) subiram 18 pontos e o espaço recolheu 40.000 novos endereços de email verificados no primeiro trimestre.

Caso de Estudo de Retalho: Operador Nacional de Centros Comerciais

  • Desafio: Um operador de retalho com 45 centros comerciais tinha dificuldades em promover o envolvimento dos visitantes porque o iCloud Private Relay impedia o carregamento do Captive Portal em 40% dos dispositivos iOS.
  • Implementação: Implementou o bloqueio de Private Relay ao nível da rede (devolvendo NXDOMAIN para os domínios de retransmissão da Apple para forçar o encaminhamento local) e implementou o WiFi Analytics.
  • Resultados: As taxas de conclusão do portal passaram de 58% para 94%. A equipa de marketing monetizou o inventário do portal recuperado com campanhas de meios de retalho localizadas, gerando uma receita publicitária adicional de $120.000 por trimestre.

Recursos Relacionados

Para equipas de rede que implementam redes sem fios convidadas empresariais, estes recursos fornecem um contexto técnico mais aprofundado:

A plataforma de Guest WiFi da Purple serve espaços de hotelaria, retalho, saúde e transportes em todo o mundo, fornecendo experiências de login de convidados otimizadas para CNA em escala.

Definições Principais

Apple Captive Network Assistant (CNA)

Um daemon do sistema operativo iOS e macOS que sonda a conectividade à internet e inicia automaticamente um modal WebKit restrito (WebSheet) quando um captive portal é detetado.

Controla se a página de início de sessão aparece automaticamente nos iPhones ao ligarem-se ao WiFi de convidados.

URL de sondagem canário

Um endpoint HTTP leve (como http://captive.apple.com/hotspot-detect.html) solicitado pelos sistemas operativos dos clientes para verificar a acessibilidade irrestrita à internet.

Se a resposta da sonda for modificada ou redirecionada, o sistema operativo aciona o seu assistente de captive portal.

API de Captive Portal RFC 8908

Um protocolo padrão IETF que fornece um endpoint de API onde os dispositivos podem consultar o estado de catividade da rede, os termos do local e o tempo restante da sessão via JSON.

Substitui o sequestro de HTTP legado por uma deteção de rede cativa estruturada e criptograficamente segura.

Opção DHCP 114 (Captive-Portal)

Uma opção DHCP (RFC 8910) que transmite o URI da API de Captive Portal RFC 8908 para o dispositivo cliente durante a atribuição inicial de endereço de Camada 3.

Sinaliza a catividade ao iOS 14+ imediatamente durante a aquisição do IP, evitando a adulteração de DNS.

iCloud Private Relay

Um serviço de privacidade da Apple que encaminha o tráfego do Safari e o DNS não encriptado através de uma arquitetura de proxy encriptada de duplo salto.

Pode mascarar consultas DNS de pré-autenticação, a menos que a rede local emita um sinal explícito de deterioração de rede (NXDOMAIN).

Endereço WiFi privado (aleatorização MAC)

Uma funcionalidade de privacidade no iOS 14+ que gera um endereço MAC aleatório exclusivo por SSID para evitar a monitorização física entre diferentes locais.

Pode dessincronizar sessões de contabilidade RADIUS se os endereços MAC rodarem a meio da sessão ou durante a reautenticação.

Exemplos Práticos

Um hotel de luxo que implementou Cisco Catalyst 9800 WLCs constata que os utilizadores de iPhone convidados nunca recebem o ecrã de boas-vindas do captive portal ao ligarem-se ao SSID aberto Guest WiFi. Os computadores portáteis Android e Windows carregam o portal imediatamente. Como deve a equipa de rede diagnosticar e corrigir o problema de deteção de CNA da Apple?

  1. Inspecionar a ACL de redirecionamento pré-autenticação: Verifique se a ACL de redirecionamento do Cisco 9800 nega (ignora) o tráfego DNS UDP 53 e permite o tráfego HTTP TCP 80 para acionar o redirecionamento. 2. Verificar a lista de permissões de sondagem da Apple: Garanta que captive.apple.com NÃO está na lista de permissões do walled garden de pré-autenticação antes do redirecionamento; colocá-lo na lista de permissões faz com que o iOS pense que a internet está aberta, suprimindo o portal. 3. Verificar HTTP 302 vs 307: Configure o mapa de parâmetros webauth do WLC para retornar um redirecionamento HTTP 302 Found com o FQDN do portal. 4. Desativar a interceção de HTTPS: Garanta que o tráfego HTTPS na porta 443 é descartado ou rejeitado, em vez de ser sequestrado com um certificado não confiável. 5. Implementar a Opção DHCP 114: Adicione option 114 ascii https://app.purplewifi.net/api/v1/capport ao pool DHCP de convidados para deteção nativa de iOS 14 a 18.
Comentário do Examinador: Os dispositivos Apple dependem de uma correspondência estrita para o token Success de captive.apple.com. Se o domínio de sondagem for permitido prematuramente através do walled garden, o iOS assume falsamente que tem internet aberta e nunca irá acionar o WebSheet.

Um administrador de rede de um estádio observa que os utilizadores de iOS 17 e iOS 18 experienciam um ciclo infinito de início de sessão: a janela do CNA aparece, o utilizador aceita os termos e clica em Ligar, o modal fecha-se, mas 30 segundos depois o modal volta a abrir solicitando o início de sessão novamente. Qual é a causa raiz e a resolução?

  1. Rastreio de sessão RADIUS: No iOS 17/18, as Opções de Endereço Wi-Fi Privado utilizam endereços MAC rotativos, se configurados, ou o dispositivo pode renegociar o DHCP após fechar o modal. 2. Configuração de RADIUS CoA: Verifique se o controlador processa o Disconnect de Change of Authorization (CoA) do RADIUS RFC 3576 na porta UDP 3799, para que a ACL de pré-autenticação seja removida imediatamente após a autenticação. 3. Tempo limite de sessão e período de carência: Aumente o tempo limite da cache de bypass de autenticação MAC (MAB) para 1440 minutos (24 horas) com uma janela de carência de concessão de 15 minutos. 4. Ativos OAuth no Walled Garden: Verifique se todos os endpoints OAuth (Google, Apple, Microsoft) e tipos de letra/folhas de estilo estão no walled garden para que a sessão termine o carregamento completo antes de fechar o WebSheet.
Comentário do Examinador: Os ciclos de redirecionamento infinito resultam tipicamente de atrasos no RADIUS CoA onde o controlador ainda não atualizou o estado do cliente de pré-autenticação para pós-autenticação quando o iOS envia a sua sonda de verificação pós-início de sessão.

Perguntas de Prática

Q1. Porque é que a tentativa de redirecionar o tráfego HTTPS (porta 443) causa erros de Captive Portal em dispositivos iOS em vez de abrir a splash page?

Dica: Considere como a encriptação TLS, a verificação de certificados e o HSTS protegem o tráfego web.

Ver resposta modelo

O HTTPS estabelece um túnel TLS encriptado ponto a ponto entre o navegador do cliente e o servidor web de destino. Quando um gateway de rede sem fios tenta intercetar a porta 443 e apresentar um redirecionamento, o certificado SSL/TLS fornecido pelo gateway não corresponde ao nome de anfitrião solicitado (por exemplo, google.com ou apple.com). O iOS impõe o HTTP Strict Transport Security (HSTS), fazendo com que o Safari e o WebKit abortem a ligação com um aviso de segurança grave em vez de seguirem o redirecionamento.

Q2. Como deve uma rede de convidados empresarial lidar com o iCloud Private Relay para garantir um redirecionamento suave do Captive Portal em dispositivos iOS?

Dica: Reveja as diretrizes oficiais de rede da Apple relativas às respostas DNS para mask.icloud.com.

Ver resposta modelo

Os administradores de rede devem configurar os seus servidores DNS recursivos locais para devolverem uma resposta NXDOMAIN (ou uma falha de resolução DNS) para os nomes de domínio mask.icloud.com e mask-h2.icloud.com. Quando o iOS recebe uma resposta NXDOMAIN para estes domínios canário, exibe um alerta de sistema informando o utilizador de que a rede não suporta o Private Relay e reverte de forma limpa para o processamento padrão de DNS e sondas HTTP.

Q3. Qual é a vantagem de implementar a API de Captive Portal RFC 8908 em vez das técnicas tradicionais de desvio de DNS e HTTP?

Dica: Pense na clareza do protocolo, na sinalização de Camada 3 e na experiência do utilizador.

Ver resposta modelo

A RFC 8908 fornece uma API REST JSON padronizada comunicada através da Opção DHCP 114 ou de Router Advertisements IPv6. Em vez de intercetar o tráfego web do utilizador, o SO do cliente consulta a API diretamente via HTTPS para saber se a rede é cativa, obter o URL de início de sessão do portal, inspecionar a quota restante e receber uma notificação personalizada do local. Isto elimina os avisos de certificado SSL, suporta gestores de palavras-passe e preserva a integridade de segurança do navegador.

Perguntas frequentes

Why is my captive portal not popping up on iPhone?

Captive portals fail to pop up on iPhones when the Apple Captive Network Assistant (CNA) cannot complete its probe to http://captive.apple.com/hotspot-detect.html. Common causes include: 1) Pre-authentication firewalls blocking UDP port 53 DNS; 2) The network prematurely whitelisting captive.apple.com in the walled garden; 3) Gateways attempting HTTPS interception instead of HTTP 302 redirection; or 4) iCloud Private Relay interfering with DNS resolution.

How do I force the WiFi login screen to appear on iOS?

To manually trigger the captive portal on iPhone: 1) Open Safari and navigate to a plaintext HTTP URL such as http://captive.apple.com, http://neverssl.com, or http://1.1.1.1; 2) Go to Settings > Wi-Fi, tap the info (i) icon next to the network, and ensure Auto-Join and Auto-Login are toggled ON; 3) Turn Wi-Fi off and back on to trigger the CNA probe daemon.

What domains must be in the walled garden for Apple devices?

To support Apple iOS and macOS captive portal detection and assets, whitelist: captive.apple.com, www.airport.us, appleiphonecell.com, *.apple.com, *.purple.ai, *.purplewifi.net, and any third-party OAuth provider domains (e.g. accounts.google.com) or CDN assets used on the splash page.

How does RFC 8908 solve iOS captive portal issues?

RFC 8908 (Captive Portal API) and RFC 8910 (DHCP Option 114) pass the captive portal URL directly to iOS during the DHCP IP lease negotiation. This allows iOS 14+ to recognize network captivity instantly at Layer 3 without relying on fragile HTTP redirection or DNS hijacking.

How does MAC address randomisation affect captive portal authentication?

iOS Private Wi-Fi Addresses use unique MAC addresses per SSID. If the device rotates its MAC address or if session caching is tied strictly to physical MAC addresses without RADIUS accounting grace periods, the user may be forced to re-authenticate repeatedly. Configuring a 24-hour lease grace period and deploying Passpoint (Hotspot 2.0) resolves this issue.

Fontes

  1. Apple Developer Documentation - Captive Network Architecture and CNA
  2. Apple Support - Prepare Your Network for iCloud Private Relay
  3. IETF RFC 8908 - Captive Portal API Specification
  4. IETF RFC 8910 - Captive-Portal Identification in DHCP and Router Advertisements
  5. Wireless Broadband Alliance (WBA) - Captive Portal Standards and Best Practices
  6. Purple - Captive Portal Architecture & Troubleshooting Guide
  7. Purple - MAC Address Randomisation Impact Guide

Continue a ler esta série

Portal de convidados Ubiquiti UniFi não redireciona: causas e correções

Este guia isola uma falha de redirecionamento do portal de convidados UniFi ao seguir sequencialmente o estado do convidado, o redirecionamento, a rota de pré-autorização e a autorização do controlador. Oferece às equipas de TI dos recintos um método fundamentado para resolver a confusão entre rede de convidados e Hotspot, transições de portais externos, requisitos atuais de conta do UniFi OS e testes de isolamento de DNS.

Ler o guia →

Cisco Meraki splash page não funciona: um fluxograma de resolução de problemas

Este guia prático de segundo dia isola onde falhou um fluxo de splash do Cisco Meraki: autorização do cliente, início de redirecionamento HTTP, acessibilidade do walled garden ou início de sessão RADIUS. Oferece às equipas de TI dos locais um caminho de evidências controlado, para que possam restaurar o Guest WiFi sem efetuar alterações amplas numa infraestrutura ativa.

Ler o guia →

Guia de Configuração de WiFi para Visitantes Empresariais: Segmentação de VLAN, Segurança e Portais Cativos

Este guia técnico mostra às equipas de TI como configurar o WiFi para Visitantes como um serviço controlado de acesso à internet, utilizando segmentação de VLAN, política de firewall e um captive portal. Também explica como os formulários de registo e controlos de adesão do Purple apoiam uma experiência de visitante proporcional sem enfraquecer o limite em torno dos sistemas operacionais, de pagamento e dos funcionários.

Ler o guia →

Tem dúvidas sobre a sua configuração específica?

A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área o resolveram.