Accesso al captive portal su Android: una checklist di distribuzione per Cisco Meraki, HPE Aruba e Ubiquiti UniFi

La pagina di accesso Android non viene visualizzata quando il controllo di connettività di Google raggiunge internet prima dell'accesso, o se il suo reindirizzamento è bloccato. Escludi l'host di prova dal walled garden, consenti solo i domini di splash e login, reindirizza la sonda HTTP a una splash page HTTPS e imposta un timeout di sessione su Cisco Meraki, HPE Aruba o Ubiquiti UniFi.

Cosa fa in realtà il login del captive portal su Android?

Un captive portal è la splash page che un visitatore visualizza prima che la rete consenta l'accesso a internet. Presenta le opzioni di login che l'ospite deve completare prima di andare online. L'articolo di supporto di Purple sul captive portal descrive l'intera sequenza.

Ogni sistema operativo principale include un Captive Network Assistant (CNA). Il CNA è un piccolo browser integrato che gestisce il portale per l'ospite. Su Android, il CNA ha quattro compiti:

1. Verificare la connettività internet non appena il telefono si connette alla rete.
2. Informare la persona che tiene in mano il telefono che potrebbe dover effettuare l'accesso.
3. Aprire una sessione del browser per la splash page quando tocca la notifica.
4. Confermare lo stato online una volta che il login è andato a buon fine.

Quando uno di questi passaggi si interrompe, l'ospite vede una rete connessa che non funziona. Di solito la colpa viene attribuita al tuo WiFi, non al loro telefono.

La sonda del controllo di connettività

Quando un telefono Android si connette a una rete, invia una richiesta HTTP semplice a un endpoint di controllo della connettività ospitato da Google. Tale endpoint normalmente restituisce una risposta HTTP 204 vuota. Se il telefono riceve la risposta 204, deduce che internet è raggiungibile e non mostra alcuna richiesta di accesso.

Su una rete ospiti, il tuo controller intercetta quella richiesta prima dell'accesso e restituisce invece un reindirizzamento alla splash page. Il telefono vede una risposta imprevista e deduce di trovarsi dietro un captive portal. L'intero processo di rilevamento dipende dal fatto che la sonda venga intercettata, non lasciata passare.

La notifica "Accedi alla rete WiFi"

Una volta che la sonda fallisce, Android mostra una notifica che informa l'ospite che potrebbe dover effettuare l'accesso. Toccandola si avvia la sessione del browser CNA. Se l'ospite ignora la notifica con uno scorrimento, il telefono rimane connesso senza accesso a internet. In questo caso, Purple consiglia di aprire un browser e visitare neverssl.com. Questo sito di terze parti rimane su HTTP semplice, in modo che il controller possa reindirizzarlo senza errori di certificato.

Cos'è l'app di login del captive portal su Android?

L'app di login del captive portal è il CNA di Android. Si tratta di un browser ridotto all'essenziale, senza la barra degli indirizzi o estensioni. La documentazione di supporto di Purple lo descrive come una "tela bianca" che consente al reindirizzamento del captive portal di completarsi senza ostacoli. La versione stock di Android chiude automaticamente la finestra una volta completata l'autenticazione. Alcuni produttori di telefoni modificano questa impostazione predefinita, quindi su quei telefoni l'ospite potrebbe dover chiudere la finestra manualmente. Dietro le quinte, tre sistemi lavorano insieme. Il controller gestisce l'interazione con i server della splash page di Purple. La splash page raccoglie i dati dell'ospite e rilascia un login monouso. Il controller trasmette quindi tale login al server RADIUS di Purple, il servizio di autenticazione che concede l'accesso, per completare la registrazione.

L'API Captive Portal e l'opzione DHCP 114

Le versioni più recenti di Android possono anche rilevare un portale senza effettuare prove. La rete annuncia un indirizzo API Captive Portal tramite l'opzione DHCP 114, definita in RFC 8910. Il DHCP è il servizio che distribuisce gli indirizzi IP. Il telefono interroga tale API tramite HTTPS e la risposta, definita in RFC 8908, indica se il dispositivo è vincolato e dove risiede il portale. Questo evita del tutto il trucco del reindirizzamento. Funziona solo se l'endpoint API dietro l'opzione è attivo e correttamente certificato.

