Cisco Meraki splash page não está funcionando: um fluxograma de diagnóstico de problemas

As splash pages do Cisco Meraki param de aparecer quando um cliente ainda está autorizado, não consegue emitir a requisição HTTP que aciona o redirecionamento, não consegue alcançar uma dependência splash permitida ou não consegue concluir a autenticação RADIUS. Comece com um cliente afetado, filtre os registros de Auth, DHCP e RADIUS pelo seu endereço MAC e, em seguida, teste o ramo relevante abaixo. 1 2 3 5

O que ainda deve funcionar para que uma splash page do Meraki apareça?

Trate um Captive Portal como uma cadeia curta, não como uma única página web. Um dispositivo deve se associar ao SSID correto, receber endereçamento válido, ser classificado como não autorizado, enviar tráfego que possa iniciar o fluxo de splash, alcançar o serviço hospedado necessário e, em seguida, receber autorização. A Cisco Meraki descreve o gatilho como um HTTP GET de um cliente não autorizado. O AP intercepta essa requisição e retorna um redirecionamento HTTP 307 para a URL de splash. 1

Isso explica uma chamada de suporte comum: um visitante consegue se conectar ao seu Guest WiFi, mas diz que a splash page não está carregando. O ponto de acesso pode estar funcionando conforme o esperado. Se o dispositivo abrir um destino exclusivamente HTTPS primeiro, a requisição criptografada não poderá ser redirecionada. A Cisco Meraki identifica especificamente isso como um cenário de timeout do navegador. Teste o ramo de HTTP controlado antes de alterar o SSID, o design da página ou o servidor RADIUS. 2

A mesma disciplina evita um segundo erro comum: tratar cada solicitação repetida como uma falha de página. A frequência do splash é uma política de autorização. A Cisco Meraki mantém o estado do splash no ponto de acesso gateway e no controlador de nuvem, enquanto o navegador retém um cookie de sessão. Um cliente com um período de autorização válido pode não ver a página novamente depois que você encurtar a frequência configurada. Por outro lado, um cliente com cookies desativados ou limpos pode parecer receber a solicitação com muita frequência. 2

O que você deve capturar antes de alterar qualquer coisa?

Comece com um único relatório reproduzível. Registre o endereço MAC do cliente, o SSID, o ponto de acesso do gateway ou MX, o tipo de dispositivo, a hora local, o navegador e se o dispositivo já havia concluído a autenticação do splash anteriormente. Peça ao relator para deixar o dispositivo conectado enquanto você o inspeciona. Isso fornece um limite para o incidente e evita que um hotel, loja de varejo ou local de eventos movimentado transforme uma reclamação geral em alterações de configuração às cegas.

Abra os detalhes do cliente e verifique se ele está autorizado. O Cisco Meraki identifica um cliente não autorizado como Splash: Not authorized; um cliente autorizado mostra o tempo de autorização restante. Não use uma guia de navegador salva como teste. Isso pode misturar uma sessão passada com o estado atual de rádio e DHCP. 1

Em seguida, filtre o registro de eventos do Dashboard pelo endereço MAC do cliente e a hora do incidente. Para pontos de acesso MR, o tipo de evento Auth representa a autenticação da página splash. 802.11 mostra associação e desassociação, DHCP carrega eventos relacionados à concessão e RADIUS identifica a atividade de bypass de autenticação RADIUS ou MAC. O mesmo filtro Auth está disponível para a autenticação splash do MX. O Cisco Meraki observa que os dispositivos carregam eventos armazenados após retornarem online, mantendo os carimbos de data/hora originais, portanto, alinhe o fuso horário antes de decidir o que aconteceu primeiro. 5

Use o registro ordenado a seguir. Ele reduz o domínio de falha sem adivinhações.

Como executar o fluxograma de solução de problemas?

Use o fluxograma uma vez para um cliente de teste limpo e outra para um cliente que sabidamente apresenta o problema. A diferença é útil. Se um cliente limpo alcança a página de login e o dispositivo conhecido não, você tem evidências de autorização, estado do navegador ou política específica do cliente, em vez de uma queda em todo o local.

