Cisco Meraki splash page non funziona: un diagramma di flusso per la risoluzione dei problemi

Le splash page Cisco Meraki smettono di apparire quando un client è ancora autorizzato, non riesce a inviare la richiesta HTTP che attiva il reindirizzamento, non riesce a raggiungere una dipendenza splash consentita o non riesce a completare l'autenticazione RADIUS. Inizia con un client interessato, filtra i record Auth, DHCP e RADIUS in base al suo indirizzo MAC, quindi testa il ramo pertinente descritto di seguito. 1 2 3 5

Cosa deve continuare a funzionare affinché appaia una splash page Meraki?

Considera un Captive Portal come una catena corta, non come una singola pagina web. Un dispositivo deve associarsi al corretto SSID, ricevere un indirizzamento valido, essere classificato come non autorizzato, inviare traffico in grado di avviare il flusso splash, raggiungere il servizio ospitato richiesto e infine ricevere l'autorizzazione. Cisco Meraki descrive l'attivatore come una richiesta HTTP GET proveniente da un client non autorizzato. L'AP intercetta tale richiesta e restituisce un reindirizzamento HTTP 307 all'URL della splash page. 1

Questo spiega una tipica chiamata di supporto: un ospite riesce a connettersi alla tua rete WiFi per gli ospiti ma riferisce che la splash page non si carica. L'access point potrebbe funzionare esattamente come previsto. Se il dispositivo apre per prima una destinazione esclusivamente HTTPS, la richiesta crittografata non può essere reindirizzata. Cisco Meraki identifica specificamente questo scenario come un timeout del browser. Testa il ramo HTTP controllato prima di modificare l'SSID, il design della pagina o il server RADIUS. 2

La stessa precisione evita un secondo errore comune: considerare ogni successiva richiesta di accesso come un errore della pagina. La frequenza della splash page è definita dalla policy di autorizzazione. Cisco Meraki mantiene lo stato della splash page sull'access point gateway e sul controller cloud, mentre il browser conserva un cookie di sessione. Un client con un periodo di autorizzazione valido potrebbe non visualizzare nuovamente la pagina dopo aver abbreviato la frequenza configurata. Al contrario, un client con cookie disabilitati o cancellati può sembrare ricevere la richiesta troppo spesso. 2

Cosa dovresti acquisire prima di modificare qualsiasi cosa?

Inizia con un singolo report riproducibile. Registra l'indirizzo MAC del client, l'SSID, l'access point gateway o l'MX, il tipo di dispositivo, l'ora locale, il browser e se il dispositivo ha completato in precedenza l'autenticazione tramite splash page. Chiedi alla persona che ha segnalato il problema di lasciare il dispositivo connesso mentre lo esamini. Questo ti fornisce un perimetro dell'incidente ed evita che un hotel affollato, un punto vendita o un luogo di eventi trasformi un reclamo generico in modifiche di configurazione alla cieca.

Apri i dettagli del client e verifica se è autorizzato. Cisco Meraki identifica un client non autorizzato come Splash: Not authorized; un client autorizzato mostra il tempo di autorizzazione rimanente. Non utilizzare una scheda del browser salvata come test. Ciò può mescolare una sessione passata con lo stato radio e DHCP attuale. 1

Quindi filtra il registro eventi della Dashboard in base all'indirizzo MAC del client e all'ora dell'incidente. Per gli access point MR, il tipo di evento Auth rappresenta l'autenticazione tramite splash page. 802.11 mostra l'associazione e la disassociazione, DHCP riporta gli eventi relativi ai lease e RADIUS identifica l'attività RADIUS o MAC Authentication Bypass. Lo stesso filtro Auth è disponibile per l'autenticazione splash MX. Cisco Meraki fa notare che i dispositivi caricano gli eventi memorizzati dopo essere tornati online, pur mantenendo i timestamp originali, quindi allinea il fuso orario prima di decidere cosa sia accaduto prima. 5

Utilizza il seguente registro ordinato. Riduce il dominio di errore senza procedere a tentativi.

Come si esegue il diagramma di flusso per la risoluzione dei problemi?

Usa il diagramma di flusso una volta per un client di test pulito e una volta per un client noto che presenta il problema. La differenza è utile. Se un client pulito raggiunge la pagina iniziale e il dispositivo noto no, avrai la prova di un problema di autorizzazione, dello stato del browser o di criteri specifici del client, piuttosto che di un disservizio a livello di intera sede.

1. Conferma l'associazione e l'indirizzamento. Se il registro eventi non mostra il client associato al SSID desiderato, non risolvere i problemi della pagina iniziale. Se si associa ma i record DHCP mostrano un errore, correggi prima l'indirizzamento o il percorso VLAN. Cisco Meraki identifica il tagging VLAN sull'SSID o sulla porta dello switch a monte come un'area comune di errore DHCP. 6