Di cosa hai bisogno prima di iniziare?

Raccogli questi elementi prima di toccare qualsiasi access point:

• Accesso come amministratore al tuo controller o dashboard: Cisco Meraki Dashboard, HPE Aruba (Instant o Central, o un Mobility Controller) o l'applicazione UniFi Network.
• Un SSID ospite aperto. Purple consiglia di fornire il WiFi per gli ospiti su una rete aperta. Le reti aperte rappresentano ormai lo standard e riducono l'attrito per i visitatori.
• Una VLAN ospite dedicata. Una VLAN è un segmento di rete logico. Il traffico degli ospiti non dovrebbe mai condividere un segmento con il personale o con i sistemi di pagamento, il che ti mantiene all'interno delle regole di conformità PCI-DSS.
• L'elenco dei walled garden di Purple e l'URL della splash page. Prendi i valori correnti dall'articolo di supporto del captive portal. Non copiarli da una vecchia implementazione.
• Dettagli RADIUS per i server di autenticazione di Purple, dal tuo account Purple.
• Dispositivi di prova. Utilizza almeno tre telefoni Android di diversi produttori, più un iPhone per il confronto.

Purple è indipendente dall'hardware. Funziona come un overlay cloud su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Configuri il controller che già possiedi, senza necessità di alcuna sostituzione dell'hardware.

Come si configura l'accesso al captive portal su Android per Meraki, Aruba e UniFi?

Procedi attraverso cinque impostazioni nell'ordine indicato. Ognuna di esse corrisponde a una funzionalità specifica su ciascuna piattaforma. Per i percorsi di menu precisi e i valori correnti, segui l'articolo di supporto di Purple invece di questo riepilogo.

Passaggio 1: crea un walled garden rigoroso

Il walled garden è l'elenco dei domini che un ospite può raggiungere prima di registrarsi. Deve includere i domini della splash page di Purple e i domini di eventuali login social offerti. Non deve includere l'host di controllo della connettività di Google.

L'errore comune è l'uso di una wildcard generica. L'aggiunta di ogni dominio Google per supportare l'accesso con Google consente anche il passaggio del probe di Android. Il telefono riceve il suo codice 204, decide di essere online e non mostra mai la notifica. Limita le voci di accesso social al livello più restrittivo consentito dal provider. Se hai bisogno dell'accesso con Google e del rilevamento Android contemporaneamente, testa entrambi dopo ogni modifica al walled garden.

Passaggio 2: blocca tutto il resto fino all'accesso

Il controller deve intercettare tutto il traffico web proveniente da dispositivi non autenticati. Qualsiasi cosa lasciata aperta offre ad Android un percorso verso un falso risultato "online".

Su Cisco Meraki, imposta la restrizione del Captive Portal per bloccare tutti gli accessi fino alla registrazione. Su HPE Aruba, assicurati che il ruolo di pre-autenticazione neghi tutto ad eccezione del walled garden e del DNS. Su Ubiquiti UniFi, conferma che la rete guest limiti tutti gli accessi prima dell'autorizzazione, ad eccezione dell'elenco consentito di pre-autorizzazione.

Passaggio 3: reindirizza l'HTTP e proteggi la pagina di login con HTTPS

I controller non possono intercettare in modo pulito il traffico HTTPS senza attivare errori di certificato. Il probe di Android utilizza il protocollo HTTP in chiaro, che il controller può reindirizzare. Lascia attiva l'intercettazione HTTP del probe.

La pagina su cui atterra l'ospite è una questione diversa. L'articolo di Purple sulla configurazione del certificato del captive portal Cisco WLC mostra cosa succede quando un controller reindirizza a un indirizzo di login HTTP non sicuro. I browser mostrano un avviso del tipo "La tua connessione non è privata" e gli ospiti presumono che la rete non sia sicura. La soluzione consiste in un certificato SSL/TLS pubblicamente attendibile sul controller. L'hostname virtuale del controller deve corrispondere al Common Name del certificato. Lo stesso principio si applica ai controller Aruba che ospitano la propria pagina di login.

Passaggio 4: mantieni il DNS attivo per i dispositivi non autenticati

