Cisco Meraki splash page não funciona: um fluxograma de resolução de problemas

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

O que tem de continuar a funcionar para que uma splash page Meraki apareça?

Trate um Captive Portal como uma cadeia curta, não como uma única página web. Um dispositivo deve associar-se ao SSID correto, receber endereçamento válido, ser classificado como não autorizado, enviar tráfego que possa iniciar o fluxo da splash, aceder ao serviço alojado 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 esse pedido e devolve um redirecionamento HTTP 307 para o URL da splash. 1

Isto explica uma chamada de suporte comum: um convidado consegue associar-se ao seu Guest WiFi mas diz que a splash page não está a carregar. O ponto de acesso pode estar a funcionar conforme concebido. Se o dispositivo abrir primeiro um destino apenas HTTPS, o pedido encriptado não pode ser redirecionado. A Cisco Meraki identifica especificamente isto como um cenário de tempo limite (timeout) do browser. Teste o ramo 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 da splash é uma política de autorização. A Cisco Meraki mantém o estado da splash no ponto de acesso gateway e no controlador cloud, enquanto o browser 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 de encurtar a frequência configurada. Por outro lado, um cliente com cookies desativados ou limpos pode parecer ser solicitado com demasiada frequência. 2

O que deve registar antes de alterar qualquer coisa?

Comece com um relatório reproduzível. Registe o endereço MAC do cliente, SSID, ponto de acesso gateway ou MX, tipo de dispositivo, hora local, navegador e se o dispositivo já tinha concluído a autenticação no splash anteriormente. Peça ao utilizador que reportou o problema para manter o dispositivo ligado enquanto o inspeciona. Isto dá-lhe um limite para o incidente e evita que um hotel movimentado, um espaço de retalho ou um local de eventos transforme uma reclamação geral em alterações cegas de configuração.

Abra os detalhes do cliente e verifique se este está autorizado. A Cisco Meraki identifica um cliente não autorizado como Splash: Not authorized; um cliente autorizado mostra o seu tempo restante de autorização. Não utilize um separador guardado no navegador como teste. Isso pode misturar uma sessão passada com o estado de rádio e DHCP atual. 1

Depois, filtre o registo de eventos do Dashboard pelo endereço MAC do cliente e pela hora do incidente. Para pontos de acesso MR, o tipo de evento Auth representa a autenticação na splash page. 802.11 mostra a associação e desassociação, DHCP transporta eventos relacionados com concessões e RADIUS identifica a atividade de RADIUS ou MAC Authentication Bypass. O mesmo filtro Auth está disponível para a autenticação splash do MX. A Cisco Meraki indica que os dispositivos carregam eventos armazenados após voltarem a ficar online, mantendo os carimbos de data/hora originais, por isso alinhe o fuso horário antes de decidir o que aconteceu primeiro. 5

Utilize o seguinte registo ordenado. Ele reduz o domínio da falha sem necessidade de adivinhar.

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

Utilize o fluxograma uma vez para um dispositivo cliente de teste limpo e outra para um dispositivo cliente afetado conhecido. A diferença é útil. Se um cliente limpo alcançar a página de splash e o dispositivo conhecido não, terá provas de um problema de autorização, do estado do browser ou de uma política específica do cliente, em vez de uma falha em todo o local.

1. Confirme a associação e o endereçamento. Se o registo de eventos não mostrar o cliente a associar-se ao SSID pretendido, não tente resolver problemas da página de splash. Se este se associar mas os registos DHCP mostrarem um erro, corrija primeiro o endereçamento ou o caminho da VLAN. A Cisco Meraki identifica a marcação de VLAN no SSID ou na porta do comutador a montante como uma área comum de falha de DHCP. 6

2. Confirme que o cliente não está autorizado. Um dispositivo previamente autorizado pode ainda não necessitar de outra página de splash. A Cisco Meraki documenta uma função de revogação de autorização do cliente para testes repetidos controlados. Utilize esta função no dispositivo nomeado, em vez de alterar a frequência da página de splash para todos os utilizadores do local. 2 3

3. Teste o gatilho com HTTP. Limpe a cache do browser apenas quando isso se enquadrar no seu procedimento de teste, confirme que os cookies estão ativados e, em seguida, abra um destino HTTP. A Cisco Meraki indica que um pedido HTTPS inicial não pode ser redirecionado porque o tráfego está encriptado. Se o teste de HTTP funcionar, documente o comportamento do cliente como a causa. A rede não perdeu o seu redirecionamento de splash. 1 2

4. Teste a acessibilidade da página e o walled garden. Um walled garden permite endereços IP, gamas ou nomes de host específicos antes da autenticação de splash, incluindo domínios com caracteres wildcard. Se utilizar um URL de splash personalizado, a Cisco Meraki indica que o endereço IP e/ou URL da página personalizada deve estar no walled garden. Quando a página depende de endpoints separados de ativos, identidade ou serviço, reveja cada destino necessário com o proprietário do serviço. Não tente adivinhar endereços IP nem adicione um acesso geral à internet como atalho. 3