1. Confirme a associação e o endereçamento. Se o registro de eventos não mostrar o cliente se associando ao SSID pretendido, não solucione problemas da tela de login. Se ele se associar, mas os registros de DHCP mostrarem um erro, corrija o endereçamento ou o caminho da VLAN primeiro. O Cisco Meraki identifica a marcação de VLAN no SSID ou na porta do switch upstream como uma área comum de falha de DHCP. 6

2. Confirme que o cliente não está autorizado. Um dispositivo previamente autorizado pode não exigir outra página de login ainda. O Cisco Meraki documenta uma função de revogação de autorização de cliente para testes controlados. Use isso no dispositivo indicado, em vez de alterar a frequência da tela de login para todos os usuários do local. 2 3

3. Teste o gatilho com HTTP. Limpe o cache do navegador apenas onde isso se ajustar ao seu procedimento de teste, confirme se os cookies estão ativados e, em seguida, abra um destino HTTP. O Cisco Meraki informa que uma solicitação HTTPS-first não pode ser redirecionada porque o tráfego é criptografado. Se o teste HTTP funcionar, documente o comportamento do cliente como a causa. A rede não perdeu o redirecionamento da sua tela de login. 1 2

4. Teste a acessibilidade da página e o walled garden. Um walled garden permite endereços IP, intervalos ou nomes de host específicos antes da autenticação na tela de login, incluindo domínios curinga. Se você usar uma URL de Captive Portal personalizada, o Cisco Meraki informa que o endereço IP e/ou URL da página personalizada deve estar no walled garden. Quando a página depende de endpoints de ativos, identidade ou serviços separados, revise cada destino necessário com o proprietário do serviço. Não adivinhe endereços IP nem adicione acesso amplo à internet como um atalho. 3

As páginas Purple tornam essa distinção clara. Uma página de login offline aparece antes do login e não pode incluir links ou recursos externos porque o visitante está no walled garden. Uma página online aparece após o login bem-sucedido e pode conter mídias ou links externos. Se uma página HTML offline do Purple perdeu uma imagem, folha de estilo, script ou elemento de identidade de terceiros após uma alteração, compare essas dependências com as entradas permitidas de pré-autenticação antes de alterar o design. 7 8

1. Teste o RADIUS de autenticação apenas após o carregamento da página. O RADIUS, protocolo usado aqui para solicitações de autenticação central, não é o primeiro suspeito quando nenhuma tela de login aparece. Ele se torna relevante quando o formulário de login é carregado, mas a autenticação falha ou expira. Para este fluxo do Cisco Meraki, a nuvem do Dashboard origina a solicitação de acesso RADIUS, e não o AP ou MX local. O servidor precisa de acessibilidade pública a partir dos intervalos de origem documentados do Dashboard, uma chave secreta compartilhada correspondente e suporte para PAP. O Cisco Meraki afirma que o RADSec não é compatível com a autenticação de tela de login. 4 6. Execute o teste de RADIUS suportado e examine o registro do servidor. A Cisco Meraki fornece um teste de RADIUS no Dashboard para a configuração sem fio documentada, embora o botão de teste não exista para redes das séries MX ou Z. Um tempo limite (timeout) significa que você deve verificar as informações atuais do firewall do Dashboard, entradas de clientes RADIUS, capacidade de alcance do host público, alinhamento do segredo compartilhado e comportamento da política. O teste de integridade da Cisco Meraki envia solicitações de acesso periódicas e trata o servidor como inacessível após seis tentativas sem resposta, com intervalo de 20 segundos entre elas. 4

Como isolar os pontos de falha comuns?

A frequência da tela de splash parece incorreta

Se a Captive Portal (tela de splash) aparecer com menos frequência do que a política sugere, verifique se o cliente já estava autorizado quando a frequência foi alterada. A Cisco Meraki afirma que o período de autorização existente permanece em vigor. Revogar a autorização do cliente selecionado cria um teste válido da configuração atualizada. Se a página aparecer com mais frequência, verifique a aceitação de cookies do navegador, a limpeza do cache e a continuidade do ponto de acesso do gateway. A reinicialização do gateway pode exigir autenticação novamente, a menos que o navegador possa apresentar seu cookie. 2

Isso é importante no setor de hospitalidade. Um hotel de exemplo com 200 quartos deve testar com um celular controlado após uma alteração e, em seguida, medir o resultado como três desfechos simples: o cliente passa para autorizado, recebe a expiração esperada e a próxima requisição HTTP limpa se comporta como pretendido. Essa é uma homologação melhor do que perguntar à recepção se as reclamações pararam.

