Risoluzione dei problemi di reindirizzamento del Captive Portal: Risolvere i problemi di connessione WiFi degli ospiti

Quando gli ospiti si connettono al WiFi ma non riescono ad accedere a Internet, la causa è quasi sempre un reindirizzamento del captive portal configurato in modo errato, non un guasto hardware. Questa guida fornisce un riferimento tecnico approfondito per IT manager, network architect e CTO per diagnosticare e risolvere l'intera catena di errori: dai probe di connettività a livello di sistema operativo e dai conflitti di certificati HSTS fino alle lacune di autorizzazione RADIUS e all'esaurimento DHCP. Associa ogni modalità di guasto a una soluzione concreta e mostra come l'overlay cloud indipendente dall'hardware di Purple elimina questi problemi nelle implementazioni Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme Networks e Fortinet.

📖 9 minuti di lettura📝 2,237 parole🔧 2 esempi pratici❓ 3 domande di esercitazione📚 9 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast

HOST (INGLESE REGNO UNITO, TONO DA CONSULENTE REALE ED ESPERTO):

Benvenuti al Technical Briefing di Purple. Oggi affrontiamo uno dei problemi più persistenti nelle reti aziendali: il fallimento del reindirizzamento al Captive Portal. Quando il vostro WiFi per gli ospiti risulta connesso ma non c'è accesso a Internet, i visitatori si innervosiscono, il supporto tecnico viene sommerso di richieste e la vostra strategia di acquisizione dati si blocca. In questo briefing analizzeremo l'architettura tecnica dei Captive Portal, esploreremo i motivi per cui i sistemi operativi e i browser moderni spesso li bloccano e vi forniremo strategie di implementazione concrete per risolvere questi problemi in modo permanente.

[PAUSA]

Inquadriamo la situazione. Avete distribuito access point Cisco Meraki o HPE Aruba in cento punti vendita. L'hardware è solido. Ma gli ospiti si lamentano di non riuscire a navigare su Internet. Selezionano l'SSID, il loro dispositivo mostra l'icona del WiFi, ma la splash page non compare mai. O peggio, visualizzano un allarmante errore del certificato SSL.

Perché succede questo? Tutto dipende da come i sistemi operativi rilevano la connettività Internet. Quando un dispositivo si connette a una rete, invia un probe HTTP a un URL noto. Per iOS, è captive.apple.com. Per Android, è connectivitycheck.gstatic.com. Windows utilizza msftconnecttest.com. Se il dispositivo riceve una risposta standard HTTP 200 OK, presuppone di avere un accesso diretto a Internet. Se il gateway di rete intercetta tale richiesta e risponde con un reindirizzamento HTTP 302 a un URL diverso, il sistema operativo capisce di trovarsi dietro a un Captive Portal. Di conseguenza, apre un pseudo-browser per caricare la splash page.

Il fallimento si verifica solitamente in questo punto di intercettazione.

[PAUSA]

Il primo principale punto di errore è il probe NCSI (Network Connectivity Status Indicator). Se il firewall o il gateway blocca queste richieste HTTP non crittografate, il sistema operativo non riceve mai il reindirizzamento 302. Presuppone semplicemente che la rete non funzioni. Per risolvere questo problema, è necessario assicurarsi che le tabelle di controllo degli accessi pre-autenticazione consentano il traffico HTTP verso gli specifici URL di rilevamento del sistema operativo.

Il secondo problema, sempre più comune, è l'HTTP Strict Transport Security, o HSTS. I browser moderni impongono l'HTTPS per i domini principali. Se un utente si connette al vostro WiFi e tenta immediatamente di aprire google.com, il browser esige una connessione crittografata. Quando il vostro gateway intercetta la richiesta HTTPS e prova a reindirizzarla al Captive Portal, il browser rileva un attacco di tipo man-in-the-middle. Il certificato presentato dal gateway non corrisponde a google.com. Il risultato è un blocco totale. L'utente visualizza un avviso di sicurezza e non può procedere alla pagina di accesso.

La soluzione in questo caso è duplice. In primo luogo, affidarsi ai meccanismi di rilevamento a livello di sistema operativo di cui abbiamo appena parlato. Questi utilizzano specificamente l'HTTP non crittografato per evitare questa discrepanza nei certificati. In secondo luogo, assicurarsi che la configurazione del walled garden sia impeccabile.

Cos'è un walled garden? È l'elenco dei domini e degli indirizzi IP a cui un ospite può accedere prima di autenticarsi. Se utilizzi il login social tramite Microsoft Entra ID o Google Workspace, o se elabori pagamenti tramite Stripe, questi domini devono essere presenti nel tuo walled garden. In caso contrario, la splash page potrebbe caricarsi, ma il processo di autenticazione fallirà silenziosamente.

[PAUSE]

Diamo un'occhiata a uno scenario reale. McDonald's serve milioni di clienti in migliaia di sedi. Utilizzano Purple per gestire il loro WiFi per gli ospiti. Se il timeout della sessione è impostato su un valore troppo breve, un cliente che controlla il telefono durante un pranzo lungo potrebbe essere costretto a riautenticarsi più volte. Questo rovina l'esperienza. Consigliamo di impostare la durata della sessione a 24 ore per gli ambienti retail e dell'ospitalità, utilizzando il caching degli indirizzi MAC per riconoscere i dispositivi di ritorno in modo fluido.

