Perché il mio WiFi ospiti non si connette? Risoluzione dei problemi del captive portal

TITOLO: Perché il mio WiFi per ospiti non si connette? Risoluzione dei problemi del Captive Portal FORMATO: Podcast Purple Technical Briefing VOCE: Inglese britannico - Tono da Senior Solutions Architect DURATA: Circa 10 minuti --- SEZIONE 1: Introduzione e contesto - circa 1 minuto Salve e benvenuti a questo briefing tecnico di Purple. Sono il vostro presentatore e oggi affronteremo uno dei problemi più persistenti e meno compresi nelle reti wireless aziendali: il Captive Portal del WiFi per ospiti che si rifiuta categoricamente di caricarsi. Vi sarà sicuramente capitato. Un ospite arriva nel vostro hotel, nel vostro negozio, nel vostro stadio o nel vostro centro congressi. Si connette alla rete WiFi. Non succede nulla. Nessuna pagina di accesso. Nessuna connessione a internet. Solo un'icona che gira e un crescente senso di frustrazione. Per i direttori delle operazioni della struttura e per i responsabili IT, questo momento non è solo un piccolo inconveniente. Rappresenta un fallimento diretto della vostra esperienza per gli ospiti, un picco di chiamate di supporto alla reception e un'opportunità persa di acquisire i dati di prima parte che giustificano il vostro investimento nell'infrastruttura wireless. In questo briefing analizzeremo cosa succede 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 problemi di connessione e vi forniremo un quadro di risoluzione dei problemi pratico e attuabile che potrete consegnare al vostro team IT oggi stesso. Cominciamo. --- SEZIONE 2: Approfondimento tecnico - circa 5 minuti Per risolvere un problema relativo al Captive Portal, è prima necessario comprendere cosa fa effettivamente un Captive Portal a livello di rete. La maggior parte delle persone lo considera semplicemente come 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 vostro SSID per 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 test controllato dal produttore. 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 all'indirizzo detectportal.firefox.com. Se la rete ha un accesso a internet aperto, questi probe restituiscono le risposte previste e il sistema operativo deduce che è tutto a posto. Ma su una rete per ospiti, il vostro gateway o controller wireless intercetta quella richiesta HTTP prima che raggiunga internet. Al posto della risposta prevista, il gateway restituisce un reindirizzamento HTTP 302 che punta alla pagina di cortesia del vostro Captive Portal. Il sistema operativo rileva il reindirizzamento imprevisto, si rende conto di trovarsi dietro un Captive Portal e apre una finestra del browser sandbox - spesso chiamata Assistente Captive Portal - per visualizzare la pagina di login. Questo è il percorso 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 a pochi minuti dall'apertura delle porte. Ogni successivo tentativo di connessione 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 alta rotazione 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 del 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 un packet capture su un dispositivo di test. Causa principale numero tre: walled garden incompleto. Il walled garden - chiamato anche elenco di controllo degli accessi pre-autorizzazione - definisce quali domini esterni possono essere raggiunti dagli ospiti non autenticati. Se la tua splash page del portale carica elementi da una CDN che non si trova nel walled garden, la pagina viene visualizzata come una schermata vuota. Se offri il login social 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 potrebbe essere silenziosamente fuori uso 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 funzione è 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 tutti i principali siti web - e il gateway tenta di intercettare tale 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 probe canary HTTP non crittografati. La soluzione a lungo termine basata sugli standard è la specifica 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 e Android 11 e versioni successive supportano questa funzione in modo nativo. Causa principale numero cinque: VPN attiva sul dispositivo dell'ospite. Una VPN crittografa tutto il traffico 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 visualizza 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 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'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 esegue l'autenticazione al Layer 2 utilizzando le credenziali anziché gli indirizzi MAC, rendendo irrilevante la randomizzazione. - SEZIONE 3: Raccomandazioni di implementazione e insidie comuni - circa 2 minuti Ora che abbiamo compreso le cause principali, parliamo di come si presenta effettivamente un'installazione di un Captive Portal ben configurata. Inizia con la tua architettura DHCP. Per qualsiasi struttura 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 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: l'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 di Purple, manteniamo e aggiorniamo queste voci del walled garden in modo automatico 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 affidabile rilasciato 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 struttura. Un errore comune in cui incappano molti team IT: testare il portale da un dispositivo che si è precedentemente autenticato. La sessione del dispositivo è ancora attiva, quindi si salta completamente il portale concludendo che tutto funzioni correttamente. Esegui sempre i test da un dispositivo in uno stato pulito e non autenticato - o un nuovo dispositivo, o uno su cui hai rimosso la rete e cancellato il profilo WiFi. Infine, considera la direzione strategica del percorso. I Captive Portal sono una tecnologia matura, ma comportano un attrito intrinseco. OpenRoaming, basato su Passpoint e 802.1X, consente agli ospiti che ritornano di connettersi in modo automatico e sicuro senza mai visualizzare una pagina di login. Purple funge da identity provider gratuito per OpenRoaming con il nostro piano Connect. Strutture come Premier Inn e Manchester Airports Group stanno già implementando questa soluzione per eliminare l'attrito della ri-autenticazione per i visitatori ricorrenti, mantenendo la piena conformità GDPR e l'acquisizione di dati di prima parte. - SEZIONE 4: Domande e Risposte Rapide - circa 1 minuto Esaminiamo le domande più comuni che riceviamo dai team IT delle strutture. Domanda: Perché il portale funziona su iPhone ma non sui dispositivi Android? Risposta: 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. Domanda: Un ospite riferisce che il portale si è caricato ma non riesce ad andare online dopo l'accesso. Risposta: Si tratta quasi sempre di 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 RADIUS per individuare eventuali messaggi di Access-Reject. Domanda: Come gestiamo gli ospiti che continuano a essere disconnessi dopo pochi minuti? Risposta: Controlla l'impostazione dell'idle timeout. Molti controller sono impostati di default su un idle timeout di 5 minuti, decisamente troppo aggressivo per i dispositivi mobili che vanno in standby tra un'interazione e l'altra. Imposta l'idle timeout ad almeno 30 minuti per gli ambienti retail e hospitality. - SEZIONE 5: Sintesi e Prossimi Passi - circa 1 minuto Per riassumere: i malfunzionamenti del Captive Portal per il WiFi ospiti rientrano in sei categorie - esaurimento degli indirizzi 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 verificabile. 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 correnti dei provider di social login e testare il portale da un dispositivo pulito e non autenticato dopo ogni modifica di configurazione. Per la roadmap a lungo termine, valuta OpenRoaming come successore della ri-autenticazione tramite Captive Portal per i visitatori ricorrenti. La tecnologia è matura, gli standard sono definiti da IEEE 802.1X e WPA3-Enterprise, e Purple la rende disponibile senza costi software aggiuntivi con il piano Connect. Per guide più tecniche, casi di studio e risorse di implementazione, visita purple.ai. Grazie per aver ascoltato questo briefing tecnico di Purple. Mantieni le tue reti affidabili e i tuoi ospiti connessi.