Pular para o conteúdo principal
Português (Brasil)

Por que o seu captive portal não está carregando no iPhone: Corrigir erros do Apple CNA

Solucione problemas e corrija falhas de popup do captive portal no iPhone e iOS. Saiba como o Apple CNA, o iCloud Private Relay e a randomização de MAC quebram os logins de WiFi, e saiba como corrigi-los.

Por Tom HackettPublicado
📖 10 min de leitura1,883 palavras2 exemplos práticos3 questões práticas6 definições principais

Video overview

Ouça este guia

Ver transcrição do podcast
[Intro Music: Upbeat, modern electronic synth-pop with clean piano highlights, establishing a professional, tech-forward tone] **Host (Senior Consultant)**: Olá e boas-vindas ao Briefing Técnico da Purple. Eu sou o seu anfitrião e hoje vamos nos aprofundar em um dos problemas mais comuns - e sinceramente, mais frustrantes - enfrentados por administradores de rede, gerentes de TI e diretores de operações de locais de grande público atualmente. Todos nós já passamos por isso. Você passou semanas planejando, configurando e implantando uma rede WiFi para convidados de última geração para o seu hotel, shopping ou estádio. Você tem os pontos de acesso mais recentes, uma controladora robusta e uma linda splash page pronta para capturar dados de convidados e gerar engajamento. Mas então, os chamados de suporte começam a chegar. E todos dizem exatamente a mesma coisa: "Conectei ao WiFi de convidados no meu iPhone, mas a página de login não carrega." Para o convidado, o seu WiFi simplesmente não funciona. Mas para nós, como engenheiros e arquitetos de rede, sabemos que há uma batalha técnica complexa acontecendo nos bastidores do iOS. Hoje, vamos detalhar exatamente por que o seu Captive Portal não está carregando nos iPhones, como funciona a lógica de detecção em segundo plano da Apple e os caminhos de mitigação passo a passo que você pode implementar em sua rede neste trimestre. [Brief transitional musical swell] **Host**: Vamos começar com o aprofundamento técnico. Por que um iPhone se conecta ao WiFi de convidados mas falha em exibir a tela de login? Para entender isso, precisamos 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, ele não fica apenas esperando o usuário abrir um navegador. Em vez disso, um daemon de sistema em segundo plano envia imediatamente uma requisição HTTP GET simples para uma URL muito específica: `http://captive.apple.com/hotspot-detect.html`. Essa sonda em segundo plano usa um User-Agent de sistema exclusivo chamado `CaptiveNetworkSupport`. O daemon do CNA busca uma resposta muito específica. Se os servidores da Apple retornarem um código de status HTTP **200 OK** com um corpo contendo exatamente a palavra "Success", o iOS conclui que a rede tem acesso irrestrito à internet. Ele estabelece silenciosamente o WiFi como a interface de roteamento primária e o usuário segue com o seu dia. No entanto, se o seu gateway de rede interceptar essa requisição HTTP e retornar 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. Ele inicia instantaneamente o **Websheet app** nativo. Este é aquele painel modal deslizante familiar que exibe a sua página de login de convidados. Agora, aqui está a primeira grande armadilha de engenharia: **O Walled Garden**. Muitos engenheiros de rede cometem o erro de incluir os domínios de sucesso da Apple, como `captive.apple.com`, em suas listas de controle de acesso de pré-autenticação. Eles pensam: "Bem, é um domínio da Apple, devo deixá-lo passar." Mas se você o incluir na lista de permissões, a verificação em segundo plano chega com sucesso aos servidores da Apple, recebe a resposta de "Success" e o iOS assume que não há um Captive Portal. A Websheet nunca é acionada! Enquanto isso, o usuário é impedido de acessar qualquer outro site. 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 quanto aos recursos modernos de privacidade do iOS? Mesmo com um walled garden perfeito, recursos como o **iCloud Private Relay** e **Private MAC Addresses** estão mudando o jogo. Vamos falar sobre o iCloud Private Relay, introduzido no iOS 15. Esse recurso criptografa e roteia o tráfego de DNS e HTTP do Safari por meio de uma arquitetura proxy de salto duplo. Quando um usuário com o Private Relay ativo se conecta ao seu WiFi de convidados, a verificação HTTP em segundo plano é encapsulada dentro de um túnel criptografado. Como o gateway da sua rede não pode inspecionar ou interceptar esse pacote criptografado, ele não pode injetar o redirecionamento. A verificação falha silenciosamente e o iPhone simplesmente exibe um aviso de "Sem Conexão com a Internet". Sem portal, sem login, apenas fricção. Felizmente, existe uma mitigação programática em nível de rede para isso. A Apple projetou o Private Relay para respeitar bloqueios em nível de 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. Ele exibirá imediatamente um aviso do sistema perguntando ao usuário se ele deseja "Usar Sem Private Relay" para esta rede. No momento em que ele toca nessa opção, o túnel criptografado é contornado, a verificação HTTP é interceptada e o seu Captive Portal carrega perfeitamente. O próximo passo são os **Private MAC Addresses** e os novos **Rotating MAC Addresses** no iOS 18. Por padrão, os iPhones randomizam seu endereço MAC para cada SSID. No iOS 18, esse endereço gira periodicamente, mesmo enquanto conectado à mesma rede. Se a sua controladora sem fio rastreia 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 desconectado e forçado a fazer login novamente. Para mitigar isso, os locais corporativos devem se afastar do simples rastreamento baseado em MAC. Plataformas como a **Purple** resolvem isso inserindo um cookie seguro e persistente na sessão do navegador ou, melhor ainda, migrando os locais para o **Passpoint**, também conhecido como Hotspot 2.0. O Passpoint usa perfis seguros 802.1X para autenticar automaticamente e com segurança os convidados que retornam, sem nunca exibir uma tela de Captive Portal. É seguro, é contínuo e contorna completamente as limitações do CNA. [Breve aumento musical de transição] **Apresentador**: Agora, vamos falar sobre perfis de DNS personalizados e VPNs locais. Muitos usuários técnicos instalam perfis de DNS personalizados como NextDNS ou AdGuard que impõem DNS-over-HTTPS criptografado. Como esses perfis ignoram os servidores DNS locais atribuídos pelo DHCP, o seu gateway não consegue interceptar a consulta de DNS para `captive.apple.com`. Da mesma forma, perfis de VPN "Sempre Ativa" tentarão estabelecer um túnel criptografado no instante em que um IP for atribuído. Se a VPN tiver sucesso, ela ignora o seu redirecionamento; se for bloqueada, ela trava a conexão. Para esses usuários, o recurso manual definitivo é o truque do **neverssl.com**. Se um visitante estiver conectado ao seu WiFi, mas o Captive Portal não carregar, diga para ele abrir o Safari e digitar `neverssl.com` na barra de endereços. Como este domínio é estritamente HTTP não criptografado, o gateway certamente interceptará o tráfego da porta 80 e forçará o carregamento do redirecionamento, ignorando qualquer interferência de DNS personalizado ou VPN. [Efeito sonoro: Sinal sonoro de transição rápida] **Apresentador**: Vamos fazer uma sessão rápida de perguntas e respostas sobre as dúvidas mais comuns que recebemos das equipes de suporte dos locais. *Pergunta um: Por que meu iPhone mostra 'Sem Conexão com a Internet' em laranja embaixo do nome do WiFi?* **Resposta**: Isso significa que o iPhone concluiu a associação WiFi 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 êxito, geralmente devido ao iCloud Private Relay ou a uma VPN ativa. *Pergunta duas: Podemos simplesmente desativar o mini-navegador CNA inteiramente em nossa rede?* **Resposta**: Sim, a maioria dos controladores de LAN sem fio empresariais tem uma configuração chamada 'CNA Bypass' ou 'Captive Portal Bypass'. Quando ativado, o controlador simula a verificação de sucesso da Apple, informando ao iPhone que ele tem internet total. Isso evita que o Websheet apareça, mas depende de o usuário abrir manualmente o Safari para acionar o redirecionamento, o que às vezes pode criar ainda mais confusão para o usuário. *Pergunta três: O que é o problema de verificação pós-autenticação?* **Resposta**: Depois que o visitante faz o login, o CNA Websheet executa uma verificação secundária para verificar o acesso à internet. Se o seu gateway os redirecionar para uma landing page, mas continuar bloqueando os domínios de sucesso da Apple, o botão superior direito continuará travado em 'Cancelar'. Clicar em 'Cancelar' desconecta o usuário do WiFi. Você deve garantir que os domínios de sucesso da Apple estejam totalmente acessíveis após a autenticação. [Breve transição musical] **Apresentador**: Para encerrar, vamos analisar o impacto real nos negócios. Otimizar seu Captive Portal não se trata apenas de elegância técnica; trata-se do resultado final. Recentemente, trabalhamos com um grupo de resorts de luxo de 5 estrelas que estava enfrentando uma taxa de falha de 35% nas conexões de WiFi de convidados, gerando mais de 450 reclamações na recepção toda semana. Ao reestruturar o walled garden, bloquear domínios de Private Relay no nível de DNS para forçar o roteamento local e implantar a solução de **Guest WiFi da Purple**, eles viram os chamados de WiFi na recepção caírem **92%** em apenas 30 dias. Suas pontuações de satisfação dos hóspedes dispararam e eles capturaram milhares de perfis de hóspedes verificados. Se você deseja garantir que sua rede WiFi de convidados interaja perfeitamente com o Captive Network Assistant da Apple, ao mesmo tempo em que maximiza a captura de dados e minimiza os custos de suporte, acesse **purple.ai**. Nossa plataforma foi projetada para lidar com todas essas nuances específicas do iOS de forma nativa. Obrigado por ouvir este Informativo Técnico da Purple. Implemente estas estratégias de walled garden e DNS esta semana e veja seus chamados de suporte desaparecerem. Até a próxima, mantenha suas conexões seguras e o onboarding de seus convidados perfeito. [Música de Encerramento: Synth-pop eletrônico animado desaparece lentamente]

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