2. Conferma che il client non sia autorizzato. Un dispositivo precedentemente autorizzato potrebbe non richiedere ancora un'altra pagina iniziale. Cisco Meraki documenta una funzione di revoca dell'autorizzazione del client per test ripetuti e controllati. Utilizza questa funzione sul dispositivo designato, piuttosto che modificare la frequenza della pagina iniziale per ogni utente della sede. 2 3

3. Verifica l'attivazione con HTTP. Svuota la cache del browser solo se questo rientra nella procedura di test, conferma che i cookie siano abilitati, quindi apri una destinazione HTTP. Cisco Meraki indica che una richiesta inizialmente in HTTPS non può essere reindirizzata perché il traffico è crittografato. Se il test HTTP funziona, documenta il comportamento del client come causa. La rete non ha perso il reindirizzamento alla pagina iniziale. 1 2

4. Verifica la raggiungibilità della pagina e il walled garden. Un walled garden consente indirizzi IP, intervalli o nomi host specifici prima dell'autenticazione sulla pagina iniziale, inclusi i domini con caratteri jolly. Se utilizzi un URL personalizzato per la pagina iniziale, Cisco Meraki indica che l'indirizzo IP e/o l'URL della pagina personalizzata devono essere inseriti nel walled garden. Quando la pagina si affida a endpoint separati per risorse, identità o servizi, esamina ogni destinazione richiesta con il proprietario del servizio. Non indovinare gli indirizzi IP né aggiungere un ampio accesso a Internet come scorciatoia. 3

Le pagine Purple rendono chiara questa distinzione. Una pagina iniziale offline viene visualizzata prima del login e non può includere link o risorse esterne perché il visitatore si trova nel walled garden. Una pagina online viene visualizzata dopo l'avvenuto login e può contenere media o link esterni. Se una pagina HTML di Purple offline ha perso un'immagine, un foglio di stile, uno script o un elemento di identità di terze parti dopo una modifica, confronta tali dipendenze con le voci pre-autenticazione consentite prima di modificare il design. 7 8

1. Verifica il RADIUS di accesso solo dopo il caricamento della pagina. RADIUS, il protocollo utilizzato in questo caso per le richieste di autenticazione centralizzata, non è il primo indiziato quando non appare alcuna pagina iniziale. Diventa rilevante quando il modulo di accesso si carica ma l'autenticazione non riesce o va in timeout. Per questo flusso Cisco Meraki, è il cloud della Dashboard a originare la richiesta di accesso RADIUS, non l'AP locale o l'MX. Il server necessita di raggiungibilità pubblica dagli intervalli sorgente documentati della Dashboard, di un segreto condiviso corrispondente e del supporto per PAP. Cisco Meraki dichiara che RADSec non è supportato per l'autenticazione tramite pagina iniziale. 4
2. Esegui il controllo RADIUS supportato ed esamina il record del server. Cisco Meraki fornisce un test RADIUS del Dashboard per la configurazione wireless documentata, sebbene il pulsante di test non esista per le reti serie MX o Z. Un timeout indica che è necessario verificare le informazioni correnti sul firewall del Dashboard, le voci dei client RADIUS, la raggiungibilità dell'host pubblico, l'allineamento del segreto condiviso e il comportamento dei criteri. Il controllo dello stato di Cisco Meraki invia richieste di accesso periodiche e considera il server non raggiungibile dopo sei tentativi senza risposta, a distanza di 20 secondi l'uno dall'altro. 4

Come si isolano i punti di errore comuni?

La frequenza della splash page sembra errata

Se la splash page appare meno spesso di quanto suggerito dai criteri, verifica se il client era già autorizzato quando la frequenza è cambiata. Cisco Meraki indica che il periodo di autorizzazione esistente rimane in vigore. La revoca dell'autorizzazione del client selezionato crea un test valido dell'impostazione aggiornata. Se la pagina appare più spesso, controlla l'accettazione dei cookie del browser, lo svuotamento della cache e la continuità del punto di accesso del gateway. Un riavvio del gateway potrebbe richiedere nuovamente l'autenticazione a meno che il browser non possa presentare il proprio cookie. 2

Questo è importante nel settore dell'ospitalità. Un hotel di esempio da 200 camere dovrebbe effettuare un test con un telefono cellulare controllato dopo una modifica, quindi misurare il risultato come tre semplici esiti: il client passa allo stato autorizzato, riceve la scadenza prevista e la successiva richiesta HTTP pulita si comporta come previsto. Questa è una soglia di rilascio migliore rispetto al chiedere alla reception se i reclami sono cessati.

