Perché il mio WiFi ospiti non si connette? Risoluzione dei problemi del Captive Portal

TITLE: Perché il mio Wi-Fi ospiti non si connette? Risoluzione dei problemi del Captive Portal FORMAT: Purple Technical Briefing Podcast VOICE: UK English - Senior Solutions Architect tone DURATION: Circa 10 minuti --- SECTION 1: Introduzione e contesto - circa 1 minuto Salve e benvenuti a questo briefing tecnico di Purple. Sono il vostro ospite e oggi affronteremo uno dei problemi più persistenti e meno compresi nel networking wireless aziendale: il Captive Portal del Wi-Fi ospiti che si rifiuta categoricamente di caricarsi. Ci siete passati anche voi. Un ospite arriva nel vostro hotel, nel vostro negozio, nel vostro stadio o nel vostro centro congressi. Si connette alla rete Wi-Fi. Non succede nulla. Nessuna pagina di login. Nessuna connessione a Internet. Solo un'icona che gira e un senso di frustrazione crescente. Per i direttori operativi delle strutture e i responsabili IT, quel momento non è solo un piccolo inconveniente. Rappresenta un fallimento diretto della vostra esperienza utente, un'impennata di chiamate di supporto alla reception e un'opportunità persa di acquisire i dati di prima parte che giustificano l'investimento nella vostra infrastruttura wireless. In questo briefing andremo a guardare 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 framework di risoluzione dei problemi pratico e attuabile che potrete consegnare al vostro team IT oggi stesso. Cominciamo. --- SECTION 2: Approfondimento tecnico - circa 5 minuti Per risolvere un problema relativo al Captive Portal, è necessario innanzitutto capire 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 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 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 test su detectportal.firefox.com. Se la rete ha un accesso a Internet aperto, questi test restituiscono le risposte attese e il sistema operativo conclude che tutto è a posto. Ma su una rete ospiti, il gateway o controller wireless intercetta quella richiesta HTTP prima che raggiunga Internet. Invece della risposta attesa, il gateway restituisce un reindirizzamento HTTP 302 che punta alla pagina di benvenuto 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 protetta (sandbox) - spesso chiamata Assistente Captive Portal - per visualizzare la pagina di login. Questo è lo scenario ideale. Ora parliamo dei sei modi in cui questo processo può interrompersi. Causa principale numero uno: esaurimento del pool DHCP. Questo è il killer silenzioso negli eventi ad alta densità. Se gestisci una conferenza con duemila partecipanti su una subnet standard slash-24, hai a disposizione 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 fallirà 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 turnover 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 risoluzione 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 dei 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-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 social login tramite Google, Apple o Facebook, ogni dominio OAuth utilizzato da tali provider deve essere inserito nella whitelist. E questo è 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 non funzionante oggi. Pianifica audit trimestrali del walled garden e utilizza il wildcard domain snooping dove il tuo 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. 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 HSTS - e questo include praticamente ogni sito web principale - e il gateway tenta di intercettare quella richiesta HTTPS per reindirizzarla al portale, il browser rileva una mancata corrispondenza del certificato. Presenta quindi 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 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, Android 11 e versioni successive supportano questa funzione nativamente. 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. Di conseguenza, 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 e poi 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 di default indirizzi MAC randomizzati 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, un ospite che si è autenticato un'ora prima potrebbe visualizzare 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 specifico SSID nelle impostazioni di rete. La soluzione lato operatore consiste nell'implementare l'autenticazione basata su profili, come OpenRoaming tramite Passpoint e 802.1X, che autentica al Livello 2 utilizzando le credenziali anziché gli indirizzi MAC, rendendo irrilevante la randomizzazione. --- SEZIONE 3: Raccomandazioni di implementazione ed errori comuni - circa 2 minuti Ora che abbiamo compreso le cause principali, analizziamo come si presenta effettivamente una distribuzione di Captive Portal ben configurata. Inizia con la tua architettura DHCP. Per qualsiasi location che preveda più di 200 dispositivi simultanei, evita di utilizzare 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: 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 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 tuo team. Per il certificato del portale, utilizza un certificato TLS pubblicamente attendibile 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 incorrono 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 funzioni. Testate sempre da un dispositivo in uno stato nuovo e non autenticato, o un nuovo dispositivo o uno in cui avete dissociato la rete e cancellato il profilo WiFi. Infine, considerate 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 automaticamente e in sicurezza 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 lo stanno già implementando per eliminare l'attrito della riautenticazione per i visitatori ricorrenti, mantenendo al contempo la piena conformità al 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. Aggiungetelo 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. Verificate che il server RADIUS sia raggiungibile dal controller wireless, verificate che la chiave segreta condivisa corrisponda su entrambi i lati e controllate i log RADIUS per individuare eventuali messaggi di Access-Reject. Domanda: Come gestiamo gli ospiti che continuano a essere disconnessi dopo pochi minuti? Risposta: Controllate 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 standby tra un'interazione e l'altra. Impostate il timeout di inattività ad almeno 30 minuti per gli ambienti hospitality e retail. --- SEZIONE 5: Riepilogo e prossimi passi - circa 1 minuto Per riassumere: i guasti del Captive Portal del WiFi per gli ospiti rientrano in sei categorie: esaurimento del 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 vostro 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 non autenticato dopo ogni modifica della configurazione. Per la vostra roadmap a lungo termine, valutate 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 con il piano Connect. Per altre guide 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.