Resumo Executivo

A falha de login no Captive Portal em dispositivos iOS (iPhone e iPad) é uma das principais causas de reclamações de conexão WiFi de visitantes em ambientes de hospitalidade, varejo, saúde e corporativos. Quando um dispositivo iOS se associa a uma rede sem fio aberta ou autenticada por web, o daemon Captive Network Assistant (CNA) da Apple inicia uma série de testes de sondagem HTTP em segundo plano. Se esses testes forem bloqueados, mal direcionados ou interceptados incorretamente, a splash page do Captive Portal falha ao carregar, deixando o usuário sem acesso à internet e sem uma maneira óbvia de fazer o login.

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

Enfrentando problemas de abandono de WiFi de visitantes no iOS?

A plataforma de Guest WiFi gerenciada em nuvem do Purple lida com testes de sondagem do Apple CNA, iCloud Private Relay e randomização de MAC automaticamente - oferecendo uma integração perfeita de Captive Portal em todos os dispositivos iOS e Android.

Explore Purple Guest WiFi →

Análise Técnica Detalhada

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

Quando um iPhone se conecta a um ponto de acesso sem fio, a pilha de rede do iOS envia imediatamente um daemon chamado captivenetworkd. Esse daemon emite requisições HTTP GET simples para URLs de verificação predefinidas 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 status 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 operacional conclui que a rede fornece acesso irrestrito à internet. Nenhuma splash page é exibida.
  2. Resposta de Redirecionamento (HTTP 302 / 307): O gateway da rede intercepta a requisição HTTP da Porta 80 e redireciona o cliente para a URL do Captive Portal. O iOS reconhece o redirecionamento e inicia o CNA Websheet (uma janela de navegador modal especializada).
  3. Tempo Limite de Conexão ou Reinicialização: Se o gateway descartar os pacotes da Porta 80 ou falhar em responder às consultas DNS, a sondagem expira. O iOS exibe um aviso de "Sem Conexão com a Internet" abaixo do nome do SSID em Ajustes, mas falha em exibir a página de login.

