Visualizza trascrizione del podcast
Benvenuto alla serie Purple Technical Briefing. Sono il tuo presentatore e oggi tratteremo un argomento che emerge in quasi tutte le implementazioni WiFi per ospiti aziendali su cui lavoriamo: la configurazione di un captive portal su access point Cisco Meraki MR, e nello specifico come integrarlo con la piattaforma cloud di Purple utilizzando l'autenticazione RADIUS. Che tu sia un MSP che gestisce un nuovo cliente nel settore dell'ospitalità o un network architect interno presso una catena retail, questo episodio ti fornirà i passaggi precisi di configurazione e le motivazioni alla base di ognuno di essi.
Analizziamo lo scenario. Hai 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 WiFi per gli ospiti brandizzata 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 rappresenta 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 proviene dal cloud Meraki - dall'infrastruttura della Dashboard - e non dall'AP sulla tua LAN. Questa è una distinzione fondamentale che mette in difficoltà molti ingegneri alla loro prima installazione Meraki. Significa che il tuo server RADIUS, in questo caso l'endpoint cloud RADIUS di Purple, deve essere raggiungibile da internet e le regole del tuo firewall devono consentire il traffico dagli intervalli IP della Dashboard di Meraki, non solo dalla sottorete AP locale. Troverai gli intervalli IP attuali della Dashboard alla voce Help, poi Firewall Info nella tua Dashboard Meraki.
Bene, passiamo alla configurazione. Ti guiderò attraverso questo processo nell'ordine in cui lo faresti effettivamente in un'implementazione reale.
Fase uno: configurazione dell'SSID. Nella Dashboard Meraki, naviga su Wireless, poi Configure, quindi SSIDs. Seleziona lo slot SSID che desideri utilizzare per l'accesso degli ospiti. Assegnagli un nome chiaro - qualcosa come GuestWiFi o NomeSede underscore Guest. Sotto Association requirements, imposta la 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 stai effettuando l'implementazione in un ambiente PCI-DSS, dovrai assicurarti che il traffico degli ospiti sia isolato sulla propria VLAN, aspetto che tratteremo a breve.
Fase due: Splash page e autenticazione. Sempre nella pagina Access Control per il tuo SSID, scorri 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, vedrai l'opzione Forza captive portal. Impostala su Blocca tutti gli accessi fino al completamento del sign-on. Questo è ciò che applica la walled garden - senza di essa, gli ospiti potrebbero aggirare completamente il portale.
Fase tre: Configurazione del server RADIUS. Nella sezione RADIUS, clicca 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 sede del portale. Per garantire la ridondanza nelle installazioni 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 analytics di Purple, un'opzione che consiglio vivamente per qualsiasi sede in cui il tempo di permanenza e la durata della sessione sono metriche significative.
Una rapida nota sugli attributi RADIUS. Meraki rispetta l'attributo Session-Timeout restituito nella risposta RADIUS Access-Accept. Purple lo utilizza per controllare la durata della sessione di un ospite prima che sia richiesta 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 (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à nelle sedi ad alta densità.
Fase quattro: URL della splash page. Vai su Wireless, poi Configura, quindi Splash page. Seleziona il tuo SSID ospite dal menu a discesa. Imposta l'URL splash personalizzato sull'URL del portale Purple della tua sede. 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: la walled garden. È qui che la maggior parte delle installazioni riscontra problemi. La walled garden è l'elenco dei domini e degli 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à, perché al browser sarà impedito di raggiungere la CDN di Purple e i provider di login social.
Torna su Controllo Accessi per il tuo SSID guest. Imposta Walled garden su Walled garden abilitato. Nel campo degli intervalli del Walled garden, devi aggiungere quanto segue. Innanzitutto, 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 login social, hai bisogno dei 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 con 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 cambiare frequentemente, dovresti utilizzare la wildcard del dominio 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 è 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 - senza RADIUS, solo accettazione dei termini. Il problema era che non avevano alcuna visibilità su chi si connettesse, nessuna acquisizione di e-mail e nessun modo per eseguire campagne di marketing post-soggiorno. Li abbiamo migrati a Purple con accesso basato su RADIUS. La configurazione è stata semplice, ma l'inghippo è stato che il loro firewall a monte bloccava l'UDP in uscita sulla porta 1812 verso qualsiasi cosa esterna alla subnet locale. Una volta aggiunti gli intervalli IP della Dashboard Meraki alla allow-list del firewall, l'autenticazione ha funzionato immediatamente. Dopo l'implementazione, l'hotel ha acquisito gli indirizzi e-mail di circa il 68% dei guest 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 è una catena retail con 45 negozi, ognuno dei quali utilizza access point Meraki MR33. La sfida in questo caso era rappresentata dalla scalabilità e dalla coerenza. Configurare manualmente 45 SSID con le impostazioni RADIUS e gli elenchi di walled garden corretti sarebbe stato fonte di errori e avrebbe richiesto molto 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, quindi abbiamo associato tutte le 45 reti dei negozi a quel modello. Qualsiasi modifica - ad esempio, l'aggiunta di un nuovo provider di login social al walled garden - viene effettuata una sola volta nel modello e si propaga a tutti i negozi in modo automatico. Gli strumenti di analytics di Purple hanno poi aggregato i dati sull'affluenza e sui tempi di permanenza in tutti i negozi, offrendo al team operativo del retail un'unica dashboard per visualizzare il comportamento degli ospiti per negozio, per regione e per ora del giorno.
Permettetemi di fornirvi tre regole empiriche che vi faranno risparmiare tempo in ogni installazione di un Captive Portal Meraki.
Regola uno: verificate sempre gli intervalli IP della Dashboard Meraki prima di configurare RADIUS. Gli intervalli cambiano occasionalmente e, se il firewall li blocca, l'autenticazione fallirà silenziosamente dal punto di vista dell'utente - vedrà semplicemente la pagina del portale bloccarsi. Utilizzate lo strumento di test RADIUS integrato nella Dashboard sotto Access Control per verificare la connettività prima di andare online.
Regola due: utilizzate i caratteri jolly del dominio nel walled garden, non gli intervalli IP, per qualsiasi contenuto ospitato su CDN. Gli intervalli IP delle CDN sono ampi e cambiano frequentemente. Un inserimento di dominio con carattere jolly è più facile da gestire e più affidabile.
Regola tre: abilitate il RADIUS accounting sulla porta 1813 anche se pensate di non averne ancora bisogno. I dati di sessione sono preziosi per la risoluzione dei problemi di disconnessione e per inserire metriche accurate sui tempi di permanenza nella vostra piattaforma di analytics. Non costa nulla abilitarlo ed è molto difficile integrarlo a posteriori.
Ora, alcune domande rapide che mi vengono poste regolarmente.
Posso usare la splash page integrata di Meraki invece di Purple? Sì, ma perderete la cattura dei dati, gli analytics, la marketing automation e la gestione dei consensi conforme al GDPR. La splash page integrata va bene per un semplice clic d'accesso, ma non è una piattaforma di guest intelligence.
Questa configurazione funziona sui firewall Meraki MX oltre che sugli access point MR? La configurazione della splash page RADIUS è supportata sugli access point MR. Gli hardware MX gestiscono l'autenticazione VPN client in modo diverso. Specificamente per il WiFi ospiti, si configurano gli SSID degli MR.
Cosa c'è da sapere su WPA3? Gli access point Meraki MR supportano WPA3 sugli SSID aziendali. Per le implementazioni con Captive Portal per gli ospiti, l'SSID è in genere Open, quindi WPA3 non si applica direttamente. Tuttavia, se state distribuendo un SSID Passpoint o OpenRoaming accanto al vostro SSID con Captive Portal - cosa supportata da Purple - quell'SSID utilizzerà WPA3-Enterprise con 802.1X, ed è qui che WPA3 diventa rilevante.
Per concludere: l'integrazione tra Cisco Meraki e Purple è ampiamente testata e affidabile, ma richiede attenzione a tre elementi: il routing dell'IP di origine RADIUS, la completezza del walled garden e la configurazione del timeout di sessione. Configurando correttamente questi tre aspetti, l'implementazione è immediata. Il business case è chiaro - i locali che implementano una piattaforma WiFi per ospiti configurata correttamente con acquisizione dei dati registrano costantemente ritorni misurabili in termini di coinvolgimento marketing e informazioni operative.
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 affrontassimo, contatta il team tecnico di Purple. Ci vediamo nel prossimo episodio.