Il WiFi per gli ospiti non reindirizza

Non affermare che l'HTTPS ha "rotto" i Captive Portal. Il comportamento documentato di Cisco Meraki è più circoscritto: il meccanismo di reindirizzamento funziona su un HTTP GET non autorizzato, mentre una richiesta inizialmente in HTTPS non può essere reindirizzata. I dispositivi moderni possono avviare il flusso di rilevamento del Captive Portal del proprio sistema operativo al momento dell'associazione. Se tale richiesta non viene visualizzata, utilizza il test HTTP per stabilire se la diramazione di rete funziona. 1 2

Per un'implementazione di esempio nel settore retail, un team IT del negozio può riprodurre il reclamo con un dispositivo di test del personale sull'SSID del punto vendita. La prova di accettazione non è una vaga richiesta di caricamento della pagina. Registra il record di associazione, l'indirizzo valido, lo stato non autorizzato, l'evento Auth dopo il test HTTP e lo stato di autorizzazione risultante. Questo record può essere confrontato tra i vari negozi senza esporre le credenziali dei visitatori.

Il walled garden è incompleto

Un walled garden è un accesso intenzionalmente limitato prima dell'autorizzazione. Non dovrebbe diventare un elenco di bypass. Verifica innanzitutto l'host della splash page, quindi le dipendenze di cui la tua pagina di pre-autenticazione ha realmente bisogno. Cisco Meraki consente indirizzi IP, intervalli IP e nomi host, con domini jolly. Cisco richiede inoltre un URL o un indirizzo IP della splash page personalizzata nel walled garden quando tale funzionalità è abilitata. 3 Una pagina offline di Purple è la fase più limitata. Purple specifica che non è possibile utilizzare link o risorse esterne mentre il visitatore si trova nel walled garden. L'editor HTML consente al tuo team di caricare asset nel portale e visualizzare in anteprima la pagina corrente, il che può ridurre le dipendenze remote non necessarie. Segui i passaggi pubblicati da Purple prima di pubblicare un modello modificato. 7 8

La pagina di accesso (splash page) va in timeout o rifiuta le credenziali

Distingui un rifiuto da un timeout. Un rifiuto è il risultato di un'autenticazione o di una policy. Un timeout o un messaggio di "difficoltà di connessione" indica innanzitutto un problema di raggiungibilità tra la Dashboard e il server RADIUS configurato. Cisco Meraki documenta che le richieste della pagina di accesso (splash page) hanno origine nel cloud della Dashboard e non possono utilizzare un indirizzo LAN privato per il server RADIUS. 4

Verifica che il server preveda il protocollo PAP per questa modalità splash, che gli intervalli di origine documentati della Dashboard siano consentiti, che tutti gli IP di origine rilevanti siano configurati come client RADIUS e che la chiave segreta condivisa corrisponda su entrambi i lati. Cisco Meraki specifica inoltre che l'integrazione della splash page esterna deve utilizzare la login_url fornita senza modifiche e che il filtraggio deve consentire il suo hostname variabile anziché un unico pattern fisso. 4

Cosa significano gli eventi splash di Meraki nel registro degli eventi?

Interpreta il record come una sequenza temporale. 802.11 association significa che il client si è associato a un AP. Non significa che il client abbia un indirizzo, abbia raggiunto la splash page o abbia ottenuto l'accesso a Internet. Un evento Auth è la categoria di evento per l'autenticazione della splash page. Un evento DHCP registrato nello stesso momento potrebbe spostare l'indagine verso l'indirizzamento. Un evento RADIUS è rilevante per un flusso di accesso basato su RADIUS, ma non costituisce una prova del fatto che il browser abbia raggiunto la pagina. 5 6

Evita di confondere lo standard 802.1X con una splash page di accesso. Cisco Meraki identifica i messaggi 802.1X e RADIUS per gli SSID WPA2-Enterprise. La sua documentazione RADIUS separata per la splash page di accesso descrive il protocollo PAP tra il cloud della Dashboard e il tuo server RADIUS. In questa guida, utilizza le categorie association, Auth, DHCP e RADIUS per individuare la fase in cui si verifica l'errore. Non dedurre una causa radice esatta da una singola riga di registro. 4 6

Cisco Meraki espone anche i tentativi di accesso alla splash page tramite la sua Dashboard API documentata. Il record include l'ora di accesso, l'SSID, il MAC del dispositivo gateway, il MAC del client e lo stato di autorizzazione. Per i team IT multi-sede, questo consente di associare il ticket della sede a un esito di autenticazione senza trattare un aneddoto come prova dell'incidente. 9

