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

Um captive portal Meraki que falha costuma ter uma de quatro falhas. O tipo de splash page está incorreto, ou o walled garden não tem os domínios e recursos do portal. A transferência do grant URL pode estar corrompida, ou os pontos de acesso não conseguem aceder ao RADIUS com um segredo partilhado correspondente. O registo de eventos Meraki mostra qual a falha que tem.

Qual é o aspeto de um captive portal Meraki que não está a funcionar?

Três sintomas cobrem a maioria dos pedidos de suporte. Cada um aponta para um elo diferente na cadeia de início de sessão.

• A splash page nunca aparece. O dispositivo junta-se ao SSID e obtém um endereço IP, mas nenhum aviso de início de sessão se abre.
• O portal entra em loop. O convidado preenche o formulário, toca em ligar e volta a cair na página de início de sessão.
• O portal aceita os dados mas nunca concede acesso. A página reporta sucesso, mas o dispositivo permanece cativo.

Um quarto sintoma é mais silencioso. É pedido aos convidados habituais que iniciem sessão com muito mais frequência do que o esperado. Isso raramente é uma falha do portal. Normalmente é a definição de frequência da splash page.

Antes de alterar qualquer coisa, confirme como deve funcionar a cadeia. Numa implementação Purple, o ponto de acesso Meraki redireciona o dispositivo para os servidores da splash page da Purple. A splash page recolhe os dados do convidado e emite um início de sessão único. O ponto de acesso passa então esse início de sessão para o servidor RADIUS da Purple para concluir a autenticação. O artigo de suporte do captive portal da Purple descreve este fluxo. Cada sintoma mapeia para uma falha numa 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 Meraki e não repete os passos de configuração.

O que costuma fazer 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, início de sessão com um servidor RADIUS e captive portal externo. O portal e o SSID devem esperar o mesmo método.

Um portal externo click-through liberta o dispositivo chamando um grant URL. Um portal externo de início de sessão envia credenciais, que o ponto de acesso verifica no RADIUS. Se o SSID e o portal não estiverem de acordo, a transferência falha e o convidado entra em loop.

O walled garden está incompleto

O walled garden lista os destinos que um dispositivo pode alcançar antes de se autenticar. A Meraki aceita entradas como domínios ou intervalos de IP. Se o próprio domínio do portal estiver em falta, a splash page não consegue sequer carregar.

Recursos em falta causam falhas mais subtis. Folhas de estilo, imagens, tipos de letra, redes de distribuição de conteúdos e fornecedores de início de sessão social carregam todos a partir dos seus próprios servidores. Se algum estiver bloqueado, a página aparece desconfigurada ou o botão de início de sessão não faz nada.

O walled garden também pode ser generoso demais. Os dispositivos executam um Captive Network Assistant (CNA), que verifica um domínio predefinido para testar o acesso à internet. Se esse domínio de teste for alcançável antes do início de sessão, o dispositivo conclui que está online. Depois, nunca mostra o aviso de início de sessão.

O grant URL ou continue URL perdeu-se

Com um Captive Portal externo, a Meraki anexa parâmetros ao redirecionamento. Estes incluem um URL de concessão base e o URL de continuação que o convidado solicitou originalmente. O portal deve enviar o dispositivo de volta para o URL de concessão para o libertar.

Se o portal perder, reescrever ou colocar em cache esses parâmetros, o ponto de acesso nunca recebe a concessão. O convidado vê uma mensagem de sucesso, e o carregamento da página seguinte redireciona-o novamente para a página de início de sessão.

O RADIUS está inacessível ou o segredo partilhado está incorreto

O início de sessão com RADIUS depende de os pontos de acesso conseguirem alcançar o servidor RADIUS. O RADIUS é o protocolo Remote Authentication Dial-In User Service, definido no RFC 2865. O servidor trata cada remetente como um cliente RADIUS e verifica um segredo partilhado em cada pedido.

Duas falhas predominam. Um firewall bloqueia o tráfego RADIUS dos pontos de acesso, ou o segredo partilhado difere entre o dashboard e o servidor. De qualquer forma, o portal recolhe os detalhes mas a autenticação nunca é concluída.

O modo NAT e o modo bridge alteram o que deve verificar

No modo NAT, o ponto de acesso atribui os endereços dos clientes por si próprio. Os dispositivos a montante veem o tráfego do ponto de acesso, não do cliente. No modo bridge, os clientes obtêm endereços do seu servidor DHCP na sua LAN ou VLAN.