Sondagem Pós-Autenticação (O Desafio do Botão "OK")

Depois que um usuário envia suas credenciais ou aceita os termos de serviço na splash page, o controlador de LAN sem fio (WLC) atualiza o estado da ACL do cliente para "autenticado". O daemon do CNA emite imediatamente uma sondagem HTTP de acompanhamento para captive.apple.com.

Se a segunda sondagem retornar HTTP 200 "Success", o botão no canto superior direito do CNA Websheet muda de "Cancelar" para "OK". Se a rede falhar em permitir o acesso HTTP fora de banda imediatamente após a autenticação, o botão permanece travado em "Cancelar" e tocá-lo pode desconectar completamente o dispositivo da rede WiFi.

-

Fatores de Interferência Específicos do iOS

1. Retransmissão Privada do iCloud

Introduzido no iOS 15, a Retransmissão Privada do iCloud é um serviço da Apple projetado para proteger a privacidade da navegação na web. Quando ativado, o tráfego do Safari e o tráfego HTTP não criptografado são criptografados e roteados através de duas retransmissões de Internet separadas:

[ iPhone ] === Criptografado QUIC/TLS ===> [ Proxy de Entrada da Apple ] ---> [ Proxy de Saída ] ---> [ Destino Web ]
  • O Problema: A Retransmissão Privada criptografa as requisições DNS via Oblivious DNS-over-HTTPS (ODoH) e canaliza o tráfego HTTP via QUIC (Porta UDP 443). Como os roteadores de gateway locais não podem inspecionar ou interceptar o tráfego QUIC criptografado, eles não conseguem injetar o redirecionamento HTTP 302 padrão.
  • Impacto: A sondagem HTTP inicial para captive.apple.com é canalizada para fora do gateway local, resultando em tempos limites de conexão e ausência de splash pages.

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 padrão. Em vez de usar 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 usuários autenticados têm permissão de acesso por 24 horas com base no endereço MAC), a rotação do MAC faz com que o gateway da rede visualize os dispositivos que retornam como clientes novos e não autenticados.
  • Impacto: Os usuários visualizam repetidamente a splash page do Captive Portal, resultando em uma experiência de usuário ruim e em chamados de suporte na recepção.