[PAUSE]

Passiamo ora alle raccomandazioni di implementazione. Quando distribuisci un Captive Portal, devi configurare il tuo gateway per intercettare correttamente il traffico DNS e HTTP. Se utilizzi un overlay cloud come Purple, il tuo hardware locale, che si tratti di Juniper Mist o Ubiquiti UniFi, deve essere in grado di raggiungere i server RADIUS di Purple.

Ecco un errore critico: la risoluzione DNS. Se un dispositivo ospite non riesce a risolvere l'hostname del tuo Captive Portal, il reindirizzamento fallisce. Assicurati che il tuo server DHCP fornisca indirizzi DNS affidabili e verifica che il tuo gateway consenta il passaggio delle query DNS attraverso il walled garden.

Inoltre, considera l'ambiente fisico. Le sedi ad alta densità come gli stadi o gli snodi di trasporto, come il Manchester Airports Group, gestiscono migliaia di tentativi di connessione simultanei. Se il pool DHCP locale è esaurito, i nuovi dispositivi si connetteranno all'access point ma non riusciranno a ricevere un indirizzo IP. Non raggiungeranno mai nemmeno la fase del Captive Portal. Dimensiona sempre le sottoreti in modo appropriato per la capacità di picco e utilizza tempi di lease DHCP brevi per le reti di visitatori temporanei.

[PAUSE]

Ora passiamo a una sessione di domande e risposte rapide basata sui ticket di assistenza più comuni.

Domanda uno: Perché il portale funziona su iPhone ma fallisce sui dispositivi Android?

Risposta: Si tratta quasi certamente di un problema di walled garden. Probabilmente hai inserito nella whitelist captive.apple.com ma hai tralasciato connectivitycheck.gstatic.com. Aggiorna i tuoi elenchi di controllo degli accessi di pre-autenticazione.

Domanda due: Gli ospiti si autenticano con successo, ma non hanno comunque internet. Perché?

Risposta: Controlla la configurazione RADIUS. Probabilmente il gateway non riceve il messaggio di Access-Accept dal server RADIUS, oppure le regole del firewall post-autenticazione bloccano il traffico. Verifica il segreto condiviso e assicurati che le porte 1812 e 1813 siano aperte.

Domanda tre: Possiamo usare HTTPS per il reindirizzamento iniziale per evitare avvisi di sicurezza?

Risposta: No. Non è possibile intercettare una richiesta HTTPS senza causare un errore di certificato, a meno che non si installi un certificato root su ogni dispositivo ospite, il che è impossibile per il WiFi pubblico. Devi affidarti alle sonde del sistema operativo HTTP non crittografate per attivare il portale.

[PAUSE]

In sintesi: i guasti del Captive Portal sono raramente dovuti a difetti hardware. Quasi sempre si tratta di discrepanze di configurazione nel flusso di reindirizzamento, nel walled garden o nelle impostazioni DNS.

Punto primo: assicurarsi che gli URL di rilevamento del sistema operativo siano accessibili prima dell'autenticazione.

Punto secondo: configurare il walled garden per includere tutti i provider di identità e le content delivery network necessarie.

Punto terzo: verificare la comunicazione RADIUS tra il gateway e la piattaforma di autenticazione.

Punto quarto: dimensionare gli scope DHCP per la densità di picco.

Padroneggiando questi elementi, si eliminano gli attriti di connessione. Eviterai di frustrare i visitatori e inizierai a raccogliere i dati di prima parte necessari per incrementare la fidelizzazione e i ricavi. Le Identity-Based Networks di Purple semplificano questo processo, fornendo un overlay cloud indipendente dall'hardware che gestisce la complessità di RADIUS, Captive Portal e analytics in modo fluido in oltre 80.000 sedi attive in tutto il mondo.

Grazie per aver partecipato a questo Purple Technical Briefing. Per guide di configurazione e diagrammi di architettura più dettagliati, visita purple.ai.

Punti chiave

✓I guasti del Captive Portal sono quasi sempre problemi di configurazione - non guasti hardware. La catena di reindirizzamento ha sei passaggi e ognuno può interrompersi.
✓Ogni sistema operativo invia un URL di sonda HTTP diverso per rilevare i Captive Portal. Se il gateway blocca una di queste sonde, quel sistema operativo non vedrà mai la splash page.
✓Non tentare mai di intercettare il traffico HTTPS per il reindirizzamento al Captive Portal. HSTS causa errori irreversibili del certificato. Affidati alle sonde HTTP non crittografate del sistema operativo.
✓Il walled garden deve includere gli URL delle sonde del sistema operativo, i domini dell'identity provider (Microsoft Entra ID, Google Workspace), gli asset della CDN e i domini del processore di pagamento prima dell'autenticazione.
✓L'autenticazione (completamento del modulo di login) e l'autorizzazione (il gateway che applica la regola del firewall) sono passaggi distinti. Se il portale mostra che l'operazione è andata a buon fine ma non c'è Internet, la comunicazione RADIUS tra il gateway e i server di Purple è interrotta.
✓In luoghi ad alta densità, l'esaurimento del DHCP produce sintomi identici a un guasto del Captive Portal. Dimensiona il pool DHCP per il numero massimo di dispositivi simultanei e utilizza tempi di lease brevi.
✓Testa ogni distribuzione su iOS, Android e Windows prima dell'approvazione finale. I guasti specifici di un sistema operativo indicano lacune nel walled garden, non errori di configurazione fondamentali.

