Solução de problemas do Captive Portal Cisco Meraki: checklist de splash page, walled garden e RADIUS

Um captive portal Meraki que falha geralmente apresenta um de quatro erros. O tipo de splash page está incorreto ou o walled garden não possui os domínios e recursos do portal. A transferência do URL de concessão (grant URL) pode estar corrompida ou os pontos de acesso não conseguem alcançar o RADIUS com um segredo compartilhado correspondente. O log de eventos da Meraki mostra qual erro você possui.

Como é a aparência de um captive portal Meraki que não está funcionando?

Três sintomas cobrem a maioria dos chamados de suporte. Cada um aponta para um elo diferente na cadeia de login.

• A splash page nunca aparece. O dispositivo conecta-se ao SSID e recebe um endereço IP, mas nenhuma tela de login é exibida.
• O portal entra em loop. O visitante preenche o formulário, toca em conectar e retorna para a página de login.
• O portal aceita os dados, mas nunca concede o acesso. A página informa sucesso, mas o dispositivo continua retido.

Um quarto sintoma é mais silencioso. Os visitantes que retornam precisam fazer login com muito mais frequência do que o esperado. Isso raramente é uma falha do portal. Geralmente é a configuração de frequência da splash page.

Antes de alterar qualquer coisa, confirme como a cadeia deve funcionar. Em uma implantação do Purple, o ponto de acesso Meraki redireciona o dispositivo para os servidores de splash page da Purple. A splash page coleta os dados do visitante e emite um login único. O ponto de acesso então passa esse login para o servidor RADIUS da Purple para concluir a autenticação. O artigo de suporte do captive portal do Purple descreve esse fluxo. Cada sintoma mapeia a falha em uma dessas três transferências.

Este guia pressupõe que o SSID já está criado. Ele complementa o guia de configuração do captive portal da Meraki e não repete as etapas de configuração.

O que geralmente faz com que uma splash page Meraki não apareça ou entre em loop?

O tipo de splash page não corresponde ao portal

A Meraki oferece opções de click-through, login com um servidor RADIUS e captive portal externo. O portal e o SSID devem esperar o mesmo método.

Um portal externo click-through libera o dispositivo chamando um URL de concessão. Um portal externo de login envia credenciais que o ponto de acesso verifica junto ao RADIUS. Se houver divergência entre o SSID e o portal, a transferência falha e o visitante entra em loop.

O walled garden está incompleto

O walled garden lista os destinos que um dispositivo pode acessar antes de se autenticar. A Meraki aceita entradas como domínios ou intervalos de IP. Se o próprio domínio do portal estiver ausente, a splash page não poderá ser carregada.

Recursos ausentes causam falhas mais sutis. Folhas de estilo, imagens, fontes, redes de distribuição de conteúdo (CDNs) e provedores de login social são carregados de seus próprios hosts. Se algum deles for bloqueado, a página será exibida com erros ou o botão de login não fará nada.

O walled garden também pode ser excessivamente permissivo. Os dispositivos executam um Assistente de Rede Captiva (CNA), que verifica um domínio predefinido para testar o acesso à internet. Se esse domínio de teste for alcançável antes do login, o dispositivo conclui que está online e nunca exibe a tela de login.

O URL de concessão (grant URL) ou URL de continuação (continue URL) foi perdido

Com um Captive Portal externo, o Meraki anexa parâmetros ao redirecionamento. Isso inclui uma URL de concessão base e a URL de continuação que o convidado solicitou originalmente. O portal deve enviar o dispositivo de volta para a URL de concessão para liberá-lo.

Se o portal perder, reescrever ou armazenar em cache esses parâmetros, o ponto de acesso nunca receberá a concessão. O convidado verá uma mensagem de sucesso, mas o próximo carregamento de página o redirecionará para a página de login novamente.

RADIUS está inacessível ou o segredo compartilhado está incorreto

O login com RADIUS depende dos pontos de acesso alcançarem o servidor RADIUS. O RADIUS é o protocolo Remote Authentication Dial-In User Service, definido na RFC 2865. O servidor trata cada remetente como um cliente RADIUS e verifica um segredo compartilhado a cada solicitação.

Dois erros predominam. Um firewall bloqueia o tráfego RADIUS vindo dos pontos de acesso, ou o segredo compartilhado difere entre o painel e o servidor. De qualquer forma, o portal coleta os dados, mas a autenticação nunca é concluída.

O modo NAT e o modo bridge alteram o que verificar

No modo NAT, o próprio ponto de acesso atribui os endereços dos clientes. Os dispositivos upstream veem o tráfego vindo do ponto de acesso, não do cliente. No modo bridge, os clientes recebem endereços do seu servidor DHCP na sua LAN ou VLAN.

O modo bridge adiciona pontos de falha que pertencem a você. Isso inclui um escopo DHCP esgotado, uma VLAN não conectada ao ponto de acesso e regras de DNS upstream ou de firewall que bloqueiam os hosts do portal.

Como descobrir qual é a causa?

