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

A página de início de sessão do Android não aparece quando a verificação de conectividade da Google acede à internet antes do início de sessão, ou quando o seu redirecionamento é bloqueado. Mantenha o anfitrião de teste fora do seu walled garden, permita apenas domínios de splash page e de início de sessão, redirecione o teste HTTP para uma splash page HTTPS e defina um limite de tempo de sessão em Cisco Meraki, HPE Aruba ou Ubiquiti UniFi.

O que faz realmente o início de sessão do captive portal no Android?

Um captive portal é a splash page que um visitante vê antes de a rede conceder acesso à internet. Apresenta as opções de início de sessão que o convidado conclui antes de ficar online. O artigo de suporte da Purple sobre o captive portal descreve a sequência completa.

Todos os principais sistemas operativos incluem um Captive Network Assistant (CNA). O CNA é um pequeno navegador integrado que gere o portal para o convidado. No Android, o CNA tem quatro funções:

1. Verificar a conectividade à internet assim que o telemóvel se junta à rede.
2. Informar a pessoa que tem o telemóvel de que poderá ter de iniciar sessão.
3. Abrir uma sessão de navegador para a splash page quando esta toca na notificação.
4. Confirmar o estado online assim que o início de sessão for bem-sucedido.

Quando qualquer um destes passos falha, o convidado vê uma rede ligada que não funciona. Normalmente culpam o seu WiFi, não o seu telemóvel.

O teste de verificação de conectividade

Quando um telemóvel Android se junta a uma rede, envia um pedido HTTP simples para um ponto de extremidade de verificação de conectividade alojado pela Google. Esse ponto de extremidade devolve normalmente uma resposta HTTP 204 vazia. Se o telemóvel receber a resposta 204, conclui que a internet está acessível e não apresenta qualquer solicitação de início de sessão.

Numa rede de convidados, o seu controlador intercetará esse pedido antes do início de sessão e, em vez disso, devolverá um redirecionamento para a splash page. O telemóvel vê uma resposta inesperada e conclui que está atrás de um captive portal. Todo o processo de deteção depende de o teste ser intercetado e não de lhe ser permitida a passagem.

A notificação "Iniciar sessão na rede WiFi"

Assim que o teste falha, o Android apresenta uma notificação a informar o convidado de que poderá ter de iniciar sessão. Ao tocar nela, é iniciada a sessão do navegador CNA. Se o convidado descartar a notificação, o telemóvel permanece ligado sem acesso à internet. Para esse caso, a Purple recomenda abrir um navegador e visitar neverssl.com. Este site de terceiros permanece em HTTP simples, para que o controlador o possa redirecionar sem erros de certificado.

O que é a aplicação de início de sessão do captive portal no Android?

A aplicação de início de sessão do captive portal é o CNA do Android. É um navegador simplificado, sem barra de endereço ou extensões a sobrecarregar o ecrã. A documentação de suporte da Purple descreve-o como uma "tela em branco" que permite que o redirecionamento do captive portal seja concluído sem impedimentos. O Android original fecha a janela automaticamente assim que a autenticação é bem-sucedida. Alguns fabricantes de telemóveis alteram esse comportamento predefinido, pelo que nesses dispositivos o convidado poderá ter de fechar a janela manualmente.Por trás do ecrã, três sistemas funcionam em conjunto. O controlador gere a interação com os servidores da splash page da Purple. A splash page recolhe os dados do visitante e emite um início de sessão único. O controlador passa depois esse início de sessão para o servidor RADIUS da Purple, o serviço de autenticação que concede o acesso, para concluir o início de sessão.

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

As versões mais recentes do Android também conseguem detetar um portal sem necessidade de sondagem. A rede anuncia um endereço de API de Captive Portal através da opção DHCP 114, definida na RFC 8910. O DHCP é o serviço que distribui endereços IP. O telemóvel consulta essa API através de HTTPS e a resposta, definida na RFC 8908, indica se o dispositivo está cativo e onde se encontra o portal. Isto evita totalmente o truque de redirecionamento. Apenas funciona se o endpoint da API por trás da opção estiver ativo e corretamente certificado.

O que precisa antes de começar?