O WiFi de visitantes não está redirecionando

Não afirme que o HTTPS "quebrou" os portais cativos. O comportamento documentado da Cisco Meraki é mais restrito: o mecanismo de redirecionamento funciona em um HTTP GET não autorizado, enquanto uma requisição prioritária em HTTPS não pode ser redirecionada. Dispositivos modernos podem iniciar seu fluxo de detecção de Captive Portal do sistema operacional na associação. Se esse prompt não aparecer, use o teste HTTP para estabelecer se a ramificação da rede funciona. 1 2

Para uma implantação de varejo ilustrativa, a equipe de TI de uma loja pode reproduzir a reclamação com um dispositivo de teste da equipe no SSID da área de vendas. A evidência de aceitação não é uma alegação vaga de carregamento de página. Capture o registro de associação, o endereço válido, o estado não autorizado, o evento de Auth após o teste HTTP e o estado de autorização resultante. Esse registro pode ser comparado entre lojas sem expor as credenciais dos visitantes.

O jardim murado (walled garden) está incompleto

Um jardim murado (walled garden) é um acesso intencionalmente limitado antes da autorização. Ele não deve se tornar uma lista de desvio. Revise primeiro o host de splash e, em seguida, as dependências que sua página de pré-autenticação realmente precisa. A Cisco Meraki permite endereços IP, faixas de IP e nomes de host, com domínios curinga (wildcard). A Cisco também exige uma URL de Captive Portal customizada ou endereço IP no jardim murado (walled garden) quando esse recurso está ativado. 3

Uma página offline do Purple é a etapa mais restrita. O Purple afirma que não pode usar links ou recursos externos enquanto o visitante estiver no walled garden. O editor HTML permite que sua equipe envie ativos para o portal e visualize a página atual, o que pode reduzir dependências remotas desnecessárias. Siga as etapas publicadas pelo Purple antes de publicar um modelo editado. 7 8

O splash de login expira ou rejeita as credenciais

Separe a rejeição do tempo limite (timeout). Uma rejeição é um resultado de autenticação ou política. Um tempo limite ou mensagem de "dificuldade de conexão" aponta primeiro para a capacidade de alcance entre o Dashboard e o servidor RADIUS configurado. A Cisco Meraki documenta que as solicitações de splash de login se originam na nuvem do Dashboard e não podem usar um endereço de LAN privada para o servidor RADIUS. 4

Confirme se o servidor espera PAP para este modo de splash, se os intervalos de origem documentados do Dashboard são permitidos, se todos os IPs de origem relevantes estão configurados como clientes RADIUS e se o segredo compartilhado coincide em ambas as extremidades. A Cisco Meraki também afirma que a integração externa do splash deve usar o login_url fornecido sem modificações, e o filtro deve permitir seu hostname variável em vez de um único padrão fixo. 4

O que os eventos de splash da Meraki no registro de eventos significam?

Leia o registro como uma linha do tempo. 802.11 association significa que o cliente se conectou a um AP. Isso não significa que o cliente possui um endereço, acessou a página de splash ou obteve acesso à internet. Um evento Auth é a categoria de evento para autenticação de página de splash. Um evento DHCP próximo ao mesmo horário pode mudar a investigação para o endereçamento. Um evento RADIUS é importante para um fluxo de login baseado em RADIUS, mas não é prova de que o navegador acessou a página. 5 6

Evite confundir 802.1X com uma página de splash de login. A Cisco Meraki identifica mensagens 802.1X e RADIUS para SSIDs WPA2-Enterprise. Sua documentação separada de RADIUS para splash de login descreve o PAP entre a nuvem do Dashboard e o seu servidor RADIUS. Neste guia, use as categorias de associação, Auth, DHCP e RADIUS para localizar a etapa com falha. Não infira uma causa raiz exata a partir de apenas uma linha de registro. 4 6

Cisco Meraki também expõe tentativas de login na splash page por meio de sua API de Dashboard documentada. O registro inclui o horário de login, SSID, MAC do dispositivo de gateway, MAC do cliente e status de autorização. Para equipes de TI de vários locais, isso permite correlacionar o chamado do local com o resultado da autenticação sem tratar um caso isolado como evidência de incidente. 9

Como evitar que uma splash page corrigida falhe novamente?

