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

Benvenuto in questo briefing tecnico di Purple. Oggi affronteremo uno dei problemi più persistenti e fraintesi nel networking wireless aziendale: il Captive Portal del WiFi per gli ospiti che rifiuta categoricamente di caricarsi. Ci sei già passato. Un ospite arriva nel tuo hotel, nel tuo negozio, nel tuo stadio o nel tuo centro congressi. Si connette alla rete WiFi. Non succede nulla. Nessuna pagina di login. Nessun accesso a internet. Solo un'icona che gira e un crescente senso di frustrazione. Per i direttori delle operazioni delle strutture e i manager IT, quel momento non è solo un piccolo inconveniente. Rappresenta un fallimento diretto della tua guest experience, un picco di chiamate di supporto alla reception e un'opportunità persa per acquisire i dati di prima parte che giustificano il tuo investimento nell'infrastruttura wireless. In questo briefing, guarderemo sotto il cofano. Spiegheremo esattamente come funziona il rilevamento del Captive Portal a livello di sistema operativo, identificheremo le sei cause principali responsabili della stragrande maggioranza dei fallimenti di connessione e ti forniremo un framework di risoluzione dei problemi pratico e applicabile che potrai consegnare al tuo team IT oggi stesso. Iniziamo con i meccanismi. La maggior parte delle persone pensa a un Captive Portal semplicemente come a una pagina di login. In realtà si tratta di un meccanismo di intercettazione del traffico a livello di rete, e questa distinzione è estremamente importante quando le cose vanno storte. Ecco la sequenza. Il dispositivo di un ospite si connette al tuo SSID ospite e riceve un indirizzo IP tramite DHCP. A quel punto, il sistema operativo non aspetta che l'utente apra un browser. In background, un servizio di sistema avvia immediatamente una richiesta HTTP GET non crittografata a un URL di probe controllato dal fornitore. I dispositivi Apple interrogano captive.apple.com. I dispositivi Android interrogano connectivitycheck.gstatic.com. I dispositivi Windows interrogano msftconnecttest.com. Firefox ha il proprio probe su detectportal.firefox.com. Se la rete ha un accesso a internet aperto, questi probe restituiscono le risposte previste e il sistema operativo conclude che tutto è a posto. Ma su una rete ospite, il tuo gateway o controller wireless intercetta quel probe HTTP prima che raggiunga internet. Invece della risposta prevista, il gateway restituisce un reindirizzamento HTTP 307 che punta alla pagina di splash del tuo Captive Portal. Il sistema operativo rileva il reindirizzamento imprevisto, si rende conto di trovarsi dietro a un Captive Portal e apre una finestra del browser in sandbox - spesso chiamata Captive Network Assistant - per mostrare la pagina di login. Questo è lo scenario ideale. Ora parliamo dei sei modi in cui questo processo si interrompe. Causa principale numero uno: esaurimento del pool DHCP. Questo è il killer silenzioso negli eventi ad alta densità. Se stai gestendo una conferenza con duemila partecipanti su una subnet standard /24, hai 254 indirizzi IP utilizzabili. Se il tempo di lease DHCP è impostato sul valore predefinito di 24 ore, esaurirai quel pool a pochi minuti dall'apertura delle porte. Ogni tentativo di connessione successivo fallisce prima ancora che inizi la sequenza del captive portal. La soluzione è semplice: imposta i tempi di lease DHCP per gli ospiti tra 15 e 30 minuti per gli ambienti ad alto ricambio e dimensiona le subnet in modo appropriato per il picco di utenti simultanei, non solo per il numero totale di partecipanti. Causa principale numero due: errore di intercettazione DNS. Il reindirizzamento al captive portal dipende dal gateway che intercetta il probe HTTP. Ma il probe richiede prima una ricerca DNS. Se la configurazione DNS non consente ai client non ancora autenticati di risolvere i nomi di dominio esterni, il probe non si attiva mai. Assicurati che la policy del firewall consenta esplicitamente le query DNS da parte di client non autenticati e verifica che l'intercettazione DNS funzioni eseguendo un packet capture su un dispositivo di test. Causa principale numero tre: walled garden incompleto. Il walled garden - chiamato anche lista di controllo degli accessi pre-autenticazione - definisce quali domini esterni possono essere raggiunti dagli ospiti non autenticati. Se la splash page del tuo portale carica risorse da una CDN che non è nel walled garden, la pagina viene visualizzata come una schermata vuota. Se offri il social login tramite Google, Apple o Facebook, ogni dominio OAuth utilizzato da tali provider deve essere inserito nella whitelist. E qui sta il punto cruciale: i provider di identità social aggiornano regolarmente i propri intervalli IP CDN e i domini di autenticazione. Un walled garden che funzionava perfettamente sei mesi fa potrebbe essere silenziosamente compromesso oggi. Pianifica audit trimestrali del walled garden e utilizza lo snooping dei domini con caratteri jolly dove il tuo hardware lo supporta. Su Cisco Meraki, HPE Aruba, Ruckus e Juniper Mist, questa funzionalità è disponibile nativamente. Causa principale numero quattro: l'HSTS blocca il reindirizzamento. L'HTTP Strict Transport Security, o HSTS, è una policy di sicurezza del browser che forza le connessioni a domini specifici solo tramite HTTPS. Se il dispositivo di un ospite tenta di contattare un dominio precaricato HSTS - e questo include praticamente ogni sito web principale - e il tuo gateway tenta di intercettare quella richiesta HTTPS per reindirizzarla al portale, il browser rileva una mancata corrispondenza del certificato. Presenta un avviso di sicurezza non ignorabile e blocca completamente il reindirizzamento. La soluzione corretta consiste nel non tentare mai l'intercettazione HTTPS. Il gateway dovrebbe reindirizzare solo i canary probe HTTP non crittografati. La soluzione a lungo termine basata sugli standard è l'RFC 8910, che definisce l'Opzione DHCP 114. Questa opzione consente al server DHCP di pubblicizzare direttamente l'URL del captive portal al dispositivo client, eliminando completamente la necessità di reindirizzamento HTTP. iOS 14 e Android 11 e versioni successive supportano questa funzionalità nativamente. Causa principale numero cinque: VPN attiva sul dispositivo ospite. Una VPN crittografa tutto il traffico dal dispositivo e lo indirizza attraverso un tunnel esterno prima che raggiunga il gateway. Il gateway non vede mai il probe HTTP. La sequenza di rilevamento del captive portal non si attiva mai. L'ospite non vede alcuna pagina di login e non ha accesso a Internet. La soluzione per l'ospite è semplice: disattivare la VPN, connettersi al portale, quindi riattivare la VPN. Per il personale di reception, questa dovrebbe essere la prima domanda da porre quando un ospite segnala un problema di connessione. Causa principale numero sei: la randomizzazione dell'indirizzo MAC interrompe la persistenza della sessione. I moderni dispositivi iOS e Android utilizzano indirizzi MAC randomizzati per impostazione predefinita come funzionalità di privacy. Ogni volta che un dispositivo si connette a una rete, potrebbe presentare un indirizzo MAC diverso. Poiché lo stato della sessione del captive portal è tracciato tramite l'indirizzo MAC, a un ospite che si è autenticato un'ora fa potrebbe essere presentata nuovamente la pagina di login dopo la rotazione del MAC del dispositivo. La soluzione lato ospite consiste nel disattivare l'Indirizzo Privato per lo specifico SSID nelle impostazioni di rete. La soluzione lato operatore consiste nell'implementare un'autenticazione basata su profilo, come OpenRoaming tramite Passpoint e 802.1X, che autentica al Livello 2 utilizzando le credenziali anziché gli indirizzi MAC, rendendo irrilevante la randomizzazione. Ora parliamo di implementazione. Come si presenta in pratica una distribuzione di un captive portal ben configurata? Inizia con la tua architettura DHCP. Per qualsiasi struttura che prevede più di 200 dispositivi contemporanei, evita una singola sottorete slash-24. Utilizza una slash-22 o superiore e imposta i tempi di lease in base al profilo di permanenza della tua struttura. Un hotel imposta i lease a 8 ore. Uno stadio imposta i lease a 3 ore. Un centro commerciale imposta i lease a 90 minuti. Un centro congressi imposta i lease a 30 minuti. Successivamente, convalida il tuo walled garden prima di ogni evento importante. Le voci minime richieste sono: il nome di dominio completo (FQDN) del tuo portale e tutti i domini CDN associati, gli URL di rilevamento del captive portal per Apple, Google, Windows e Firefox, e i domini OAuth per ogni provider di social login supportato. Sulla piattaforma Purple, manteniamo e aggiorniamo automaticamente queste voci di walled garden come parte del nostro servizio gestito in cloud, eliminando l'onere della manutenzione manuale per il tuo team. Per il certificato del tuo portale, utilizza un certificato TLS pubblicamente attendibile emesso da un'autorità di certificazione riconosciuta. I certificati autofirmati genereranno avvisi del browser su ogni dispositivo. Rinnova i certificati prima della scadenza: un certificato scaduto è una delle cause più comuni di improvvisi malfunzionamenti del portale a livello dell'intera struttura. Un errore comune che trae in inganno molti team IT: testare il portale da un dispositivo che si è autenticato in precedenza. La sessione del tuo dispositivo è ancora attiva, quindi eviti completamente il portale e concludi che tutto funzioni. Esegui sempre i test da un dispositivo in uno stato nuovo e non autenticato: un nuovo dispositivo o uno in cui hai dimenticato la rete e cancellato il profilo WiFi. Ecco due scenari reali che illustrano questi principi. Scenario uno: un hotel da 350 camere nel centro di Londra. La struttura gestiva una singola subnet slash-24 per il WiFi degli ospiti. Durante una grande conferenza, sono arrivati contemporaneamente 400 delegati. Nel giro di 20 minuti, il pool DHCP si è esaurito. Gli ospiti riferivano di essere connessi ma impossibilitati a raggiungere il portale o internet. La soluzione immediata è stata quella di estendere la subnet a slash-22, offrendo 1.022 indirizzi utilizzabili, e di ridurre il lease time da 24 a 8 ore. La soluzione a lungo termine è stata l'implementazione del Captive Portal gestito in cloud di Purple, che monitora l'utilizzo del pool DHCP in tempo reale e avvisa il team di rete prima che si verifichi l'esaurimento. Il tasso di errore del portale è sceso quasi a zero entro 48 ore dalla modifica. Scenario due: una grande catena di vendita al dettaglio con 200 negozi. La catena utilizzava il social login tramite Google e Facebook sul portale ospiti. Dopo che Google ha aggiornato la sua infrastruttura OAuth, i nuovi domini di autenticazione non erano inclusi nel walled garden. Gli ospiti potevano raggiungere la pagina del portale, ma i pulsanti di social login mostravano schermate vuote. Il team IT della catena ha impiegato due giorni per diagnosticare il problema prima di identificare la lacuna nel walled garden. Una volta individuata, la soluzione ha richiesto solo 10 minuti. La lezione: non inserire mai indirizzi IP hardcoded nel walled garden per i provider OAuth basati su cloud. Utilizza record di dominio con wildcard e verificali trimestralmente. Ora passiamo ad alcune domande rapide che riceviamo regolarmente dai team IT delle location. Perché il portale funziona su iPhone ma non sui dispositivi Android? Android utilizza connectivitycheck.gstatic.com come URL di probe. Se quel dominio è bloccato dal firewall o non è nel walled garden, i dispositivi Android non attiveranno mai il portale. Aggiungilo esplicitamente. Un ospite riferisce che il portale si è caricato ma non riesce a navigare dopo l'accesso. Nella quasi totalità dei casi, si tratta di un errore di autorizzazione RADIUS. Verifica che il server RADIUS sia raggiungibile dal controller wireless, che la chiave segreta condivisa corrisponda su entrambi i lati e controlla i log RADIUS per individuare eventuali messaggi di Access-Reject. Come gestire gli ospiti che continuano a essere disconnessi dopo pochi minuti? Controlla l'impostazione dell'idle timeout. Molti controller impostano come predefinito un idle timeout di 5 minuti, decisamente troppo aggressivo per i dispositivi mobili che vanno in modalità standby tra un'interazione e l'altra. Imposta l'idle timeout a un minimo di 30 minuti per gli ambienti retail e hospitality. Per riassumere i punti chiave del briefing di oggi. I problemi del Captive Portal del WiFi ospiti rientrano in sei categorie: esaurimento del pool DHCP, errore di intercettazione DNS, walled garden incompleto, blocco del reindirizzamento HSTS, VPN attiva sul dispositivo client e randomizzazione dell'indirizzo MAC. Ognuno di essi ha una soluzione specifica e testabile. Per il tuo team IT, le azioni immediate sono: verificare i tempi di lease DHCP e il dimensionamento della subnet, convalidare il walled garden rispetto ai domini OAuth attuali dei provider di social login e testare il portale da un nuovo dispositivo non autenticato dopo ogni modifica della configurazione. Per la tua roadmap a lungo termine, valuta OpenRoaming come successore della riautenticazione tramite captive portal per i visitatori di ritorno. La tecnologia è matura, gli standard sono stabiliti secondo IEEE 802.1X e WPA3-Enterprise, e Purple lo rende disponibile senza costi software aggiuntivi nell'ambito del piano Connect. Purple opera in oltre 80.000 location e ha elaborato 440 milioni di login solo nel 2024. Abbiamo riscontrato ogni modalità di errore descritta in questo briefing e abbiamo sviluppato gli strumenti per prevenirli. Se desideri scoprire come l'overlay cloud di Purple si integra con la tua infrastruttura esistente Cisco Meraki, HPE Aruba, Ruckus o Juniper Mist, visita purple.ai o contatta il tuo account manager. Grazie per l'attenzione.