Trabalhe a partir do cliente para fora. Teste com um dispositivo e esqueça a rede entre as tentativas para que cada teste comece do zero.

Sintoma	O que o log de eventos mostra	Causa mais provável	Primeira verificação
Nenhuma splash page aparece	Associação, mas sem redirecionamento da splash	Domínio de teste do CNA acessível, ou falha de DHCP ou DNS	Confirme se o dispositivo possui um IP e DNS, e depois abra neverssl.com
Splash page em branco ou sem formatação	Redirecionamento da splash, página incompleta	Walled garden sem os hosts de ativos	Ferramentas de desenvolvedor do navegador, listando cada host bloqueado
Loops após o envio	Redirecionamentos repetidos de splash, sem concessão	Parâmetros de URL de concessão perdidos, ou incompatibilidade do tipo de splash	Compare a query string de redirecionamento com o que o portal retorna
Mensagem de sucesso, sem internet	Tentativas de autenticação que falham ou expiram	RADIUS bloqueado ou incompatibilidade de segredo compartilhado	Logs do servidor RADIUS para solicitações vindas dos pontos de acesso
Convidados recorrentes solicitados novamente	Novos eventos de splash para dispositivos conhecidos	Frequência de splash muito curta	Configuração de frequência de splash no SSID
Aviso de certificado no desktop	Redirecionamento concluído	Página de login servida via HTTP	Certificado no host do portal

Lendo o log de eventos do Meraki

Abra o log de eventos de rede no painel do Meraki e filtre pelo endereço MAC do dispositivo de teste. Em seguida, filtre pelos tipos de eventos de splash e autenticação.

Leia os eventos em ordem cronológica: associação, atribuição de endereço, redirecionamento de splash, autenticação. O ponto onde a sequência para é onde está a falha. Nenhum evento de splash significa que o redirecionamento nunca foi acionado. Um evento de splash sem evento de autenticação aponta para o portal ou para a URL de concessão. Um evento de autenticação com falha aponta para o RADIUS.

Como resolver isso em redes Meraki MR e dispositivos de clientes?

Siga as etapas do fornecedor no artigo de suporte do Captive Portal da Purple. As correções abaixo informam o que alterar e o porquê.

Corrigir o jardim murado (walled garden)

Carregue a página de splash em um dispositivo fora da rede de convidados, com as ferramentas de desenvolvedor abertas. Registre todos os hosts que a página chama, incluindo provedores de login social. Adicione cada um ao jardim murado como um domínio ou intervalo de IP. Remova qualquer coisa que corresponda a um domínio de sondagem de CNA.

Corrigir a entrega da URL de concessão

Capture a URL de redirecionamento completa de um dispositivo com falha. Confirme se o portal retorna o dispositivo para a URL de concessão base com os parâmetros intactos. Verifique se nenhum proxy, encurtador de link ou cache está localizado entre o portal e o dispositivo.

Corrigir o RADIUS

Confirme se os pontos de acesso conseguem alcançar o servidor RADIUS nas portas configuradas. Insira novamente o segredo compartilhado em ambos os lados, a partir de uma única cópia, ao mesmo tempo. Em seguida, verifique o log do servidor para ver se há solicitações vindas dos endereços dos pontos de acesso.

Corrigir o comportamento do cliente

O Android exibe uma notificação "pode ser necessário fazer login" que abre o CNA. Alguns fabricantes de dispositivos alteram esse comportamento, portanto, teste nos modelos que seus convidados utilizam. Se um convidado perder o aviso, a Purple recomenda abrir um navegador e acessar neverssl.com. Esse site evita problemas de redirecionamento SSL porque nunca usa HTTPS.

Os navegadores de desktop alertam quando uma página de login é servida via HTTP simples. O artigo sobre certificado Cisco WLC da Purple aborda a falha equivalente em Cisco WLCs. A correção nesse caso é um certificado publicamente confiável cujo Common Name corresponda ao hostname do portal. O mesmo princípio se aplica a qualquer host de portal.

Outros fornecedores

A Purple é agnóstica em relação a hardware. As mesmas verificações se aplicam em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Apenas os nomes dos menus são diferentes.

Dois cenários práticos

Um hotel de 200 quartos após o redesign do portal

Situação. Um estabelecimento de hospitality no centro da cidade atualizou sua página de splash com novas fontes e um botão de login social. Depois disso, os hóspedes passaram a ver uma página em branco sem o botão de login.

O que foi feito. A equipe de TI carregou a nova página com as ferramentas de desenvolvedor abertas e encontrou dois hosts bloqueados. Um era uma rede de distribuição de fontes. O outro era o provedor de login social. Ambos foram adicionados ao jardim murado.

Resultado. A página foi renderizada completamente no teste seguinte. As reclamações na recepção sobre o acesso de convidados cessaram no mesmo dia.

Uma rede varejista de 40 lojas após uma alteração de firewall

Situação. Uma rede de varejo reforçou o firewall de sua matriz. Na manhã seguinte, os clientes em todas as lojas visualizavam a página de sucesso, mas não conseguiam navegar.