Gli ospiti devono poter risolvere l'hostname della splash page prima di effettuare l'accesso. Consenti il DNS standard verso il resolver prescelto nella policy di pre-autenticazione. Senza di esso, il reindirizzamento punta a un nome che il telefono non può risolvere.

L'impostazione Private DNS di Android aggiunge una seconda considerazione, trattata nella sezione di risoluzione dei problemi riportata di seguito.

Passaggio 5: imposta un timeout di sessione adatto alla visita

Il timeout di sessione stabilisce la durata di un accesso prima che l'ospite debba effettuare nuovamente il login. Adattalo alla durata della permanenza dei visitatori. Un bar potrebbe utilizzare poche ore. Un hotel dovrebbe coprire l'intera durata del soggiorno.

Passaggio 6: decidi sull'opzione DHCP 114

Includi l'opzione 114 solo se supportata da un endpoint API funzionante e conforme allo standard RFC 8908. Un valore che punta a un endpoint che non risponde correttamente aggiunge un punto di vulnerabilità invece di risolverlo. In caso di dubbi, lascialo non impostato. Android utilizzerà il probe di connettività alternativo, già supportato dai passaggi da 1 a 4. Conferma con il supporto di Purple prima di abilitarlo.

Dove si trova ciascuna soluzione sulla tua piattaforma

Soluzione	Cisco Meraki	HPE Aruba	Ubiquiti UniFi
Consenti i domini splash e di login prima dell'accesso	Intervalli di walled garden nelle impostazioni della splash page dell'SSID	Whitelist del walled garden nel profilo del captive portal o nel ruolo pre-auth	Elenco dei permessi di pre-autorizzazione sull'hotspot guest
Mantieni bloccato l'host di probe	Rimuovi i caratteri jolly generici di Google dagli intervalli del walled garden	Rimuovi i caratteri jolly generici di Google dalla whitelist	Rimuovi i caratteri jolly generici di Google dall'elenco dei permessi
Blocca tutto l'altro traffico fino all'accesso	Forza del captive portal: blocca ogni accesso fino al login	Il ruolo pre-auth nega tutto tranne il walled garden e il DNS	Restrizioni della rete guest prima dell'autorizzazione
Proteggi la pagina di login	Reindirizza all'URL HTTPS della splash page di Purple	Certificato pubblicamente attendibile sul controller	Reindirizza all'URL HTTPS della splash page di Purple
Durata della sessione	Frequenza di splash e timeout della sessione RADIUS	Timeout della sessione nel captive portal o nel profilo RADIUS	Scadenza dell'autorizzazione sull'hotspot
Opzione DHCP 114	Opzione DHCP personalizzata su MX o sul server DHCP a monte	Ambito DHCP sul controller o sul server a monte	Opzione DHCP personalizzata sulla rete del gateway UniFi

Come si verifica il funzionamento della pagina di login di Android?

Esegui il test da uno stato pulito ogni volta. Un telefono che ricorda la rete, o che mantiene una sessione attiva, nasconde il problema che stai cercando di trovare.

1. Dimentica la rete su ciascun dispositivo di test, quindi riconnettiti.
2. Attendi la notifica entro pochi secondi dalla connessione. L'assenza di notifica indica che il probe ha raggiunto Internet o che il DNS ha riscontrato un errore.
3. Tocca la notifica e completa l'accesso. La splash page dovrebbe caricarsi senza avvisi di certificato.
4. Verifica il comportamento della finestra. Su Android stock si chiude da sola. Sulle build di alcuni produttori è necessario chiuderla manualmente, il che è normale.
5. Naviga su un normale sito HTTPS per confermare l'accesso completo.
6. Ripeti con il DNS privato impostato su Rigoroso su un dispositivo, in modo da sapere cosa vedranno gli ospiti che lo utilizzano.
7. Controlla i log. Conferma l'accettazione RADIUS in Purple e lo stato autorizzato del client sul controller.

Esegui il test su telefoni Android di almeno tre produttori diversi. L'iPhone utilizza un host di probe e una CNA differenti, trattati nella guida di Purple complementare per il captive portal di iPhone, ma le cause sul lato controller sono le stesse. Una sola sessione di test individua i problemi su entrambe le piattaforme.

Perché non viene mostrata la notifica di accesso alla rete WiFi di Android e come si risolve?