O modo bridge adiciona pontos de falha que são da sua responsabilidade. Estes incluem um escopo DHCP esgotado, uma VLAN não ligada em trunk ao ponto de acesso, e regras de DNS ou firewall a montante que bloqueiam os hosts do portal.

Como descobrir qual é a causa que tem?

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

Sintoma	O que o registo de eventos mostra	Causa mais provável	Primeira verificação
Nenhuma splash page aparece	Associação, mas sem redirecionamento de splash	Domínio de sonda CNA acessível, ou falha de DHCP ou DNS	Confirme se o dispositivo tem um IP e DNS, depois abra o nuncassl.com
Splash page em branco ou sem estilo	Redirecionamento de splash, página incompleta	Walled garden sem os hosts de recursos	Ferramentas de programador do browser, liste todos os hosts bloqueados
Ciclo infinito após submissão	Redirecionamentos de splash repetidos, sem concessão	Parâmetros de URL de concessão perdidos, ou incompatibilidade de tipo de splash	Compare a query string de redirecionamento com o que o portal devolve
Mensagem de sucesso, sem internet	Tentativas de autenticação que falham ou expiram	RADIUS bloqueado ou incompatibilidade de segredo partilhado	Registos do servidor RADIUS para pedidos dos pontos de acesso
Convidados que regressam voltam a ver o prompt	Novos eventos de splash para dispositivos conhecidos	Frequência de splash demasiado curta	Definição de frequência de splash no SSID
Aviso de certificado no desktop	Redirecionamento concluído	Página de início de sessão servida através de HTTP	Certificado no host do portal

Ler o registo de eventos da Meraki

Abra o registo de eventos de rede no dashboard da Meraki e filtre pelo endereço MAC do dispositivo de teste. Depois, filtre pelos tipos de eventos de splash e autenticação.

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

Como corrigir isto em redes Meraki MR e dispositivos cliente?

Siga os passos do fabricante no artigo de suporte do Captive Portal da Purple. As correções abaixo indicam-lhe o que alterar e porquê.

Corrigir o walled garden

Carregue a splash page num dispositivo fora da rede de convidados, com as ferramentas de programador abertas. Registe todos os hosts que a página chama, incluindo fornecedores de login social. Adicione cada um deles ao walled garden como um domínio ou intervalo de IP. Remova tudo o que coincidir com um domínio de teste CNA.

Corrigir a entrega do URL de concessão

Registe o URL de redirecionamento completo de um dispositivo com falha. Confirme que o portal devolve o dispositivo ao URL de concessão base com os parâmetros intactos. Verifique se não existe nenhum proxy, encurtador de links ou cache entre o portal e o dispositivo.

Corrigir o RADIUS

Confirme que os pontos de acesso conseguem alcançar o servidor RADIUS nas portas configuradas. Reintroduza o segredo partilhado em ambos os lados, a partir de uma única cópia, ao mesmo tempo. De seguida, verifique o registo do servidor para ver se chegam pedidos a partir dos endereços dos pontos de acesso.

Corrigir o comportamento do cliente

O Android mostra uma notificação "poderá ter de iniciar sessão" que abre o CNA. Alguns fabricantes de telemóveis alteram este comportamento, pelo que deve testar nos modelos que os seus convidados utilizam. Se um convidado perder o aviso, a Purple recomenda abrir um navegador e visitar neverssl.com. Esse site evita problemas de redirecionamento SSL porque nunca utiliza HTTPS.

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

Outros fabricantes

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

Dois cenários práticos

Um hotel de 200 quartos após a reformulação do portal

Situação. Um espaço de hospitality no centro da cidade atualizou a sua splash page com novas fontes e um botão de login social. Depois disso, os convidados viram uma página em branco sem botão de login.

O que foi feito. A equipa de TI carregou a nova página com as ferramentas de programador abertas e encontrou dois hosts bloqueados. Um era uma rede de distribuição de fontes. O outro era o fornecedor de login social. Ambos foram adicionados ao walled garden.

Resultado. A página foi totalmente renderizada no teste seguinte. As reclamações na receção sobre o acesso de convidados pararam no próprio dia.

Uma cadeia de retalho com 40 lojas após uma alteração de firewall

Situação. Uma cadeia de retalho reforçou a firewall da sua sede. Na manhã seguinte, os clientes em todas as lojas viam a página de sucesso, mas não conseguiam navegar.

O que foi feito. O registo de eventos mostrou falhas por limite de tempo (timeouts) de autenticação em todos os locais. A nova regra tinha bloqueado o tráfego RADIUS a partir dos pontos de acesso das lojas. A equipa reverteu a regra apenas para as portas RADIUS.

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

