Login no Captive Portal no Android: uma lista de verificação de implantação para Cisco Meraki, HPE Aruba e Ubiquiti UniFi

A página de login do Android não aparece quando a verificação de conectividade do Google alcança a internet antes do login, ou quando seu redirecionamento é bloqueado. Mantenha o host de teste fora do seu walled garden, permita apenas domínios de splash e login, redirecione o teste HTTP para uma página de splash HTTPS e configure um tempo limite de sessão no Cisco Meraki, HPE Aruba ou Ubiquiti UniFi.

O que o login do Captive Portal do Android realmente faz?

Um Captive Portal é a página de splash que um visitante vê antes que a rede conceda acesso à internet. Ele apresenta as opções de login que o visitante conclui antes de ficar online. O artigo de suporte da Purple sobre o Captive Portal descreve a sequência completa.

Todo sistema operacional principal inclui um Captive Network Assistant (CNA). O CNA é um pequeno navegador integrado que gerencia o portal para o visitante. No Android, o CNA tem quatro funções:

1. Verificar a conectividade com a internet assim que o telefone se conecta à rede.
2. Informar à pessoa com o telefone que ela pode precisar fazer login.
3. Abrir uma sessão de navegador para a página de splash quando ela tocar na notificação.
4. Confirmar o status online assim que o login for bem-sucedido.

Quando qualquer uma dessas etapas falha, o visitante vê uma rede conectada que não funciona. Geralmente, eles culpam o seu WiFi, e não o telefone deles.

O teste de verificação de conectividade

Quando um telefone Android se conecta a uma rede, ele envia uma solicitação HTTP simples para um endpoint de verificação de conectividade hospedado pelo Google. Esse endpoint normalmente retorna uma resposta HTTP 204 vazia. Se o telefone receber o 204, ele conclui que a internet está acessível e não exibe nenhuma solicitação de login.

Em uma rede de visitantes, seu controlador intercepta essa solicitação antes do login e retorna um redirecionamento para a página de splash. O telefone vê uma resposta inesperada e conclui que está atrás de um Captive Portal. Todo o processo de detecção depende de o teste ser interceptado, e não permitido.

A notificação "Fazer login na rede WiFi"

Assim que o teste falha, o Android exibe uma notificação informando ao visitante que ele pode precisar fazer login. Tocar nela inicia a sessão do navegador CNA. Se o visitante descartar a notificação, o telefone permanece conectado sem acesso à internet. Para esse caso, a Purple recomenda abrir um navegador e acessar neverssl.com. Este site de terceiros permanece em HTTP simples, para que o controlador possa redirecioná-lo sem erros de certificado.

O que é o aplicativo de login do Captive Portal no Android?

O aplicativo de login do Captive Portal é o CNA do Android. É um navegador simplificado, sem barra de endereços poluída ou extensões. A documentação de suporte da Purple o descreve como uma "tela em branco" que permite que o redirecionamento do Captive Portal ocorra sem impedimentos. O Android padrão fecha a janela automaticamente assim que a autenticação é bem-sucedida. Alguns fabricantes de dispositivos alteram esse padrão, portanto, nesses telefones, o visitante pode precisar fechar a janela manualmente.

Por trás da tela, três sistemas trabalham juntos. O controlador gerencia a interação com os servidores de splash page da Purple. A splash page coleta os dados do visitante e emite um login único. O controlador então passa esse login para o servidor RADIUS da Purple, o serviço de autenticação que concede o acesso, para concluir o login.

A API de Captive Portal e a opção DHCP 114

Versões mais recentes do Android também podem identificar um portal sem a necessidade de testes. A rede anuncia um endereço de API de Captive Portal por meio da opção DHCP 114, definida na RFC 8910. O DHCP é o serviço que distribui endereços IP. O telefone consulta essa API via HTTPS, e a resposta, definida na RFC 8908, diz se o dispositivo é cativo e onde o portal está localizado. Isso evita completamente o truque de redirecionamento. Só funciona se o endpoint da API por trás da opção estiver ativo e certificado corretamente.