Reúna estes elementos 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 a aplicação UniFi Network.
• Um SSID de convidados aberto. A Purple recomenda a disponibilização de WiFi para convidados através de uma rede aberta. As redes abertas são agora a convenção padrão e reduzem a fricção para os visitantes.
• Uma VLAN de convidados dedicada. Uma VLAN é um segmento de rede lógico. O tráfego de convidados nunca deve partilhar um segmento com funcionários ou sistemas de pagamento, o que o mantém dentro das regras de âmbito do PCI-DSS.
• A lista de walled garden da Purple e o URL da splash page. Obtenha os valores atuais a partir do artigo de suporte do captive portal. Não os copie de uma implementação antiga.
• Detalhes de RADIUS para os servidores de autenticação da Purple, a partir da sua conta Purple.
• Dispositivos de teste. Utilize pelo menos três telemóveis Android de fabricantes diferentes, mais um iPhone para comparação.

A Purple é agnóstica em termos de hardware. Funciona como uma sobreposição na nuvem em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Configura o controlador que já possui, sem necessidade de substituir equipamentos.

Como configurar o início de sessão do captive portal no Android para Meraki, Aruba e UniFi?

Siga cinco definições por ordem. Cada uma corresponde a uma funcionalidade nomeada em cada plataforma. Para obter caminhos de menu exatos e valores atuais, consulte o artigo de suporte da Purple em vez deste resumo.

Passo 1: construir um walled garden restrito

O walled garden é a lista de domínios que um convidado pode aceder antes de iniciar sessão. Deve incluir os domínios da splash page da Purple e os domínios de qualquer início de sessão social que disponibilize. Não deve incluir o anfitrião de verificação de conectividade da Google.

O erro comum é usar um carácter universal amplo. Adicionar todos os domínios da Google para suportar o início de sessão com a Google também permite que a sonda do Android passe. O telemóvel recebe o seu código 204, decide que está online e nunca mostra a notificação. Defina o âmbito das entradas de início de sessão social da forma mais restrita que o fornecedor permitir. Se precisar do início de sessão com a Google e da deteção de Android em conjunto, teste ambos após cada alteração no walled garden.

Passo 2: bloquear tudo o resto até ao início de sessão

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

No Cisco Meraki, defina a força do Captive Portal para bloquear todo o acesso até ao início de sessão. No HPE Aruba, certifique-se de que a função de pré-autenticação nega tudo exceto o walled garden e o DNS. No Ubiquiti UniFi, confirme que 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: redirecionar HTTP e proteger a página de início de sessão com HTTPS

Os controladores não conseguem intercetar de forma limpa o tráfego HTTPS sem acionar erros de certificado. A sonda do Android utiliza HTTP simples, que o controlador pode redirecionar. Deixe a interceção HTTP da sonda ativa.

A página onde o convidado vai parar é outra questão. O artigo da Purple sobre a configuração de certificado do Captive Portal no Cisco WLC mostra o que acontece quando um controlador redireciona para um endereço de início de sessão HTTP não protegido. Os navegadores mostram um aviso do tipo "A sua ligaçã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 nome de anfitrião virtual do controlador deve corresponder ao Common Name do certificado. O mesmo princípio aplica-se aos controladores Aruba que alojam a sua própria página de início de sessão.

Passo 4: manter o DNS a funcionar para dispositivos não autenticados

Os convidados têm de resolver o nome de anfitrião da splash page antes de iniciarem sessão. Permita o DNS padrão para o resolvedor que escolheu na política de pré-autenticação. Sem isso, o redirecionamento aponta para um nome que o telemóvel não consegue procurar.

A definição de Private DNS do Android adiciona uma segunda consideração, abordada na secção de resolução de problemas abaixo.

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

O limite de tempo de sessão decide quanto tempo dura um início de sessão antes de o convidado ter de iniciar sessão novamente. Adapte-o ao tempo de permanência dos visitantes. Um café pode utilizar algumas horas. Um hotel deve cobrir a duração de uma estadia.

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

Anuncie apenas a opção 114 se existir um endpoint de API funcional e em conformidade com a RFC 8908 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 a certeza, deixe-o por definir. O Android recorre à sonda de conectividade, que os Passos 1 a 4 já suportam. Confirme com o suporte da Purple antes de ativá-lo.

Onde reside cada solução na sua plataforma