La maggior parte dei problemi è riconducibile a una di queste cinque cause. Inizia con il sintomo segnalato dall'ospite.

Sintomo	Causa probabile	Soluzione
Connesso, nessuna notifica, nessun accesso a Internet	Probe consentito tramite una voce troppo generica nel walled garden	Rimuovi le voci jolly di Google dal walled garden
La notifica compare, ma la splash page non si carica	DNS bloccato prima dell'accesso, o dominio splash mancante dal walled garden	Consenti il DNS pre-auth; aggiungi i domini splash di Purple
Avviso sul certificato o "non privato"	Pagina di login del controller servita tramite HTTP o con un certificato non attendibile	Installare un certificato pubblicamente attendibile corrispondente al nome host
Il login riesce, la finestra rimane aperta	Il produttore ha modificato le impostazioni predefinite della CNA	Chiudere la finestra manualmente; non è necessaria alcuna modifica alla rete
L'ospite deve accedere a ogni visita	Nuovo indirizzo MAC randomizzato o timeout della sessione breve	Allungare il timeout; spiegare le impostazioni del MAC randomizzato
L'ospite ha ignorato la notifica	Nessun messaggio di avviso a cui fare riferimento	Aprire un browser e visitare neverssl.com

Il DNS privato compromette i Captive Portal?

Sì, può accadere. L'impostazione DNS privato di Android crittografa le query DNS utilizzando DNS over TLS. Dispone di due modalità attive che si comportano in modo diverso su una rete ospiti.

In modalità Automatica, Android utilizza il DNS crittografato quando la rete lo supporta, e torna al DNS della rete stessa quando questa non lo supporta. I Captive Portal si caricano normalmente.

In modalità Rigida, l'ospite specifica il nome host di un provider DNS particolare. Prima dell'accesso, tale provider non è raggiungibile perché la policy di pre-autenticazione lo blocca. Il telefono potrebbe non essere in grado di risolvere la splash page e Android potrebbe avvisare che non è possibile accedere al server DNS privato.

Non è ragionevole aggiungere tutti i provider di DNS crittografati pubblici al walled garden. La soluzione pratica consiste nel fornire istruzioni all'ospite. Aggiungete una riga alla segnaletica o alla pagina di aiuto: impostare il DNS privato su Automatico, accedere e poi ripristinare l'impostazione precedente.

Perché i telefoni Android devono accedere nuovamente a ogni visita?

Di default, Android utilizza un indirizzo MAC randomizzato per ogni rete. Un indirizzo MAC è l'identificatore hardware utilizzato dal controller per riconoscere un dispositivo. L'indirizzo randomizzato di solito rimane stabile per un determinato SSID. Cambia se l'ospite rimuove la rete, ripristina le impostazioni di rete o modifica le impostazioni sulla privacy. Per il controller, quel telefono risulta quindi come un dispositivo completamente nuovo.

La seconda causa è il timeout della sessione impostato dall'amministratore. Un timeout breve impone un nuovo accesso alla scadenza della sessione, indipendentemente dalla stabilità dell'indirizzo MAC. Verificate entrambi gli aspetti prima di presumere che il problema risieda nel telefono. Per le strutture in cui il ritorno dei visitatori è importante, OpenRoaming offre una riconnessione automatica e sicura senza alcuna splash page. È la soluzione ideale per hub di trasporto e strutture multi-sito.

Scenario d'esempio 1: un hotel da 200 camere con accesso Google

Scenario puramente illustrativo, cifre fornite solo a scopo dimostrativo.

Situazione. Un hotel di città da 200 camere ha aggiunto l'accesso Google alla propria splash page. Nel giro di una settimana, il personale della reception ha registrato ripetuti reclami da parte di ospiti con dispositivi Android. I telefoni mostravano il segnale massimo ma non caricavano alcuna pagina, e non appariva alcuna richiesta di accesso. Gli ospiti con iPhone segnalavano molti meno problemi.

Cosa è stato fatto. Il team di rete ha esaminato il walled garden di Meraki. Un fornitore esterno aveva aggiunto un carattere jolly generico che copriva tutti i domini Google per supportare la nuova opzione di accesso. Quella voce consentiva il passaggio del test di connettività di Android. Il team ha sostituito il carattere jolly con le voci più specifiche elencate nell'articolo di supporto di Purple. Hanno quindi eseguito nuovamente i test su telefoni di tre diversi produttori.