3. Perfis de DNS Criptografados (DoH / DoT)

Usuários com perfis de configuração iOS personalizados (como NextDNS, Cloudflare 1.1.1.1 ou configurações de DNS de MDM corporativo) transmitem todas as consultas de DNS por HTTPS criptografado (DoH) ou TLS (DoT) diretamente para resolvedores externos.

  • O Problema: O servidor DNS da rede local não consegue interceptar ou falsificar solicitações de DNS para captive.apple.com ou domínios inexistentes.
  • Impacto: A resolução de DNS inicial ignora completamente a controladora local, impedindo o acionamento do redirecionamento do portal.

Guia de Implementação e Mitigação

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

Para garantir a renderização confiável do Captive Portal no iOS, os engenheiros de rede devem configurar a Lista de Controle 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 acessem a infraestrutura e os recursos do portal Purple.
Interceptar HTTP (Porta TCP 80) para qualquer destino Intercepta 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 de Permissões captive.apple.com, www.apple.com NÃO deve ser colocado na lista de permissões. A liberação faz com que as sondagens tenham sucesso sem iniciar o portal.

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

  1. Configurar Interceptação de DNS: Defina o servidor DHCP para atribuir o endereço IP do gateway como o servidor DNS primário para clientes não autenticados.
  2. Configurar Sinalização do 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 (or NXDOMAIN)
    Quando o iOS recebe NXDOMAIN para esses hostnames, ele apresenta o aviso do sistema: "Esta rede bloqueia o iCloud Private Relay. Deseja usar esta rede sem o Private Relay?" Tocar em Usar Sem Private Relay restaura o redirecionamento padrão do portal.
  3. Configurar Tempo Limite da Sessão: Defina o tempo limite da sessão do gateway com base em pares de IP/MAC ou descarte 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 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.

Melhores Práticas e Padrões do Setor

O gerenciamento da integração de visitantes sem fio em escala exige a adesão aos padrões de rede modernos:

  • Transição para WPA3-Personal (OWE): Os portais de visitantes herdados funcionam em SSIDs abertos e não criptografados. Os locais corporativos devem adotar o Opportunistic Wireless Encryption (OWE) (IEEE 802.11aq) para fornecer criptografia individualizada sem senhas.
  • Conformidade com PCI DSS e GDPR: Os portais de visitantes devem isolar o tráfego de visitantes das redes de pagamento PCI DSS. Ao coletar detalhes de contato, os portais devem apresentar caixas de seleção de consentimento da GDPR explícitas e separadas - gerenciadas facilmente por meio de uma plataforma de WiFi Analytics.
  • Implantar Passpoint (Hotspot 2.0): Para eliminar totalmente a fricção do Captive Portal, os locais podem implantar o Passpoint (Hotspot 2.0). O Passpoint utiliza autenticação de estilo celular para conectar dispositivos iOS de forma segura e automática por meio de um perfil pré-instalado, ignorando completamente o daemon CNA.

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