Mantenha um guia de execução operacional curto junto ao proprietário do serviço de Guest WiFi . O guia deve identificar o SSID de teste, o dispositivo de teste, o procedimento de revogação de autorização, o host esperado da página, as dependências de pré-autenticação, a responsabilidade do RADIUS e o contato de escalonamento. Ele também deve definir o comportamento de desconexão do controlador da implantação. A Cisco Meraki documenta o comportamento aberto, restrito e padrão quando o controlador em nuvem está indisponível. 3

Para redes que usam um Captive Portal para consentimento, branding e política de acesso, trate a página offline como um componente controlado do aplicativo. O Purple oferece tipos de páginas offline, online e fora do horário de atendimento. Use as orientações publicadas de Splash Pages para alterações na jornada de acesso e o guia do editor HTML para ativos enviados e visualização. Mantenha o diagnóstico do dia a dia separado da configuração inicial do zero. 7 8

Quando isso se tornar um problema recorrente no local, centralize as evidências em vez de centralizar suposições. Correlacione o horário do incidente, o MAC do cliente, o AP ou MX, o SSID, o estado de autorização, as categorias de registro de eventos e a resposta do servidor RADIUS. Essa abordagem se adapta a locais de Hospitality , Retail e Transport onde as equipes locais precisam de um limite claro de escalonamento e a equipe de rede precisa de evidências reproduzíveis. Para um design de serviço mais amplo, consulte Guest WiFi Management: Smart Authentication & Segmentation .

Perguntas frequentes

O Purple funciona com os pontos de acesso Cisco Meraki existentes?

Sim. O Purple oferece suporte a implantações de WiFi para visitantes que se integram à infraestrutura existente, incluindo Cisco Meraki. Este guia aborda o diagnóstico do segundo dia de uma falha de tela de splash Meraki. Ele não substitui o trabalho de design e integração necessário para um novo Captive Portal. Use as diretrizes publicadas de Purple Splash Pages para tipos de página suportados e alterações na jornada de acesso. 7

Quanto trabalho é necessário para migrar uma tela de splash Meraki para o Purple?

O trabalho depende do fluxo de autenticação existente, das dependências de pré-autenticação e do design da página. Comece fazendo um inventário do host da página atual, entradas de walled garden, método de login e destino pós-login. O Purple suporta modelos de tela de splash padrão e HTML, incluindo ativos carregados e visualização em tempo real. Planeje a migração como uma mudança controlada, não como a correção de um incidente. 7 8

Uma tela de splash do Cisco Meraki pode redirecionar uma solicitação apenas HTTPS?

Não. A Cisco Meraki documenta que seu redirecionamento de splash começa quando um cliente não autorizado envia um HTTP GET. O tráfego HTTPS-first é criptografado e não pode ser redirecionado por esse mecanismo. Teste com um destino HTTP e, em seguida, distinga o comportamento do navegador do cliente de uma falha de splash em toda a rede. 1 2

Quais entradas de walled garden uma tela de splash Meraki personalizada precisa?

O walled garden deve permitir o endereço IP e/ou URL da tela de splash personalizada quando estiver ativado. Em seguida, permita apenas os endpoints adicionais de pré-autenticação de que a página realmente precisa. O Cisco Meraki suporta endereços IP, intervalos e hostnames, incluindo domínios curinga. Não substitua essa revisão pelo acesso irrestrito à internet. 3

Por que uma tela de splash de login do Meraki expira o tempo limite com RADIUS?

Um tempo limite geralmente significa que a nuvem do Cisco Meraki Dashboard não consegue obter uma resposta do servidor RADIUS configurado. Verifique a acessibilidade pública, os intervalos de origem atuais do Dashboard, os segredos compartilhados do cliente RADIUS correspondentes e o suporte a PAP. O AP ou MX local não é a origem das solicitações de RADIUS de splash. 4

Como monitoramos falhas de login de splash em vários locais?

Use o registro de eventos do Meraki para filtrar o cliente e a janela de tempo afetados e, em seguida, correlacione as categorias de Auth, DHCP e RADIUS. A API de tentativas de login de splash da Cisco pode retornar o horário de login, SSID, dispositivo de gateway, identificador do cliente e status de autorização. Isso cria um registro de evidências consistente para um suporte técnico de vários locais. 5 9

Referências