Solução	Cisco Meraki	HPE Aruba	Ubiquiti UniFi
Permitir domínios de splash e início de sessão antes do registo	Intervalos de walled garden nas definições de página splash do SSID	Lista branca de walled garden no perfil do captive portal ou função de pré-autenticação	Lista de permissões de pré-autorização no hotspot de convidados
Manter o host de teste (probe host) bloqueado	Remover wildcards genéricos da Google dos intervalos de walled garden	Remover wildcards genéricos da Google da lista branca	Remover wildcards genéricos da Google da lista de permissões
Bloquear todo o restante tráfego até ao registo	Força do captive portal: bloquear todo o acesso até ao registo	Função de pré-autenticação nega tudo exceto walled garden e DNS	Restrições da rede de convidados antes da autorização
Proteger a página de início de sessão	Redirecionar para o URL HTTPS da página splash da Purple	Certificado publicamente confiável no controlador	Redirecionar para o URL HTTPS da página splash da Purple
Duração da sessão	Frequência de splash e tempo limite de sessão RADIUS	Tempo limite 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 a montante	Escopo DHCP no controlador ou servidor a montante	Opção DHCP personalizada na rede de gateway UniFi

Como verificar se a página de início de sessão do Android funciona?

Teste sempre a partir de um estado limpo. Um telemóvel que se lembra da rede, ou que mantém uma sessão ativa, esconde o problema que está a tentar encontrar.

1. Esqueça a rede em cada telemóvel de teste e, em seguida, volte a ligar.
2. Aguarde pela notificação poucos segundos após a ligação. A ausência de notificação significa que o teste (probe) chegou à internet ou que o DNS falhou.
3. Toque nela e conclua o início de sessão. A página splash deve carregar sem avisos de certificado.
4. Confirme o comportamento da janela. No Android padrão (stock), esta fecha-se sozinha. Em compilações de alguns fabricantes, é necessário fechá-la manualmente, o que é esperado.
5. Navegue para um site HTTPS normal para confirmar o acesso total.
6. Repita com o DNS Privado definido como Estrito (Strict) num dos telemóveis, para saber o que os convidados que o utilizam irão ver.
7. Verifique os registos. Confirme a aceitação do RADIUS na Purple e o estado autorizado do cliente no controlador.

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

Porque é que a notificação de início de sessão na rede WiFi do Android não aparece e como resolver?

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

Sintoma	Causa provável	Correção
Ligado, sem notificação, sem internet	Teste (probe) permitido por uma entrada genérica de walled garden	Remover entradas genéricas wildcard da Google do walled garden
A notificação aparece, a página splash nunca carrega	DNS bloqueado antes do início de sessão, ou domínio de splash em falta no walled garden	Permitir DNS pré-autenticação; adicionar os domínios de splash da Purple
Aviso de certificado ou "não privado"	Página de início de sessão do controlador servida através de HTTP ou com um certificado não confiável	Instale um certificado confiável publicamente correspondente ao hostname
O início de sessão é bem-sucedido, a janela permanece aberta	O fabricante alterou o padrão da CNA	Feche a janela manualmente; não é necessária qualquer alteração na rede
O convidado deve iniciar sessão em todas as visitas	Novo endereço MAC aleatório ou tempo limite de sessão curto	Aumente o tempo limite; explique as definições de MAC aleatório
O convidado descartou a notificação	Sem aviso para recorrer	Abra um navegador e visite neverssl.com

O DNS privado quebra os portais cativos?

Pode quebrar. A definição de DNS privado do Android encripta as consultas de DNS utilizando DNS over TLS. Tem dois modos ativos que se comportam de forma diferente numa rede de convidados.

No modo Automático, o Android utiliza DNS encriptado quando a rede o suporta e recorre ao próprio DNS da rede quando não suporta. Os portais cativos carregam normalmente.

No modo Estrito, o convidado nomeia um hostname específico de um fornecedor de DNS. Antes do início de sessão, esse fornecedor está inacessível, porque a 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 acedido.

Não é viável adicionar todos os fornecedores públicos de DNS encriptado ao seu walled garden. A solução prática é a orientação do lado do convidado. Adicione uma linha à sua sinalética ou página de ajuda: altere o DNS privado para Automático, inicie sessão e depois volte a alterar.

Porque é que os telefones Android têm de iniciar sessão novamente em cada visita?

O Android utiliza um endereço MAC aleatório por rede, por padrão. Um endereço MAC é o identificador de hardware que o seu controlador utiliza para reconhecer um dispositivo. O endereço aleatório geralmente permanece estável para um SSID. Altera-se se o convidado esquecer a rede, repuser as definições de rede ou alterar a definição de privacidade. Para o seu controlador, esse telefone é então um dispositivo totalmente novo.