Sintesi esecutiva

La richiesta "guest WiFi connesso ma senza internet" è uno dei ticket di supporto più comuni nel networking aziendale. Il sintomo è visibile a ogni visitatore; la causa è invisibile alla maggior parte dei team IT finché non comprendono la catena di reindirizzamento. Un Captive Portal (chiamato anche splash page o gateway hotspot) intercetta il probe di connettività HTTP iniziale di un dispositivo e genera un reindirizzamento HTTP 302 a una pagina di login. Se un qualsiasi passaggio di questa catena si interrompe - probe bloccati, conflitti HSTS, lacune nel walled garden, guasti RADIUS o esaurimento DHCP - l'ospite non vede altro che l'icona del WiFi connesso e l'assenza di internet. Questa guida ti accompagna attraverso ogni modalità di guasto, i meccanismi di protocollo sottostanti e le modifiche di configurazione per risolverli. Purple opera in oltre 80.000 sedi attive, elaborando 440 milioni di accessi all'anno (dati interni Purple, 2024), e i pattern qui descritti rappresentano le cause principali più frequenti che riscontriamo nei settori dell'ospitalità, retail, trasporti e settore pubblico.

Approfondimento tecnico

Come funziona effettivamente il rilevamento del captive portal

Ogni principale sistema operativo include un meccanismo integrato per rilevare se una rete richiede l'autenticazione prima di concedere l'accesso a internet. Comprendere questi meccanismi è alla base di qualsiasi risoluzione dei problemi relativi al Captive Portal.

Quando un dispositivo si associa a un SSID, l'OS invia una richiesta HTTP GET non crittografata a un URL predefinito. La tabella seguente elenca gli URL dei probe per piattaforma.

Operating system	Probe URL	Expected response
iOS / macOS	`http://captive.apple.com/hotspot-detect.html`	HTTP 200 con body specifico
Android (Google)	`http://connectivitycheck.gstatic.com/generate_204`	HTTP 204 No Content
Windows (NCSI)	`http://www.msftconnecttest.com/connecttest.txt`	HTTP 200 con body "Microsoft Connect Test"
Chrome (tutte le piattaforme)	`http://www.gstatic.com/generate_204`	HTTP 204 No Content
Firefox	`http://detectportal.firefox.com/success.txt`	HTTP 200

Se il gateway intercetta una di queste richieste e restituisce un reindirizzamento HTTP 302 che punta all'URL del Captive Portal, l'OS riconosce di trovarsi dietro un portale e apre un pseudo-browser (una WebView leggera) per visualizzare la splash page. Se il probe viene bloccato completamente, l'OS segnala "Nessuna connessione internet" e non tenta mai di aprire il portale. Questa è la causa più comune in assoluto del sintomo "guest WiFi connesso ma senza internet".

Il problema HSTS

HTTP Strict Transport Security (HSTS) è una policy di sicurezza web definita in RFC 6797. Indica ai browser di rifiutare tutte le connessioni HTTP in chiaro a un dominio e di rifiutare qualsiasi certificato che non corrisponda esattamente. I domini principali, inclusi google.com, facebook.com e la maggior parte dei siti bancari, si trovano nell'elenco di precaricamento HSTS integrato in Chrome, Firefox, Safari ed Edge.

Quando un ospite apre un browser e digita google.com, il browser aggiorna la richiesta a HTTPS prima che lasci il dispositivo. Il gateway non può intercettare una richiesta HTTPS e reindirizzarla in modo pulito - dovrebbe presentare un certificato per google.com, che non possiede. Il browser rileva la mancata corrispondenza del certificato e visualizza un avviso di sicurezza critico. L'ospite non può procedere alla pagina di login.

L'architettura corretta si affida interamente ai probe HTTP a livello di sistema operativo descritti sopra. Tali probe utilizzano HTTP in chiaro verso URL non-HSTS specificamente per consentire ai gateway di intercettarli e reindirizzarli senza conflitti di certificati. Il gateway deve intercettare questi probe HTTP ed emettere il reindirizzamento 302. Non tentare di intercettare il traffico HTTPS per scopi legati al Captive Portal.

Il walled garden

Un walled garden è l'insieme di domini e indirizzi IP che un dispositivo può raggiungere prima di essere autenticato. Se il walled garden è troppo ristretto, la splash page potrebbe caricarsi ma l'autenticazione fallirà. Le lacune più comuni includono:

Domini del provider di identità: se utilizzi Microsoft Entra ID, Okta o Google Workspace per l'accesso social o SSO, i relativi endpoint di autenticazione devono essere inclusi nel walled garden.
Domini CDN e di asset: la tua splash page potrebbe caricare CSS, JavaScript o font da una rete di distribuzione dei contenuti (CDN). Se tali domini CDN sono bloccati, il rendering della pagina risulterà compromesso.
Domini del processore di pagamento: se addebiti un costo per l'accesso tramite Stripe o un altro elaboratore, i domini del loro SDK JavaScript devono essere preventivamente autenticati.
Domini della piattaforma Purple: l'overlay cloud di Purple richiede che il gateway raggiunga i server RADIUS e gli endpoint del portale di Purple. Questi sono documentati nelle guide all'integrazione hardware di Purple per ciascuna piattaforma supportata.

