Captive Portal Login: Troubleshooting and Explainer
Questa guida fornisce un riferimento tecnico completo per comprendere, distribuire e risolvere i problemi dei sistemi di Captive Portal login negli ambienti WiFi guest aziendali. Spiega gli esatti meccanismi di reindirizzamento HTTP e di DNS hijacking utilizzati dai moderni Captive Portal, illustra in dettaglio come l'HSTS e i browser HTTPS sicuri possano bloccare i reindirizzamenti locali e fornisce una checklist di risoluzione dei problemi chiara e pratica che copre sia le soluzioni lato client (disattivazione delle VPN, disattivazione della randomizzazione MAC, utilizzo di NeverSSL) sia le risoluzioni lato operatore (configurazione del walled garden, ottimizzazione del tempo di lease DHCP, verifica dell'intercettazione DNS). I gestori delle location, i responsabili IT e gli architetti di rete troveranno questa guida essenziale per ridurre al minimo i ticket di supporto degli ospiti e massimizzare il ROI della loro infrastruttura wireless.
Ascolta questa guida
Visualizza trascrizione del podcast
📚 Part of our core series: The Ultimate Guide to Captive Portals →
Executive Summary
Per le moderne strutture aziendali, le reti wireless per gli ospiti non sono più un semplice servizio di cortesia; rappresentano un punto di contatto fondamentale per il coinvolgimento dei clienti, l'intelligence operativa e il posizionamento del brand. Tuttavia, il valore aziendale di queste reti dipende interamente dall'affidabilità dell'esperienza di connessione iniziale. Quando un ospite si connette a una rete e la pagina di captive portal login non viene visualizzata, la struttura subisce immediatamente un aumento degli attriti nel front-of-house, un'impennata dei ticket di supporto e la perdita di opportunità di acquisizione dati.
Alla base di questi disservizi c'è una tensione fondamentale tra gli standard web sicuri e le tecniche di intercettazione a livello di rete storicamente utilizzate dai Captive Portal. I browser web e i sistemi operativi moderni sono progettati per rilevare e bloccare il reindirizzamento non autorizzato del traffico al fine di proteggere gli utenti dagli attacchi man-in-the-middle (MitM). Comprendendo le precise sequenze di reindirizzamento HTTP e DNS, l'impatto di protocolli sicuri come HTTP Strict Transport Security (HSTS) e le impostazioni lato client che interrompono questi meccanismi, i dipartimenti IT possono implementare configurazioni robuste che garantiscono un onboarding senza interruzioni.
Questa guida illustra in dettaglio come la piattaforma cloud-managed Guest WiFi di Purple affronti queste sfide per offrire un reindirizzamento ad alta disponibilità su tutti i sistemi operativi consumer, riducendo al minimo i costi di supporto per le strutture e massimizzando il ritorno sugli investimenti nelle infrastrutture wireless. Sia che operiate nei settori Hospitality , Retail , Healthcare o Transport , i principi e le checklist di questa guida si applicano universalmente.
Approfondimento Tecnico
Per risolvere efficacemente i problemi legati ai malfunzionamenti del Captive Portal, gli amministratori di rete devono comprendere l'esatta sequenza di eventi che si verifica quando un dispositivo client si connette a una rete wireless per ospiti aperta o con chiave precondivisa (PSK). I sistemi operativi moderni — inclusi Apple iOS/macOS, Google Android, Microsoft Windows e le distribuzioni Linux — non attendono che l'utente apra un browser per verificare la connettività Internet. Al contrario, eseguono un meccanismo di probing attivo automatizzato subito dopo aver completato le fasi di associazione e DHCP.
La Sequenza di Rilevamento del Captive Portal
Il processo di connessione e verifica segue una sequenza altamente strutturata:
| Fase | Azione | Descrizione Tecnica | Indicatore di Successo Previsto |
|---|---|---|---|
| 1 | Associazione | Il client si associa al SSID Guest al Livello 2. | Scambio riuscito di frame di associazione 802.11. |
| 2 | Assegnazione IP | Il server DHCP assegna un indirizzo IP, una subnet mask, un gateway e un server DNS locale. | Pacchetto DHCP ACK ricevuto dal client. |
| 3 | Active Probing | Il servizio in background del sistema operativo invia una richiesta HTTP GET non crittografata a un URL canary specifico del fornitore. | HTTP 200 OK (Apple/Windows) o HTTP 204 No Content (Google). |
| 4 | Interception & Redirect | Il gateway/controller wireless intercetta il probe HTTP e restituisce un reindirizzamento HTTP 302/303 che punta al portale. | Reindirizzamento HTTP 302 al FQDN del Captive Portal. |
| 5 | Portal Rendering | Il motore del browser del Captive Portal Assistant (CPA) si apre e visualizza la splash page. | Rendering riuscito dell'interfaccia di login. |
+--------+ +------------+ +------------+ +-------------------+
| Client | | AP/Gateway | | DNS Server | | Captive Portal IP |
+--------+ +------------+ +------------+ +-------------------+
| | | |
|--- 1. DHCP Request --->| | |
|<-- 2. DHCP Ack --------| | |
| (IP & DNS Assigned) | | |
|--- 3. DNS Query ------>|------------------------->| |
| (canary URL) | | |
|<-- 4. DNS Response ----|<-------------------------| |
| (Resolved IP) | | |
|--- 5. HTTP GET ------->| | |
| (canary URL) | | |
|<-- 6. HTTP 302 --------| | |
| (Redirect to Portal)| | |
|--- 7. DNS Query ------>|------------------------->| |
| (Portal FQDN) | | |
|<-- 8. DNS Response ----|<-------------------------| |
| (Portal IP) | | |
|--- 9. HTTP/S GET ------>-------------------------------------------------------->|
| (Render Splash Page)| | |
|<-- 10. Render Page <-------------------------------------------------------------||
Ciascun sistema operativo utilizza un set distinto di URL canary e risposte attese per determinare lo stato della rete. Apple (iOS/macOS) interroga http://captive.apple.com/hotspot-detect.html attendendosi un documento HTML contenente solo la parola Success sia nel titolo che nel corpo. Google (Android/ChromeOS) interroga http://connectivitycheck.gstatic.com/generate_204 attendendosi un codice di stato HTTP 204 No Content con un corpo vuoto. Microsoft (Windows 10/11) interroga http://www.msftconnecttest.com/connecttest.txt attendendosi una risposta in formato testo semplice pari a Microsoft Connect Test.
Se il dispositivo riceve la risposta attesa, deduce che la rete ha un accesso a Internet diretto e senza ostacoli. Se la risposta viene modificata — ad esempio ricevendo un reindirizzamento HTTP 302 — il Captive Portal Assistant (CPA) del sistema operativo avvia immediatamente una finestra del browser dedicata e in modalità sandbox per mostrare la destinazione del reindirizzamento: la pagina di login del captive portal.
Il conflitto di reindirizzamento HSTS e HTTPS
Il metodo storico di reindirizzamento del captive portal si basa sul dirottamento del DNS o sull'intercettazione HTTP. Quando un utente non autenticato tenta di navigare su qualsiasi sito web, il gateway intercetta il traffico sulla porta TCP 80 (HTTP) o sulla porta 443 (HTTPS) e risponde per conto del server di destinazione, inserendo un reindirizzamento HTTP 302. Sebbene questo funzionasse perfettamente in un'era di navigazione web HTTP non crittografata, introduce gravi sfide operative e di sicurezza nei moderni ambienti dominati dall'HTTPS.
L'ostacolo principale è l'HTTP Strict Transport Security (HSTS), un meccanismo di politica di sicurezza web specificato nella RFC 6797. L'HSTS costringe i browser web a interagire con i siti web utilizzando esclusivamente connessioni HTTPS sicure. Quando un browser tenta di connettersi a un dominio abilitato per HSTS — come Google, Facebook o i portali bancari — vieta rigorosamente qualsiasi comunicazione non crittografata e impone una convalida rigorosa del certificato SSL/TLS.
Se un gateway di captive portal tenta di intercettare una richiesta HTTPS verso un dominio HSTS, deve presentare al client il proprio certificato SSL o un certificato contraffatto. Poiché il certificato del gateway non corrisponde al nome di dominio richiesto, il browser del client rileva un attacco man-in-the-middle e mostra un avviso di sicurezza non ignorabile (ad es. NET::ERR_CERT_COMMON_NAME_INVALID o La tua connessione non è privata). Il browser blocca completamente il reindirizzamento, impedendo il caricamento della captive portal page e lasciando l'utente con una connessione interrotta.
Per mitigare questo problema, le moderne reti wireless aziendali utilizzano due meccanismi avanzati. In primo luogo, l'esenzione dei probe del sistema operativo garantisce che i probe HTTP non crittografati inviati dai sistemi operativi non siano mai soggetti a intercettazione HTTPS; il gateway deve consentire il reindirizzamento del probe HTTP non crittografato tramite una risposta HTTP 302 standard verso il nome di dominio completo (FQDN) sicuro del Captive Portal. In secondo luogo, l'RFC 8910 (Captive Portal API) definisce un meccanismo in cui le opzioni DHCP (Opzione 114) o i Router Advertisement IPv6 informano il dispositivo client dell'URL esatto dell'endpoint dell'API del Captive Portal. Invece di affidarsi al dirottamento DNS a forza bruta o al reindirizzamento HTTP, i dispositivi client compatibili interrogano direttamente questa API per ottenere l'URL del portale e lo stato della rete, aggirando completamente il conflitto HSTS.
Guida all'implementazione
La distribuzione di un Captive Portal affidabile richiede un'attenta coordinazione tra l'infrastruttura wireless fisica (Access Point, Controller, Gateway) e la piattaforma del portale basata su cloud. Questa sezione fornisce una guida all'implementazione passo-passo, indipendente dal fornitore, per garantire una solida compatibilità di reindirizzamento nelle reti aziendali, facendo riferimento alle configurazioni standard presenti nei controller di Cisco, Aruba e Ruckus. Per l'architettura di controllo degli accessi correlata, consultare la guida su Come implementare l'autenticazione 802.1X con Cloud RADIUS .
Passaggio 1: Configurazione del Walled Garden (ACL)
Un Walled Garden o Access Control List (ACL) definisce gli specifici domini esterni, indirizzi IP o subnet a cui un dispositivo ospite non autenticato è autorizzato ad accedere prima di effettuare l'accesso. Se il walled garden è configurato in modo errato, il dispositivo client non sarà in grado di risolvere o caricare le risorse del Captive Portal, con conseguente schermata vuota o errore di timeout.
Per garantire un funzionamento ottimale con la piattaforma di Purple, il walled garden deve includere i seguenti componenti. I FQDN del portale sono i nomi di dominio completi dei server che ospitano la splash page (ad es. *.purple.ai o varianti regionali). Gli Identity Provider (IdP) devono essere inclusi se il portale supporta il social login — il walled garden deve includere l'ampio elenco di domini utilizzati da questi provider per l'autenticazione OAuth. Devono essere incluse anche le Content Delivery Network (CDN) che ospitano CSS, JavaScript, font o immagini utilizzati nella splash page.
Molti controller moderni supportano i nomi di dominio con caratteri jolly (ad es. *.purple.ai) nelle loro configurazioni di walled garden. Il controller analizza dinamicamente (snooping) le query DNS dei client non autenticati; quando un client interroga un dominio corrispondente al carattere jolly, il controller aggiunge temporaneamente l'indirizzo IP restituito alla whitelist di pre-autenticazione del client. Per i controller legacy che supportano solo indirizzi IP statici, gli amministratori devono configurare un proxy DNS locale o aggiornare regolarmente i blocchi IP statici associati al portale cloud.
Passaggio 2: Ottimizzazione DHCP e DNS
Poiché il rilevamento del Captive Portal dipende fortemente dall'handshake di rete iniziale, le configurazioni DHCP e DNS devono essere ottimizzate per ambienti ad alta densità e di passaggio. In luoghi ad alta affluenza come centri commerciali, hub di trasporto o stadi, l'esaurimento degli indirizzi IP è una causa comune di errore del Captive Portal. Se il tempo di lease DHCP è impostato su un valore troppo lungo (ad esempio, 24 ore), il pool di IP si esaurirà rapidamente, impedendo ai nuovi ospiti di ottenere un indirizzo IP. Per le reti guest, il tempo di lease DHCP deve essere configurato tra 15 e 30 minuti (da 900 a 1800 secondi).
Ai client guest deve essere assegnato un server DNS affidabile e veloce, in grado di risolvere sia i domini pubblici sia l'FQDN locale del Captive Portal. Si raccomanda vivamente di utilizzare resolver DNS pubblici di livello enterprise come Cloudflare 1.1.1.1 o Google 8.8.8.8, oppure un forwarder DNS locale ad alte prestazioni. Aspetto fondamentale, il gateway wireless deve consentire ai client non autenticati di eseguire la risoluzione DNS. Se una regola del firewall blocca il traffico sulla porta 53 (UDP/TCP) per gli utenti pre-autenticati, il sistema operativo del client non sarà in grado di risolvere gli URL canary e l'assistente del Captive Portal non si avvierà mai.
Passaggio 3: Gestione dei certificati SSL/TLS
Quando un dispositivo ospite viene reindirizzato al Captive Portal, il browser stabilisce una connessione HTTPS sicura con l'FQDN del portale. Per evitare schermate di avviso sui certificati, il Captive Portal deve essere protetto con un certificato SSL/TLS valido e pubblicamente attendibile. I certificati autofirmati verranno immediatamente bloccati dai moderni sistemi operativi mobili, impedendo all'assistente del Captive Portal di caricare la pagina. Se il meccanismo di reindirizzamento richiede che il client comunichi con l'IP del gateway locale (ad esempio, per l'associazione locale MAC-to-IP), il gateway deve disporre di un certificato valido corrispondente al suo FQDN locale, e questo FQDN deve essere risolvibile dal DNS guest.
Best Practice
Per mantenere una rete wireless guest ad alte prestazioni che riduca al minimo i ticket di supporto e massimizzi la soddisfazione degli utenti, gli operatori di rete dovrebbero attenersi ai seguenti standard di settore e best practice.
1. Ottimizzare le regole del Walled Garden per i Social Login
Quando si utilizzano le opzioni di social login per acquisire i profili utente, il walled garden deve essere gestito meticolosamente. Le piattaforme di social media aggiornano frequentemente i propri sottodomini di autenticazione e gli intervalli IP delle CDN. Se un solo dominio richiesto manca dal walled garden, la finestra pop-up del social login non si caricherà o si bloccherà a tempo indeterminato.
| Provider | Domini essenziali del Walled Garden |
|---|---|
accounts.google.com, ssl.gstatic.com, fonts.gstatic.com, lh3.googleusercontent.com |
|
facebook.com, *.facebook.com, *.fbcdn.net, m.facebook.com |
|
| Apple | appleid.apple.com, appleid.cdn-apple.com, gsa.apple.com |
2. Transizione all'autenticazione basata su profilo e OpenRoaming
Sebbene i Captive Portal siano eccellenti per l'acquisizione iniziale dei dati e l'accettazione dei termini di servizio, ripetere il processo di login a ogni visita introduce attrito per l'utente. Le moderne reti aziendali stanno passando sempre più all'autenticazione basata su profilo e alle tecnologie Passpoint (Hotspot 2.0), come OpenRoaming.
Sotto la licenza Purple Connect , Purple agisce come identity provider gratuito per i servizi OpenRoaming. Passpoint consente a un ospite di installare un profilo sicuro sul proprio dispositivo durante la prima visita. Nelle visite successive a qualsiasi sede aderente in tutto il mondo, il dispositivo si associa automaticamente e in modo sicuro alla rete a livello Layer 2 utilizzando l'autenticazione WPA3-Enterprise e 802.1X, bypassando completamente il Captive Portal. Ciò offre un'esperienza di roaming fluida, simile a quella cellulare, mantenendo al contempo una trasmissione dati sicura e crittografata. Per una guida dettagliata sull'implementazione, consulta Come implementare l'autenticazione 802.1X con Cloud RADIUS .
3. Garantire la conformità con i quadri normativi
Le distribuzioni di Wi-Fi per gli ospiti devono essere progettate nel rigoroso rispetto degli standard globali di sicurezza e privacy dei dati. Per la Conformità GDPR / CCPA, il Captive Portal deve presentare termini di servizio e informative sulla privacy chiari e inequivocabili. Il consenso per le comunicazioni di marketing deve essere fornito attivamente (non preselezionato) e gli utenti devono disporre di un meccanismo semplice per richiedere la cancellazione dei dati. Per la Conformità PCI DSS, se la rete ospiti coesiste sulla stessa infrastruttura fisica dei sistemi Point of Sale (POS) della sede, deve essere applicata una rigorosa segmentazione logica. La VLAN ospiti deve essere completamente isolata dalle VLAN di produzione e di pagamento tramite regole di firewall e ACL. Per la sicurezza wireless, implementa la Modalità di transizione WPA3 per consentire ai dispositivi più vecchi di connettersi utilizzando WPA2-Personal, mentre i dispositivi più recenti beneficiano della sicurezza avanzata di WPA3, inclusi i Protected Management Frames (PMF).
Risoluzione dei problemi e mitigazione dei rischi
Quando vengono segnalati problemi con il Wi-Fi ospiti, il personale operativo e di reception necessita di una sequenza diagnostica chiara e strutturata per identificare e risolvere la causa principale. I malfunzionamenti del Captive Portal rientrano generalmente in due categorie: configurazioni errate lato client e problemi infrastrutturali lato operatore.
Elenco di controllo per la diagnostica e la risoluzione lato client
Per il personale di reception che assiste gli ospiti, seguire questi passaggi in ordine.
1. Disabilitare le VPN attive. Le reti private virtuali (VPN) stabiliscono un tunnel crittografato dal dispositivo client direttamente a un server remoto. Poiché il client VPN tenta di crittografare e instradare tutto il traffico immediatamente dopo la connessione alla rete, bypassa le regole di DNS hijack e di reindirizzamento HTTP del gateway locale. L'ospite deve disabilitare temporaneamente la propria VPN per completare l'accesso al Captive Portal, dopodiché la VPN può essere riattivata in sicurezza.
2. Disattivare gli indirizzi MAC privati/casuali. I sistemi operativi moderni (iOS 14+ e Android 10+) abilitano per impostazione predefinita l'indirizzo Wi-Fi privato o la randomizzazione del MAC per impedire il tracciamento. Sebbene sia vantaggiosa per la privacy, questa funzione fa sì che il dispositivo presenti un indirizzo MAC diverso alla rete nelle connessioni successive o dopo un breve periodo di inattività. Ciò interrompe la persistenza della sessione basata su MAC, costringendo l'ospite a ripetere continuamente l'autenticazione. Istruire l'ospite a disabilitare l'opzione Indirizzo privato per l'SSID della struttura nelle impostazioni wireless del proprio dispositivo.
3. Bypassare il DNS sicuro (DoH/DoT). Se l'ospite ha configurato un server DNS personalizzato o utilizza DNS-over-HTTPS (DoH) o DNS-over-TLS (DoT) nelle impostazioni del browser, quest'ultimo rifiuterà di accettare le risposte DNS intercettate dal gateway locale. L'utente deve disabilitare temporaneamente il DNS sicuro nelle impostazioni del browser o svuotare la cache DNS del dispositivo per consentire il funzionamento del reindirizzamento locale.
4. Forzare una connessione HTTP non crittografata (NeverSSL). Se l'assistente del Captive Portal non si avvia automaticamente, il browser dell'ospite potrebbe bloccarsi nel tentativo di caricare una pagina HTTPS. Istruire l'ospite ad aprire una normale finestra del browser e a navigare su http://neverssl.com. Poiché questo sito web è progettato specificamente per non utilizzare mai SSL/TLS, il gateway può intercettare la richiesta HTTP e inserire correttamente il reindirizzamento HTTP 302 alla schermata di accesso a Internet per gli ospiti.
5. Dissociare e riconnettersi alla rete. Se una sessione di autenticazione precedente è stata interrotta in modo anomalo, il dispositivo client potrebbe conservare dati obsoleti nella cache DHCP o ARP. Dissociare la rete nelle impostazioni wireless e riconnettersi forza un handshake DHCP pulito e riavvia la sequenza di rilevamento del Captive Portal.
Risoluzione dei problemi dell'infrastruttura lato operatore
Per gli amministratori di rete che indicano problemi sistemici in cui più ospiti segnalano malfunzionamenti del portale, è necessario eseguire i seguenti controlli. Monitorare l'utilizzo del pool DHCP ispezionando l'ambito DHCP sul gateway o router locale; se il pool è utilizzato al 100%, ridurre il tempo di lease a 5-10 minuti per recuperare rapidamente gli indirizzi IP degli ospiti che hanno lasciato la struttura. Verificare le regole di reindirizzamento DNS eseguendo una cattura dei pacchetti (PCAP) sull'interfaccia del gateway per confermare che i client non autenticati inviino correttamente le query DNS alla porta 53 e ricevano le risposte. Controllare la latenza del Walled Garden per garantire che il walled garden sia ottimizzato e che la risoluzione DNS per i domini del walled garden sia memorizzata correttamente nella cache del controller. Infine, verificare la scadenza dei certificati per assicurarsi che il certificato SSL/TLS installato sul controller wireless o sul gateway sia valido, non scaduto e firmato da un'Autorità di Certificazione (CA) attendibile.
ROI e impatto aziendale
Investire in una piattaforma di Captive Portal robusta e gestita in cloud come Purple genera ritorni finanziari e operativi misurabili per le sedi aziendali. Risolvendo sistematicamente i problemi di accesso al Captive Portal, le organizzazioni influiscono direttamente sia sui ricavi che sui profitti.
Riduzione dei costi di supporto e dell'attrito per gli ospiti
Nelle strutture ricettive e nei punti vendita al dettaglio, il personale di contatto dedica spesso tempo prezioso alla risoluzione dei problemi di connettività WiFi degli ospiti. Un tasso elevato di malfunzionamenti del Captive Portal comporta una maggiore frustrazione degli ospiti e recensioni online negative, un volume elevato di ticket di supporto a bassa complessità inoltrati al team IT e inefficienze operative dovute alla distrazione del personale dalle proprie mansioni principali. Implementando il robusto meccanismo di reindirizzamento di Purple, compatibile con diverse piattaforme, le sedi registrano in genere una riduzione dal 50% al 70% dei reclami di supporto relativi al WiFi.
Massimizzazione dell'acquisizione dati e del ROI di marketing
Il Captive Portal rappresenta il gateway principale per acquisire preziosi dati di prima parte dei clienti, inclusi indirizzi e-mail, numeri di telefono e profili social. Quando un Captive Portal non si carica, la sede perde l'opportunità di registrare quell'ospite. Con un portale funzionante, le sedi possono raggiungere tassi di opt-in superiori al 60% per le comunicazioni di marketing, ampliando rapidamente il proprio database CRM clienti. Integrando l'autenticazione degli ospiti con WiFi Analytics , i gestori delle sedi ottengono informazioni approfondite sul comportamento dei visitatori, inclusi i tempi di permanenza, i tassi di ritorno e i flussi di visitatori nelle diverse zone.
Sbloccare opportunità di Retail Media e monetizzazione
Per le grandi strutture come centri commerciali, stadi e centri espositivi, il captive portal rappresenta uno spazio digitale di altissimo valore. Utilizzando la splash page e le schermate di reindirizzamento post-login, gli operatori possono attingere al mercato in rapida crescita dei Retail Media. Mostra annunci pubblicitari altamente mirati e basati sulla posizione geografica degli ospiti nell'esatto momento in cui si connettono, oppure vendi pacchetti di sponsorizzazione ai brand, trasformando un tradizionale centro di costo IT in una risorsa in grado di generare ricavi diretti.
Riferimenti
[1] Collaboratori di Wikipedia. "Captive Portal." Wikipedia, L'enciclopedia libera. https://en.wikipedia.org/wiki/Captive_portal
[2] IETF RFC 6797. "HTTP Strict Transport Security (HSTS)." Internet Engineering Task Force. https://datatracker.ietf.org/doc/html/rfc6797
[3] IETF RFC 8910. "Captive-Portal Identification in DHCP and Router Advertisements." Internet Engineering Task Force. https://datatracker.ietf.org/doc/html/rfc8910
[4] Wireless Broadband Alliance. "OpenRoaming." WBA. https://wballiance.com/openroaming/
[5] NeverSSL. "NeverSSL: Helping you get online." NeverSSL. http://neverssl.com/
Definizioni chiave
Captive Portal
Una pagina web presentata agli utenti appena connessi a una rete ospite prima che venga concesso loro un accesso a internet più ampio. Il portale richiede in genere l'autenticazione (e-mail, social login o codice voucher), l'accettazione dei termini di servizio o entrambi. È il meccanismo principale per l'acquisizione dei dati degli ospiti nelle distribuzioni WiFi aziendali.
I team IT riscontrano nei captive portal il primo punto di errore in caso di reclami sul WiFi degli ospiti. Comprendere l'architettura tecnica del portale è essenziale per diagnosticare il motivo per cui la pagina di login non viene visualizzata.
DNS Hijacking
Una tecnica utilizzata dai gateway dei captive portal in cui il server DNS locale restituisce l'indirizzo IP del server del captive portal in risposta a tutte le query DNS provenienti da client non autenticati, indipendentemente dal dominio effettivamente richiesto. Ciò costringe il browser del client a connettersi al portale anziché alla destinazione prevista.
Il DNS hijacking è il meccanismo principale alla base della maggior parte delle implementazioni di reindirizzamento dei captive portal. È efficace per il traffico HTTP, ma viene bloccato dalle configurazioni DNS-over-HTTPS (DoH) e DNS-over-TLS (DoT) sui dispositivi client.
HTTP Strict Transport Security (HSTS)
Un meccanismo di politica di sicurezza web (RFC 6797) che istruisce i browser a comunicare con un sito web solo tramite HTTPS e a rifiutare qualsiasi connessione HTTP o connessione con certificati SSL non validi. Una volta che un browser ha ricevuto un'intestazione HSTS da un dominio, applica questa politica per una durata specificata (max-age), anche se l'utente digita manualmente un URL HTTP.
L'HSTS è il motivo principale per cui i reindirizzamenti dei captive portal falliscono sui dispositivi moderni. Quando un gateway tenta di intercettare una richiesta HTTPS verso un dominio abilitato per HSTS, il browser rileva la mancata corrispondenza del certificato e blocca il reindirizzamento, impedendo il caricamento del portale.
Captive Portal Assistant (CPA)
Un processo browser leggero e in modalità sandbox integrato nei sistemi operativi moderni (CNA di Apple, CPA di Android, NCSI di Windows) che si avvia automaticamente quando il sistema operativo rileva di trovarsi dietro un captive portal. Il CPA esegue il rendering della splash page in un ambiente limitato che impedisce al portale di accedere alle credenziali del dispositivo o alla memoria persistente.
Il CPA è ciò che fa apparire automaticamente la pagina di login sulla maggior parte dei dispositivi. Se il CPA non si avvia (ad esempio a causa di una VPN o del DoH), l'ospite deve navigare manualmente verso l'URL del portale.
Walled Garden
Una lista di controllo degli accessi (ACL) di pre-autenticazione che definisce gli specifici domini esterni, indirizzi IP o sottoreti a cui i dispositivi degli ospiti non autenticati possono accedere prima di completare il login al captive portal. Le risorse esterne al walled garden sono bloccate fino al completamento dell'autenticazione.
Un walled garden configurato in modo errato è una delle cause più comuni di errore del captive portal, in particolare per i flussi di social login che richiedono l'accesso a più domini OAuth di terze parti.
MAC Address Randomization
Una funzione di privacy nei moderni sistemi operativi mobili (iOS 14+, Android 10+) che fa sì che il dispositivo presenti un indirizzo MAC generato casualmente a ciascuna rete WiFi a cui si connette, anziché il suo indirizzo MAC assegnato dall'hardware. L'indirizzo randomizzato può anche cambiare periodicamente durante la connessione.
La randomizzazione del MAC interrompe la persistenza della sessione del captive portal perché il gateway utilizza l'indirizzo MAC per tracciare i client autenticati. Quando il MAC cambia, il gateway tratta il dispositivo come un nuovo client non autenticato, forzando una nuova autenticazione.
RFC 8910 (Captive Portal API)
Uno standard IETF che definisce un meccanismo per consentire alle reti di informare i dispositivi client della presenza e dell'URL di un captive portal utilizzando l'opzione DHCP 114 (per IPv4) o le opzioni IPv6 Router Advertisement. I dispositivi compatibili interrogano direttamente l'endpoint API pubblicizzato per determinare lo stato della propria rete e ottenere l'URL del portale, eliminando la necessità di DNS hijacking.
La RFC 8910 è l'alternativa moderna e conforme agli standard al DNS hijacking per il rilevamento dei captive portal. Risolve il conflitto HSTS comunicando l'URL del portale a livello di rete anziché tentare di intercettare il traffico HTTP/HTTPS.
DNS-over-HTTPS (DoH)
Un protocollo che crittografa le query DNS inviandole tramite una connessione HTTPS a un risolutore attendibile (come Cloudflare 1.1.1.1 o Google 8.8.8.8), anziché inviarle come pacchetti UDP in chiaro al server DNS assegnato alla rete. Ciò impedisce al gateway locale di intercettare o dirottare le risposte DNS.
Il DoH è sempre più abilitato per impostazione predefinita nei browser moderni (Chrome, Firefox, Edge) e nei sistemi operativi. Quando il DoH è attivo, il meccanismo di DNS hijacking del captive portal viene aggirato e la schermata di login a internet per gli ospiti non apparirà automaticamente.
NeverSSL
Un sito web di utilità pubblica (http://neverssl.com) esplicitamente progettato per non utilizzare mai la crittografia SSL/TLS. Funge da trigger manuale affidabile per i reindirizzamenti del captive portal perché il gateway può sempre intercettare la sua richiesta HTTP non crittografata e inserire un reindirizzamento 302 alla pagina di login del portale.
NeverSSL è la soluzione manuale consigliata quando il dispositivo di un ospite non riesce a visualizzare automaticamente la pagina di login del captive portal. Il personale di reception dovrebbe essere formato a indirizzare gli ospiti a questo URL come primo passo per la risoluzione del problema.
OpenRoaming (Passpoint/Hotspot 2.0)
Uno standard globale di roaming WiFi sviluppato dalla Wireless Broadband Alliance (WBA) che consente ai dispositivi di autenticarsi automaticamente e in modo sicuro alle reti WiFi partecipanti utilizzando un profilo di credenziali preinstallato, senza richiedere l'interazione manuale con il captive portal. L'autenticazione utilizza i protocolli WPA3-Enterprise e 802.1X.
OpenRoaming rappresenta l'evoluzione a lungo termine oltre i captive portal per il WiFi ospiti aziendale. Con la licenza Connect di Purple, Purple funge da provider di identità gratuito per OpenRoaming, consentendo agli ospiti che ritornano di bypassare completamente il captive portal nelle visite successive.
Esempi pratici
Un hotel in centro città da 350 camere ha distribuito una rete WiFi per gli ospiti gestita da Purple su tutti i piani e nelle aree comuni. La reception riceve 15-20 reclami al giorno da parte di ospiti la cui pagina di accesso del Captive Portal non si carica. L'hotel utilizza controller wireless Cisco Catalyst 9800 e un router Cisco ISR 4331. Un'indagine iniziale mostra che il problema è più comune su iPhone con iOS 17 e dispositivi Android 13. In che modo l'architetto di rete dovrebbe diagnosticare e risolvere questo problema?
Iniziare con una diagnostica strutturata su quattro livelli. Livello 1 (DHCP): accedere al Cisco ISR 4331 ed eseguire show ip dhcp pool e show ip dhcp binding. Verificare il numero totale di binding attivi rispetto alle dimensioni del pool. Se l'utilizzo supera l'85%, il pool è quasi esaurito. Ridurre il tempo di lease dal valore predefinito di 1 giorno a 1800 secondi (30 minuti) utilizzando ip dhcp pool GUEST_WIFI e lease 0 0 30. Livello 2 (DNS): sul Catalyst 9800, verificare che l'ACL di pre-autenticazione (utilizzata per l'SSID del Captive Portal) consenta il traffico sulle porte UDP e TCP 53 verso i server DNS assegnati. Eseguire un'acquisizione di pacchetti sull'interfaccia VLAN degli ospiti per confermare che le query DNS ricevano risposta. Livello 3 (Walled Garden): accedere alla GUI del Catalyst 9800 in Configuration > Tags & Profiles > Policy. Ispezionare l'elenco dei filtri URL associato all'SSID degli ospiti. Confermare che siano inclusi *.purple.ai, accounts.google.com, *.facebook.com, appleid.apple.com e tutti i domini CDN associati. Abilitare il DNS snooping sul filtro URL per consentire la risoluzione dei domini con caratteri jolly. Livello 4 (Specifico per iOS): i dispositivi iOS 17 utilizzano captive.apple.com/hotspot-detect.html come URL di probe. Confermare che il Catalyst 9800 stia intercettando questa richiesta HTTP e restituendo un reindirizzamento HTTP 302 all'FQDN del portale Purple (ad es. https://portal.purple.ai). Verificare che il certificato del portale Purple sia valido e non autofirmato. Se il reindirizzamento punta all'IP locale del controller anziché all'FQDN del portale cloud, aggiornare l'URL di reindirizzamento esterno nella configurazione dell'SSID.
Una catena di vendita al dettaglio nazionale con 120 negozi ha distribuito il WiFi per gli ospiti utilizzando AP Aruba Instant gestiti tramite Aruba Central. Il team di marketing segnala che l'opzione di accesso social 'Accedi con Google' sul Captive Portal non funziona per circa il 30% degli ospiti. L'opzione di accesso tramite email standard funziona correttamente. Il problema si presenta in modo intermittente ed è più comune nei negozi che hanno aggiornato di recente il firmware Aruba. In che modo il team di rete e IT dovrebbe indagare su questo problema?
Il fallimento intermittente del social login a fronte del corretto funzionamento dell'accesso tramite email è un classico problema di copertura dei domini del walled garden, probabilmente aggravato da un aggiornamento del firmware che ha ripristinato o modificato l'ACL di pre-autenticazione. Procedere come segue. Passaggio 1 — Riprodurre e acquisire: in un negozio interessato, connettere un dispositivo di test all'SSID degli ospiti e tentare un accesso con Google. Aprire gli strumenti di sviluppo del browser (F12 > scheda Rete) prima di fare clic su 'Accedi con Google'. Notare eventuali richieste non riuscite, che verranno visualizzate come voci rosse con codici di stato come ERR_CONNECTION_REFUSED o ERR_NAME_NOT_RESOLVED. Questi domini non riusciti sono le voci mancanti nel walled garden. Passaggio 2 — Controllare il Walled Garden di Aruba Central: accedere ad Aruba Central e passare alla configurazione dell'SSID per la rete ospiti. Esaminare le voci del Walled Garden / Whitelist. Il flusso OAuth di Google richiede come minimo: accounts.google.com, ssl.gstatic.com, fonts.gstatic.com, www.gstatic.com, lh3.googleusercontent.com e oauth2.googleapis.com. Dopo un aggiornamento del firmware, Aruba Central potrebbe essere tornato a una configurazione basata su modelli che escludeva alcune di queste voci. Passaggio 3 — Abilitare il DNS Snooping: in Aruba Central, abilitare il whitelist basato su DNS per l'SSID degli ospiti. Ciò consente all'AP di risolvere dinamicamente e inserire nella whitelist gli indirizzi IP restituiti per i domini che corrispondono ai pattern con caratteri jolly configurati (ad es. *.google.com, *.gstatic.com). Questo sistema è più resiliente rispetto alla whitelist di IP statici, poiché gli IP della CDN di Google cambiano frequentemente. Passaggio 4 — Convalidare e distribuire: testare la correzione nel negozio pilota, confermare che la percentuale di successo dell'accesso con Google raggiunga il 95%+, quindi applicare la configurazione aggiornata a tutti i 120 negozi tramite la distribuzione dei criteri di gruppo di Aruba Central.
Domande di esercitazione
Q1. Un centro congressi che ospita un evento con 2.000 delegati segnala che il 40% dei partecipanti non riesce a visualizzare la pagina di login del WiFi per gli ospiti sui propri dispositivi. L'evento è iniziato 30 minuti fa. L'infrastruttura wireless utilizza controller Ruckus SmartZone. Qual è la causa principale più probabile e qual è la risoluzione più rapida?
Suggerimento: Considera la portata dell'evento (2.000 connessioni simultanee) e il tempo trascorso dall'inizio dell'evento. Pensa a quale risorsa di rete ha la maggiore probabilità di esaurirsi nei primi 30 minuti di un evento ad alta densità.
Visualizza risposta modello
La causa principale più probabile è l'esaurimento del pool DHCP. Con 2.000 delegati che tentano di connettersi simultaneamente entro 30 minuti, il pool di indirizzi DHCP per la VLAN ospiti è quasi certamente esaurito, in particolare se il tempo di lease era impostato sul valore predefinito di 8 o 24 ore. I delegati che non riescono a ottenere un indirizzo IP non vedranno alcuna pagina di login perché la sequenza di rilevamento del Captive Portal non può iniziare senza l'assegnazione di un IP valido. La risoluzione più rapida consiste nell'accedere al controller Ruckus SmartZone, navigare nella configurazione del server DHCP per la VLAN ospiti e ridurre il tempo di lease a 5-10 minuti per forzare il recupero rapido degli indirizzi dai delegati che se ne sono già andati o si sono disconnessi. Inoltre, verificare se la dimensione del pool DHCP è sufficiente per il numero di utenti simultanei previsto: un pool di 254 indirizzi (subnet /24) non è sufficiente per 2.000 delegati. Espandere il pool a una subnet /22 o /21 (1.022 o 2.046 indirizzi) se possibile. Come controllo secondario, verificare che l'ACL di pre-autenticazione sullo SmartZone consenta le query DNS (porta 53) da parte dei client non autenticati, poiché un traffico DNS ad alto volume può talvolta attivare regole di limitazione della frequenza.
Q2. Il responsabile IT di un hotel riceve un reclamo da un ospite che soggiorna nella camera 412. L'ospite dichiara che la pagina di login del WiFi è apparsa brevemente, ha inserito il proprio indirizzo email e accettato i termini, ma ora gli viene chiesto di accedere nuovamente ogni 10-15 minuti. Altri ospiti sullo stesso piano non segnalano questo problema. L'ospite utilizza un iPhone 15 con iOS 17. Qual è la causa e la risoluzione più probabile?
Suggerimento: Il problema è specifico di un singolo dispositivo e comporta ripetute riautenticazioni a brevi intervalli. Considera cosa fa iOS 17 per impostazione predefinita con gli indirizzi MAC sulle reti WiFi e come il gateway wireless dell'hotel tiene traccia delle sessioni autenticate.
Visualizza risposta modello
La causa più probabile è la randomizzazione dell'indirizzo MAC. iOS 14 e versioni successive abilitano l'opzione Indirizzo Wi-Fi privato per impostazione predefinita, il che fa sì che l'iPhone presenti un indirizzo MAC generato casualmente a ciascuna rete. In iOS 17, il MAC randomizzato può ruotare periodicamente (circa ogni 24 ore) o a ogni nuova associazione di rete. Il gateway wireless dell'hotel tiene traccia delle sessioni degli ospiti autenticati tramite indirizzo MAC; quando l'indirizzo MAC cambia, il gateway tratta il dispositivo come un nuovo client non autenticato e blocca l'accesso a Internet, attivando nuovamente il Captive Portal. La risoluzione per l'ospite consiste nel disattivare l'Indirizzo privato per l'SSID dell'hotel: andare su Impostazioni > Wi-Fi, toccare l'icona (i) accanto all'SSID dell'hotel e disattivare Indirizzo Wi-Fi privato. Il dispositivo si riconnetterà con il suo indirizzo MAC hardware e la sessione persisterà senza ripetute riautenticazioni. Come mitigazione a lungo termine lato operatore, l'hotel dovrebbe considerare l'implementazione della persistenza della sessione basata sull'indirizzo IP (oltre al MAC) o il passaggio a OpenRoaming/Passpoint per gli ospiti che ritornano, eliminando del tutto il problema della riautenticazione sul Captive Portal.
Q3. Il team IT di una catena di negozi ha configurato un nuovo Captive Portal utilizzando Purple. Il walled garden è stato impostato con il dominio del portale e i domini dei principali provider di social login. Durante i test, la pagina del portale si carica correttamente e l'opzione di login via email funziona, ma quando un tester fa clic su 'Accedi con Google', viene visualizzato brevemente un popup di accesso di Google che poi si chiude senza completare l'autenticazione. Il tester utilizza un Samsung Galaxy S23 con Android 13 e browser Chrome. Cosa dovrebbe verificare il team IT?
Suggerimento: Il popup di Google appare ma si chiude senza completarsi: questo significa che il reindirizzamento OAuth iniziale a Google funziona, ma qualcosa fallisce durante il callback di autenticazione o lo scambio di token. Considera quali domini sono coinvolti nel flusso completo di Google OAuth 2.0 oltre a accounts.google.com.
Visualizza risposta modello
Il sintomo — il popup di Google che appare ma si chiude senza completarsi — indica che il reindirizzamento OAuth iniziale a Google ha successo (accounts.google.com è nel walled garden), ma uno o più domini successivi di callback OAuth o di scambio di token vengono bloccati. Il flusso Google OAuth 2.0 per le applicazioni web coinvolge più domini oltre a accounts.google.com. Il team IT dovrebbe aprire Chrome DevTools sul dispositivo di test (o utilizzare un browser desktop per simulare il flusso), fare clic su Accedi con Google e osservare la scheda Network per individuare eventuali richieste non andate a buon fine. I domini mancanti più comuni includono: oauth2.googleapis.com (endpoint del token), www.googleapis.com (chiamate API), ssl.gstatic.com e fonts.gstatic.com (la CDN di Google per le risorse della pagina di accesso) e lh3.googleusercontent.com (caricamento dell'immagine del profilo, che può causare il blocco del popup). Aggiungere tutti i domini mancanti identificati al walled garden nella configurazione del controller Aruba/Cisco/Ruckus, utilizzando pattern wildcard (*.googleapis.com, *.gstatic.com) dove il controller supporta il DNS snooping. Eseguire nuovamente il test dopo ogni aggiunta per isolare il dominio bloccante specifico. Una volta che il flusso completo di Google OAuth si completa con successo, convalidare la correzione sia su dispositivi Android che iOS prima del rilascio in produzione.
Continua a leggere questa serie
Come configurare un Captive Portal su Starlink: una guida per sedi remote e marittime
Questa guida spiega in dettaglio come escludere l'hardware nativo di Starlink e integrare un Captive Portal gestito in cloud utilizzando apparecchiature di routing aziendali. Imparerai come superare il limite del CGNAT, applicare la segmentazione VLAN, gestire i vincoli di larghezza di banda satellitare e garantire la conformità normativa.
Captive Portal Best Practices: Progettazione per Conversioni Elevate e Compliance
Questa guida tecnica offre a IT manager, architetti di rete e direttori operativi delle location un modello completo per l'implementazione di Captive Portal in grado di bilanciare la sicurezza di rete con un tasso elevato di conversione degli utenti. Copre l'intera architettura, dalla segmentazione VLAN e autenticazione RADIUS fino alla progettazione del consenso conforme al GDPR e alla selezione del metodo di autenticazione. Basata sull'esperienza operativa di Purple in oltre 80.000 location e 440 milioni di login nel 2024, ogni raccomandazione è fondata su dati reali di implementazione.
Come ottimizzare i Captive Portal per la massima sicurezza di rete e conversione degli utenti
Questa guida fornisce un progetto tecnico completo per l'ottimizzazione dei captive portal all'interno di strutture aziendali, coprendo l'architettura di segmentazione della rete, la selezione dei metodi di autenticazione, la progettazione del consenso conforme al GDPR e l'ottimizzazione delle conversioni. È scritta per IT manager, architetti di rete e CTO di hotel, catene di vendita al dettaglio, stadi e organizzazioni del settore pubblico che devono bilanciare la sicurezza della rete con l'acquisizione di dati di prima parte. Purple gestisce l'infrastruttura dei captive portal in oltre 80.000 sedi con 440 milioni di accessi nel 2024, e i framework qui presentati riflettono tale esperienza operativa.