O que você precisa antes de começar?

Reúna estes itens antes de mexer em qualquer ponto de acesso:

• Acesso de administrador ao seu controlador ou painel: Cisco Meraki Dashboard, HPE Aruba (Instant ou Central, ou um Mobility Controller) ou o aplicativo UniFi Network.
• Um SSID de visitante aberto. A Purple recomenda fornecer WiFi para visitantes em uma rede aberta. Redes abertas são agora a convenção padrão e reduzem o atrito para os visitantes.
• Uma VLAN dedicada para visitantes. Uma VLAN é um segmento lógico de rede. O tráfego de visitantes nunca deve compartilhar um segmento com funcionários ou sistemas de pagamento, o que mantém você dentro das regras de escopo do PCI-DSS.
• A lista de walled garden da Purple e a URL da splash page. Obtenha os valores atuais no artigo de suporte do captive portal. Não os copie de uma implantação antiga.
• Detalhes de RADIUS para os servidores de autenticação da Purple, obtidos na sua conta Purple.
• Aparelhos de teste. Use pelo menos três telefones Android de fabricantes diferentes, além de um iPhone para comparação.

A Purple é agnóstica em relação ao hardware. Ela roda como uma sobreposição em nuvem no Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Você configura o controlador que já possui, sem necessidade de substituição de hardware.

Como configurar o login do captive portal no Android para Meraki, Aruba e UniFi?

Trabalhe em cinco configurações em ordem. Cada uma delas mapeia para um recurso específico em cada plataforma. Para caminhos de menu exatos e valores atuais, siga o artigo de suporte da Purple em vez deste resumo.

Passo 1: construa um walled garden restrito

O walled garden é a lista de domínios que um visitante pode acessar antes do login. Ele deve incluir os domínios de splash page da Purple e os domínios de qualquer login social que você oferecer. Ele não deve incluir o host de verificação de conectividade do Google.O erro comum é um wildcard amplo. Adicionar todos os domínios do Google para dar suporte ao login do Google também permite a passagem da verificação do Android. O telefone recebe seu 204, decide que está online e nunca exibe a notificação. Defina o escopo das entradas de login social de forma tão restrita quanto o provedor permitir. Se você precisar do login do Google e da detecção do Android juntos, teste ambos após cada alteração no walled garden.

Passo 2: bloqueie todo o resto até a autenticação

O controlador deve interceptar todo o tráfego web de dispositivos não autenticados. Qualquer coisa deixada aberta oferece ao Android um caminho para um resultado "online" falso.

No Cisco Meraki, defina a intensidade do Captive Portal para bloquear todo o acesso até a autenticação. No HPE Aruba, certifique-se de que a função de pré-autenticação negue tudo, exceto o walled garden e o DNS. No Ubiquiti UniFi, confirme se a rede de convidados restringe todo o acesso antes da autorização, com exceção da lista de permissões de pré-autorização.

Passo 3: redirecione HTTP e proteja a página de login com HTTPS

Os controladores não conseguem interceptar de forma limpa o tráfego HTTPS sem gerar erros de certificado. A verificação do Android usa HTTP simples, que o controlador pode redirecionar. Deixe a interceptação de HTTP da verificação ativa.

A página em que o convidado chega é outra questão. O artigo da Purple sobre Cisco WLC captive portal certificate setup mostra o que acontece quando um controlador redireciona para um endereço de login HTTP não seguro. Os navegadores exibem um aviso do tipo "Sua conexão não é privada" e os convidados assumem que a rede não é segura. A solução é um certificado SSL/TLS publicamente confiável no controlador. O hostname virtual do controlador deve corresponder ao Common Name do certificado. O mesmo princípio se aplica aos controladores Aruba que hospedam sua própria página de login.