RADIUS e il gap di autorizzazione

RADIUS (Remote Authentication Dial-In User Service) è il protocollo che collega il gateway locale alla piattaforma di autenticazione. Quando un ospite completa il modulo di login, il Captive Portal invia le credenziali al server RADIUS. Il server RADIUS restituisce un messaggio Access-Accept o Access-Reject. Il gateway agisce su tale messaggio aprendo o mantenendo chiusa la regola del firewall che garantisce l'accesso a internet.

Il gap di autorizzazione - in cui un ospite effettua correttamente l'accesso sulla splash page ma continua a non avere internet - significa quasi sempre che il gateway non ha ricevuto o elaborato il messaggio Access-Accept. Le cause comuni includono un segreto condiviso non corrispondente, le porte UDP 1812 e 1813 bloccate da un firewall locale o l'indirizzo IP del server RADIUS configurato in modo errato sul gateway.

Esaurimento DHCP in ambienti ad alta densità

Nei grandi impianti sportivi, nei centri congressi e negli snodi di trasporto, l'esaurimento dei DHCP è una causa frequente di problemi di connessione che si manifesta in modo identico a un problema del Captive Portal. Se il pool DHCP è pieno, un nuovo dispositivo si associa all'access point ma non riceve mai un indirizzo IP. Senza un indirizzo IP, il dispositivo non può inviare il probe HTTP e non raggiunge mai il Captive Portal. Il dispositivo risulta connesso alla SSID ma non ha accesso a Internet.

Per sedi come Manchester Airports Group (MAG), dove i volumi di passeggeri raggiungono picchi molto elevati, le sottoreti devono essere dimensionate per il numero massimo di dispositivi simultanei, non per la media. Tempi di lease DHCP brevi (15 - 30 minuti per le reti di visitatori di passaggio) consentono di recuperare rapidamente gli indirizzi dai dispositivi che si sono allontanati.

Guida all'implementazione

I passaggi seguenti si applicano a qualsiasi piattaforma hardware - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks o Fortinet - quando integrata con l'overlay cloud di Purple.

Fase 1: Configurare l'SSID per il Captive Portal esterno. Nel controller hardware, impostare l'SSID guest per reindirizzare i client non autenticati all'URL del portale esterno di Purple. Disabilitare qualsiasi splash page locale sul controller stesso.

Fase 2: Definire il walled garden. Aggiungere come minimo i seguenti domini: gli endpoint del portale e RADIUS di Purple (consultare la guida all'integrazione dell'hardware), gli URL dei probe di rilevamento del sistema operativo sopra elencati, i domini del provider di identità (Microsoft Entra ID, Okta o Google Workspace) e tutti i domini CDN utilizzati dagli asset della splash page.

Fase 3: Configurare il RADIUS. Inserire gli indirizzi IP dei server RADIUS di Purple, il segreto condiviso della dashboard di Purple, e impostare la porta di autenticazione su 1812 e la porta di accounting su 1813. Verificare che il firewall locale consenta l'UDP in uscita su queste porte.

Fase 4: Impostare i parametri di sessione. Per il settore hospitality e retail, impostare la durata della sessione a 24 ore con la memorizzazione nella cache degli indirizzi MAC abilitata. Ciò evita che gli ospiti debbano ripetere l'autenticazione durante un'unica visita. Per gli ambienti ad alta sicurezza, sono più indicate sessioni più brevi con nuova autenticazione.

Fase 5: Dimensionare l'intervallo DHCP. Calcolare il numero massimo di dispositivi simultanei per la struttura alla massima capacità. Un ristorante da 500 posti può registrare 800 dispositivi durante un servizio intenso. Dimensionare il pool DHCP a 1.000 indirizzi con un tempo di lease di 30 minuti.

Fase 6: Testare su tutti i sistemi operativi. Dopo la configurazione, testare l'intero flusso su dispositivi iOS, Android e Windows. Ognuno di essi utilizza un URL di probe e un'implementazione WebView diversi. Un errore su una piattaforma mentre le altre funzionano è quasi sempre dovuto a una lacuna nel walled garden.

Best practice

Le seguenti raccomandazioni riflettono gli standard e i modelli adottati in oltre 80.000 installazioni di Purple.

Separa le reti degli ospiti e del personale. Gestisci almeno tre SSIDs: Guest WiFi, Staff WiFi e una rete IoT. Il traffico Guest deve essere isolato dai sistemi interni. Consulta la nostra guida su Tre SSIDs per dominarli tutti: guest, Passpoint e IoT WiFi per i dettagli sull'architettura.

Usa una VLAN dedicata per gli ospiti. Segmenta il traffico degli ospiti nella propria VLAN per prevenire spostamenti laterali e semplificare le policy del firewall. Questo è un requisito PCI-DSS se i dati delle carte di pagamento transitano sulla rete.

Implementa opt-in a scelta consapevole. Il GDPR richiede che la raccolta dei dati sul Captive Portal si basi su un consenso informato e affermativo. Gli opt-in a scelta consapevole di Purple presentano le opzioni di raccolta dati in modo chiaro, con caselle di controllo separate per ciascuna finalità. Questo non è facoltativo per le sedi che operano nel Regno Unito o nell'UE.

