Risoluzione dei problemi della WiFi pubblica: come risolvere "Connesso, senza Internet" e i problemi di reindirizzamento della Splash Page

Benvenuto in questo briefing tecnico di Purple. Oggi affronteremo uno dei problemi più persistenti e fraintesi nelle reti wireless aziendali: il Captive Portal del WiFi per gli ospiti che si 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 accesso. Nessuna connessione internet. Solo un'icona che gira e un crescente senso di frustrazione. Per i direttori delle operazioni della struttura e per i manager IT, quel momento non è solo un piccolo inconveniente. Rappresenta un fallimento diretto della tua esperienza ospite, un picco di chiamate di supporto alla reception e un'opportunità mancata per raccogliere i dati di prima parte che giustificano il tuo investimento nell'infrastruttura wireless. In questo briefing, andremo 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 quadro di risoluzione dei problemi pratico e applicabile che potrai consegnare al tuo team IT oggi stesso. Iniziamo con il funzionamento tecnico. La maggior parte delle persone pensa a un Captive Portal semplicemente come a una pagina di accesso. 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 per gli ospiti 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 verso un URL di prova 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 suo probe su detectportal.firefox.com. Se la rete ha un accesso a internet aperto, questi probe restituiscono le risposte attese e il sistema operativo conclude che tutto è a posto. Ma su una rete ospiti, il tuo gateway wireless o controller intercetta quel probe HTTP prima che raggiunga internet. Invece della risposta attesa, il gateway restituisce un reindirizzamento HTTP 307 che punta alla pagina di accesso 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 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 slash-24 standard, hai 254 indirizzi IP utilizzabili. Se il tempo di lease DHCP è impostato sul valore predefinito di 24 ore, esaurirai quel pool nel giro di pochi minuti dall'apertura delle porte. Ogni tentativo di connessione successivo fallisce prima ancora che la sequenza del Captive Portal abbia inizio. La soluzione è semplice: imposta i tempi di lease DHCP per gli ospiti tra 15 e 30 minuti per gli ambienti ad alto turnover e dimensiona le subnet in modo appropriato per il picco di utenti simultanei, non solo per il numero totale di persone. 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 autenticati di risolvere i nomi di dominio esterni, il probe non si avvia 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 una cattura dei pacchetti 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 si trova nel walled garden, la pagina viene visualizzata come uno schermo vuoto. Se offri il social login tramite Google, Apple o Facebook, ogni dominio OAuth utilizzato da tali provider deve essere inserito nella whitelist. E qui c'è 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 oggi potrebbe essersi interrotto silenziosamente. Pianifica verifiche trimestrali del walled garden e utilizza lo snooping dei domini con caratteri jolly dove l'hardware lo supporta. Su Cisco Meraki, HPE Aruba, Ruckus e Juniper Mist, questa funzionalità è disponibile nativamente. Causa principale numero quattro: HSTS che blocca il reindirizzamento. HTTP Strict Transport Security, o HSTS, è una policy di sicurezza del browser che impone connessioni a domini specifici esclusivamente 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 tuo gateway dovrebbe reindirizzare solo i canary probe HTTP non crittografati. La soluzione a lungo termine basata sugli standard è 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 del tutto la necessità di reindirizzamento HTTP. iOS 14, Android 11 e versioni successive supportano questa funzione in modo nativo. Causa principale numero cinque: VPN attiva sul dispositivo ospite. Una VPN crittografa tutto il traffico dal dispositivo e lo instrada attraverso un tunnel esterno prima che raggiunga il gateway. Il gateway non intercetta mai la richiesta HTTP di prova. 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 che 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, può presentare un indirizzo MAC diverso. Poiché lo stato della sessione del Captive Portal viene tracciato tramite l'indirizzo MAC, a un ospite che si è autenticato un'ora prima potrebbe essere presentata nuovamente la pagina di login dopo la rotazione del MAC del suo dispositivo. La soluzione lato ospite consiste nel disattivare l'opzione Indirizzo Privato per lo SSID specifico nelle impostazioni di rete. La soluzione lato operatore consiste nell'implementare l'autenticazione basata su profilo - come OpenRoaming tramite Passpoint e 802.1X - che autentica al Layer 2 utilizzando le credenziali anziché gli indirizzi MAC, rendendo irrilevante la randomizzazione. Parliamo ora di implementazione. Come si presenta in pratica un deployment di un Captive Portal ben configurato? Inizia con la tua architettura DHCP. Per qualsiasi sede che preveda più di 200 dispositivi simultanei, abbandona la singola sottorete slash-24. Utilizza una slash-22 o superiore e imposta i tempi di lease in base al profilo di permanenza della tua sede. 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 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 di intera sede. Un errore comune che trae in inganno molti team IT: testare il portale da un dispositivo che si è autenticato in precedenza. La sessione del dispositivo è ancora attiva, quindi bypassi completamente il portale e concludi che tutto funzioni. Esegui sempre i test da un dispositivo in uno stato nuovo e non autenticato - o un nuovo dispositivo, o uno in cui hai rimosso la rete e cancellato il profilo WiFi.Lascia che ti presenti due scenari reali che illustrano questi principi. Scenario uno: un hotel da 350 camere nel centro di Londra. La struttura gestiva una singola sottorete slash-24 per il WiFi degli ospiti. Durante una grande conferenza, 400 delegati sono arrivati contemporaneamente. Nel giro di 20 minuti, il pool DHCP si è esaurito. Gli ospiti hanno riferito di essere connessi ma impossibilitati a raggiungere il Captive Portal o internet. La soluzione immediata è stata quella di estendere la sottorete a slash-22, offrendo 1.022 indirizzi utilizzabili, e di ridurre il tempo di lease 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 login social tramite Google e Facebook sul proprio portale ospiti. Dopo che Google ha aggiornato la sua infrastruttura OAuth, i nuovi domini di autenticazione non erano presenti nel walled garden. Gli ospiti potevano raggiungere la pagina del portale, ma i pulsanti di login social 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 identificata, la correzione ha richiesto 10 minuti. La lezione: non inserire mai indirizzi IP statici nel walled garden per i provider OAuth basati su cloud. Utilizza voci di dominio con caratteri jolly e rivedile trimestralmente. Ora passiamo ad alcune domande rapide che riceviamo regolarmente dai team IT delle strutture. 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 tuo firewall o non è nel tuo 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. Questo è quasi sempre un errore di autorizzazione RADIUS. Verifica che il tuo server RADIUS sia raggiungibile dal controller wireless, verifica che la chiave segreta condivisa corrisponda su entrambi i lati e controlla i log RADIUS per individuare eventuali messaggi di Access-Reject. Come gestiamo gli ospiti che continuano a essere disconnessi dopo pochi minuti? Controlla l'impostazione del timeout di inattività. Molti controller sono impostati di default su un timeout di inattività di 5 minuti, che è decisamente troppo aggressivo per i dispositivi mobili che entrano in modalità di sospensione tra un'interazione e l'altra. Imposta il timeout di inattività ad almeno 30 minuti per gli ambienti alberghieri e retail. Per riassumere i punti chiave del briefing di oggi. I malfunzionamenti del Captive Portal del WiFi per gli 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 sottorete, convalidare il walled garden rispetto ai domini OAuth correnti dei tuoi provider di login social e testare il portale da un 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 ricorrenti. La tecnologia è matura, gli standard sono stabiliti ai sensi di IEEE 802.1X e WPA3-Enterprise, e Purple la rende disponibile senza costi software aggiuntivi nell'ambito del piano Connect. Purple opera in oltre 80.000 sedi e ha gestito 440 milioni di accessi solo nel 2024. Abbiamo visto ogni singola modalità di guasto descritta in questo briefing - e abbiamo sviluppato gli strumenti per prevenirle. 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.