O que foi feito. O log de eventos mostrou tempo limite de autenticação (timeouts) esgotado em todos os locais. A nova regra havia bloqueado o tráfego RADIUS vindo dos pontos de acesso das lojas. A equipe restaurou a regra apenas para as portas RADIUS.

Resultado. Os eventos de autenticação voltaram ao normal em todas as 40 lojas em menos de uma hora após a alteração.

Como evitar que falhas no Captive Portal Meraki aconteçam novamente?

• Vincule o walled garden às alterações do portal. Cada mudança de design aciona uma revisão do walled garden antes do go-live.
• Mantenha o SSID aberto. A Purple recomenda uma rede aberta para o acesso de visitantes, pois a convenção é familiar e reduz o atrito.
• Rotacione segredos compartilhados em pares. Altere o dashboard e o servidor RADIUS em uma única janela de manutenção.
• Teste em quatro plataformas. Android, iOS, Windows e macOS lidam com o CNA de maneiras diferentes.
• Use um certificado confiável. Apresente a página de login via HTTPS com um certificado publicamente confiável.
• Separe a equipe dos visitantes. Os funcionários devem se autenticar por identidade, e não por meio de uma tela de splash para visitantes. Consulte Como Ativar o Single Sign On.

A Purple opera WiFi para visitantes em mais de 80.000 locais ativos e processou 440 milhões de logins em 2024 (dados próprios da Purple). A mesma lista de verificação se aplica a terminais de transporte que atendem passageiros e a locais de saúde que atendem pacientes e visitantes.

Perguntas frequentes

A Purple funciona com os meus pontos de acesso Cisco Meraki existentes?

Sim, a Purple funciona nos seus pontos de acesso Cisco Meraki MR existentes como uma sobreposição em nuvem. Você aponta a tela de splash do SSID para a Purple e configura os detalhes de RADIUS da Purple no dashboard Meraki. Nenhum hardware novo é necessário. O artigo de suporte do Captive Portal da Purple aborda as etapas de configuração. A mesma abordagem funciona em todo o restante de uma infraestrutura mista.

A Purple pode operar WiFi para visitantes em uma infraestrutura de múltiplos fabricantes?

Sim, a Purple é agnóstica em relação ao hardware e suporta Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Você gerencia uma única tela de splash e um único fluxo de login para todos os fabricantes, a partir de uma única plataforma. Isso é ideal para grupos que adquiriram locais com hardwares diferentes. Também atende a infraestruturas que planejam substituir os pontos de acesso gradualmente, em vez de fazer tudo em um único projeto.

O acesso de visitantes deve funcionar em um SSID aberto ou protegido?

A Purple recomenda um SSID aberto para o acesso de visitantes, pois este é o padrão atual e os visitantes o reconhecem. O Captive Portal gerencia a etapa de login, de modo que os visitantes não precisam de uma senha antes de se conectarem. Uma rede aberta reduz o atrito no momento da conexão. Mantenha os dispositivos dos funcionários em uma rede separada, baseada em identidade, em vez de compartilhar o SSID de visitantes.

Os dados dos visitantes capturados por meio da splash page estão em conformidade com o GDPR?

Sim, o Purple é certificado pelas normas ISO 27001 e Cyber Essentials, e opera em conformidade com o GDPR e a CCPA. Os visitantes dão consentimento de escolha consciente na splash page, de modo que o consentimento de marketing é explícito. Os dados coletados são dados primários, de propriedade da sua organização. O Purple também é uma B Corp certificada. Verifique se o seu próprio aviso de privacidade corresponde aos campos que sua splash page coleta.

Por que os navegadores de desktop mostram um aviso de certificado antes da página de login?

Os navegadores de desktop exibem um aviso quando o portal redireciona para uma página de login via HTTP simples. Os navegadores modernos esperam que as páginas de login usem HTTPS, por isso sinalizam a conexão como não privada. A solução é um certificado SSL/TLS publicamente confiável no host do portal. O Common Name do certificado deve corresponder ao hostname usado pelo redirecionamento. O aviso não bloqueia o acesso, mas desgasta a confiança do visitante.

Quem lida com a autenticação RADIUS quando o Purple executa o portal?

O servidor RADIUS do Purple conclui o login. A splash page emite um login único e o ponto de acesso Meraki o repassa para o servidor RADIUS do Purple. Você insere os detalhes do RADIUS do Purple e o shared secret no painel do Meraki. Seu firewall deve permitir que o tráfego RADIUS dos pontos de acesso chegue ao Purple. Se o shared secret for diferente em qualquer um dos lados, a autenticação falhará.

Quanto esforço é necessário para mudar da splash page do Meraki para o Purple?

A migração é uma mudança de configuração em cada SSID, não um projeto de hardware. Você altera o tipo de splash page, adiciona as entradas de walled garden e insere os detalhes de RADIUS do Purple. A maior parte do esforço é dedicada a testes no Android, iOS, Windows e macOS antes do lançamento oficial. Planeje um site piloto primeiro e depois distribua as configurações testadas para o restante do complexo.