Passo 4: mantenha o DNS funcionando para dispositivos não autenticados

Os convidados precisam resolver o hostname da splash page antes de fazer o login. Permita o DNS padrão para o seu resolvedor escolhido na política de pré-autenticação. Sem isso, o redirecionamento aponta para um nome que o telefone não consegue consultar.

A configuração de Private DNS do Android traz uma segunda consideração, abordada na seção de solução de problemas abaixo.

Passo 5: defina um tempo limite de sessão adequado à visita

O tempo limite de sessão decide quanto tempo um login dura antes que o convidado precise se autenticar novamente. Combine-o com o tempo de permanência dos visitantes. Uma cafeteria pode usar algumas horas. Um hotel deve cobrir a duração de uma estadia.

Passo 6: decida sobre a opção DHCP 114

Anuncie a opção 114 apenas se um endpoint de API funcional e compatível com a RFC 8908 estiver por trás dela. Um valor que aponta para um endpoint que não responde corretamente adiciona um ponto de falha em vez de remover um. Se não tiver certeza, deixe desmarcado. O Android recorre à verificação de conectividade, que os Passos 1 a 4 já suportam. Confirme com o suporte da Purple antes de ativá-lo.

Onde cada correção reside na sua plataforma

Correção	Cisco Meraki	HPE Aruba	Ubiquiti UniFi
Permitir domínios de splash e login antes do login	Intervalos de walled garden nas configurações de página de splash do SSID	Lista de permissões do walled garden no perfil do captive portal ou função pré-auth	Lista de permissões de pré-autorização no hotspot de visitantes
Manter o host de teste (probe) bloqueado	Remover curingas amplos do Google dos intervalos do walled garden	Remover curingas amplos do Google da lista de permissões	Remover curingas amplos do Google da lista de permissões
Bloquear todo o tráfego restante até o login	Força do captive portal: bloquear todo o acesso até o login	Função pré-auth nega tudo exceto walled garden e DNS	Restrições de rede de visitantes antes da autorização
Proteger a página de login	Redirecionar para a URL da página de splash HTTPS da Purple	Certificado publicamente confiável no controlador	Redirecionar para a URL da página de splash HTTPS da Purple
Duração da sessão	Frequência de splash e timeout de sessão RADIUS	Timeout de sessão no captive portal ou perfil RADIUS	Expiração de autorização no hotspot
Opção DHCP 114	Opção DHCP personalizada no MX ou servidor DHCP upstream	Escopo DHCP no controlador ou servidor upstream	Opção DHCP personalizada na rede do gateway UniFi

Como verificar se a página de login do Android funciona?

Teste a partir de um estado limpo todas as vezes. Um telefone que se lembra da rede, ou mantém uma sessão ativa, esconde o problema que você está tentando encontrar.

1. Esqueça a rede em cada aparelho de teste e, em seguida, reconecte.
2. Fique atento à notificação dentro de alguns segundos após a conexão. Nenhuma notificação significa que o teste (probe) alcançou a internet ou que o DNS falhou.
3. Toque nela e conclua o login. A página de splash deve carregar sem avisos de certificado.
4. Confirme o comportamento da janela. No Android padrão ela se fecha sozinha. Em builds de alguns fabricantes você deve fechá-la manualmente, o que é esperado.
5. Navegue até um site HTTPS normal para confirmar o acesso total.
6. Repita com o DNS privado definido como Estrito em um aparelho, para saber o que os visitantes que o utilizam verão.
7. Verifique os logs. Confirme o aceite do RADIUS na Purple e o estado autorizado do cliente no controlador.

Teste em pelo menos três telefones Android de fabricantes diferentes. O iPhone usa um host de teste e CNA diferentes, abordados no guia complementar de captive portal para iPhone da Purple, mas as causas do lado do controlador são as mesmas. Uma única sessão de teste identifica problemas em ambas as plataformas.