Caminho de Autorreparação do Usuário Final

  1. Desativar o iCloud Private Relay para a Rede: Abra Ajustes > WiFi, toque no ícone (i) ao lado do nome da rede e desative a opção Limitar Rastreamento de Endereço IP.
  2. Desativar Endereço WiFi Privado: No mesmo menu de configurações de rede, desative a opção Endereço WiFi Privado se o acesso baseado em MAC for necessário.
  3. Forçar o Redirecionamento do Portal via Safari: Abra o Safari e insira o endereço HTTP simples: http://neverssl.com Como o neverssl.com não utiliza HTTPS, o roteador local interceptará a solicitação de forma confiável e carregará o portal.

Caminho de Diagnóstico do Engenheiro de Rede

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

Retorno sobre o Investimento (ROI) e Impacto no Negócio

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

Estudo de Caso de Hospitalidade: Grupo de Resorts Cinco Estrelas

  • Desafio: Um grupo de hotéis de luxo com 12 propriedades sofria com uma taxa de falha de conexão de WiFi de visitantes de 35%, gerando mais de 450 reclamações semanais na recepção.
  • Implementação: A equipe de TI reestruturou o seu jardim murado, desativou o rastreamento de sessão baseado em MAC e implantou a solução de Guest WiFi da Purple com tratamento otimizado de CNA.
  • Resultados: As reclamações relacionadas ao WiFi na recepção caíram 92% em 30 dias. As pontuações de satisfação do cliente (CSAT) aumentaram 18 pontos e o local capturou 40.000 novos endereços de e-mail verificados no primeiro trimestre.

Estudo de Caso de Varejo: Operadora Nacional de Shopping Centers

  • Desafio: Uma operadora de varejo com 45 shopping centers enfrentava dificuldades para impulsionar o engajamento dos visitantes porque o iCloud Private Relay impedia o carregamento do Captive Portal em 40% dos dispositivos iOS.
  • Implementação: Implementou o bloqueio do Private Relay a nível de rede (retornando NXDOMAIN para os domínios de retransmissão da Apple para forçar o roteamento local) e implantou o WiFi Analytics.
  • Resultados: As taxas de conclusão do portal saltaram de 58% para 94%. A equipe de marketing monetizou o inventário de portal recuperado com campanhas de mídia de varejo localizadas, gerando um valor adicional de $120.000 em receita de publicidade por trimestre.

Recursos Relacionados

Para equipes de rede que implantam redes sem fio para convidados corporativos, estes recursos oferecem um contexto técnico mais profundo:

A plataforma de Guest WiFi da Purple atende locais de hospitalidade, varejo, saúde e transporte em todo o mundo, oferecendo experiências de login de convidados otimizadas para CNA em escala.

Definições principais

Apple Captive Network Assistant (CNA)

Um daemon do sistema operacional iOS e macOS que realiza sondagens para verificar a conectividade com a internet e inicia automaticamente uma tela modal restrita do WebKit (WebSheet) quando um captive portal é detectado.

Controla se a página de splash de login aparece automaticamente nos iPhones ao se conectarem ao WiFi de convidados.

Canary probe URL

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

Se a resposta de sondagem for modificada ou redirecionada, o sistema operacional aciona seu manipulador de captive portal.

RFC 8908 Captive Portal API

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

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

DHCP Option 114 (Captive-Portal)

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

Sinaliza a restrição da rede ao iOS 14+ imediatamente durante a aquisição de IP, ignorando a adulteração de DNS.

iCloud Private Relay

Um serviço de privacidade da Apple que roteia o tráfego do Safari e o DNS não criptografado por meio de uma arquitetura de proxy criptografada de dois saltos.

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

Private WiFi address (randomização de MAC)

Um recurso de privacidade no iOS 14+ que gera um endereço MAC randomizado exclusivo por SSID para evitar o rastreamento físico entre locais.

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

Exemplos práticos

Um hotel de luxo que implementou Cisco Catalyst 9800 WLCs percebe que os hóspedes usuários de iPhone nunca recebem a tela de splash do captive portal ao se conectarem ao SSID de WiFi de Convidados aberto. Laptops Android e Windows carregam o portal imediatamente. Como a equipe de rede deve diagnosticar e corrigir o problema de detecção do Apple CNA?

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