Monitora la salute del portale in modo proattivo. La piattaforma WiFi Analytics di Purple offre visibilità in tempo reale sui tassi di successo dei login, sul conteggio delle sessioni e sugli errori di autenticazione. Un calo improvviso dei login andati a buon fine è un preavviso di un problema RADIUS o di walled garden prima che gli ospiti inizino a lamentarsi.

Applica un branding coerente. La splash page è la prima interazione brandizzata che un ospite ha con la tua rete. Un portale ben progettato aumenta i tassi di adesione e definisce le aspettative per l'esperienza WiFi. Consulta la guida Come fare un'ottima prima impressione con il tuo guest WiFi per indicazioni sul design.

Risoluzione dei problemi e mitigazione del rischio

Quando viene segnalato un problema al Captive Portal, segui questa sequenza diagnostica prima di apportare modifiche alla configurazione.

Isola il punto di errore. Chiedi all'ospite quale OS e browser sta utilizzando. Testa lo stesso flusso tu stesso sullo stesso OS. Se il problema è specifico del sistema operativo, la causa è quasi certamente una voce mancante nel walled garden per l'URL di probe di quell'OS.

Verifica la risoluzione DNS. Da un dispositivo sulla VLAN ospite, tenta di risolvere l'hostname del Captive Portal. Se la risoluzione DNS fallisce, il dispositivo non può raggiungere la splash page anche se il reindirizzamento viene emesso correttamente. Verifica che il server DHCP distribuisca indirizzi DNS affidabili e che il gateway consenta le query DNS nello stato di pre-autenticazione.

Cattura il reindirizzamento. Utilizza gli strumenti per sviluppatori del browser (F12) o una cattura di pacchetti per osservare lo scambio HTTP. Dovresti vedere la richiesta di probe dell'OS seguita da una risposta HTTP 302 contenente l'URL del portale. Se vedi la richiesta di probe ma nessuna risposta 302, il gateway non sta intercettando correttamente. Se non vedi alcuna richiesta di probe, l'OS ha già stabilito di avere accesso a Internet (probabilmente da uno stato memorizzato nella cache) e non sta inviando il probe. Verifica la comunicazione RADIUS. Sul gateway, controlla i log di accounting RADIUS. Un'autenticazione riuscita produce un record di Accounting-Start. Se non vedi alcun record di accounting dopo l'accesso di un utente, la comunicazione RADIUS è interrotta. Verifica la chiave segreta condivisa (shared secret), l'IP del server e le regole del firewall.

Controlla l'utilizzo dei lease DHCP. Sul server DHCP, verifica il numero di lease attivi rispetto alla dimensione del pool. Se l'utilizzo supera il 90%, ti stai avvicinando all'esaurimento. Amplia il pool o riduci immediatamente il tempo di lease.

La tabella seguente mappa i sintomi più comuni con le loro cause principali e la relativa soluzione.

Sintomo	Causa principale più probabile	Soluzione
Il portale non appare mai su alcun dispositivo	Probe del sistema operativo bloccato dall'ACL del gateway	Aggiungi gli URL dei probe alla lista dei consentiti pre-autenticazione
Il portale appare su iOS, ma non su Android	URL del probe Android mancante nel walled garden	Aggiungi `connectivitycheck.gstatic.com` al walled garden
Errore del certificato HTTPS al caricamento del portale	Il gateway intercetta l'HTTPS invece dell'HTTP	Affidati solo all'intercettazione del probe HTTP
Il portale si carica, ma non c'è internet dopo il login	RADIUS Access-Accept non ricevuto dal gateway	Verifica la chiave segreta condivisa, le porte 1812/1813 e l'IP del server RADIUS
Il pulsante di social login non funziona senza messaggi di errore	Il dominio dell'identity provider non è nel walled garden	Aggiungi gli endpoint di Microsoft Entra ID / Google Workspace
Gli ospiti devono autenticarsi nuovamente a ogni visita	Durata della sessione troppo breve o MAC caching disabilitato	Imposta la sessione a 24 ore, abilita il caching degli indirizzi MAC
Errori intermittenti nelle ore di punta	Esaurimento del pool DHCP	Amplia la subnet, riduci il tempo di lease

ROI e impatto aziendale

Ogni mancato funzionamento del Captive Portal rappresenta un'opportunità persa di acquisizione dati. La piattaforma Guest WiFi di Purple trasforma ogni autenticazione riuscita in un record di dati di prima parte - nome, email, dati demografici e frequenza delle visite - che alimenta direttamente l'automazione del marketing e i programmi di fidelizzazione.

Per un operatore dell' ospitalità come Premier Inn o Whitbread, un miglioramento del 10% nei tassi di successo dell'autenticazione al portale in una proprietà di 700 strutture si traduce direttamente in decine di migliaia di record opt-in aggiuntivi al mese. Questi record alimentano campagne email personalizzate con tassi di apertura notevolmente superiori rispetto alle liste acquistate.

Per gli operatori del retail , il Captive Portal è il punto di ingresso per comprendere il tempo di permanenza degli acquirenti, la frequenza delle visite ripetute e il comportamento tra i diversi punti vendita. Purple ha raccolto 29 miliardi di punti dati (dati interni di Purple) in tutta la sua rete di sedi. Tali dati sono utili solo nella misura in cui lo è il tasso di autenticazione che li genera.