Por que a notificação de login do Android na rede WiFi não aparece e como corrigir isso?

A maioria das falhas se deve a uma de cinco causas. Comece com o sintoma que o visitante relata.

Sintoma	Causa provável	Correção
Conectado, sem notificação, sem internet	Teste (probe) permitido por uma entrada ampla no walled garden	Remova as entradas curinga do Google do walled garden
A notificação aparece, a página de splash nunca carrega	DNS bloqueado antes do login, ou domínio de splash ausente do walled garden	Permita o DNS pré-auth; adicione os domínios de splash da Purple
Aviso de certificado ou "não privado"	Página de login do controlador servida via HTTP ou com um certificado não confiável	Instale um certificado publicamente confiável correspondente ao nome do host
Login bem-sucedido, a janela permanece aberta	O fabricante alterou o padrão do CNA	Feche a janela manualmente; nenhuma alteração de rede é necessária
O visitante deve fazer login a cada visita	Novo endereço MAC aleatório ou tempo limite de sessão curto	Aumente o tempo limite; explique as configurações de MAC aleatório
O visitante descartou a notificação	Sem solicitação para retornar	Abra um navegador e visite neverssl.com

O DNS privado quebra os Captive Portals?

Ele pode quebrar. A configuração de DNS privado do Android criptografa as consultas de DNS usando DNS over TLS. Ela possui dois modos ativos que se comportam de maneira diferente em uma rede de visitantes.

No modo Automático, o Android usa DNS criptografado quando a rede o suporta e recorre ao próprio DNS da rede quando não suporta. Os Captive Portals carregam normalmente.

No modo Estrito, o visitante nomeia o nome de host de um provedor de DNS específico. Antes do login, esse provedor fica inacessível porque sua política de pré-autenticação o bloqueia. O telefone pode não conseguir resolver a splash page, e o Android pode avisar que o servidor de DNS privado não pode ser acessado.

Você não pode adicionar de forma viável todos os provedores públicos de DNS criptografado ao seu walled garden. A correção prática é a orientação ao visitante. Adicione uma linha à sua sinalização ou página de ajuda: altere o DNS privado para Automático, faça login e depois altere de volta.

Por que os telefones Android precisam fazer login novamente a cada visita?

O Android usa um endereço MAC aleatório por rede por padrão. Um endereço MAC é o identificador de hardware que seu controlador usa para reconhecer um dispositivo. O endereço aleatório geralmente permanece estável para um SSID. Ele muda se o visitante esquecer a rede, redefinir as configurações de rede ou alterar a configuração de privacidade. Para o seu controlador, esse telefone passa a ser um dispositivo totalmente novo.

A segunda causa é o tempo limite da sua própria sessão. Um tempo limite curto força um novo login sempre que a sessão expira, por mais estável que o endereço MAC seja. Revise ambos os fatores antes de presumir que a falha é do telefone. Para locais onde os visitantes frequentes são importantes, o OpenRoaming oferece reconexão automática e segura sem uma splash page. É ideal para centros de transporte e propriedades com vários locais.

Cenário prático 1: um hotel de 200 quartos com login do Google

Cenário ilustrativo, números apenas para fins de demonstração.

Situação. Um hotel urbano de 200 quartos adicionou o login do Google à sua splash page. Em uma semana, a equipe da recepção registrou repetidas reclamações de visitantes com Android. Os telefones mostravam sinal cheio, mas nenhuma página carregava e nenhuma solicitação de login aparecia. Os visitantes com iPhone relataram muito menos problemas.

O que foi feito. A equipe de rede revisou o walled garden do Meraki. Um prestador de serviços havia adicionado um wildcard amplo cobrindo todos os domínios do Google para dar suporte à nova opção de login. Essa entrada permitia a passagem da verificação de conectividade do Android. A equipe substituiu o wildcard pelas entradas mais restritas listadas no artigo de suporte da Purple. Em seguida, realizaram novos testes em telefones de três fabricantes diferentes.

