Risoluzione dei problemi del Captive Portal Cisco Meraki: checklist per splash page, walled garden e RADIUS

Un captive portal Meraki che fallisce ha solitamente uno di quattro guasti. Il tipo di splash page è errato, oppure il walled garden non contiene i domini e le risorse del portale. Il passaggio del grant URL potrebbe essere interrotto, oppure gli access point non riescono a raggiungere il RADIUS con una shared secret corrispondente. Il registro eventi di Meraki mostra quale guasto si è verificato.

Che aspetto ha un captive portal Meraki che non funziona?

Tre sintomi coprono la maggior parte dei ticket di supporto. Ognuno indica un anello diverso nella catena di login.

• La splash page non appare mai. Il dispositivo si connette al SSID e ottiene un indirizzo IP, ma non si apre alcuna richiesta di login.
• Il portale va in loop. L'ospite compila il modulo, tocca connetti e si ritrova nuovamente sulla pagina di login.
• Il portale accetta i dati ma non concede mai l'accesso. La pagina segnala il successo, eppure il dispositivo rimane prigioniero.

Un quarto sintomo è più silenzioso. Agli ospiti che ritornano viene chiesto di accedere molto più spesso del previsto. Questo raramente è un guasto del portale. Di solito si tratta dell'impostazione della frequenza della splash page.

Prima di modificare qualsiasi cosa, conferma come dovrebbe funzionare la catena. In un'installazione Purple, l'access point Meraki reindirizza il dispositivo ai server della splash page di Purple. La splash page raccoglie i dati dell'ospite ed emette un login monouso. L'access point passa quindi quel login al server RADIUS di Purple per completare l'autenticazione. L'articolo di supporto Purple captive portal support article descrive questo flusso. Ciascun sintomo corrisponde al fallimento di uno di questi tre passaggi.

Questa guida presuppone che lo SSID sia già creato. Integra la guida alla configurazione del captive portal Meraki e non ripete i passaggi di configurazione.

Cosa causa solitamente la mancata visualizzazione o il loop di una splash page Meraki?

Il tipo di splash page non corrisponde al portale

Meraki offre opzioni click-through, sign-on con un server RADIUS e opzioni di captive portal esterno. Il portale e lo SSID devono prevedere lo stesso metodo.

Un portale esterno click-through sblocca il dispositivo chiamando un grant URL. Un portale esterno sign-on invia le credenziali, che l'access point verifica tramite RADIUS. Se lo SSID e il portale non concordano, il passaggio fallisce e l'ospite va in loop.

Il walled garden è incompleto

Il walled garden elenca le destinazioni che un dispositivo può raggiungere prima di autenticarsi. Meraki accetta inserimenti come domini o intervalli IP. Se manca il dominio stesso del portale, la splash page non può caricarsi affatto.

La mancanza di risorse causa guasti più sottili. Fogli di stile, immagini, font, content delivery network e provider di social login si caricano tutti dai propri host. Se uno di questi è bloccato, la pagina viene visualizzata danneggiata o il pulsante di login non fa nulla.

Il walled garden può anche essere troppo generoso. I dispositivi eseguono un Captive Network Assistant (CNA), che controlla un dominio predefinito per verificare l'accesso a Internet. Se tale dominio di prova è raggiungibile prima del login, il dispositivo conclude che è online. Di conseguenza, non mostra mai la richiesta di login.

Il grant URL o il continue URL è andato perso

Con un Captive Portal esterno, Meraki aggiunge parametri al reindirizzamento. Questi includono un URL di concessione di base e l'URL di continuazione originariamente richiesto dall'ospite. Il portale deve rimandare il dispositivo all'URL di concessione per abilitarlo.

Se il portale perde, riscrive o memorizza in cache questi parametri, l'access point non riceverà mai la concessione. L'ospite visualizzerà un messaggio di successo, ma al caricamento della pagina successiva verrà reindirizzato nuovamente alla pagina di login.

RADIUS non è raggiungibile o il segreto condiviso è errato

