Captive Portal for Cisco Meraki

Benvenuti alla serie di Technical Briefing di Purple. Sono il vostro ospite e oggi parleremo di un argomento che emerge in quasi tutte le implementazioni di guest WiFi aziendali su cui lavoriamo: la configurazione di un captive portal sugli access point Cisco Meraki MR, e nello specifico come integrarlo con la piattaforma cloud di Purple utilizzando l'autenticazione RADIUS. Che siate un MSP che sta integrando un nuovo cliente nel settore hospitality o un network architect interno di una catena retail, questo episodio vi fornirà i passaggi di configurazione precisi e le motivazioni alla base di ciascuno di essi. Inquadriamo la situazione. Avete una sede — potrebbe essere un hotel, un centro congressi, uno stadio o un parco commerciale — che utilizza access point Cisco Meraki MR gestiti tramite la Meraki Dashboard. L'obiettivo è implementare un'esperienza guest WiFi personalizzata con il vostro brand che acquisisca dati di prima parte, imponga l'accettazione dei termini di servizio e invii i dati analitici a una piattaforma di marketing. Questo è esattamente ciò per cui Purple è stato progettato, e Meraki è una delle nostre implementazioni hardware più comuni a livello globale. Ora, il punto architetturale chiave da comprendere prima di toccare una singola impostazione è questo: su Cisco Meraki, l'autenticazione RADIUS per una splash page non viene elaborata localmente dall'access point. La richiesta RADIUS Access-Request ha origine dal cloud Meraki — dall'infrastruttura della Dashboard — e non dall'AP sulla vostra LAN. Questa è una distinzione fondamentale che mette in difficoltà molti ingegneri alla loro prima implementazione Meraki. Significa che il vostro server RADIUS, in questo caso l'endpoint RADIUS cloud di Purple, deve essere raggiungibile da Internet e le regole del firewall devono consentire il traffico dagli intervalli IP della Dashboard di Meraki, non solo dalla sottorete locale dell'AP. Troverete gli intervalli IP correnti della Dashboard alla voce Help, quindi Firewall Info nella vostra Dashboard Meraki. Bene, passiamo alla configurazione. Vi guiderò attraverso questo processo nell'ordine in cui lo fareste effettivamente in un'implementazione reale. Fase uno: configurazione dell'SSID. Nella Dashboard Meraki, andate su Wireless, quindi Configure, e poi SSIDs. Selezionate lo slot SSID che desiderate utilizzare per l'accesso guest. Assegnategli un nome chiaro, come GuestWiFi o NomeSede underscore Guest. In Association requirements, impostate Security su Open, no encryption. Questo è corretto e intenzionale: il livello di sicurezza per gli ospiti è gestito dal captive portal e dall'autenticazione RADIUS, non dalla crittografia WPA. Se state effettuando l'implementazione in un ambiente PCI DSS, dovrete assicurarvi che il traffico guest sia isolato sulla propria VLAN, aspetto che tratteremo a breve. Fase due: Splash page e autenticazione. Rimanendo nella pagina Access Control per il tuo SSID, scorri verso il basso fino alla sezione Splash page. Impostala su Sign-on con e, dal menu a discesa, seleziona il mio server RADIUS. Questa è l'impostazione fondamentale che indica a Meraki di autenticare gli utenti tramite un server RADIUS esterno prima di concedere l'accesso alla rete. Sotto questa voce, vedrai l'opzione Forza del Captive Portal. Impostala su Blocca tutti gli accessi fino al completamento del sign-on. Questo è ciò che applica il walled garden — senza di esso, gli ospiti potrebbero aggirare completamente il portale. Fase tre: Configurazione del server RADIUS. Nella sezione RADIUS, fai clic su Aggiungi server. Avrai bisogno di tre informazioni dal tuo account Purple: l'indirizzo IP o FQDN del server RADIUS, la porta di autenticazione che è UDP 1812 e il segreto condiviso. Purple fornisce questi dati nella sezione di configurazione della location del portale. Per garantire la ridondanza nelle distribuzioni di produzione, dovresti aggiungere un server RADIUS secondario — Purple fornisce un endpoint di failover. Imposta la porta di accounting su UDP 1813 se desideri che i dati di sessione vengano inviati al motore di analisi di Purple, cosa che consiglio vivamente per qualsiasi location in cui il tempo di permanenza e la durata della sessione sono metriche significative. Una breve nota sugli attributi RADIUS. Meraki rispetta l'attributo Session-Timeout restituito nella risposta RADIUS Access-Accept. Purple lo utilizza per controllare la durata di una sessione ospite prima che sia necessaria una nuova autenticazione. Per un hotel, potresti impostarlo su 86.400 secondi — ovvero 24 ore. Per una caffetteria, è più appropriato un valore come 3.600 secondi, ovvero un'ora. Viene rispettato anche l'attributo Idle-Timeout, ma solo se l'accounting RADIUS è abilitato. Questo disconnette le sessioni inattive, il che è importante per la gestione della capacità in location ad alta densità. Fase quattro: URL della Splash page. Naviga su Wireless, poi su Configura, quindi su Splash page. Seleziona il tuo SSID ospite dal menu a discesa. Imposta l'URL personalizzato della splash page sull'URL del portale Purple per la tua location. Questo è l'URL a cui Meraki reindirizzerà i client non autenticati. Meraki aggiunge parametri di query a questo URL — incluso un parametro login_url — che Purple utilizza per completare l'handshake di autenticazione. Non modificare o rimuovere questi parametri. Fase cinque: il walled garden. Questo è il punto in cui la maggior parte delle distribuzioni riscontra problemi. Il walled garden è l'elenco di domini e intervalli IP che un dispositivo ospite può raggiungere prima di essersi autenticato. Senza le voci corrette, la pagina stessa del Captive Portal non si caricherà, poiché al browser sarà impedito di raggiungere la CDN di Purple e i provider di social login. Torna alla sezione Access Control per il tuo SSID ospiti. Imposta Walled garden su Walled garden is enabled. Nel campo Walled garden ranges, devi aggiungere quanto segue. In primo luogo, i domini della piattaforma Purple: star dot purple dot ai e star dot venuewifi dot com. In secondo luogo, i domini CDN che Purple utilizza per distribuire gli asset del portale: star dot cloudfront dot net e star dot akamaihd dot net. In terzo luogo, l'infrastruttura di reindirizzamento Meraki: star dot network-auth dot com. In quarto luogo, se offri opzioni di social login, devi inserire i relativi domini OAuth. Per Google: accounts dot google dot com, star dot googleapis dot com, star dot gstatic dot com. Per Facebook: star dot facebook dot com, star dot fbcdn dot net e connect dot facebook dot net. Per Twitter o X: star dot twitter dot com e star dot twimg dot com. Una nota importante su come Meraki gestisce i domini wildcard nel walled garden. Meraki supporta le voci wildcard utilizzando il prefisso asterisco, ad esempio star dot cloudfront dot net. Tuttavia, si tratta di una corrispondenza basata su DNS: Meraki risolve il dominio e consente gli indirizzi IP risultanti. Ciò significa che per i provider CDN come CloudFront o Akamai, dove gli IP risolti possono variare frequentemente, è necessario utilizzare il dominio wildcard anziché intervalli IP statici. Le voci IP statiche vanno bene per gli endpoint RADIUS di Purple, che sono stabili, ma non per il traffico CDN. Ora parliamo di due scenari reali su cui ho lavorato direttamente. Il primo riguarda un hotel di 350 camere nel Regno Unito. Il cliente utilizzava access point Meraki MR46 in tre edifici, con circa 400 dispositivi guest simultanei nei momenti di picco. La distribuzione iniziale utilizzava una splash page click-through: nessun RADIUS, solo l'accettazione dei termini. Il problema era che non avevano alcuna visibilità su chi si connettesse, nessuna acquisizione di e-mail e nessun modo per avviare campagne di marketing post-soggiorno. Li abbiamo migrati a Purple con un accesso basato su RADIUS. La configurazione è stata semplice, ma l'inghippo era che il loro firewall a monte bloccava l'UDP in uscita sulla porta 1812 verso qualsiasi elemento esterno alla sottorete locale. Una volta aggiunti gli intervalli IP della Meraki Dashboard all'elenco dei consentiti del firewall, l'autenticazione ha funzionato immediatamente. Dopo l'implementazione, l'hotel ha acquisito gli indirizzi e-mail di circa il 68% degli ospiti connessi nel primo mese e il loro team di marketing ha avviato una campagna di re-engagement che ha generato un aumento misurabile delle prenotazioni dirette. Il secondo scenario riguarda una catena retail con 45 negozi, ciascuno dotato di access point Meraki MR33. La sfida in questo caso era rappresentata dalla scalabilità e dalla coerenza. Configurare manualmente 45 SSID con le impostazioni RADIUS corrette e gli elenchi di walled garden avrebbe comportato il rischio di errori e una notevole perdita di tempo. La soluzione è stata quella di utilizzare la configurazione basata su modelli di Meraki. Abbiamo creato un unico modello di rete con le impostazioni SSID, RADIUS e walled garden corrette, per poi associare a quel modello tutte le reti dei 45 negozi. Qualsiasi modifica — ad esempio, l'aggiunta di un nuovo provider di social login al walled garden — viene effettuata una sola volta nel modello e si propaga automaticamente a tutti i negozi. La piattaforma di analytics di Purple ha poi aggregato i dati sull'affluenza e sul tempo di permanenza di tutti i punti vendita, offrendo al team retail un'unica dashboard per visualizzare il comportamento degli ospiti per negozio, per regione e per fascia oraria. Ecco tre regole empiriche che vi faranno risparmiare tempo in ogni implementazione del Captive Portal di Meraki. Regola uno: verificate sempre gli intervalli IP della dashboard Meraki prima di configurare il server RADIUS. Questi intervalli cambiano occasionalmente e, se il firewall li blocca, l'autenticazione fallirà in modo silenzioso dal punto di vista dell'utente, che vedrà semplicemente la pagina del portale bloccarsi. Utilizzate lo strumento di test RADIUS integrato nella dashboard, alla voce Controllo Accessi, per verificare la connettività prima di andare online. Regola due: utilizzate i domini jolly (wildcard) nel walled garden, non gli intervalli IP, per qualsiasi contenuto ospitato su CDN. Gli intervalli IP delle CDN sono ampi e cambiano frequentemente. L'inserimento di un dominio jolly è più facile da gestire e più affidabile. Regola tre: abilitate il RADIUS accounting sulla porta 1813 anche se pensate che non vi serva ancora. I dati di sessione sono preziosi per risolvere i problemi di disconnessione e per inviare metriche precise sul tempo di permanenza alla vostra piattaforma di analytics. L'abilitazione non costa nulla ed è molto difficile da implementare a posteriori. Ora, alcune risposte rapide alle domande che mi vengono poste più di frequente. Posso usare la splash page integrata di Meraki invece di Purple? Sì, ma perderete l'acquisizione dei dati, gli analytics, la marketing automation e la gestione del consenso conforme al GDPR. La splash page integrata va bene per un semplice click-through, ma non è una piattaforma di guest intelligence. Questa configurazione funziona sui firewall Meraki MX così come sugli access point MR? La configurazione della splash page RADIUS è supportata sugli access point MR. I dispositivi MX gestiscono l'autenticazione VPN dei client in modo diverso. Per il WiFi ospiti nello specifico, la configurazione viene eseguita sugli SSID degli MR. E per quanto riguarda il WPA3? Gli access point Meraki MR supportano il WPA3 sugli SSID aziendali. Per le implementazioni di Captive Portal per ospiti, l'SSID è solitamente Aperto, quindi il WPA3 non si applica direttamente. Tuttavia, se insieme all'SSID del Captive Portal state implementando un SSID Passpoint o OpenRoaming — supportato da Purple — quell'SSID utilizzerà il WPA3-Enterprise con 802.1X, ed è qui che il WPA3 diventa rilevante. Per riassumere: l'integrazione tra Cisco Meraki e Purple è ampiamente testata e affidabile, ma richiede attenzione a tre aspetti: il routing dell'IP sorgente RADIUS, la completezza del walled garden e la configurazione del timeout di sessione. Configurando correttamente questi tre elementi, l'implementazione risulta lineare. Il caso aziendale è evidente: le location che implementano una piattaforma di guest WiFi configurata correttamente con acquisizione dati registrano costantemente ritorni misurabili in termini di coinvolgimento marketing e insight operativi. Se desideri approfondire, consulta la guida di Purple sull'implementazione dell'autenticazione 802.1X con RADIUS cloud e la nostra guida all'implementazione degli AP Cisco Wireless sul blog di Purple. Entrambe sono collegate nelle note dell'episodio. Grazie per l'ascolto. Se hai uno scenario di implementazione specifico che vorresti trattassimo, contatta il team tecnico di Purple. Ci vediamo nel prossimo episodio.