Risoluzione dei problemi di reindirizzamento del Captive Portal: come risolvere gli errori di connessione alla rete WiFi ospiti
Quando gli ospiti si connettono alla tua rete 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, architetti di rete e CTO per diagnosticare e risolvere l'intera catena di errori: dai probe di connettività a livello di sistema operativo e conflitti di certificati HSTS fino alle lacune di autorizzazione RADIUS e all'esaurimento DHCP. Associa ogni modalità di errore a una soluzione concreta e mostra come l'overlay cloud indipendente dall'hardware di Purple elimini questi problemi nelle distribuzioni Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.
Video overview
Ascolta questa guida
Visualizza trascrizione del podcast
Parte della nostra serie principale: Guida al Captive Portal →
- Sintesi per il management
- Approfondimento tecnico
- Come funziona effettivamente il rilevamento del Captive Portal
- Il problema HSTS
- Il walled garden
- RADIUS e il problema di autorizzazione
- Esaurimento DHCP in ambienti ad alta densità
- Guida all'implementazione
- Best practice
- Risoluzione dei problemi e mitigazione dei rischi
- ROI e impatto aziendale
- Riferimenti

Sintesi per il management
La richiesta "guest WiFi connesso ma senza internet" rappresenta uno dei ticket di supporto più comuni nel networking aziendale. Sebbene il sintomo sia visibile a ogni visitatore, la causa rimane invisibile per la maggior parte dei team IT finché non comprendono la catena di reindirizzamento. Un Captive Portal (chiamato anche splash page o hotspot gateway) intercetta la richiesta iniziale di connettività HTTP del dispositivo e genera un reindirizzamento HTTP 302 verso 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 del pool DHCP - l'ospite vedrà solo l'icona del WiFi connesso ma nessuna connessione internet. Questa guida ti accompagna attraverso ogni modalità di errore, i meccanismi di protocollo sottostanti e le modifiche di configurazione necessarie per risolverli. Purple opera in oltre 80.000 sedi attive, elaborando 440 milioni di accessi all'anno (dati interni Purple, 2024), e i pattern descritti qui rappresentano le cause principali più frequenti che riscontriamo nei settori hospitality, retail, trasporti e pubblica amministrazione.
Approfondimento tecnico
Come funziona effettivamente il rilevamento del Captive Portal
Ogni principale sistema operativo integra un meccanismo per rilevare se una rete richiede l'autenticazione prima di concedere l'accesso a internet. Comprendere questi meccanismi è fondamentale per la risoluzione di qualsiasi problema relativo al Captive Portal.
Quando un dispositivo si associa a un SSID, il sistema operativo invia una richiesta HTTP GET non crittografata a un URL predefinito. La tabella seguente elenca gli URL di probe suddivisi per piattaforma.
| Operating system | Probe URL | Risposta attesa |
|---|---|---|
| iOS / macOS | http://captive.apple.com/hotspot-detect.html |
HTTP 200 con corpo specifico |
| Android (Google) | http://connectivitycheck.gstatic.com/generate_204 |
HTTP 204 No Content |
| Windows (NCSI) | http://www.msftconnecttest.com/connecttest.txt |
HTTP 200 con corpo '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, il sistema operativo riconosce di trovarsi dietro a un portale e apre un pseudo-browser (una WebView leggera) per mostrare la splash page. Se il probe viene bloccato del tutto, il sistema operativo segnala "Nessuna connessione internet" e non tenta mai di aprire il portale. Questa è la causa singola più comune per cui si verifica il 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 bloccante. 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 affinché i gateway possano 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 dell'identity provider: se utilizzi Microsoft Entra ID, Okta o Google Workspace per il login social o SSO, i loro endpoint di autenticazione devono essere inseriti nel walled garden.
- Domini CDN e di asset: la splash page potrebbe caricare CSS, JavaScript o font da una rete di distribuzione dei contenuti. Se tali domini CDN sono bloccati, la pagina viene visualizzata in modo errato.
- Domini del processore di pagamento: se addebiti un costo per l'accesso tramite Stripe o un altro processore, i domini del loro SDK JavaScript devono essere pre-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 problema di autorizzazione
RADIUS (Remote Authentication Dial-In User Service) è il protocolto che collega il gateway locale alla piattaforma di autenticazione. Quando un ospite compila 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 quel messaggio aprendo o mantenendo chiusa la regola del firewall che garantisce l'accesso a internet.
Il problema di autorizzazione - in cui un ospite effettua correttamente il login 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 stadi, nei centri congressi e negli snodi di trasporto, l'esaurimento del DHCP è una causa frequente di problemi di connessione che si manifesta in modo identico a un guasto 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 la sonda HTTP e non raggiunge mai il captive portal. Il dispositivo risulta connesso al SSID ma non ha accesso a internet.
Per sedi come il Manchester Airports Group (MAG), dove i volumi di passeggeri registrano picchi improvvisi, le subnet 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 o Fortinet - se integrata con l'overlay cloud di Purple.
Passaggio 1: Configura il SSID per il captive portal esterno. Nel controller hardware, imposta il SSID guest per reindirizzare i client non autenticati all'URL del portale esterno di Purple. Disabilita qualsiasi splash page locale sul controller stesso.
Passaggio 2: Definisci il walled garden. Aggiungi come minimo i seguenti domini: gli endpoint del portale e RADIUS di Purple (consulta la guida all'integrazione dell'hardware), gli URL delle sonde di rilevamento del sistema operativo elencati sopra, i domini del tuo provider di identità (Microsoft Entra ID, Okta o Google Workspace) e tutti i domini CDN utilizzati dagli asset della tua splash page.
Passaggio 3: Configura RADIUS. Inserisci gli indirizzi IP dei server RADIUS di Purple, la chiave segreta condivisa presa dalla tua dashboard Purple, quindi imposta la porta di autenticazione su 1812 e la porta di accounting su 1813. Verifica che il tuo firewall locale consenta il traffico UDP in uscita su queste porte.
Passaggio 4: Imposta i parametri di sessione. Per il settore hospitality e retail, imposta la durata della sessione a 24 ore con la memorizzazione nella cache degli indirizzi MAC abilitata. Questo evita che gli ospiti debbano autenticarsi nuovamente durante la stessa visita. Per gli ambienti ad alta sicurezza, sono più indicati tempi di sessione più brevi con autenticazione periodica.
Passaggio 5: Dimensiona il tuo ambito DHCP. Calcola il numero massimo di dispositivi simultanei per la tua sede alla massima capacità. Un ristorante da 500 posti può registrare fino a 800 dispositivi durante un servizio intenso. Dimensiona il pool DHCP a 1.000 indirizzi con un tempo di lease di 30 minuti.
Passaggio 6: Test su diversi sistemi operativi. Al termine della configurazione, testa l'intero flusso su dispositivi iOS, Android e Windows. Ognuno di essi utilizza un URL di sonda e un'implementazione WebView differenti. Un malfunzionamento su una singola piattaforma mentre le altre funzionano indica quasi sempre una lacuna nel walled garden.
Hai domande sulla tua configurazione specifica?
Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.
Best practice