L'accesso con RADIUS dipende dal fatto che gli access point riescano a raggiungere il server RADIUS. RADIUS è il protocollo Remote Authentication Dial-In User Service, definito nella RFC 2865. Il server tratta ogni mittente come un client RADIUS e verifica un segreto condiviso su ogni richiesta.

I problemi principali sono due. Un firewall blocca il traffico RADIUS dagli access point, oppure il segreto condiviso differisce tra la dashboard e il server. In entrambi i casi, il portale raccoglie i dettagli ma l'autenticazione non viene mai completata.

La modalità NAT e la modalità bridge cambiano cosa verificare

In modalità NAT, l'access point assegna autonomamente gli indirizzi ai client. I dispositivi a monte vedono il traffico proveniente dall'access point, non dal client. In modalità bridge, i client ottengono gli indirizzi dal server DHCP sulla LAN o VLAN.

La modalità bridge aggiunge punti di errore sotto la tua gestione. Questi includono un pool DHCP esaurito, una VLAN non associata all'access point e regole DNS o firewall a monte che bloccano gli host del portale.

Come si individua la causa esatta?

Procedi dal client verso l'esterno. Esegui i test con un solo dispositivo e dissocia la rete tra un tentativo e l'altro per far sì che ogni test inizi da zero.

Sintomo	Cosa mostra il registro eventi	Causa più probabile	Prima verifica
Non appare la pagina di benvenuto	Associazione, ma nessun reindirizzamento alla pagina di benvenuto	Dominio di probe CNA raggiungibile, oppure errore DHCP o DNS	Conferma che il dispositivo abbia un IP e un DNS, quindi apri neverssl.com
Pagina di benvenuto vuota o senza stile	Reindirizzamento alla pagina di benvenuto, pagina incompleta	Walled garden privo degli host di risorse	Strumenti per sviluppatori del browser, elenca tutti gli host bloccati
Loop continuo dopo l'invio	Ripetuti reindirizzamenti alla pagina di benvenuto, nessuna concessione	Parametri dell'URL di concessione persi, o discrepanza nel tipo di pagina di benvenuto	Confronta la stringa di query di reindirizzamento con quanto restituito dal portale
Messaggio di successo, ma nessun accesso a internet	Tentativi di autenticazione falliti o scaduti	RADIUS bloccato o segreto condiviso non corrispondente	Registri del server RADIUS alla ricerca di richieste provenienti dagli access point
Richiesta ripetuta agli ospiti che ritornano	Nuovi eventi della pagina di benvenuto per dispositivi noti	Frequenza della pagina di benvenuto troppo breve	Impostazione della frequenza della pagina di benvenuto sull'SSID
Avviso di certificato su desktop	Il reindirizzamento viene completato	Pagina di login servita tramite HTTP	Certificato sull'host del portale

Lettura del registro eventi Meraki

Apri il registro degli eventi di rete nella dashboard Meraki e filtra per l'indirizzo MAC del dispositivo di test. Successivamente, filtra per i tipi di evento relativi alla pagina di benvenuto e all'autenticazione. Leggi gli eventi in ordine cronologico: associazione, assegnazione dell'indirizzo, reindirizzamento alla splash page, autenticazione. Il punto in cui la sequenza si interrompe è dove risiede il guasto. L'assenza di un evento splash significa che il reindirizzamento non è mai stato attivato. Un evento splash senza un evento di autenticazione punta al portale o all'URL di autorizzazione. Un evento di autenticazione fallito punta a RADIUS.

Come risolvere il problema sulle reti Meraki MR e sui dispositivi client?

Segui i passaggi del fornitore nell'articolo di supporto di Purple captive portal. Le correzioni riportate di seguito indicano cosa modificare e perché.

Correggere il walled garden

Carica la splash page su un dispositivo esterno alla rete ospiti, con gli strumenti di sviluppo aperti. Registra ogni host chiamato dalla pagina, compresi i provider di login social. Aggiungi ciascuno di essi al walled garden come dominio o intervallo di IP. Rimuovi tutto ciò che corrisponde a un dominio di sonda CNA.