A segunda causa é o seu próprio tempo limite de sessão. Um tempo limite curto força um novo início de sessão sempre que a sessão expira, independentemente de quão estável o endereço MAC seja. Reveja ambos antes de assumir que a culpa é do telefone. Para locais onde os visitantes recorrentes são importantes, o OpenRoaming oferece uma ligação automática e segura sem splash page. Adequa-se a hubs de transportes e propriedades com vários locais.

Cenário prático 1: um hotel de 200 quartos com início de sessão Google

Cenário ilustrativo, valores apenas para fins ilustrativos.

Situação. Um hotel citadino de 200 quartos adicionou o início de sessão Google à sua splash page. No prazo de uma semana, a equipa da receção registou reclamações repetidas de convidados com Android. Os telefones mostravam sinal máximo, mas nenhuma página carregava e não aparecia nenhum aviso de início de sessão. Os convidados com iPhone comunicaram muito menos problemas. O que foi feito. A equipa de rede reviu o walled garden Meraki. Um prestador de serviços tinha adicionado um wildcard abrangente cobrindo todos os domínios da Google para suportar a nova opção de início de sessão. Essa entrada permitia a passagem do teste de conectividade do Android. A equipa substituiu o wildcard pelas entradas mais restritas listadas no artigo de suporte da Purple. Em seguida, testaram novamente em telemóveis de três fabricantes.

Resultado. Todos os telemóveis de teste apresentaram a notificação de início de sessão na primeira ligação. A receção não registou mais reclamações de Android WiFi nas duas semanas seguintes. O hotel também alargou o tempo limite da sessão para cobrir uma estadia típica de três noites. Isso eliminou os novos inícios de sessão diários para os hóspedes que regressavam. Veja como a Purple apoia os locais de hospitalidade.

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

Cenário ilustrativo, valores apenas para fins de ilustração.

Situação. Um município geria WiFi para convidados em 12 bibliotecas filiais em Ubiquiti UniFi. Os visitantes com telemóveis Android mais recentes reportavam um aviso de "Não é possível aceder ao servidor DNS privado" e uma página de captura que nunca carregava. O pessoal da filial perdia tempo a explicar definições que os visitantes não compreendiam.

O que foi feito. A equipa de TI confirmou que o DNS era permitido antes da autorização, pelo que as pesquisas padrão estavam a funcionar. Todos os telemóveis afetados tinham o DNS Privado definido como Strict com um fornecedor nomeado. A equipa adicionou uma instrução curta ao texto de ajuda da página de captura e aos cartazes da filial. Dizia aos visitantes para mudarem o DNS Privado para Automático, iniciarem sessão e depois voltarem a mudar. Também deixaram a opção DHCP 114 desativada, porque não existia nenhum endpoint de API em conformidade.

Resultado. O pessoal da filial relatou que a maioria dos visitantes afetados agora iniciava sessão sem ajuda utilizando as instruções do cartaz. Os pedidos de suporte para o suporte de TI central para o WiFi da biblioteca caíram para uns pozinhos por mês. Os locais do setor público partilham muitos dos mesmos padrões que os locais de transportes e saúde.

Quanto custa e qual é o retorno?

A maioria das correções de Captive Portal para Android custa tempo de equipa, não hardware. As entradas de walled garden, a intensidade do Captive Portal, os tempos limite de sessão e as regras de DNS são alterações de configuração no controlador que já possui. O principal custo direto é um certificado fidedigno público, nos casos em que o seu controlador aloja a sua própria página de início de sessão.

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, por isso peça à Purple uma cotação para o seu património.

O retorno é cada visitante Android que inicia sessão em vez de desistir. Cada início de sessão concluído é um convidado ligado, e no Capture e Engage é também dados primários recolhidos através de consentimentos por escolha consciente. Esses dados alimentam a análise de WiFi e as plataformas de CRM e marketing que já utiliza. Os próprios dados da Purple mostram 440 milhões de inícios de sessão em 2024 em mais de 80.000 locais ativos. A esta escala, uma falha de deteção num SSID de convidado é uma perda mensurável de visitantes ligados. Há também um custo que evita. Os visitantes que veem um aviso de certificado ou uma ligação sem rede julgam o seu espaço, não o telemóvel deles. Para marcas de retalho e hotelaria, essa primeira impressão acontece logo à porta.