Per i nodi di trasporto come Manchester Airports Group, un servizio WiFi per gli ospiti affidabile è una metrica di soddisfazione dei passeggeri monitorata a livello di consiglio di amministrazione. Un portale che presenta problemi intermittenti durante i periodi di picco delle partenze genera reclami e danneggia il Net Promoter Score della struttura. Per gli ambienti del settore sanitario , un WiFi per ospiti affidabile riduce la pressione sul personale clinico che altrimenti dovrebbe gestire i reclami sulla connettività, e supporta le metriche sulla soddisfazione dei pazienti.

L'SLA di uptime del 99.999% di Purple garantisce che l'overlay cloud non sia il punto di errore. Quando si verificano problemi con il portale, la causa è quasi sempre la configurazione locale - che questa guida ti aiuta a risolvere senza dover aprire un ticket di supporto.

References

[1] Troubleshooting Tip: General captive portal explanation, flow and troubleshooting. Fortinet Community, November 2024. https://community.fortinet.com/fortigate-3/troubleshooting-tip-general-captive-portal-explanation-flow-and-troubleshooting-188409

[2] RFC 8910: Captive-Portal Identification in DHCP and Router Advertisements. IETF. https://www.rfc-editor.org/info/rfc8910

[3] Network Connectivity Status Indicator overview for Windows. Microsoft Learn, February 2025. https://learn.microsoft.com/en-us/windows-server/networking/ncsi/ncsi-overview

[4] 7 Captive Portal Problems That Break Guest WiFi (And Quick Fixes). Spotipo, February 2026. https://www.spotipo.com/post/troubleshooting-captive-portals-common-issues

[5] Solution for HSTS issues with captive portal. Ubiquiti Community. https://community.ui.com/questions/Solution-for-HSTS-issues-with-captive-portal/17b033e7-3dfe-4830-af8f-bf6ead23d8b0

Definizioni chiave

Captive portal

Una pagina web presentata a un dispositivo che si connette a una rete prima che venga concesso l'accesso completo a Internet. Il gateway intercetta la richiesta di connettività HTTP iniziale del dispositivo e la reindirizza all'URL del portale.

Il meccanismo alla base di ogni pagina di accesso WiFi per gli ospiti, dalle hall degli hotel alle arene degli stadi. Definito nella RFC 8910.

Walled garden

L'insieme di domini e indirizzi IP che un dispositivo può raggiungere prima di completare l'autenticazione del Captive Portal. Il traffico verso le destinazioni incluse nel walled garden bypassa i requisiti di autenticazione.

Deve includere gli URL per il controllo del sistema operativo, gli endpoint dei provider di identità, i domini CDN e i domini dei processori di pagamento. Un walled garden configurato in modo errato è la seconda causa più comune di errore del Captive Portal.

NCSI (Network Connectivity Status Indicator)

Una funzionalità di Windows che interroga `msftconnecttest.com` per determinare se il dispositivo ha accesso a Internet o se si trova dietro un Captive Portal. Definito nella documentazione di rete di Microsoft.

Se il gateway blocca questo controllo, Windows segnala "Nessun accesso a Internet" e non attiva mai la visualizzazione web del Captive Portal. La soluzione consiste nell'aggiungere l'URL NCSI all'elenco di elementi consentiti prima dell'autenticazione.

HSTS (HTTP Strict Transport Security)

Una policy di sicurezza web definita nella specifica RFC 6797 che impone ai browser di rifiutare le connessioni HTTP non crittografate e di respingere qualsiasi certificato che non corrisponda esattamente al dominio.

Impedisce ai gateway di intercettare le richieste HTTPS per il reindirizzamento al Captive Portal. I domini principali, tra cui google.com, sono inclusi nell'elenco di precaricamento HSTS in tutti i browser principali.

Reindirizzamento HTTP 302

Un codice di risposta HTTP standard che indica che la risorsa richiesta si trova temporaneamente a un URI diverso, fornito nell'intestazione Location.

Il meccanismo utilizzato dai gateway per deviare la richiesta di connettività di un dispositivo alla pagina di accesso del Captive Portal. Alcuni gateway utilizzano invece il codice HTTP 303 o HTTP 200 con un corpo di reindirizzamento.

RADIUS (Remote Authentication Dial-In User Service)

Un protocollo di rete che fornisce una gestione centralizzata di autenticazione, autorizzazione e tracciamento (AAA), operante su UDP sulle porte 1812 (autenticazione) e 1813 (accounting).

La piattaforma cloud di Purple funge da server RADIUS. Il gateway locale (Meraki, Aruba, ecc.) invia le richieste di autenticazione ai server RADIUS di Purple e agisce in base alla risposta Access-Accept o Access-Reject.

Caching degli indirizzi MAC

Il processo di memorizzazione dell'identificatore hardware univoco di un dispositivo per riconoscere i dispositivi che ritornano e mantenere lo stato della sessione senza richiedere una nuova autenticazione.

Consente la persistenza della sessione in caso di brevi disconnessioni e visite ripetute all'interno della finestra temporale della sessione. Essenziale per gli ambienti hospitality in cui gli ospiti si spostano tra aree diverse.