As páginas da Purple tornam a distinção clara. Uma página de splash offline surge antes do início de sessão e não pode incluir hiperligações ou recursos externos porque o visitante se encontra no walled garden. Uma página online surge após o início de sessão bem-sucedido e pode conter meios ou hiperligações externas. Se uma página HTML offline da Purple perdeu uma imagem, folha de estilos, 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 início de sessão apenas após o carregamento da página. O RADIUS, o protocolo aqui utilizado para pedidos de autenticação central, não é o primeiro suspeito quando nenhuma página de splash é exibida. Torna-se relevante quando o formulário de início de sessão é carregado mas a autenticação falha ou expira. Para este fluxo da Cisco Meraki, é a cloud do Dashboard que origina o pedido de acesso RADIUS, e não o AP ou MX local. O servidor necessita de acessibilidade pública a partir das gamas de origem documentadas do Dashboard, de um segredo partilhado correspondente e de suporte para PAP. A Cisco Meraki indica que o RADSec não é suportado para autenticação de splash. 4 6. Execute o teste de RADIUS suportado e examine o registo do servidor. A Cisco Meraki fornece um teste RADIUS no Dashboard para a configuração sem fios documentada, embora o botão de teste não exista para redes MX ou da série Z. Um timeout significa que deve verificar as informações atuais do firewall do Dashboard, as entradas de clientes RADIUS, a acessibilidade do host público, o alinhamento do segredo partilhado e o comportamento da política. O teste de integridade da Cisco Meraki envia pedidos de acesso periódicos e trata o servidor como inacessível após seis tentativas sem resposta, com um intervalo de 20 segundos entre cada uma. 4

Como isolar os pontos de falha comuns?

A frequência da splash page parece incorreta

Se a splash page 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 definição atualizada. Se a página aparecer com mais frequência, verifique a aceitação de cookies do browser, a limpeza da cache e a continuidade do ponto de acesso do gateway. Um reinício do gateway pode exigir nova autenticação, a menos que o browser consiga apresentar o seu cookie. 2

Isto é importante na hotelaria. Um hotel ilustrativo de 200 quartos deve testar com um telemóvel controlado após uma alteração e, em seguida, medir o resultado através de três resultados simples: o cliente passa a autorizado, recebe a expiração esperada e o próximo pedido HTTP limpo comporta-se como pretendido. Este é um critério de validação melhor do que perguntar à receção se as reclamações pararam.

O WiFi de convidados não está a redirecionar

Não afirme que o HTTPS "partiu" os portais cativos. O comportamento documentado da Cisco Meraki é mais restrito: o mecanismo de redirecionamento funciona num HTTP GET não autorizado, enquanto um pedido exclusivamente HTTPS não pode ser redirecionado. Os dispositivos modernos podem iniciar o fluxo de deteção de Captive Portal do sistema operativo no momento da associação. Se esse aviso não aparecer, utilize o teste HTTP para verificar se o segmento de rede funciona. 1 2

Para uma implementação ilustrativa no retalho, a equipa de TI de uma loja pode reproduzir a reclamação com um dispositivo de teste da equipa no SSID da loja. A prova de aceitação não é uma alegação vaga de carregamento de página. Registe o histórico 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. Este registo pode ser comparado entre lojas sem expor as credenciais dos visitantes.

O walled garden está incompleto

Um walled garden é um acesso pré-autorização intencionalmente limitado. Não deve tornar-se uma lista de desvio. Reveja primeiro o host da splash page e, em seguida, as dependências que a sua página de pré-autenticação realmente necessita. A Cisco Meraki permite endereços IP, gamas de IP e hostnames, com domínios wildcard. A Cisco também exige um URL de splash page personalizado ou endereço IP no walled garden quando essa funcionalidade está ativada. 3

Uma página offline da Purple é a fase mais limitada. A Purple indica que não pode utilizar hiperligações ou recursos externos enquanto o visitante estiver no walled garden. O editor de HTML permite que a sua equipa carregue ficheiros para o portal e pré-visualize a página atual, o que pode reduzir dependências remotas desnecessárias. Siga os passos publicados pela Purple antes de publicar um modelo editado. 7 8

O ecrã de início de sessão expira ou rejeita credenciais

Separe a rejeição do tempo expirado (timeout). Uma rejeição é um resultado de autenticação ou de política. Uma mensagem de tempo expirado ou de "dificuldade de ligação" aponta primeiro para a acessibilidade entre o Dashboard e o servidor RADIUS configurado. A Cisco Meraki documenta que os pedidos do ecrã de início de sessão têm origem na cloud do Dashboard e não podem utilizar um endereço de LAN privado para o servidor RADIUS. 4

Confirme se o servidor espera PAP para este modo de ecrã, 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 partilhado coincide em ambos os extremos. A Cisco Meraki também refere que a integração do ecrã de início de sessão externo deve utilizar o login_url fornecido sem modificações, e que a filtragem deve permitir o seu hostname variável em vez de um único padrão fixo. 4

O que significam os eventos de splash Meraki no registo de eventos?