Como evitar que as falhas do Captive Portal Meraki voltem a acontecer?

• Associe o walled garden às alterações do portal. Cada alteração de design aciona uma revisão do walled garden antes de entrar em produção.
• Mantenha o SSID aberto. A Purple recomenda uma rede aberta para o acesso de convidados, pois a convenção é familiar e reduz a fricção.
• Rode os segredos partilhados em pares. Altere o painel de controlo e o servidor RADIUS numa única janela de manutenção.
• Teste em quatro plataformas. O Android, iOS, Windows e macOS lidam com o CNA de forma diferente.
• Utilize um certificado fidedigno. Apresente a página de início de sessão através de HTTPS com um certificado publicamente fidedigno.
• Separe os colaboradores dos convidados. Os colaboradores devem autenticar-se por identidade e não através de uma splash page de convidados. Consulte How to Enable Single Sign On.

A Purple gere o Guest WiFi em mais de 80.000 locais ativos e processou 440 milhões de inícios de sessão em 2024 (dados próprios da Purple). A mesma lista de verificação aplica-se a centros de transportes que servem passageiros e a locais de saúde que servem doentes 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 na nuvem. Aponta a splash page do SSID para a Purple e configura os dados de RADIUS da Purple no painel de controlo da Meraki. Não é necessário hardware novo. O artigo de suporte do Captive Portal da Purple abrange os passos de configuração. A mesma abordagem funciona no resto de uma infraestrutura mista.

A Purple pode gerir Guest WiFi numa infraestrutura de vários fornecedores (mixed-vendor)?

Sim, a Purple é independente do hardware e suporta Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Gere uma única splash page e um único fluxo de início de sessão para todos os fornecedores, a partir de uma única plataforma. Isto adequa-se a grupos que adquiriram locais com hardware diferente. Também se adequa a infraestruturas que planeiam substituir pontos de acesso gradualmente, em vez de o fazer num único projeto.

O acesso de convidados deve funcionar num SSID aberto ou protegido?

La Purple recomenda um SSID aberto para o acesso de convidados, pois é agora a convenção padrão e os convidados reconhecem-na. O Captive Portal trata do passo de início de sessão, para que os convidados não precisem de uma palavra-passe antes de se ligarem. Uma rede aberta reduz a fricção no momento da ligação. Mantenha os dispositivos dos colaboradores numa rede separada, baseada em identidade, em vez de partilhar o SSID de convidados.

Os dados dos visitantes recolhidos através da splash page estão em conformidade com o GDPR?

Sim, a Purple possui certificação ISO 27001 e Cyber Essentials, e opera em conformidade com o GDPR e a CCPA. Os visitantes dão o seu consentimento de forma consciente na splash page, garantindo que o consentimento de marketing é explícito. Os dados recolhidos são dados primários (first-party data), pertencentes à sua organização. A Purple é também uma B Corp certificada. Certifique-se de que a sua política de privacidade corresponde aos campos recolhidos na sua splash page.

Porque é que os browsers de desktop mostram um aviso de certificado antes da página de início de sessão?

Os browsers de desktop mostram um aviso quando o portal redireciona para uma página de início de sessão através de HTTP simples. Os browsers modernos exigem que as páginas de início de sessão utilizem HTTPS, pelo que sinalizam a ligação como não privada. A solução é utilizar um certificado SSL/TLS publicamente fidedigno no host do portal. O Common Name do certificado deve corresponder ao hostname utilizado no redirecionamento. O aviso não bloqueia o acesso, mas prejudica a confiança do visitante.

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

O servidor RADIUS da Purple conclui o início de sessão. A splash page emite um início de sessão único e o ponto de acesso Meraki envia-o para o servidor RADIUS da Purple. Deve introduzir os dados do RADIUS da Purple e o segredo partilhado no painel da Meraki. O seu firewall deve permitir que o tráfego RADIUS dos pontos de acesso chegue à Purple. Se o segredo partilhado for diferente em qualquer um dos lados, a autenticação falhará.

Quanto esforço é necessário para migrar da splash page da Meraki para a Purple?

A migração resume-se a uma alteração de configuração em cada SSID, não sendo um projeto de hardware. Altera o tipo de splash page, adiciona as entradas de walled garden e introduz os dados de RADIUS da Purple. O maior esforço reside nos testes em Android, iOS, Windows e macOS antes da entrada em funcionamento. Planeie primeiro um site piloto e, em seguida, aplique as configurações testadas ao resto do parque de equipamentos.