Identity-Based Networks

Il modello di architettura di Purple in cui le policy di accesso, l'assegnazione delle VLAN e l'analisi vengono applicate in base all'identità autenticata dell'utente anziché al solo indirizzo IP o MAC del dispositivo.

Consente un controllo granulare degli accessi, esperienze personalizzate e un'attribuzione accurata del comportamento di rete ai singoli utenti su hardware Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.

Esaurimento DHCP

Una condizione in cui tutti gli indirizzi IP disponibili in un pool DHCP sono stati assegnati, impedendo ai nuovi dispositivi di ottenere un indirizzo e di conseguenza di raggiungere il Captive Portal.

Comune in luoghi ad alta densità durante i periodi di picco. Si manifesta in modo identico a un errore del Captive Portal - il dispositivo risulta connesso all'SSID ma non ha Internet. Diagnosticato verificando l'utilizzo dei lease DHCP sul server.

Esempi pratici

Un hotel da 200 camere che utilizza access point HPE Aruba segnala che gli ospiti su dispositivi Android non riescono ad accedere al captive portal, mentre gli utenti iOS si connettono senza problemi. Il team IT ha confermato che l'URL del portale è raggiungibile dalla VLAN di gestione.

Il team IT dovrebbe ispezionare il walled garden di pre-autenticazione sul controller HPE Aruba. I dispositivi iOS testano captive.apple.com, che probabilmente è già inserito nella whitelist. I dispositivi Android testano connectivitycheck.gstatic.com e clients3.google.com/generate_204. Questi domini Google sono quasi certamente assenti dal walled garden. L'aggiunta di questi domini all'elenco di consentiti pre-autenticazione risolve il problema. Il team dovrebbe anche aggiungere connectivitycheck.android.com come URL di probe Android secondario. Dopo aver aggiornato il walled garden, riavviare gli SSID interessati e testare su un dispositivo Android ripristinato di fabbrica per confermare la correzione, poiché lo stato della rete memorizzato nella cache su un dispositivo precedentemente connesso potrebbe mascherare il risultato.

Commento dell'esaminatore: Questo scenario illustra la natura specifica del sistema operativo nel rilevamento del captive portal. Ogni piattaforma utilizza URL di probe diversi e un walled garden configurato solo per un sistema operativo produrrà esattamente questo pattern di errore asimmetrico. Il segnale diagnostico chiave è che l'errore è specifico per il tipo di dispositivo, non intermittente su tutti i dispositivi. Gli errori intermittenti su tutti i dispositivi indicherebbero invece problemi RADIUS o DHCP.

Una catena di negozi con 150 appliance Cisco Meraki MX segnala che gli ospiti si autenticano sulla splash page di Purple - la dashboard di Purple mostra login riusciti - ma gli ospiti non hanno ancora accesso a Internet dopo aver completato il modulo. Il problema interessa contemporaneamente tutte le sedi.

Poiché la piattaforma cloud Purple mostra login riusciti, la fase di autenticazione stessa funziona. L'errore risiede nella fase di autorizzazione: l'appliance Meraki non riceve o non risponde al messaggio RADIUS Access-Accept dai server RADIUS di Purple. Il team dovrebbe verificare tre cose in sequenza: in primo luogo, verificare che la chiave segreta condivisa RADIUS sulla dashboard Meraki corrisponda esattamente alla chiave nel portale Purple (una differenza di un singolo carattere causa un errore silenzioso); in secondo luogo, confermare che il traffico UDP in uscita sulle porte 1812 e 1813 sia consentito dall'appliance Meraki verso gli indirizzi IP del server RADIUS di Purple; in terzo luogo, verificare se una recente modifica della rete ha introdotto una regola firewall o una policy NAT che blocca questo traffico. Poiché il problema interessa contemporaneamente tutte le 150 sedi, la causa è probabilmente una modifica centralizzata della policy del firewall o una variazione dell'indirizzo IP del server RADIUS di Purple che non è stata propagata alle configurazioni Meraki.

Commento dell'esaminatore: L'analisi diagnostica critica in questo caso è che la dashboard di Purple che mostra i login riusciti indica che la fase di autenticazione cloud è stata completata. L'errore è quindi nella fase di applicazione locale - il messaggio RADIUS dal cloud al gateway. Questa distinzione tra autenticazione lato cloud e autorizzazione lato locale è fondamentale per la risoluzione dei problemi di qualsiasi implementazione di captive portal che utilizzi un'architettura overlay cloud.

Domande di esercitazione

Q1. Durante una conferenza importante in una sede da 5.000 posti, il team IT riceve segnalazioni secondo cui centinaia di partecipanti non riescono ad accedere al portale WiFi per gli ospiti. Gli access point mostrano conteggi di associazione normali. Il problema è iniziato 45 minuti dopo l'inizio dell'evento. Qual è la causa più probabile e quale la soluzione immediata?

Suggerimento: Il problema è iniziato dopo l'avvio dell'evento, non al momento del lancio. Considera quale risorsa si riduce con l'aumento dei dispositivi connessi.

Visualizza risposta modello