Correggere il passaggio dell'URL di autorizzazione

Acquisisci l'URL di reindirizzamento completo da un dispositivo che presenta l'errore. Verifica che il portale restituisca il dispositivo all'URL di autorizzazione di base con i parametri intatti. Assicurati che nessun proxy, abbreviatore di link o cache si trovi tra il portale e il dispositivo.

Correggere RADIUS

Verifica che gli access point possano raggiungere il server RADIUS sulle porte configurate. Reinserisci il segreto condiviso su entrambi i lati, copiandolo dalla stessa origine, contemporaneamente. Successivamente, controlla i log del server per verificare l'arrivo delle richieste dagli indirizzi degli access point.

Correggere il comportamento del client

Android mostra una notifica "potrebbe essere necessario accedere" che apre il CNA. Alcuni produttori di telefoni modificano questo comportamento, quindi effettua i test sui modelli utilizzati dai tuoi ospiti. Se un ospite perde l'avviso, Purple consiglia di aprire un browser e visitare mai-ssl.com. Questo sito evita i problemi di reindirizzamento SSL perché non utilizza mai HTTPS.

I browser desktop avvisano quando una pagina di accesso viene servita tramite HTTP semplice. L'articolo sul certificato Cisco WLC di Purple tratta l'errore equivalente sui Cisco WLC. La soluzione in questo caso è un certificato pubblicamente attendibile il cui Common Name corrisponde al nome host del portale. Lo stesso principio si applica a qualsiasi host del portale.

Altri fornitori

Purple è indipendente dall'hardware. Le stesse verifiche si applicano a Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Variano solo i nomi dei menu.

Due scenari di esempio pratici

Un hotel da 200 camere dopo il restyling del portale

Situazione. Una struttura ricettiva hospitality in centro città ha aggiornato la sua splash page con nuovi font e un pulsante di login social. In seguito, gli ospiti visualizzavano una pagina vuota senza pulsante di accesso.

Cosa è stato fatto. Il team IT ha caricato la nuova pagina con gli strumenti di sviluppo aperti e ha individuato due host bloccati. Uno era una rete di distribuzione di font. L'altro era il provider di login social. Entrambi sono stati aggiunti al walled garden.

Risultato. La pagina è stata visualizzata correttamente al test successivo. I reclami alla reception relativi all'accesso degli ospiti sono cessati il giorno stesso.

Una catena di vendita al dettaglio con 40 negozi dopo una modifica al firewall

Situazione. Una catena retail ha potenziato il firewall della sede centrale. La mattina successiva, i clienti in tutti i negozi visualizzavano la pagina di successo ma non potevano navigare.

Intervento. Il registro eventi mostrava timeout di autenticazione in ogni sede. La nuova regola aveva bloccato il traffico RADIUS proveniente dagli access point dei negozi. Il team ha ripristinato la regola esclusivamente per le porte RADIUS.

Risultato. Gli eventi di autenticazione sono tornati alla normalità in tutti i 40 negozi entro un'ora dalla modifica.

Come evitare che si verifichino nuovamente problemi con il captive portal Meraki?

• Collega il walled garden alle modifiche del portale. Ogni modifica al design deve attivare una revisione del walled garden prima della messa in servizio.
• Mantieni l'SSID aperto. Purple consiglia una rete aperta per l'accesso guest, poiché è una convenzione familiare che riduce gli ostacoli alla connessione.
• Ruota le chiavi segrete condivise in coppia. Modifica il dashboard e il server RADIUS all'interno di un'unica finestra di manutenzione.
• Esegui i test su quattro piattaforme. Android, iOS, Windows e macOS gestiscono tutti il CNA in modo differente.
• Usa un certificato attendibile. Offri la pagina di login tramite HTTPS utilizzando un certificato pubblicamente attendibile.
• Separa i dipendenti dagli ospiti. Il personale dovrebbe autenticarsi tramite identità, non attraverso una splash page per ospiti. Consulta Come abilitare il Single Sign-On.

