Risoluzione dei problemi della rete WiFi pubblica: come risolvere i problemi "Connesso, senza Internet" e gli errori di reindirizzamento alla pagina di benvenuto

Benvenuti in questo briefing tecnico di Purple. Oggi affronteremo uno dei problemi più persistenti e meno compresi nelle reti wireless aziendali: il Captive Portal del WiFi per gli ospiti che si rifiuta di caricarsi. Ci siete già passati. Un ospite arriva nel vostro hotel, nel vostro negozio retail, nel vostro stadio o nel vostro 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 responsabili IT, quel momento non è solo un piccolo inconveniente. Rappresenta un fallimento diretto della vostra esperienza ospite, un picco di chiamate di supporto alla reception e un'opportunità persa di raccogliere i dati di prima parte che giustificano il vostro investimento nell'infrastruttura wireless. In questo briefing analizzeremo i dettagli tecnici. Vi 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 vi forniremo un framework di risoluzione dei problemi pratico e applicabile da consegnare oggi stesso al vostro team IT. Iniziamo con il funzionamento tecnico. 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 non funzionano. Ecco la sequenza. Il dispositivo di un ospite si connette al vostro 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 a un URL di probe controllato dal vendor. I dispositivi iOS e macOS 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 attese e il sistema operativo conclude che è tutto a posto. Ma su una rete ospiti, il vostro gateway o controller wireless intercetta quel probe HTTP prima che raggiunga internet. Invece della risposta attesa, il gateway restituisce un reindirizzamento HTTP 307 che punta alla pagina di cortesia del vostro 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 visualizzare 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 slash-24, 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 fallirà 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 alta rotazione 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 risoluzione DNS. Se la configurazione DNS non consente ai client non autenticati di risolvere i nomi di dominio esterni, il probe non viene mai avviato. 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 è inclusa nel walled garden, la pagina verrà visualizzata come uno schermo vuoto. Se offri il login social tramite Google, Apple o Facebook, ogni dominio OAuth utilizzato da questi provider deve essere inserito nella whitelist. E c'è un punto critico: i provider di identità social aggiornano regolarmente i propri intervalli IP di CDN e i domini di autenticazione. Un walled garden che funzionava perfettamente sei mesi fa potrebbe essere silenziosamente non funzionante oggi. Pianifica audit trimestrali del walled garden e utilizza il wildcard domain snooping dove supportato dal tuo hardware. Su Cisco Meraki, HPE Aruba, Ruckus e Juniper Mist, questa funzionalità è disponibile nativamente. Causa principale numero quattro: HSTS che blocca il reindirizzamento. L'HTTP Strict Transport Security, o HSTS, è una policy di sicurezza del browser che forza le connessioni a domini specifici esclusivamente tramite HTTPS. Se il dispositivo di un ospite tenta di contattare un dominio precaricato con 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. Mostra quindi un avviso di sicurezza non bypassabile e blocca completamente il reindirizzamento. La soluzione corretta consiste nel non tentare mai l'intercettazione HTTPS. Il tuo gateway dovrebbe reindirizzare solo i probe canary 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 comunicare direttamente l'URL del Captive Portal al dispositivo client, eliminando del tutto la necessità di un reindirizzamento HTTP. iOS 14, Android 11 e versioni successive supportano questa funzione nativamente. La causa principale numero cinque: VPN attiva sul dispositivo dell'ospite. Una VPN crittografa tutto il traffico proveniente dal dispositivo e lo reindirizza attraverso un tunnel esterno prima che raggiunga il gateway. Il gateway non vede mai la sonda 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. La causa principale numero sei: la randomizzazione dell'indirizzo MAC che interrompe la persistenza della sessione. I moderni dispositivi iOS e Android utilizzano di default indirizzi MAC randomizzati come funzione 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, un ospite che si è autenticato un'ora fa potrebbe visualizzare nuovamente la pagina di login dopo la rotazione del MAC del proprio dispositivo. La soluzione lato ospite consiste nel disattivare l'opzione 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 Layer 2 utilizzando le credenziali anziché gli indirizzi MAC, rendendo irrilevante la randomizzazione. Parliamo ora dell'implementazione. Come si presenta in pratica una distribuzione di un Captive Portal ben configurata? Iniziate con la vostra architettura DHCP. Per qualsiasi sede che preveda più di 200 dispositivi simultanei, abbandonate la singola sottorete slash-24. Utilizzate una slash-22 o superiore e impostate i tempi di lease in base al profilo di permanenza della vostra 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, convalidate il vostro walled garden prima di ogni evento importante. Le voci minime richieste sono: il nome di dominio completo del vostro 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 del walled garden come parte del nostro servizio gestito in cloud, eliminando l'onere della manutenzione manuale per il vostro team. Per il certificato del vostro portale, utilizzate un certificato TLS pubblicamente attendibile rilasciato da un'autorità di certificazione riconosciuta. I certificati autofirmati genereranno avvisi del browser su ogni dispositivo. Rinnovate i certificati prima della scadenza - un certificato scaduto è una delle cause più comuni di improvvisi malfunzionamenti del portale a livello di intera struttura. Un tranello 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 si bypassa completamente il portale e si conclude che tutto funziona. Testate sempre da un dispositivo in uno stato nuovo e non autenticato - o un nuovo dispositivo, o uno sul quale avete dissociato la rete e cancellato il profilo WiFi.Lasciami presentare due scenari reali che illustrano questi principi. Scenario uno: un hotel da 350 camere nel centro di Londra. La struttura utilizzava una singola sottorete slash-24 per il WiFi degli ospiti. Durante un grande convegno, sono arrivati simultaneamente 400 delegati. Nel giro di 20 minuti, il pool DHCP si è esaurito. Gli ospiti riferivano di essere connessi ma non riuscivano a raggiungere il Captive Portal o internet. La soluzione immediata è stata quella di estendere la sottorete a una slash-22, fornendo 1.022 indirizzi utilizzabili, e di ridurre il tempo di lease da 24 ore 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 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 social login mostravano schermate vuote. Il team IT della catena ha trascorso due giorni a diagnosticare il problema prima di identificare la lacuna nel walled garden. Una volta individuato, la correzione ha richiesto solo 10 minuti. La lezione: non inserire mai indirizzi IP hardcoded nel walled garden per i provider OAuth basati su cloud. Utilizza voci di dominio con caratteri jolly e verificale trimestralmente. Ora passiamo ad alcune domande rapide che sentiamo 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 firewall o non è presente nel walled garden, i dispositivi Android non attiveranno mai il portale. Aggiungilo esplicitamente. Un ospite riferisce che il portale si è caricato ma non riesce ad andare online dopo aver effettuato l'accesso. Questo è quasi sempre un errore di autorizzazione RADIUS. Verifica che il server RADIUS sia raggiungibile dal controller wireless, verifica che la chiave segreta condivisa corrisponda su entrambi i lati e controlla i log di 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 vanno in sospensione tra un'interazione e l'altra. Imposta il timeout di inattività ad almeno 30 minuti per gli ambienti alberghieri e di vendita al dettaglio. Per riassumere i punti chiave del briefing di oggi. I problemi relativi ai Captive Portal delle reti 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 ha una soluzione specifica e testabile. Per il tuo team IT, le azioni immediate sono: verificare i tempi di lease DHCP e le dimensioni delle sottoreti, convalidare il walled garden rispetto ai domini OAuth correnti dei provider di social login e testare il portale da un dispositivo non autenticato dopo ogni modifica di configurazione.Per la tua roadmap a lungo termine, valuta OpenRoaming come successore del Captive Portal per la riautenticazione dei visitatori ricorrenti. La tecnologia è matura, gli standard sono stabiliti nell'ambito 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 riscontrato ogni tipo di errore descritto 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.