Se os funcionários também precisarem de acesso juntamente com os convidados, execute-os num SSID separado com autenticação baseada em identidade. O artigo do blogue da Purple sobre Como Ativar o Single Sign-On aborda a ligação ao 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 já possuo?

Sim. A Purple é agnóstica em termos de hardware e funciona como uma sobreposição na nuvem em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Mantém os seus pontos de acesso e controlador existentes. Aponta o captive portal do SSID de convidados para a splash page da Purple, adiciona as entradas de walled garden do artigo de suporte da Purple e define o servidor RADIUS da Purple para autenticação. Não é necessária qualquer substituição de hardware.

O DNS Privado do Android interfere com os captive portals?

Pode interferir, 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 nome de anfitrião de fornecedor específico, o telemóvel pode não conseguir resolver a splash page antes do início de sessão, porque esse fornecedor está inacessível até que o convidado se autentique. A solução mais rápida é o convidado mudar para Automático, iniciar sessão e depois voltar a mudar. Coloque essa instrução na sua sinalética.

Porque é que os convidados com Android têm de iniciar sessão novamente em cada visita?

Geralmente porque o telemóvel apresenta um novo endereço MAC aleatório ou a sessão expirou. O Android torna o endereço MAC aleatório por rede, e esquecer a rede ou repor as definições produz um novo. O tempo limite da sua sessão também decide a duração de um início de sessão. Defina-o para corresponder ao padrão de visita, como uma estadia completa num hotel em vez de um único café. O OpenRoaming oferece ligação automática para visitantes frequentes.

Preciso de um certificado SSL para o meu captive portal?

Sim, para qualquer página de início de sessão que o seu controlador aloje. Os browsers modernos esperam HTTPS para páginas de início de sessão e avisam quando encontram uma ligação HTTP não segura, o que faz com que uma rede fiável pareça insegura. A orientação da Purple para controladores Cisco é um certificado publicamente confiável, com o nome de anfitrião virtual a corresponder ao Common Name do certificado. A verificação do Android ainda utiliza HTTP, pelo que a interceção continua a funcionar.

A minha rede WiFi de convidados deve ser aberta ou protegida por palavra-passe?

Aberta, com um captive portal. A Purple recomenda disponibilizar WiFi de convidados através de uma rede aberta porque é atualmente a convenção padrão e reduz a fricção para os visitantes. Tanto o Android como o iPhone detetam um captive portal num SSID aberto e solicitam ao convidado que inicie sessão. Mantenha o tráfego de convidados na sua própria VLAN. Execute o acesso de funcionários ou residentes num SSID separado com autenticação baseada em identidade.

Os dados recolhidos através do captive portal estão em conformidade com o GDPR?

Sim. O Purple possui as certificações GDPR, CCPA, ISO 27001 e Cyber Essentials. A splash page utiliza caixas de seleção de escolha consciente, para que cada convidado decida o que partilha e se deseja receber marketing. Os dados recolhidos são dados primários (first-party), recolhidos com consentimento no momento do início de sessão. O utilizador continua a definir o seu próprio aviso de privacidade e política de retenção, tal como acontece com quaisquer dados pessoais que controle.

Quanto tempo demora a resolver um problema de Captive Portal em Android?

A maioria das correções consiste numa única alteração de configuração no SSID de convidados, seguida de testes. As edições do walled garden, a robustez do Captive Portal, as regras de DNS e os limites de tempo de sessão não requerem hardware novo. Reserve a maior parte do seu tempo para testar em telemóveis Android de, pelo menos, três fabricantes a partir de um estado limpo. Algumas marcas alteram o comportamento da janela de início de sessão, e convém detetar isso antes que os seus visitantes o façam.

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

Parcialmente. As causas do lado do controlador são as mesmas em ambas as plataformas: o alcance do walled garden, DNS bloqueado, redirecionamentos HTTP e limites de tempo de sessão. As diferenças residem no dispositivo. O Android sonda um endpoint alojado pela Google, enquanto o iPhone sonda um endpoint da Apple. O Android também adiciona o comportamento de Private DNS e alterações de fabricantes à janela de início de sessão. O guia complementar do Purple sobre o Captive Portal para iPhone aborda o lado da Apple em detalhe.