Purple gestisce il servizio Guest WiFi in oltre 80.000 sedi attive e ha elaborato 440 milioni di accessi nel 2024 (dati interni di Purple). La stessa checklist si applica agli hub di trasporto per i passeggeri e alle strutture di sanità per pazienti e visitatori.

Domande frequenti

Purple è compatibile con i miei access point Cisco Meraki esistenti?

Sì, Purple funziona sui tuoi access point Cisco Meraki MR esistenti come overlay cloud. È sufficiente indirizzare la splash page dell'SSID verso Purple e configurare i dettagli RADIUS di Purple nel dashboard Meraki. Non è richiesto alcun nuovo hardware. L'articolo di supporto di Purple sul captive portal illustra tutti i passaggi di configurazione. Lo stesso approccio è valido per il resto di un'infrastruttura mista.

Purple può gestire il Guest WiFi su un'infrastruttura di fornitori diversi?

Sì, Purple è indipendente dall'hardware e supporta Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Puoi gestire un'unica splash page e un solo flusso di accesso per tutti i vendor da un'unica piattaforma. Questa soluzione è ideale per i gruppi aziendali che hanno acquisito sedi dotate di hardware differenti, o per le infrastrutture che prevedono di sostituire gli access point in modo graduale anziché con un unico progetto.

L'accesso guest dovrebbe essere eseguito su un SSID aperto o protetto?

Purple consiglia un SSID aperto per l'accesso guest, poiché rappresenta ormai lo standard del settore e gli ospiti lo riconoscono facilmente. Il captive portal gestisce la fase di accesso, eliminando la necessità per gli ospiti di inserire una password prima di connettersi. Una rete aperta riduce gli ostacoli al momento della connessione. Ti consigliamo di mantenere i dispositivi del personale su una rete separata basata sull'identità, anziché condividere l'SSID guest.

I dati degli ospiti acquisiti tramite la splash page sono conformi al GDPR?

Sì, Purple è certificata ISO 27001 e Cyber Essentials, e opera in conformità con il GDPR e il CCPA. Gli ospiti esprimono un consenso esplicito e consapevole sulla splash page, rendendo il consenso al marketing inequivocabile. I dati raccolti sono dati di prima parte, di proprietà della tua organizzazione. Purple è anche una B Corp certificata. Assicurati che l'informativa sulla privacy della tua azienda corrisponda ai campi raccolti dalla tua splash page.

Perché i browser desktop mostrano un avviso di certificato prima della pagina di login?

I browser desktop mostrano un avviso quando il portale reindirizza a una pagina di login tramite HTTP semplice. I browser moderni richiedono che le pagine di login utilizzino HTTPS, pertanto segnalano la connessione come non privata. La soluzione consiste nell'installare un certificato SSL/TLS pubblicamente attendibile sull'host del portale. Il Common Name del certificato deve corrispondere all'hostname utilizzato dal reindirizzamento. L'avviso non blocca l'accesso, ma mina la fiducia degli ospiti.

Chi gestisce l'autenticazione RADIUS quando Purple gestisce il portale?

Il server RADIUS di Purple completa il login. La splash page emette un login monouso e l'access point Meraki lo passa al server RADIUS di Purple. È necessario inserire i dettagli RADIUS di Purple e la chiave segreta condivisa (shared secret) nella dashboard Meraki. Il firewall deve consentire al traffico RADIUS proveniente dagli access point di raggiungere Purple. Se la chiave segreta condivisa differisce tra i due lati, l'autenticazione non va a buon fine.

Quanto impegno richiede il passaggio dalla splash page Meraki a Purple?

Il passaggio è una semplice modifica di configurazione su ciascun SSID, non un progetto hardware. È sufficiente cambiare il tipo di splash page, aggiungere le voci del walled garden e inserire i dettagli RADIUS di Purple. La maggior parte dell'impegno consiste nel testare il funzionamento su Android, iOS, Windows e macOS prima del lancio definitivo. Consigliamo di pianificare prima un sito pilota, per poi estendere le impostazioni testate al resto della rete.