Risultato. Ogni telefono di prova ha mostrato la notifica di accesso al primo tentativo di connessione. La reception non ha registrato ulteriori reclami relativi al WiFi su Android nelle due settimane successive. L'hotel ha inoltre esteso il timeout della sessione per coprire un tipico soggiorno di tre notti. In questo modo è stato evitato il reinserimento giornaliero delle credenziali per gli ospiti che ritornavano. Scopri come Purple supporta le strutture ricettive del settore hospitality.

Scenario reale 2: la rete di una biblioteca comunale su UniFi

Scenario illustrativo, cifre fornite solo a scopo esemplificativo.

Situazione. Un comune gestiva il WiFi per gli ospiti in 12 biblioteche di quartiere su Ubiquiti UniFi. I visitatori con telefoni Android più recenti segnalavano un avviso del tipo "Impossibile accedere al server DNS privato" e una splash page che non si caricava mai. Il personale della biblioteca perdeva molto tempo a spiegare ai visitatori come modificare impostazioni che non comprendevano.

Cosa è stato fatto. Il team IT ha confermato che il DNS era consentito prima dell'autorizzazione, quindi le normali query di risoluzione funzionavano correttamente. I telefoni interessati avevano tutti l'opzione DNS privato impostata su Strict con un provider specifico. Il team ha aggiunto una breve istruzione al testo di aiuto della splash page e ai poster nelle filiali. Veniva indicato ai visitatori di impostare il DNS privato su Automatico, effettuare l'accesso e poi ripristinare l'impostazione precedente. Hanno inoltre lasciato non configurata l'opzione DHCP 114, poiché non era presente alcun endpoint API conforme.

Risultato. Il personale delle biblioteche ha riferito che la maggior parte dei visitatori interessati dal problema riusciva ora a effettuare l'accesso in autonomia seguendo le istruzioni del poster. Le richieste di supporto al desk IT centrale per il WiFi della biblioteca sono scese a una manciata al mese. Le strutture del settore pubblico condividono molte delle stesse dinamiche dei siti nei settori transport e healthcare.

Quanto costa e qual è il ritorno economico?

La maggior parte delle correzioni per il Captive Portal su Android richiede tempo del personale, non hardware. Le voci del walled garden, l'intensità del Captive Portal, i timeout di sessione e le regole DNS sono modifiche di configurazione sul controller che già utilizzi. Il costo diretto principale è rappresentato da un certificato attendibile pubblicamente, nel caso in cui il tuo controller ospiti la propria pagina di accesso.

Purple Guest WiFi è disponibile in tre piani: Connect, Capture e Engage. I prezzi variano in base al numero di sedi e al piano scelto, quindi richiedi un preventivo a Purple per la tua infrastruttura.

Il ritorno economico è rappresentato da ogni visitatore Android che effettua l'accesso invece di rinunciare. Ogni accesso completato corrisponde a un ospite connesso e, con Capture e Engage, rappresenta anche una raccolta di dati di prima parte tramite un consenso esplicito e consapevole. Questi dati alimentano le analisi WiFi, i CRM e le piattaforme di marketing che già utilizzi. I dati interni di Purple mostrano 440 milioni di accessi nel 2024 in oltre 80.000 sedi attive. Su questa scala, un errore di rilevamento su un singolo SSID per gli ospiti rappresenta una perdita misurabile di visitatori connessi. C'è anche un costo che eviti. Gli ospiti che vedono un avviso di certificato o una connessione interrotta giudicano la tua location, non il loro telefono. Per i marchi del retail e dell'ospitalità, quella prima impressione avviene sulla porta d'ingresso.

Se anche il personale ha bisogno di accedere insieme agli ospiti, gestiscilo su un SSID separato con autenticazione basata sull'identità. Il post del blog di Purple su How to Enable Single Sign On spiega come connettere Microsoft Entra ID, Okta e Google Workspace.

Domande frequenti

Purple Guest WiFi funziona con gli access point Cisco Meraki, HPE Aruba o Ubiquiti UniFi che già possiedo?