Leia o registo como uma linha do tempo. A associação 802.11 significa que o cliente se associou a um AP. Não significa que o cliente tenha um endereço, tenha acedido à página de splash ou tenha obtido acesso à internet. Um evento de Autenticação é a categoria de evento para a autenticação na página de splash. Um evento de DHCP por volta da mesma hora pode mudar a investigação para a atribuição de endereços. Um evento de RADIUS é importante para um fluxo de início de sessão baseado em RADIUS, mas não é prova de que o navegador tenha acedido à página. 5 6

Evite confundir o 802.1X com uma página de ecrã de início de sessão. A Cisco Meraki identifica mensagens 802.1X e RADIUS para SSIDs WPA2-Enterprise. A sua documentação separada de RADIUS para ecrã de início de sessão descreve PAP entre a cloud do Dashboard e o seu servidor RADIUS. Neste guia, utilize as categorias de associação, Autenticação, DHCP e RADIUS para localizar a fase de falha. Não infira uma causa raiz exata a partir de apenas uma linha de registo. 4 6

A Cisco Meraki também expõe tentativas de login na splash page através da sua Dashboard API documentada. O registo inclui a hora de login, o SSID, o MAC do dispositivo gateway, o MAC do cliente e o estado de autorização. Para equipas de TI multilocalização, isto permite-lhe fazer a correspondência entre o pedido de suporte do local e o resultado da autenticação, sem tratar um rumor como prova de incidente. 9

Como evitar que uma splash page corrigida volte a falhar?

Mantenha um breve manual de procedimentos operacionais junto do proprietário do seu serviço de Guest WiFi . O manual deve identificar o SSID de teste, o dispositivo de teste, o procedimento de revogação de autorização, o anfitrião de página esperado, as dependências de pré-autenticação, a propriedade do RADIUS e o contacto de escalonamento. Deve também indicar o comportamento de desligamento do controlador da implementação. A Cisco Meraki documenta comportamentos abertos, restritos e predefinidos para quando o controlador de nuvem está indisponível. 3

Para instalações que utilizam um Captive Portal para consentimento, imagem de marca e política de acesso, trate a página offline como um componente de aplicação controlado. A Purple disponibiliza tipos de páginas offline, online e fora de horas. Utilize o guia publicado de Splash Pages para alterações na jornada de acesso e o guia do HTML editor para recursos carregados e pré-visualização. Mantenha o diagnóstico do dia a dia separado da configuração inicial. 7 8

Quando isto se torna um problema recorrente no local, centralize as provas em vez de centralizar as suposições. Correlacione a hora do incidente, o MAC do cliente, o AP ou MX, o SSID, o estado de autorização, as categorias de registo de eventos e a resposta do servidor RADIUS. Esta abordagem adequa-se a locais de Hospitality , Retail e Transport onde as equipas locais precisam de um limite claro de escalonamento e a equipa de rede precisa de provas reproduzíveis. Para um design de serviço mais abrangente, consulte o artigo Guest WiFi Management: Smart Authentication & Segmentation .

Perguntas frequentes

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

Sim. O Purple suporta implementações de Guest WiFi que se integram na infraestrutura existente, incluindo a Cisco Meraki. Este guia aborda o diagnóstico de problemas após a implementação de uma falha de splash Meraki. Não substitui o trabalho de design e integração necessário para um novo captive portal. Utilize as diretrizes publicadas do Purple Splash Pages para tipos de páginas suportados e alterações no percurso de acesso. 7

Quanto trabalho é necessário para migrar uma splash page 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 por inventariar o anfitrião da página atual, as entradas de walled-garden, o método de início de sessão e o destino pós-login. O Purple suporta modelos de splash page padrão e HTML, incluindo recursos carregados e pré-visualização em tempo real. Planeie a migração como uma alteração controlada e não como a correção de um incidente. 7 8

Uma splash page Cisco Meraki pode redirecionar um pedido apenas de HTTPS?

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

De quais entradas de walled-garden precisa uma splash page Meraki personalizada?

O walled garden deve permitir o endereço IP e/ou URL da splash page personalizada quando esta estiver ativada. Em seguida, permita apenas os endpoints de pré-autenticação adicionais de que a página realmente necessita. A Cisco Meraki suporta endereços IP, intervalos e nomes de anfitrião, incluindo domínios com asteriscos. Não substitua essa revisão pelo acesso ilimitado à Internet. 3

Por que razão ocorre um tempo limite excedido (timeout) numa splash page de início de sessão Meraki com RADIUS?

Um tempo limite excedido significa frequentemente 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, as chaves secretas partilhadas do cliente RADIUS correspondentes e o suporte PAP. O AP ou MX local não é a origem dos pedidos RADIUS de splash. 4

Como podemos monitorizar falhas de login de splash em vários locais?

Utilize o registo de eventos da Meraki para filtrar o cliente afetado e a janela temporal e, em seguida, correlacione as categorias de Auth, DHCP e RADIUS. A API splash-login-attempts da Cisco pode devolver a hora do login, SSID, dispositivo de gateway, identificador do cliente e estado de autorização. Isso cria um registo de evidências consistente para um suporte técnico de vários locais. 5 9

Referências