Resultado. Todos os aparelhos de teste exibiram a notificação de login na primeira conexão. A recepção não registrou mais nenhuma reclamação de WiFi no Android ao longo das duas semanas seguintes. O hotel também estendeu o tempo limite de sessão para cobrir uma estadia típica de três noites. Isso eliminou a necessidade de novos logins diários para os hóspedes frequentes. Veja como a Purple oferece suporte a estabelecimentos de hospitalidade.

Cenário prático 2: uma rede de biblioteca municipal no UniFi

Cenário ilustrativo, números apenas para fins de demonstração.

Situação. Um município operava WiFi para visitantes em 12 filiais de bibliotecas usando Ubiquiti UniFi. Visitantes com celulares Android mais recentes relataram um aviso de "Não é possível acessar o servidor DNS privado" e uma splash page que nunca carregava. A equipe da filial perdia tempo explicando configurações que os visitantes não entendiam.

O que foi feito. A equipe de TI confirmou que o DNS estava liberado antes da autorização, portanto, as consultas padrão estavam funcionando. Todos os telefones afetados tinham o DNS privado definido como Estrito com um provedor nomeado. A equipe adicionou uma instrução curta ao texto de ajuda da splash page e aos cartazes das filiais. Ela orientava os visitantes a alterar o DNS privado para Automático, fazer o login e, depois, reverter a alteração. Eles também deixaram a opção DHCP 114 desconfigurada, pois nenhum endpoint de API compatível estava implementado.

Resultado. A equipe das filiais relatou que a maioria dos visitantes afetados agora fazia o login sem ajuda seguindo as instruções dos cartazes. Os chamados de suporte para a equipe de TI central relacionados ao WiFi da biblioteca caíram para poucos casos por mês. Os locais do setor público compartilham muitos dos mesmos padrões que os setores de transporte e saúde.

Quanto custa e qual é o retorno?

A maioria das correções de Captive Portal no Android custa tempo de equipe, não hardware. Entradas de walled garden, robustez do Captive Portal, tempos limite de sessão e regras de DNS são alterações de configuração no controlador que você já opera. O principal custo direto é um certificado de confiança pública, nos casos em que seu controlador hospeda a própria página de login.

O Purple Guest WiFi está disponível em três planos: Connect, Capture e Engage. O preço depende do número de locais e do plano escolhido, portanto, solicite à Purple um orçamento para a sua infraestrutura.

O retorno é cada visitante Android que faz o login em vez de desistir. Cada login concluído é um visitante conectado e, no Capture e Engage, é também um dado primário coletado por meio de consentimento por escolha consciente. Esses dados alimentam a análise de WiFi e as plataformas de CRM e marketing que você já utiliza. Os próprios dados da Purple mostram 440 milhões de logins em 2024 em mais de 80.000 locais ativos. Nessa escala, uma falha de detecção em um SSID de visitantes representa uma perda mensurável de visitantes conectados.

Existe também um custo que você evita. Convidados que veem um aviso de certificado ou uma conexão inativa julgam o seu estabelecimento, não o telefone deles. Para marcas de varejo e hotelaria, essa primeira impressão acontece logo na porta.

Se a equipe também precisar de acesso junto com os convidados, execute-os em um SSID separado com autenticação baseada em identidade. O artigo do blog da Purple sobre Como habilitar o Single Sign-On aborda a conexão com Microsoft Entra ID, Okta e Google Workspace.

Perguntas frequentes

O Purple Guest WiFi funciona com os pontos de acesso Cisco Meraki, HPE Aruba ou Ubiquiti UniFi que eu já possuo?

Sim. A Purple é agnóstica em relação ao hardware e funciona como uma sobreposição em nuvem no Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Você mantém seus pontos de acesso e controladora existentes. Basta apontar o captive portal do SSID de convidados para a splash page da Purple, adicionar as entradas de walled garden do artigo de suporte da Purple e configurar o servidor RADIUS da Purple para autenticação. Não é necessário substituir nenhum equipamento.