Sì. Purple è indipendente dall'hardware e funziona come overlay cloud su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Mantieni i tuoi access point e controller esistenti. Indirizzi il Captive Portal del SSID ospiti alla splash page di Purple, aggiungi le voci del walled garden dall'articolo di supporto di Purple e imposti il server RADIUS di Purple per l'autenticazione. Non è richiesta alcuna sostituzione dell'hardware.

Il Private DNS di Android blocca i Captive Portal?

Può succedere, in modalità Strict. In modalità automatica, Android si affida al DNS della rete stessa e il portale si carica normalmente. In modalità Strict con un hostname del provider specificato, il telefono potrebbe non essere in grado di risolvere la splash page prima dell'accesso, perché quel provider non è raggiungibile finché l'ospite non si autentica. La soluzione più rapida consiste nel far passare l'ospite alla modalità automatica, effettuare l'accesso e poi ripristinare la modalità precedente. Inserisci questa istruzione nella tua segnaletica.

Perché gli ospiti con dispositivi Android devono accedere nuovamente a ogni visita?

Di solito perché il telefono presenta un nuovo indirizzo MAC casuale o la sessione è scaduta. Android rende casuale l'indirizzo MAC per ogni rete, e dimenticare la rete o ripristinare le impostazioni ne produce uno nuovo. Anche il timeout della sessione determina la durata di un login. Impostalo in modo che corrisponda al modello di visita, come un intero soggiorno in hotel piuttosto che un singolo caffè. OpenRoaming offre la riconnessione automatica per i visitatori che ritornano.

Ho bisogno di un certificato SSL per il mio Captive Portal?

Sì, per qualsiasi pagina di login ospitata dal tuo controller. I browser moderni si aspettano l'HTTPS per le pagine di login e avvisano quando incontrano un collegamento HTTP non sicuro, il che fa sembrare non sicura una rete affidabile. La guida di Purple per i controller Cisco prevede un certificato pubblicamente attendibile, con l'hostname virtuale che corrisponde al Common Name del certificato. Il probe di Android utilizza ancora HTTP, quindi l'intercettazione continua a funzionare.

La mia rete WiFi per gli ospiti deve essere aperta o protetta da password?

Aperta, con un Captive Portal. Purple consiglia di fornire il WiFi per gli ospiti su una rete aperta perché ormai è la convenzione standard e riduce gli ostacoli per i visitatori. Sia Android che iPhone rilevano un Captive Portal su un SSID aperto e invitano l'ospite a effettuare l'accesso. Mantieni il traffico degli ospiti sulla propria VLAN. Gestisci l'accesso del personale o dei residenti su un SSID separato con autenticazione basata sull'identità.

I dati raccolti tramite il Captive Portal sono conformi al GDPR?

Sì. Purple è certificato GDPR, CCPA, ISO 27001 e Cyber Essentials. La splash page utilizza opt-in basati su scelte consapevoli, in modo che ogni ospite decida cosa condividere e se ricevere comunicazioni di marketing. I dati raccolti sono dati di prima parte, ottenuti con il consenso al momento del login. Puoi comunque impostare la tua informativa sulla privacy e la tua politica di conservazione dei dati, come per qualsiasi dato personale sotto il tuo controllo.

Quanto tempo occorre per risolvere un problema con il captive portal di Android?

La maggior parte delle soluzioni richiede una singola modifica di configurazione sull'SSID ospiti, seguita da un test. Le modifiche al walled garden, la stabilità del captive portal, le regole DNS e i timeout di sessione non richiedono nuovo hardware. Dedica la maggior parte del tempo ai test su telefoni Android di almeno tre produttori diversi partendo da uno stato pulito. Alcuni marchi modificano il comportamento della finestra di login, ed è preferibile scoprirlo prima dei tuoi visitatori.

La risoluzione per Android è diversa da quella per il captive portal di iPhone?

In parte. Le cause lato controller sono le stesse su entrambe le piattaforme: ambito del walled garden, DNS bloccato, reindirizzamenti HTTP e timeout di sessione. Le differenze risiedono sul dispositivo. Android interroga un endpoint ospitato da Google, mentre iPhone interroga un endpoint Apple. Android aggiunge anche il comportamento del Private DNS e le modifiche del produttore alla finestra di login. La guida complementare di Purple sul captive portal per iPhone copre in dettaglio il lato Apple.