La causa più probabile è l'esaurimento del pool DHCP. All'arrivo dei partecipanti che si associavano al SSID, il pool DHCP si è riempito. I nuovi dispositivi si associano all'access point ma non riescono a ottenere un indirizzo IP, di conseguenza non inviano mai la sonda HTTP necessaria per attivare il Captive Portal. La soluzione immediata consiste nel ridurre il tempo di lease DHCP a 15 minuti (recuperando più rapidamente gli indirizzi dei dispositivi disconnessi) e, se possibile, espandere il pool aggiungendo una seconda subnet. La soluzione a lungo termine consiste nel dimensionare il pool DHCP in base al numero massimo di dispositivi simultanei per il prossimo evento, non alla media.

Q2. Hai distribuito Purple su access point Ubiquiti UniFi in una catena di negozi. La splash page viene caricata correttamente su tutti i dispositivi. Gli utenti completano il modulo di acquisizione e-mail e vedono un messaggio di successo. Tuttavia, quando provano a navigare, non hanno accesso a Internet. La dashboard di Purple mostra i login come andati a buon fine. Cosa verifichi per primo?

Suggerimento: La piattaforma cloud ha registrato l'autenticazione. Il fallimento è nella fase di autorizzazione locale.

Visualizza risposta modello

Poiché la dashboard di Purple mostra login andati a buon fine, la fase di autenticazione cloud è stata completata correttamente. Il fallimento risiede nella fase di autorizzazione RADIUS: il controller UniFi non riceve o non risponde al messaggio Access-Accept proveniente dai server RADIUS di Purple. Verifica in questo ordine: (1) che il RADIUS shared secret sul controller UniFi corrisponda esattamente a quello nella dashboard di Purple; (2) che il traffico UDP in uscita sulle porte 1812 e 1813 sia consentito dal controller verso gli indirizzi IP dei server RADIUS di Purple; (3) che gli indirizzi IP dei server RADIUS configurati sul controller UniFi siano aggiornati (Purple potrebbe averli aggiornati). Un'acquisizione di pacchetti sul controller confermerà se il messaggio Access-Accept sta arrivando o meno.

Q3. Il responsabile IT di un hotel segnala che gli ospiti che utilizzano una VPN sui loro dispositivi non riescono ad accedere al Captive Portal. Gli ospiti senza VPN si connettono normalmente. L'hotel utilizza appliance Cisco Meraki MX. Il team IT dovrebbe modificare la configurazione del Captive Portal per soddisfare gli utenti VPN?

Suggerimento: Considera ciò che una VPN fa al traffico di rete del dispositivo prima che il Captive Portal possa intercettarlo.

Visualizza risposta modello

No - la configurazione del Captive Portal non deve essere modificata. Un client VPN crittografa tutto il traffico dal dispositivo prima che quest'ultimo lo lasci, inclusa la sonda di connettività HTTP. Il gateway non può intercettare il traffico VPN crittografato, quindi non invia mai il redirect 302. L'ospite deve disattivare la VPN, completare l'autenticazione sul Captive Portal e quindi riattivare la VPN. Questo è un limite architetturale fondamentale dei Captive Portal e delle VPN, non un errore di configurazione. Il team IT dovrebbe aggiungere una nota alle istruzioni del WiFi per gli ospiti, consigliando agli utenti VPN di disattivare la propria VPN prima di connettersi.

Continua a leggere questa serie

Risoluzione dei problemi del WiFi pubblico: come risolvere 'Connesso, senza Internet' e i problemi di reindirizzamento alla Splash Page

Questa guida tecnica di riferimento spiega i meccanismi alla base del rilevamento del Captive Portal e analizza in dettaglio le sei principali modalità di errore che impediscono la connessione al WiFi ospiti. Fornisce ai responsabili IT e agli architetti di rete un framework pratico di risoluzione dei problemi per risolvere problemi di reindirizzamento HTTP, conflitti DNS e sfide legate alla randomizzazione del MAC.

Le 10 principali cause di timeout DHCP sulle reti wireless ad alta densità

Questa guida tecnica di riferimento identifica le dieci principali cause di timeout DHCP sulle reti wireless ad alta densità e fornisce strategie di risoluzione pratiche e indipendenti dai singoli vendor. Progettata per IT leader senior, architetti di rete e direttori delle operazioni delle location, copre principi ingegneristici approfonditi, workflow di implementazione passo-passo e risultati di business misurabili. Scopri come eliminare i colli di bottiglia della connessione e ottimizzare la tua infrastruttura wireless per offrire una connettività fluida negli ambienti aziendali più esigenti.

Utilizzo di Packet Capture (PCAP) per diagnosticare le prestazioni WiFi lente

Questa guida di riferimento tecnico fornisce a IT manager, architetti di rete e direttori operativi delle strutture una metodologia strutturata a livello di pacchetto per diagnosticare e risolvere le prestazioni WiFi aziendali lente utilizzando l'analisi Packet Capture (PCAP). Analizzando i frame 802.11 grezzi — inclusi i tassi di ritrasmissione, l'utilizzo dell'airtime e i metadati del livello fisico — i team possono isolare con precisione i colli di bottiglia a livello RF dai problemi cablati o applicativi. Applicabile a strutture ad alta densità tra cui hotel, catene di vendita al dettaglio, stadi e centri congressi, questa guida offre flussi di lavoro diagnostici pratici, casi di studio reali e passaggi di remediation della configurazione per recuperare la capacità di rete e proteggere l'esperienza degli ospiti.