O Android Private DNS quebra os captive portals?

Pode quebrar, no modo Estrito. No modo Automático, o Android recorre ao próprio DNS da rede, e o portal carrega normalmente. No modo Estrito com um hostname de provedor nomeado, o telefone pode não conseguir resolver a splash page antes do login, porque esse provedor fica inacessível até que o convidado se autentique. A correção mais rápida é o convidado mudar para Automático, fazer o login e depois voltar para o modo anterior. Coloque essa instrução na sua sinalização física.

Por que os convidados com Android precisam fazer login novamente a cada visita?

Geralmente porque o telefone apresenta um novo endereço MAC aleatório ou a sessão expirou. O Android randomiza o endereço MAC por rede, e esquecer a rede ou redefinir as configurações gera um novo. O tempo limite da sua sessão também determina quanto tempo dura um login. Configure-o para corresponder ao padrão de visita, como uma estadia completa em um hotel em vez de apenas o tempo de um café. O OpenRoaming oferece reconexão automática para visitantes que retornam.

Preciso de um certificado SSL para o meu captive portal?

Sim, para qualquer página de login que sua controladora hospede localmente. Os navegadores modernos exigem HTTPS para páginas de login e alertam quando encontram um link HTTP não seguro, o que faz uma rede confiável parecer insegura. A orientação da Purple para controladoras Cisco é um certificado publicamente confiável, com o hostname virtual correspondendo ao Common Name do certificado. A busca do Android ainda usa HTTP, por isso a interceptação continua funcionando.

Minha rede WiFi de convidados deve ser aberta ou protegida por senha?

Aberta, com um captive portal. A Purple recomenda fornecer WiFi de convidados em uma rede aberta porque essa é a convenção padrão atual e reduz a fricção para os visitantes. Tanto o Android quanto o iPhone detectam um captive portal em um SSID aberto e solicitam que o convidado faça o login. Mantenha o tráfego de convidados em sua própria VLAN. Execute o acesso da equipe ou de residentes em um SSID separado com autenticação baseada em identidade.

Os dados coletados por meio do captive portal estão em conformidade com a GDPR?

Sim. O Purple é certificado em conformidade com GDPR, CCPA, ISO 27001 e Cyber Essentials. A splash page utiliza opt-ins de escolha consciente, de modo que cada visitante decide o que compartilha e se deseja receber comunicações de marketing. Os dados que você coleta são dados primários (first-party data), obtidos com consentimento no momento do login. Você ainda define seu próprio aviso de privacidade e política de retenção, como ocorre com qualquer dado pessoal sob seu controle.

Quanto tempo leva para corrigir um problema de Captive Portal no Android?

A maioria das correções consiste em uma única alteração de configuração no SSID de visitantes, seguida de testes. Ajustes de walled garden, robustez do Captive Portal, regras de DNS e limites de tempo de sessão não exigem novos hardwares. Reserve a maior parte do seu tempo para testar telefones Android de pelo menos três fabricantes diferentes a partir do zero. Algumas marcas alteram o comportamento da janela de login, e você certamente prefere descobrir isso antes dos seus visitantes.

A correção para Android é diferente da correção de Captive Portal para iPhone?

Em partes. As causas relacionadas ao controlador são as mesmas em ambas as plataformas: escopo do walled garden, DNS bloqueado, redirecionamentos HTTP e limites de tempo de sessão. As diferenças estão no próprio dispositivo. O Android consulta um endpoint hospedado pelo Google, enquanto o iPhone consulta um da Apple. O Android também inclui comportamento de DNS Privado e alterações de fabricantes na janela de login. O guia complementar da Purple sobre Captive Portal para iPhone detalha a perspectiva da Apple minuciosamente.