Um administrador de rede de um estádio observa que usuários do iOS 17 e iOS 18 enfrentam um loop infinito de login: a tela do CNA aparece, o usuário aceita os termos e clica em Conectar, a tela se fecha, mas 30 segundos depois ela é reaberta solicitando o login novamente. Qual é a causa raiz e a solução?

  1. Rastreamento de sessão RADIUS: No iOS 17/18, os Endereços de Wi-Fi Privados utilizam endereços MAC rotativos, se configurados, ou o dispositivo pode renegociar o DHCP ao sair da tela modal. 2. Configuração de RADIUS CoA: Verifique se a controladora processa o RADIUS Change of Authorization (CoA) Disconnect do 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 do cache de desvio de autenticação MAC (MAB) para 1440 minutos (24 horas) com uma janela de carência de concessão de 15 minutos. 4. Ativos de OAuth do Walled Garden: Verifique se todos os endpoints de OAuth (Google, Apple, Microsoft) e fontes/folhas de estilo estão no walled garden para que a sessão termine de carregar completamente antes de fechar o WebSheet.
Comentário do examinador: Os loops de redirecionamento infinito geralmente se originam de atrasos de RADIUS CoA onde a controladora ainda não atualizou o estado do cliente de pré-autenticação para pós-autenticação quando o iOS envia sua sondagem de verificação pós-login.

Questões práticas

Q1. Por 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 criptografia TLS, a verificação de certificados e o HSTS protegem o tráfego da web.

Ver resposta modelo

O HTTPS estabelece um túnel TLS criptografado de ponta a ponta entre o navegador do cliente e o servidor web de destino. Quando um gateway de WiFi tenta interceptar a porta 443 e exibir um redirecionamento, o certificado SSL/TLS fornecido pelo gateway não corresponde ao nome de host 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 conexão com um aviso de segurança grave em vez de seguir o redirecionamento.

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

Dica: Revise as orientações de rede oficiais da Apple em relação às respostas de DNS para mask.icloud.com.

Ver resposta modelo

Os administradores de rede devem configurar seus servidores DNS recursivos locais para retornar 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 esses domínios canário, ele exibe um alerta do sistema informando ao usuário que a rede não suporta o Private Relay e reverte de forma limpa para o tratamento padrão de sondagem DNS e HTTP.

Q3. Qual é a vantagem de implantar o RFC 8908 Captive Portal API em relação às técnicas tradicionais de sequestro de DNS e HTTP?

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

Ver resposta modelo

O RFC 8908 fornece uma API REST JSON padronizada comunicada via DHCP Option 114 ou IPv6 Router Advertisements. Em vez de interceptar o tráfego web do usuário, o SO do cliente consulta a API diretamente via HTTPS para saber se a rede está em estado cativo, obter a URL de login do portal, inspecionar a cota restante e receber uma notificação personalizada do local. Isso elimina avisos de certificado SSL, suporta gerenciadores de senhas 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

Ubiquiti UniFi guest portal not redirecting: causes and fixes

Este guia isola uma falha de redirecionamento do portal de convidados UniFi seguindo a sequência do status do convidado, redirecionamento, rota de pré-autorização e autorização do controlador. Ele oferece às equipes de TI do local um método fundamentado para lidar com a confusão entre rede de convidados e Hotspot, redirecionamentos para portais externos, requisitos atuais de conta do UniFi OS e testes de isolamento de DNS.

Ler o guia →

Cisco Meraki splash page não está funcionando: um fluxograma de solução de problemas

Este guia prático do dia a dia isola onde um fluxo de splash da Cisco Meraki falhou: autorização do cliente, início de redirecionamento HTTP, acessibilidade do walled-garden ou sign-on RADIUS. Ele oferece às equipes de TI do local um caminho de evidências controlado, para que possam restaurar o Guest WiFi sem fazer alterações amplas em um ambiente ativo.

Ler o guia →

Guia de Configuração de WiFi para Visitantes Corporativos: Segmentação por VLAN, Segurança e Portais Captivos

Este guia técnico mostra às equipes de TI como configurar o WiFi para Visitantes como um serviço de acesso à internet controlado, usando segmentação por VLAN, política de firewall e um Captive Portal. Ele também explica como os formulários de registro e controles de integração do Purple oferecem suporte a uma experiência de visitante proporcional, sem enfraquecer o limite em torno dos sistemas operacionais, de pagamento e da equipe.

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 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.