Configurazione del reindirizzamento del Captive Portal sui controller di rete aziendali

Benvenuto al Technical Briefing di Purple. Sono la tua guida e, nei prossimi dieci minuti, entreremo direttamente nel vivo di uno degli argomenti più cercati e meno documentati nel mondo del WiFi aziendale: la configurazione del reindirizzamento del Captive Portal sui controller di rete. Se hai mai cercato "configurar controlador portal cautivo" senza trovare risposte utili, questo è il briefing di cui avevi bisogno. Copriremo l'intero scenario: l'architettura tecnica, i passaggi di configurazione per i singoli controller, i requisiti di conformità e le insidie reali che mettono in difficoltà anche i team di rete più esperti. Iniziamo. Un Captive Portal è il meccanismo che intercetta la prima richiesta HTTP o HTTPS del dispositivo di un ospite dopo la connessione alla tua rete WiFi e lo reindirizza a una splash page personalizzata prima di concedere l'accesso a Internet. Tale splash page potrebbe richiedere un login social, la compilazione di un modulo, un semplice clic per l'accettazione dei termini o una verifica delle credenziali basata su RADIUS. Il reindirizzamento stesso viene gestito a livello di controller, non dall'access point o dal firewall. Il controller intercetta il traffico del client non autenticato, applica una lista di controllo degli accessi di pre-autenticazione (quella che chiamiamo walled garden) e reindirizza il browser del client all'URL del tuo portale. Perché questo è importante a livello commerciale? Per tre ragioni. In primo luogo, la conformità. In base al GDPR, sei tenuto a ottenere un consenso esplicito e informato prima di raccogliere dati personali dai visitatori. Un Captive Portal correttamente configurato è il tuo strumento di consenso. Senza di esso, raccogli dati in assenza di una base giuridica, esponendoti a rischi normativi. In secondo luogo, la sicurezza. Un SSID aperto senza autenticazione rappresenta un rischio. Il reindirizzamento tramite Captive Portal, combinato con la segmentazione VLAN e un server RADIUS, ti offre una tracciabilità per sessione. Sai chi si è connesso, quando e da quale dispositivo. In terzo luogo, la business intelligence. Ogni sessione autenticata rappresenta un punto di dati proprietari (first-party data). Purple elabora 440 milioni di accessi all'anno in 80.000 sedi. Questi dati — tempo di permanenza, frequenza delle visite, indicatori demografici — sono disponibili solo se il tuo Captive Portal è configurato correttamente per acquisirli e trasmetterli. Ora ti guiderò attraverso il flusso di reindirizzamento, passo dopo passo. Passo uno: il dispositivo di un ospite si associa al tuo SSID ospite. Il controller gli assegna un indirizzo IP tramite DHCP, ma lo inserisce in uno stato di pre-autenticazione limitato. Tutto il traffico viene bloccato, ad eccezione del DNS e dei domini del walled garden che hai esplicitamente autorizzato. Passo due: l'ospite apre un browser. La sua richiesta HTTP raggiunge il controller. Il controller la intercetta e genera un reindirizzamento 302 all'URL del tuo portale. Questo è il meccanismo di reindirizzamento principale. Passo tre: il browser dell'ospite carica la tua splash page, ospitata sul controller stesso o, come avviene più comunemente nelle distribuzioni aziendali, su una piattaforma cloud esterna come Purple. Fase quattro: l'ospite si autentica tramite social login, modulo o credenziali. Il portale invia un segnale di autorizzazione al controller, in genere tramite un messaggio RADIUS Access-Accept o un bypass di autorizzazione MAC. Fase cinque: il controller sposta il client dalla VLAN di pre-autenticazione alla VLAN di post-autenticazione, rimuove la regola di reindirizzamento e concede l'accesso a Internet. Questo flusso in cinque fasi è coerente su tutte le principali piattaforme di controller. Ciò che differisce è il modo in cui si configura ciascuna fase su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi e altri. Esaminiamo le piattaforme principali. Cisco Meraki. Meraki utilizza una splash page personalizzata configurata interamente tramite la Dashboard di Meraki - non è presente alcuna CLI. Accedere a Wireless, quindi a Access Control, selezionare il proprio SSID guest, impostare la splash page su "Sign-on con server RADIUS" o "Click-through", quindi inserire l'URL del portale esterno nel campo Custom Splash URL. Il walled garden è configurato nella sezione Advanced Splash Settings: si aggiungono gli indirizzi IP del server del portale in modo che l'ospite possa raggiungere la splash page prima dell'autenticazione. I dettagli del server RADIUS vanno nella sezione RADIUS: autenticazione sulla porta 1812, accounting sulla porta 1813. HPE Aruba. Su ArubaOS, si configura un profilo di Captive Portal nella sezione AAA, specificando l'URL di login, il gruppo di server che punta al server RADIUS e l'URL di reindirizzamento. Successivamente, si applica tale profilo al proprio SSID tramite il profilo AP virtuale. Il ruolo di pre-autenticazione — quello che Aruba chiama ruolo di "logon" — contiene l'ACL che consente DNS, DHCP e l'accesso all'intervallo IP del server del portale. Dopo l'autenticazione, il controller assegna il ruolo "authenticated", che consente l'accesso completo a Internet. Ruckus SmartZone utilizza un tipo di WLAN Hotspot per le distribuzioni di Captive Portal. Sotto la configurazione WLAN, impostare il tipo di WLAN su Hotspot, quindi configurare l'URL del portale, il server RADIUS per l'autenticazione e l'accounting e le voci del walled garden. L'interfaccia Northbound Portal gestisce il flusso di autorizzazione MAC tra il portale e il controller. Juniper Mist utilizza un approccio cloud-native. Sotto Network, quindi WLANs, creare una WLAN guest e impostare il tipo di portale su "Captive Portal esterno". Inserire l'URL del portale e configurare i dettagli del server RADIUS. Mist passa il MAC del client, il MAC dell'AP e il nome dell'SSID come parametri URL al portale. Ubiquiti UniFi. Nel controller di rete UniFi, accedere a Impostazioni, quindi a WiFi, selezionare la rete guest e, in Opzioni avanzate, impostare la Guest Policy per abilitare il portale hotspot. Impostare il tipo di portale su "Esterno" e inserire l'URL del portale. Configurare il server RADIUS sotto Profili, quindi RADIUS. Il walled garden è l'elemento configurato in modo errato più comunemente nelle distribuzioni di Captive Portal. Se si commette un errore qui, gli ospiti visualizzeranno un errore del browser anziché la splash page. Il walled garden deve consentire, come minimo: gli indirizzi IP o il dominio del server del portale, gli indirizzi IP del server RADIUS, la risoluzione DNS sulla porta 53 e il DHCP sulle porte 67 e 68. Se il portale carica risorse da una CDN (font, immagini, JavaScript), anche i domini di tale CDN devono essere inclusi nel walled garden. Per le implementazioni Purple, forniamo gli intervalli IP e i domini specifici da inserire nella whitelist durante l'onboarding. La modalità di errore più comune è un portale che carica il frame HTML ma non riesce a eseguire il rendering delle immagini o a eseguire JavaScript perché i domini della CDN mancano nel walled garden. Qui dominano due standard di conformità: GDPR e PCI DSS. Ai sensi del GDPR, il tuo captive portal deve presentare un meccanismo di consenso chiaro e specifico prima di raccogliere dati personali. Ciò significa caselle di controllo separate e non selezionate per l'accesso WiFi e il consenso al marketing. Non è possibile raggrupparli. Il registro dei consensi deve essere memorizzato e recuperabile a fini di audit. La piattaforma di Purple gestisce questo aspetto automaticamente, memorizzando i record di consenso per ogni sessione autenticata. Ai sensi del PCI DSS, se la tua sede elabora pagamenti con carta, la rete WiFi per gli ospiti deve essere isolata dall'ambiente delle carte di pagamento. Ciò significa una VLAN ospite dedicata con regole di firewall che impediscono qualsiasi routing tra il segmento ospiti e la rete POS. La versione 4.0 di PCI DSS, diventata obbligatoria a marzo 2024, richiede test di segmentazione della rete almeno ogni sei mesi. Ecco due scenari concreti. Scenario uno: un hotel da 350 camere che utilizza Cisco Meraki. L'hotel desidera sostituire un portale click-through di base con un'esperienza ospite personalizzata con il proprio brand che acquisisca gli indirizzi e-mail per il programma fedeltà. La configurazione: creare un SSID ospite dedicato su una VLAN separata con solo accesso a Internet. Configurare la splash page di Meraki per puntare all'URL del portale di Purple. Configurare l'autenticazione RADIUS utilizzando i dettagli del server RADIUS di Purple. Configurare il walled garden con gli intervalli IP di Purple. Nella dashboard di Purple, creare una splash page personalizzata con un modulo che acquisisca nome, e-mail e numero di camera, con caselle di controllo esplicite per il consenso al GDPR. Collegare il connettore CRM di Purple alla piattaforma di marketing dell'hotel. Premier Inn ha implementato questo modello in tutte le sue strutture e ha registrato aumenti misurabili nei tassi di prenotazione diretta da parte degli ospiti acquisiti tramite WiFi. Scenario due: una catena di vendita al dettaglio regionale con 40 negozi che utilizzano HPE Aruba. Il rivenditore necessita di un'esperienza WiFi ospiti coerente in tutte le sedi, con analisi delle presenze per confrontare le prestazioni dei singoli negozi. Distribuisci Aruba Central per gestire tutte le 40 sedi da un'unica dashboard. Configura un modello WLAN ospiti con un Captive Portal esterno che punta a Purple. Applica il modello a tutte le sedi utilizzando la funzione di criteri di gruppo di Aruba Central. In Purple, configura un unico modello di portale da applicare a tutte le sedi, con dashboard di analisi per singolo punto vendita. Il walled garden e la configurazione RADIUS vengono definiti una sola volta nel modello e propagati automaticamente. Risultato: il team IT gestisce 40 sedi da un'unica console. Il team marketing ottiene dati sulle presenze per singolo negozio, analisi dei tempi di permanenza e tassi di visite ripetute, il tutto da un'unica dashboard Purple. Quattro errori comuni che vedo ripetutamente. Uno: errori di intercettazione HTTPS. I browser moderni e i sistemi operativi mobili utilizzano probe HTTPS per rilevare i Captive Portal. Se il controller non è in grado di intercettare il traffico HTTPS (il che richiede un certificato valido per il dominio di reindirizzamento), il probe fallisce silenziosamente e l'ospite non vede alcun reindirizzamento. La soluzione: configura l'interfaccia virtuale del controller con un certificato attendibile, oppure utilizza probe solo HTTP sul tuo SSID ospiti. Due: perdita di DNS (DNS leakage). Se la tua ACL di pre-autenticazione consente un DNS illimitato, gli ospiti possono utilizzare il tunneling DNS per aggirare completamente il Captive Portal. Limita il DNS solo al resolver designato. Tre: discrepanze nel timeout di sessione. Se il timeout di sessione del controller è inferiore alla validità del token di sessione del portale, gli ospiti verranno reindirizzati al portale a metà sessione. Allinea questi valori: in genere 24 ore per il settore alberghiero, otto ore per la vendita al dettaglio. Quattro: assenza di accounting. L'accounting RADIUS (i messaggi Accounting-Start e Accounting-Stop) è il modo in cui il portale sa che una sessione è terminata. Senza l'accounting configurato, i record di sessione del portale saranno imprecisi e le analisi inaffidabili. Domande rapide, risposte rapide. Posso utilizzare un portale esterno con qualsiasi controller? Sì, a condizione che il controller supporti il reindirizzamento al Captive Portal esterno, come fanno tutte le piattaforme di cui abbiamo discusso. Ho bisogno di un server RADIUS per gestire un Captive Portal? Non sempre. I semplici portali click-through possono utilizzare il bypass dell'autorizzazione MAC senza un server RADIUS completo. Ma per i portali con credenziali o login social, RADIUS è il meccanismo standard. Il Captive Portal funziona con il WPA3? Sì. Il WPA3 gestisce il livello di crittografia wireless. Il Captive Portal gestisce il livello di autenticazione. Operano in modo indipendente e sono completamente compatibili. In che modo Purple si integra con il controller esistente? Purple funge da server del portale esterno. È sufficiente puntare l'URL splash del controller all'endpoint del portale di Purple, configurare il walled garden con gli intervalli IP di Purple e configurare RADIUS utilizzando i dettagli del server di Purple. L'integrazione segue lo stesso processo indipendentemente dal fatto che si utilizzi Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist o Ubiquiti UniFi. In sintesi, il reindirizzamento del Captive Portal viene configurato a livello di controller, non di access point. I componenti principali sono: l'URL splash che punta al portale, il walled garden che consente l'accesso al server del portale, RADIUS per l'autenticazione e l'accounting e la segmentazione VLAN per l'isolamento della rete. I passaggi di configurazione variano a seconda del fornitore, ma l'architettura è coerente. In termini di conformità, il portale deve implementare l'acquisizione del consenso conforme al GDPR e la segmentazione della rete conforme a PCI DSS. Lo standard WPA3 è l'attuale standard per la crittografia wireless e dovrebbe rappresentare la specifica di base per qualsiasi nuova implementazione. Purple si integra nativamente con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Con oltre 80.000 location e 440 milioni di accessi nel 2024, la piattaforma è progettata per essere indipendente dall'hardware: la scelta del controller non limita la capacità di acquisire dati degli ospiti di prima parte o di eseguire analisi. Il prossimo passo: verifica la configurazione attuale del controller rispetto alla checklist del walled garden e dell'accounting RADIUS presente in questa guida. Se stai implementando una nuova rete WiFi per gli ospiti, inizia con i passaggi di configurazione specifici del fornitore per la piattaforma del tuo controller e collega Purple come portale esterno. Grazie per l'attenzione. Questo è stato il Technical Briefing di Purple.