Le seguenti raccomandazioni riflettono gli standard e i modelli applicati in oltre 80.000 installazioni di Purple.
Reti separate per ospiti e personale. Gestisci almeno tre SSID: Guest WiFi, Staff WiFi e una rete IoT. Il traffico degli ospiti deve essere isolato dai sistemi interni. Consulta la nostra guida su Tre SSID per dominarli tutti: guest, Passpoint, e IoT WiFi per i dettagli sull'architettura.
Usa una VLAN dedicata agli ospiti. Segmenta il traffico degli ospiti nella propria VLAN per impedire movimenti laterali e semplificare le policy del firewall. Questo è un requisito PCI-DSS se i dati delle carte di pagamento transitano sulla rete.
Implementa l'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 dei dati in modo chiaro, con caselle di controllo separate per ciascuna finalità. Questo non è facoltativo per le strutture che operano nel Regno Unito o nell'UE.
Monitora la salute del portale in modo proattivo. La piattaforma di 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 opt-in e definisce le aspettative per l'esperienza WiFi. Vedi Come fare un'ottima prima impressione con il tuo guest WiFi per linee guida sul design.
-
Risoluzione dei problemi e mitigazione dei rischi
Quando viene segnalato un problema al Captive Portal, segui questa sequenza diagnostica prima di apportare qualsiasi modifica alla configurazione.
Isola il punto di errore. Chiedi all'ospite quale iOS, Android o altro sistema operativo e browser sta utilizzando. Testa lo stesso flusso tu stesso sul medesimo sistema operativo. Se il problema è specifico del sistema operativo, la causa è quasi certamente l'assenza di una voce nel walled garden per l'URL di probe di quel sistema operativo.
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 tuo 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 di sviluppo del browser (F12) o una cattura di pacchetti per osservare lo scambio HTTP. Dovresti vedere la richiesta di probe del sistema operativo 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, il sistema operativo ha già stabilito di avere accesso a internet (probabilmente da uno stato memorizzato nella cache) e non sta inviando il probe.Verificare la comunicazione RADIUS. Sul gateway, controllare i log di accounting RADIUS. Un'autenticazione riuscita produce un record di Accounting-Start. Se non si visualizzano record di accounting dopo l'accesso di un ospite, la comunicazione RADIUS è interrotta. Verificare il shared secret, l'IP del server e le regole del firewall.
Controllare l'utilizzo dei lease DHCP. Sul server DHCP, verificare il numero di lease attivi rispetto alle dimensioni del pool. Se l'utilizzo supera il 90%, si è vicini all'esaurimento. Ampliare il pool o ridurre immediatamente il tempo di lease.
La seguente tabella mappa i sintomi più comuni con le relative cause principali e soluzioni.
| Sintomo | Causa principale più probabile | Soluzione |
|---|---|---|
| Il portale non appare su nessun dispositivo | Probe del sistema operativo bloccato dall'ACL del gateway | Aggiungere gli URL di probe alla allow list pre-auth |
| Il portale appare su iOS, ma non su Android | URL di probe Android mancante dal walled garden | Aggiungere connectivitycheck.gstatic.com al walled garden |
| Errore del certificato HTTPS al caricamento del portale | Il gateway intercetta l'HTTPS invece dell'HTTP | Affidarsi solo all'intercettazione del probe HTTP |
| Il portale si carica, ma non c'è internet dopo il login | RADIUS Access-Accept non ricevuto dal gateway | Verificare il shared secret, le porte 1812/1813 e l'IP del server RADIUS |
| Il pulsante di social login fallisce senza errori | Dominio dell'identity provider non presente nel walled garden | Aggiungere gli endpoint di Microsoft Entra ID / Google Workspace |
| Gli ospiti devono ripetere l'autenticazione a ogni visita | Durata della sessione troppo breve o caching MAC disabilitato | Impostare la sessione a 24 ore, abilitare il caching degli indirizzi MAC |
| Errori intermittenti nelle ore di punta | Esaurimento del pool DHCP | Ampliare la subnet, ridurre il tempo di lease |
-
ROI e impatto aziendale
Ogni errore del Captive Portal rappresenta un evento di acquisizione dati mancato. La piattaforma Guest WiFi di Purple converte 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 del settore hospitality 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 sensibilmente più elevati rispetto alle liste acquistate.
Per gli operatori del settore 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 diverse sedi. Purple ha raccolto 29 miliardi di punti dati (dati interni Purple) all'interno della sua rete di sedi. Tali dati sono utili solo nella misura in cui lo è il tasso di autenticazione che li genera.
Per gli hub 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 si guasta in modo intermittente durante i periodi di picco delle partenze genera reclami e danneggia il Net Promoter Score della struttura. Per gli ambienti sanitari, un WiFi per i visitatori affidabile riduce la pressione sul personale clinico che altrimenti dovrebbe gestire i reclami relativi alla connettività, e supporta le metriche sull'esperienza dei pazienti.
La SLA di uptime del 99.999% di Purple garantisce che l'overlay cloud stesso non rappresenti il punto di guasto. Quando si verificano problemi con il portale, la causa è quasi sempre una configurazione locale - che questa guida ti aiuta a risolvere senza dover aprire un ticket di supporto.
Riferimenti
[1] Troubleshooting Tip: General captive portal explanation, flow and troubleshooting. Fortinet Community, novembre 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, febbraio 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, febbraio 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 iniziale di connettività HTTP 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 ai corridoi degli stadi. Definito nella specifica RFC 8910.
Walled garden
L'insieme di domini e indirizzi IP che un dispositivo può raggiungere prima di completare l'autenticazione tramite Captive Portal. Il traffico verso le destinazioni del walled garden bypassa i requisiti di autenticazione.
Deve includere gli URL di probe 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 si trova dietro un Captive Portal. Definito nella documentazione di rete Microsoft.
Se il gateway blocca questo probe, Windows segnala "Nessun accesso a Internet" e non avvia mai la WebView del Captive Portal. La soluzione consiste nell'aggiungere l'URL NCSI alla whitelist di pre-autenticazione.
HSTS (HTTP Strict Transport Security)
Una politica di sicurezza web definita nella RFC 6797 che impone ai browser di rifiutare connessioni HTTP non protette 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, incluso 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 verso la pagina di accesso del Captive Portal. Alcuni gateway utilizzano in alternativa l'HTTP 303 o l'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 alle 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 durante brevi disconnessioni e visite ripetute all'interno della finestra temporale della sessione. Essenziale per gli ambienti hospitality in cui gli ospiti si spostano tra diverse aree.
Network basati sull'identità
Il modello di architettura di Purple in cui i criteri di accesso, l'assegnazione della VLAN e le analisi vengono applicati in base all'identità autenticata dell'utente anziché al solo indirizzo IP o MAC del dispositivo.
Consente il controllo granulare degli accessi, esperienze personalizzate e l'attribuzione accurata del comportamento di rete ai singoli utenti su hardware Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.
Saturazione del 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 punta. Si manifesta in modo identico a un errore del Captive Portal: il dispositivo risulta connesso al SSID ma non ha Internet. Diagnosticato verificando l'utilizzo dei lease DHCP sul server.
Esempi pratici
Un hotel di 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 interrogano captive.apple.com, che probabilmente è già inserito nella whitelist. I dispositivi Android interrogano 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 pre-autenticazione consentita 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 ed eseguire un test su un dispositivo Android ripristinato alle impostazioni di fabbrica per confermare la correzione, poiché lo stato di rete memorizzato nella cache su un dispositivo precedentemente connesso potrebbe mascherare il risultato.
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 comunque 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 proveniente dai server RADIUS di Purple. Il team dovrebbe verificare tre elementi in sequenza: in primo luogo, verificare che il segreto condiviso RADIUS sulla dashboard Meraki corrisponda esattamente al segreto nel portale Purple (una singola differenza di 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 modifica dell'indirizzo IP del server RADIUS di Purple che non è stata propagata alle configurazioni Meraki.
Domande di esercitazione
Q1. Durante una conferenza importante in una struttura 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 un numero di associazioni normale. 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 all'inizio. Considera quale risorsa si esaurisce man mano che si connettono più dispositivi.
Visualizza risposta modello
La causa più probabile è l'esaurimento del pool DHCP. All'arrivo dei partecipanti che si sono associati all'SSID, il pool DHCP si è riempito. I nuovi dispositivi si associano all'access point ma non riescono a ottenere un indirizzo IP, quindi 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 dai dispositivi che si sono allontanati) e, se possibile, espandere il pool aggiungendo una seconda subnet. La soluzione a lungo termine consiste nel dimensionare il pool DHCP per il numero massimo di dispositivi simultanei per il prossimo evento, non sulla base della media.
Q2. Hai distribuito Purple su access point Ubiquiti UniFi presso una catena di negozi. La splash page viene caricata correttamente su tutti i dispositivi. Gli ospiti 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 gli accessi come riusciti. Cosa controlli per primo?
Suggerimento: La piattaforma cloud ha registrato l'autenticazione. L'errore risiede nella fase di applicazione locale.
Visualizza risposta modello
Poiché la dashboard di Purple mostra accessi riusciti, la fase di autenticazione cloud è stata completata correttamente. L'errore è nella fase di autorizzazione RADIUS - il controller UniFi non riceve o non applica il messaggio di Access-Accept proveniente dai server RADIUS di Purple. Controlla in questo ordine: (1) che il segreto condiviso RADIUS sul controller UniFi corrisponda esattamente al segreto nella dashboard di Purple; (2) che il traffico UDP in uscita sulle porte 1812 e 1813 sia consentito dal controller verso gli indirizzi IP del server RADIUS di Purple; (3) che gli indirizzi IP del server RADIUS configurati sul controller UniFi siano aggiornati (Purple potrebbe averli aggiornati). Un'acquisizione di pacchetti sul controller confermerà se il messaggio di Access-Accept sta arrivando.
Q3. Un responsabile IT di un hotel riferisce che gli ospiti che utilizzano una VPN sui propri dispositivi non riescono affatto 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 accogliere gli utenti VPN?
Suggerimento: Considera cosa fa una VPN 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 lo abbandoni, inclusa la sonda di connettività HTTP. Il gateway non può intercettare il traffico VPN crittografato, quindi non emette mai il redirect 302. L'ospite deve disattivare la propria VPN, completare l'autenticazione sul Captive Portal e poi riattivare la VPN. Questo è un vincolo 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
Ubiquiti UniFi guest portal non reindirizza: cause e soluzioni
Questa guida isola un errore di reindirizzamento del portale ospiti UniFi analizzando in sequenza lo stato dell'ospite, il reindirizzamento, il percorso di pre-autorizzazione e l'autorizzazione del controller. Fornisce ai team IT locali un metodo collaudato per risolvere i dubbi tra rete ospiti e Hotspot, i passaggi ai portali esterni, i requisiti correnti degli account UniFi OS e i test di isolamento DNS.
Cisco Meraki splash page non funzionante: un diagramma di flusso per la risoluzione dei problemi
Questa guida pratica per il secondo giorno isola i punti in cui un flusso splash Cisco Meraki ha fallito: autorizzazione del client, avvio del reindirizzamento HTTP, raggiungibilità del walled garden o sign-on RADIUS. Fornisce ai team IT delle sedi un percorso di verifica controllato, in modo da poter ripristinare il Guest WiFi senza apportare modifiche generiche a un'intera infrastruttura attiva.
Guida alla configurazione del WiFi ospiti aziendale: segmentazione VLAN, sicurezza e Captive Portals
Questa guida tecnica mostra ai team IT come configurare il WiFi ospiti come servizio di accesso internet controllato, utilizzando la segmentazione VLAN, le policy del firewall e un Captive Portal. Spiega inoltre come i moduli di registrazione e i controlli di onboarding di Purple supportino un'esperienza per i visitatori proporzionata senza indebolire il perimetro che circonda il personale, i pagamenti e i sistemi operativi.
Hai domande sulla tua configurazione specifica?
Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.