Come evitare che una splash page fissa fallisca di nuovo?

Conserva un breve runbook operativo insieme al proprietario del servizio di Guest WiFi . Il runbook deve identificare l'SSID di test, il dispositivo di test, la procedura di revoca dell'autorizzazione, l'host della pagina previsto, le dipendenze di pre-autenticazione, la proprietà del RADIUS e il contatto di escalation. Deve inoltre indicare il comportamento del controller in caso di disconnessione della distribuzione. Cisco Meraki documenta il comportamento aperto, limitato e predefinito quando il controller cloud non è disponibile. 3

Per i parchi dispositivi che utilizzano un Captive Portal per il consenso, il branding e le policy di accesso, tratta la pagina offline come un componente dell'applicazione controllato. Purple fornisce tipi di pagina offline, online e fuori orario. Utilizza la guida pubblicata sulle Splash Pages per le modifiche al percorso di accesso e la guida all' HTML editor per le risorse caricate e l'anteprima. Mantieni la diagnosi del secondo giorno separata dalla configurazione iniziale. 7 8

Quando questo diventa un problema ricorrente per la sede, centralizza le prove anziché le congetture. Correlati l'ora dell'incidente, il MAC del client, l'AP o MX, l'SSID, lo stato di autorizzazione, le categorie del registro eventi e la risposta del server RADIUS. Questo approccio si adatta ai siti di Hospitality , Retail e Transport dove i team locali hanno bisogno di un limite chiaro per l'escalation e il team di rete ha bisogno di prove riproducibili. Per una progettazione del servizio più ampia, consulta Guest WiFi Management: Smart Authentication & Segmentation .

Domande frequenti

Purple funziona con gli access point Cisco Meraki esistenti?

Sì. Purple supporta distribuzioni di Guest WiFi che si integrano sull'infrastruttura esistente, inclusa quella Cisco Meraki. Questa guida copre la diagnostica post-installazione di un errore della splash page Meraki. Non sostituisce il lavoro di progettazione e onboarding necessario per un nuovo Captive Portal. Utilizzare la guida pubblicata di Purple Splash Pages per i tipi di pagina supportati e le modifiche al percorso di accesso. 7

Quanto lavoro è necessario per migrare una splash page Meraki su Purple?

Il lavoro dipende dal flusso di autenticazione esistente, dalle dipendenze di pre-autenticazione e dal design della pagina. Iniziare inventariando l'host della pagina corrente, le voci del walled garden, il metodo di accesso e la destinazione post-login. Purple supporta modelli di splash page standard e HTML, inclusi gli asset caricati e l'anteprima in tempo reale. Pianificare la migrazione come una modifica controllata, non come la risoluzione di un incidente. 7 8

Una splash page Cisco Meraki può reindirizzare una richiesta solo HTTPS?

No. Cisco Meraki documenta che il reindirizzamento della sua splash page inizia quando un client non autorizzato invia un HTTP GET. Il traffico HTTPS-first è crittografato e non può essere reindirizzato tramite questo meccanismo. Effettuare un test con una destinazione HTTP, quindi distinguere il comportamento del browser del client da un errore della splash page a livello di rete. 1 2

Quali voci del walled garden sono necessarie per una splash page Meraki personalizzata?

Il walled garden deve consentire l'indirizzo IP e/o l'URL della splash page personalizzata quando questa è abilitata. Successivamente, consentire solo gli endpoint di pre-autenticazione aggiuntivi che la pagina richiede effettivamente. Cisco Meraki supporta indirizzi IP, intervalli e nomi host, inclusi i domini con caratteri jolly. Non sostituire questa verifica con un accesso a Internet senza restrizioni. 3

Perché una splash page di login Meraki va in timeout con il RADIUS?

Un timeout spesso significa che il cloud del Cisco Meraki Dashboard non riesce a ottenere una risposta dal server RADIUS configurato. Verificare la raggiungibilità pubblica, gli intervalli di origine attuali del Dashboard, i segreti condivisi corrispondenti del client RADIUS e il supporto PAP. L'AP o l'MX locale non è l'origine delle richieste RADIUS della splash page. 4

Come possiamo monitorare gli errori di accesso alla splash page in diverse sedi?

Utilizzare il registro eventi di Meraki per filtrare il client interessato e la finestra temporale, quindi correlare le categorie Auth, DHCP e RADIUS. L'API per i tentativi di accesso alla splash page di Cisco può restituire l'ora di accesso, l'SSID, il dispositivo gateway, l'identificatore del client e lo stato di autorizzazione. Questo crea un registro di prove coerente per un help desk multi-sito. 5 9

Riferimenti