Vai al contenuto principale
Italiano

Perché il tuo captive portal non si carica su iPhone: Risolvi gli errori Apple CNA

Risolvi i problemi e correggi i difetti di apertura dei popup del captive portal su iPhone e iOS. Scopri in che modo Apple CNA, iCloud Private Relay e la randomizzazione MAC bloccano i login al WiFi, e come risolverli.

Di Tom HackettPubblicato
📖 10 minuti di lettura1,788 parole2 esempi pratici3 domande di esercitazione6 definizioni chiave

Video overview

Ascolta questa guida

Visualizza trascrizione del podcast
[Musica introduttiva: Synth-pop elettronico moderno e ritmato con accenti nitidi di pianoforte, che stabilisce un tono professionale e all'avanguardia] **Host (Senior Consultant)**: Ciao e benvenuti al Purple Technical Briefing. Sono il vostro presentatore e oggi analizzeremo a fondo uno dei problemi più comuni e, francamente, più frustranti che gli amministratori di rete, i responsabili IT e i direttori operativi delle strutture si trovano ad affrontare oggi. Ci siamo passati tutti. Avete passato settimane a pianificare, configurare e distribuire una rete WiFi per gli ospiti all'avanguardia per il vostro hotel, centro commerciale o stadio. Avete gli access point più recenti, un controller robusto e una bellissima splash page pronta a catturare i dati degli ospiti e a stimolare il coinvolgimento. Ma poi iniziano ad arrivare i ticket di assistenza. E dicono tutti la stessa identica cosa: "Mi sono connesso al WiFi per gli ospiti sul mio iPhone, ma la pagina di accesso non si carica". Per l'ospite, il vostro WiFi è semplicemente non funzionante. Ma per noi, in qualità di ingegneri e architetti di rete, sappiamo che sotto il cofano di iOS si sta svolgendo una complessa battaglia tecnica. Oggi analizzeremo esattamente il motivo per cui il vostro Captive Portal non si carica sugli iPhone, come funziona la logica di rilevamento in background di Apple e i passaggi di mitigazione che potete implementare sulla vostra rete in questo trimestre. [Breve stacco musicale di transizione] **Host**: Iniziamo con l'approfondimento tecnico. Perché un iPhone si connette al WiFi per gli ospiti ma non mostra la schermata di accesso? Per capire questo, dobbiamo guardare al **Captive Network Assistant** di Apple, o **CNA**. Quando un iPhone si associa a un SSID aperto e riceve un indirizzo IP tramite DHCP, non aspetta semplicemente che l'utente apra un browser. Al contrario, un demone di sistema in background invia immediatamente una richiesta HTTP GET in chiaro a un URL molto specifico: `http://captive.apple.com/hotspot-detect.html`. Questo probe in background utilizza un User-Agent di sistema univoco chiamato `CaptiveNetworkSupport`. Il demone CNA è alla ricerca di una risposta molto specifica. Se i server Apple restituiscono un codice di stato HTTP **200 OK** con un corpo che contiene esattamente la parola "Success", iOS conclude che la rete ha un accesso illimitato a Internet. Stabilisce silenziosamente il WiFi come interfaccia di routing primaria e l'utente prosegue con le sue attività. Tuttavia, se il gateway di rete intercetta la richiesta HTTP e restituisce qualsiasi altra cosa - come un reindirizzamento HTTP 302 o 307 o una pagina HTML personalizzata - iOS riconosce immediatamente che si trova dietro un Captive Portal. Avvia istantaneamente l'app nativa **Websheet**. Si tratta di quella familiare scheda modale a scorrimento verso l'alto che visualizza la pagina di accesso per gli ospiti. Ora, ecco il primo grande ostacolo ingegneristico: **The Walled Garden** (il giardino recintato). Molti ingegneri di rete commettono l'errore di inserire i domini di successo di Apple, come `captive.apple.com`, nella whitelist delle loro Access Control List pre-autenticazione. Pensano: "Beh, è un dominio Apple, dovrei lasciarlo passare." Ma se lo inserisci nella whitelist, il probe in background raggiunge con successo i server di Apple, riceve la risposta "Success" e iOS presuppone che non ci sia alcun Captive Portal. Il Websheet non si attiva mai! Nel frattempo, all'utente è bloccato l'accesso a qualsiasi altro sito web. Quindi, regola numero uno: **non inserire mai captive.apple.com nel tuo walled garden.** [Breve effetto sonoro di transizione] **Host**: Ma cosa dire delle moderne funzionalità di privacy di iOS? Anche con un walled garden perfetto, funzionalità come **iCloud Private Relay** e **Private MAC Addresses** stanno cambiando le regole del gioco. Parliamo di iCloud Private Relay, introdotto in iOS 15. Questa funzionalità crittografa e instrada il traffico DNS e HTTP di Safari attraverso un'architettura proxy a doppio salto. Quando un utente con Private Relay attivo si connette al tuo guest WiFi, il probe HTTP in background viene incapsulato all'interno di un tunnel crittografato. Poiché il tuo gateway di rete non può ispezionare o intercettare questo pacchetto crittografato, non può iniettare il reindirizzamento. Il probe fallisce silenziosamente e l'iPhone mostra semplicemente un avviso di "Nessuna connessione Internet". Nessun portale, nessun login, solo attrito. Fortunatamente, esiste una mitigazione programmatica a livello di rete per questo problema. Apple ha progettato Private Relay affinché rispetti i blocchi a livello di rete. Se il tuo server DNS locale restituisce una risposta **NXDOMAIN** per i domini Private Relay di Apple - nello specifico `mask.icloud.com` e `mask-h2.icloud.com` - iOS riconosce che la rete è incompatibile con Private Relay. Mostrerà immediatamente un messaggio di sistema che chiede all'utente se desidera "Utilizzare senza Private Relay" per questa rete. Nel momento in cui lo toccano, il tunnel crittografato viene ignorato, il probe HTTP viene intercettato e il tuo Captive Portal si carica perfettamente. Il passo successivo è rappresentato da **Private MAC Addresses** e dai nuovi **Rotating MAC Addresses** in iOS 18. Per impostazione predefinita, gli iPhone rendono casuale il loro indirizzo MAC per ogni SSID. In iOS 18, questo indirizzo ruota periodicamente anche mentre si è connessi alla stessa rete. Se il tuo controller wireless traccia le sessioni guest autenticate esclusivamente tramite l'indirizzo MAC, una rotazione improvvisa farà sì che il gateway tratti l'iPhone come un dispositivo nuovo di zecca e non autenticato. L'ospite viene bruscamente disconnesso e costretto ad accedere nuovamente. Per mitigare questo problema, le sedi aziendali devono abbandonare il semplice tracciamento basato su MAC. Piattaforme come **Purple** risolvono questo problema inserendo un cookie sicuro e persistente nella sessione del browser o, meglio ancora, facendo passare le sedi a **Passpoint**, noto anche come Hotspot 2.0. Passpoint utilizza profili sicuri 802.1X per autenticare automaticamente e in modo sicuro gli ospiti che ritornano senza mai mostrare una schermata di Captive Portal. È sicuro, è fluido e aggira completamente i limiti del CNA. [Breve crescendo musicale di transizione] **Host**: Ora parliamo dei profili DNS personalizzati e delle VPN locali. Molti utenti tecnici installano profili DNS personalizzati come NextDNS o AdGuard che impongono il protocollo DNS-over-HTTPS crittografato. Poiché questi profili aggirano i server DNS locali assegnati tramite DHCP, il gateway non può camuffare la ricerca DNS per `captive.apple.com`. Allo stesso modo, i profili VPN "Always-On" tenteranno di stabilire un tunnel crittografato non appena viene assegnato un indirizzo IP. Se la VPN ha successo, bypassa il reindirizzamento; se viene bloccata, blocca la connessione in un punto di stallo. Per questi utenti, l'ultimo espediente manuale di emergenza è il trucco di **neverssl.com**. Se un ospite è connesso al tuo WiFi ma il portale non si carica, digli di aprire Safari e digitare `neverssl.com` nella barra degli indirizzi. Poiché questo dominio utilizza rigorosamente il protocollo HTTP non crittografato, il gateway intercetterà sicuramente il traffico sulla porta 80 e forzerà il caricamento del reindirizzamento, superando qualsiasi interferenza di DNS personalizzati o VPN. [Effetto sonoro: Segnale acustico di transizione rapida] **Host**: Passiamo a una sessione di domande e risposte rapide sulle problematiche più comuni segnalate dai team di supporto delle strutture. *Domanda uno: Perché il mio iPhone mostra la scritta in arancione "Nessuna connessione internet" sotto il nome del WiFi?* **Risposta**: Questo significa che l'iPhone ha completato l'associazione WiFi e ha ottenuto un indirizzo IP, ma il sondaggio CNA in background non è riuscito a ottenere una risposta dai server di successo di Apple e non è stato reindirizzato correttamente, spesso a causa di iCloud Private Relay o di una VPN attiva. *Domanda due: Possiamo disattivare del tutto il mini-browser CNA sulla nostra rete?* **Risposta**: Sì, la maggior parte dei Wireless LAN Controller aziendali ha un'impostazione chiamata "CNA Bypass" o "Captive Portal Bypass". Quando è abilitata, il controller camuffa il sondaggio di successo di Apple, dicendo all'iPhone che ha pieno accesso a Internet. Questo impedisce la comparsa del Websheet, ma costringe l'utente a aprire manualmente Safari per attivare il reindirizzamento, il che a volte può creare ancora più confusione. *Domanda tre: Che cos'è il problema del sondaggio post-autenticazione?* **Risposta**: Dopo che l'ospite ha effettuato l'accesso, il Websheet del CNA esegue un secondo sondaggio per verificare l'accesso a Internet. Se il gateway lo reindirizza a una landing page ma continua a bloccare i domini di successo di Apple, il pulsante in alto a destra rimane bloccato su "Annulla". Facendo clic su "Annulla", l'utente viene disconnesso dal WiFi. È necessario assicurarsi che i domini di successo di Apple siano completamente accessibili dopo l'autenticazione. [Breve crescendo musicale di transizione] **Host**: Per concludere, esaminiamo l'impatto aziendale nel mondo reale. L'ottimizzazione del vostro Captive Portal non è solo una questione di eleganza tecnica; riguarda direttamente i profitti. Recentemente abbiamo lavorato con un gruppo di resort di lusso a 5 stelle che registrava un tasso di fallimento del 35% nelle connessioni WiFi degli ospiti, il che generava oltre 450 reclami alla reception ogni singola settimana. Ristrutturando il loro walled garden, bloccando i domini Private Relay a livello DNS per forzare il routing locale e implementando la soluzione **Guest WiFi di Purple**, hanno registrato un calo dei ticket WiFi alla reception del **92%** in soli 30 giorni. I punteggi di soddisfazione degli ospiti sono saliti alle stelle e hanno acquisito migliaia di profili di ospiti verificati. Se desiderate garantire che la vostra rete WiFi per gli ospiti interagisca perfettamente con il Captive Network Assistant di Apple, massimizzando al contempo l'acquisizione dei dati e riducendo al minimo i costi di supporto, visitate **purple.ai**. La nostra piattaforma è progettata per gestire tutte queste sfumature specifiche di iOS in modo nativo. Grazie per aver ascoltato questo Briefing Tecnico Purple. Implementate queste strategie per walled garden e DNS questa settimana e vedrete sparire i vostri ticket di supporto. Alla prossima, mantenete le vostre connessioni sicure e il vostro onboarding degli ospiti fluido. [Musica di uscita: Synth-pop elettronico ritmato sfuma lentamente]

Parte della nostra serie principale: Guida al Captive Portal →

Sintesi Esecutiva

Il fallimento dell'accesso tramite Captive Portal sui dispositivi iOS (iPhone e iPad) è una delle cause principali dei reclami relativi alla connessione WiFi ospite negli ambienti hospitality, retail, healthcare e aziendali. Quando un dispositivo iOS si associa a una rete wireless aperta o con autenticazione web, il daemon Captive Network Assistant (CNA) di Apple avvia una serie di probe HTTP in background. Se questi probe vengono bloccati, instradati in modo errato o intercettati in modo non corretto, la splash page del Captive Portal non si carica, lasciando l'utente senza accesso a Internet e senza un modo ovvio per accedere.

Questa guida tecnica illustra in dettaglio i meccanismi alla base del rilevamento di Apple CNA, analizza le principali funzionalità di privacy di iOS - tra cui iCloud Private Relay, Indirizzi WiFi privati (randomizzazione MAC) ed Encrypted DNS - e fornisce strategie di mitigazione passo-passo per ingegneri di rete e gestori di sedi.

Problemi di Disconnessione del WiFi Ospite su iOS?

La piattaforma WiFi ospite gestita in cloud di Purple gestisce automaticamente i probe Apple CNA, iCloud Private Relay e la randomizzazione MAC - offrendo un onboarding fluido tramite Captive Portal su tutti i dispositivi iOS e Android.

Esplora Purple Guest WiFi →

Analisi Tecnica Dettagliata

Logica di Rilevamento e Meccanismo di Probe di Apple

Quando un iPhone si connette a un access point wireless, lo stack di rete iOS invia immediatamente un daemon chiamato captivenetworkd. Questo daemon invia richieste HTTP GET in chiaro a URL di verifica Apple predefiniti, tra cui:

  • http://captive.apple.com/hotspot-detect.html
  • http://www.apple.com/library/test/success.html
  • http://gsp1.apple.com/pep/gcc
+-------------------+       HTTP GET captive.apple.com       +----------------------+
|   iPhone (iOS)    | -------------------------------------> |  Network Controller  |
+-------------------+                                        +----------------------+
          |                                                             |
          | <--- Reindirizzamento HTTP 302 (https://portal.purple.ai) --+
          |
          v
[ Avvia CNA Websheet ] ---> [ Mostra Captive Portal di Purple ]

Il daemon valuta lo stato e il corpo della risposta HTTP:

  1. Risposta di Successo (HTTP 200 con <HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>"): Il sistema operativo deduce che la rete fornisce un accesso internet non limitato. Non viene visualizzata alcuna splash page.
  2. Risposta di Reindirizzamento (HTTP 302 / 307): Il gateway di rete intercetta la richiesta HTTP sulla Porta 80 e reindirizza il client all'URL del captive portal. iOS rileva il reindirizzamento e avvia il CNA Websheet (una finestra browser modale dedicata).
  3. Timeout o Reset della Connessione: Se il gateway scarta i pacchetti della Porta 80 o non risponde alle query DNS, la sonda va in timeout. iOS mostra un avviso "Nessuna connessione Internet" sotto il nome dell'SSID in Impostazioni, ma non riesce a visualizzare la pagina di login.

Sondaggio Post-Autenticazione (La Sfida del Pulsante "Fine")

Dopo che un utente ha inviato le proprie credenziali o ha accettato i termini di servizio sulla splash page, il controller LAN wireless (WLC) aggiorna lo stato dell'ACL del client su "autenticato". Il demone CNA emette immediatamente un sondaggio HTTP di controllo verso captive.apple.com.

Se il secondo sondaggio restituisce HTTP 200 "Success", il pulsante in alto a destra sul CNA Websheet cambia da "Annulla" a "Fine". Se la rete non consente l'accesso HTTP out-of-band subito dopo l'autenticazione, il pulsante rimane bloccato su "Annulla" e toccarlo potrebbe disconnettere completamente il dispositivo dalla rete WiFi.

-

Fattori di Interferenza Specifici di iOS

1. iCloud Private Relay

Introdotto in iOS 15, iCloud Private Relay è un servizio Apple progettato per proteggere la privacy della navigazione web. Quando è abilitato, Safari e il traffico HTTP non crittografato vengono crittografati e instradati attraverso due relay Internet distinti:

[ iPhone ] === Crittografato QUIC/TLS ===> [ Apple Ingress Proxy ] ---> [ Egress Proxy ] ---> [ Target Web ]
  • Il Problema: Private Relay crittografa le richieste DNS tramite Oblivious DNS-over-HTTPS (ODoH) e incapsula il traffico HTTP tramite QUIC (porta UDP 443). Poiché i router gateway locali non possono ispezionare o intercettare il traffico QUIC crittografato, non possono inserire il reindirizzamento standard HTTP 302.
  • Impatto: Il sondaggio HTTP iniziale verso captive.apple.com viene incanalato lontano dal gateway locale, con conseguenti timeout di connessione e splash page mancanti.

2. Indirizzi MAC Privati e Identificativi Rotanti

A partire da iOS 14 e con un'ulteriore espansione in iOS 18, Apple abilita l'Indirizzo WiFi Privato per impostazione predefinita. Invece di utilizzare l'indirizzo MAC hardware permanente del dispositivo, iOS genera un indirizzo MAC casuale per ciascun SSID.

  • Il Problema: Sulle reti che utilizzano l'autorizzazione della sessione basata su MAC (dove agli utenti autenticati è consentito l'accesso per 24 ore in base all'indirizzo MAC), la rotazione del MAC fa sì che il gateway di rete veda i dispositivi che ritornano come nuovi client non autenticati.
  • Impatto: Agli utenti viene presentata ripetutamente la splash page del captive portal, con conseguente scarsa esperienza utente e ticket di supporto all'assistenza clienti.

3. Profili DNS Crittografati (DoH / DoT)

Gli utenti con profili di configurazione iOS personalizzati (come NextDNS, Cloudflare 1.1.1.1 o impostazioni DNS MDM aziendali) trasmettono tutte le query DNS tramite HTTPS crittografato (DoH) o TLS (DoT) direttamente a resolver esterni.

  • Il problema: Il server DNS della rete locale non può intercettare o falsificare le richieste DNS per captive.apple.com o domini inesistenti.
  • Impatto: La risoluzione DNS iniziale aggira completamente il controller locale, impedendo l'attivazione del reindirizzamento al portale.

Guida all'implementazione e alla mitigazione

Progettazione del Walled Garden (ACL di pre-autenticazione)

Per garantire un rendering affidabile del Captive Portal su iOS, i tecnici di rete devono configurare con precisione la Access Control List (ACL) del Walled Garden di pre-autenticazione:

Tipo di regola Destinazione / Dominio Scopo
Consenti *.purple.ai, *.purpleshield.com Consente ai client non autenticati di raggiungere l'infrastruttura e le risorse del portale Purple.
Intercetta HTTP (Porta TCP 80) verso qualsiasi destinazione Intercetta il traffico web HTTP in chiaro per attivare il reindirizzamento 302.
Blocca / NXDOMAIN mask.icloud.com, mask-h2.icloud.com Restituisce NXDOMAIN per segnalare che Private Relay non è disponibile sulla rete locale.
NON inserire in whitelist captive.apple.com, www.apple.com Non deve MAI essere inserito in whitelist. L'inserimento in whitelist fa sì che i probe abbiano successo senza avviare il portale.

Configurazione WLC passo-passo (esempio Cisco Catalyst / Meraki)

  1. Configurare l'intercettazione DNS: Impostare il server DHCP per assegnare l'indirizzo IP del gateway come server DNS primario per i client non autenticati.
  2. Configurare la segnalazione di Private Relay: Aggiungere una regola di riscrittura DNS sui server DNS locali:
    mask.icloud.com      IN A 0.0.0.0 (o NXDOMAIN)
mask-h2.icloud.com   IN A 0.0.0.0 (o NXDOMAIN)
    Quando iOS riceve NXDOMAIN per questi hostname, presenta il prompt di sistema: "Questa rete blocca iCloud Private Relay. Vuoi utilizzare questa rete senza Private Relay?" Toccando Usa senza Private Relay si ripristina il reindirizzamento standard del portale.
  3. Configurare il timeout di sessione: Impostare il timeout della sessione del gateway in base alle coppie IP/MAC o eliminare i cookie di autorizzazione persistenti.

Hai domande sulla tua configurazione specifica?

Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.

Best Practice e standard di settore

La gestione dell'onboarding wireless degli ospiti su larga scala richiede il rispetto dei moderni standard di rete:

  • Transizione a WPA3-Personal (OWE): I portali guest legacy funzionano su SSID aperti e non crittografati. Le sedi aziendali dovrebbero adottare la Opportunistic Wireless Encryption (OWE) (IEEE 802.11aq) per fornire una crittografia individualizzata senza password.
  • Conformità PCI-DSS e GDPR: I portali guest devono isolare il traffico ospiti dalle reti di pagamento PCI-DSS. Quando acquisiscono i dati di contatto, i portali devono presentare caselle di controllo del consenso GDPR esplicite e separate - gestite facilmente tramite una piattaforma di WiFi Analytics.
  • Implementare Passpoint (Hotspot 2.0): Per eliminare del tutto le frizioni del Captive Portal, le sedi possono implementare Passpoint (Hotspot 2.0). Passpoint utilizza un'autenticazione di tipo cellulare per connettere i dispositivi iOS in modo sicuro e automatico tramite un profilo preinstallato, aggirando completamente il daemon CNA.

Risoluzione dei Problemi e Mitigazione dei Rischi

Percorso di Autorisoluzione per l'Utente Finale

  1. Disattivare iCloud Private Relay per la rete: Aprire Impostazioni > WiFi, toccare l'icona (i) accanto al nome della rete e disattivare Limita tracciamento indirizzo IP.
  2. Disattivare Indirizzo WiFi privato: Nel medesimo menu delle impostazioni di rete, disattivare Indirizzo WiFi privato se è richiesto l'accesso basato su indirizzo MAC.
  3. Forzare il reindirizzamento al portale tramite Safari: Aprire Safari e inserire l'indirizzo HTTP non crittografato: http://neverssl.com Poiché neverssl.com non utilizza HTTPS, il router locale intercetterà la richiesta in modo affidabile e caricherà il portale.

Percorso Diagnostico per l'Ingegnere di Rete

                  [ l'iPhone si connette al guest SSID ]
                                  |
                                  v
                        [ IP DHCP assegnato? ]
                        /                   \
                     (No)                   (Sì)
                      /                       \
        [ Verifica Pool DHCP ]          [ Risolve captive.apple.com? ]
                                        /                             \
                                     (No)                             (Sì)
                                      /                                 \
                         [ Verifica ACL DNS ]                  [ Apple è in Whitelist? ]
                                                             /                       \
                                                          (Sì)                      (No)
                                                           /                           \
                                              [ RIMUOVI da Walled Garden ]    [ Reindirizzamenti Porta 80? ]
                                                                               /                   \
                                                                            (No)                   (Sì)
                                                                             /                       \
                                                                 [ Correggi Reindirizzamento WLC ] [ Carica CNA Websheet ]

ROI e Impatto Aziendale

L'ottimizzazione dell'esperienza di onboarding degli ospiti su rete WiFi con dispositivi iOS ha un impatto diretto e misurabile sulle operazioni della struttura e sulle metriche di business.

Case Study nel Settore Hospitality: Gruppo di Resort a Cinque Stelle

  • Sfida: Un gruppo alberghiero di lusso con 12 strutture registrava un tasso di fallimento della connessione WiFi degli ospiti del 35%, generando più di 450 reclami alla reception a settimana.
  • Implementazione: il team IT ha ristrutturato il walled garden, disattivato il tracciamento delle sessioni basato su MAC e implementato la soluzione Guest WiFi di Purple con una gestione ottimizzata dei CNA.
  • Risultati: i reclami relativi al WiFi alla reception sono diminuiti del 92% entro 30 giorni. I punteggi di soddisfazione dei clienti (CSAT) sono saliti di 18 punti e la struttura ha registrato 40.000 nuovi indirizzi e-mail verificati nel primo trimestre.

Caso di Studio Retail: Operatore Nazionale di Centri Commerciali

  • Sfida: un operatore retail con 45 centri commerciali faticava a stimolare il coinvolgimento dei visitatori poiché iCloud Private Relay impediva il caricamento del Captive Portal sul 40% dei dispositivi iOS.
  • Implementazione: è stato implementato il blocco di Private Relay a livello di rete (restituendo NXDOMAIN per i domini di relay di Apple per forzare il routing locale) e implementato WiFi Analytics.
  • Risultati: i tassi di completamento del portale sono balzati dal 58% al 94%. Il team di marketing ha monetizzato lo spazio recuperato sul portale con campagne di retail media localizzate, generando un fatturato pubblicitario aggiuntivo di 120.000 $ a trimestre.

Risorse Correlate

Per i team di networking che distribuiscono reti wireless guest aziendali, queste risorse forniscono un contesto tecnico più approfondito:

La piattaforma Guest WiFi di Purple serve strutture nei settori hospitality, retail, healthcare e transport in tutto il mondo, offrendo esperienze di accesso guest ottimizzate per CNA su scala globale.

Definizioni chiave

Apple Captive Network Assistant (CNA)

Un demone del sistema operativo iOS e macOS che verifica la connettività internet e avvia automaticamente una finestra modale WebKit limitata (WebSheet) quando viene rilevato un captive portal.

Controlla se la pagina di splash di login appare automaticamente sugli iPhone durante la connessione a una WiFi ospiti.

Canary probe URL

Un endpoint HTTP leggero (come http://captive.apple.com/hotspot-detect.html) richiesto dai sistemi operativi dei client per verificare la raggiungibilità di internet senza restrizioni.

Se la risposta del probe viene modificata o reindirizzata, il sistema operativo avvia il suo gestore del captive portal.

RFC 8908 Captive Portal API

Un protocollo standard IETF che fornisce un endpoint API tramite il quale i dispositivi possono verificare lo stato di restrizione della rete, i termini della struttura e il tempo residuo della sessione tramite JSON.

Sostituisce il vecchio dirottamento HTTP con un sistema di rilevamento della rete captive strutturato e crittograficamente sicuro.

Opzione DHCP 114 (Captive-Portal)

Un'opzione DHCP (RFC 8910) che trasmette l'URI della RFC 8908 Captive Portal API al dispositivo client durante l'assegnazione iniziale dell'indirizzo Layer 3.

Segnala lo stato di captive a iOS 14+ immediatamente durante l'acquisizione dell'IP, evitando la manipolazione del DNS.

iCloud Private Relay

Un servizio per la privacy di Apple che instrada il traffico di Safari e il DNS non crittografato attraverso un'architettura proxy crittografata a doppio salto.

Può mascherare le query DNS pre-auth a meno che la rete locale non emetta un segnale esplicito di malfunzionamento della rete (NXDOMAIN).

Indirizzo WiFi privato (randomizzazione MAC)

Una funzionalità di privacy in iOS 14+ che genera un indirizzo MAC randomizzato univoco per SSID per impedire il tracciamento fisico tra diverse sedi.

Può desincronizzare le sessioni di accounting RADIUS se gli indirizzi MAC ruotano a metà sessione o durante la riautenticazione.

Esempi pratici

Un hotel di lusso che distribuisce Cisco Catalyst 9800 WLC rileva che gli ospiti con iPhone non visualizzano mai la schermata di splash del captive portal quando si connettono all'SSID aperto della WiFi ospiti. I laptop Android e Windows caricano il portale immediatamente. In che modo il team di rete dovrebbe diagnosticare e risolvere il problema di rilevamento di Apple CNA?

  1. Ispeziona l'ACL di redirect pre-auth: Verifica che l'ACL di redirect del Cisco 9800 neghi (escluda) il traffico UDP 53 DNS e consenta il traffico TCP 80 HTTP per avviare il reindirizzamento. 2. Controlla la whitelist dei probe Apple: Assicurati che captive.apple.com NON sia inserito nella whitelist del walled garden pre-auth prima del reindirizzamento; inserirlo nella whitelist fa credere a iOS che internet sia aperto, sopprimendo il portale. 3. Verifica HTTP 302 rispetto a 307: Configura la mappa dei parametri webauth del WLC per restituire un reindirizzamento HTTP 302 Found con l'FQDN del portale. 4. Disabilita l'intercettazione HTTPS: Assicurati che il traffico sulla porta 443 HTTPS venga ignorato o rifiutato anziché essere intercettato con un certificato non attendibile. 5. Distribuisci l'Opzione DHCP 114: Aggiungi l'opzione 114 ascii https://app.purplewifi.net/api/v1/capport al pool DHCP ospiti per il rilevamento nativo su iOS 14-18.
Commento dell'esaminatore: I dispositivi Apple si affidano a una corrispondenza rigorosa per il token di Success proveniente da captive.apple.com. Se il dominio del probe viene autorizzato prematuramente attraverso il walled garden, iOS presume erroneamente che internet sia aperto e non avvierà mai il WebSheet.

Un amministratore di rete di uno stadio osserva che gli utenti con iOS 17 e iOS 18 riscontrano un ciclo di login infinito: appare la schermata CNA, l'utente accetta i termini e clicca su Connetti, la finestra modale si chiude, ma 30 secondi dopo si riapre richiedendo nuovamente il login. Qual è la causa principale e come si risolve?

  1. Tracciamento della sessione RADIUS: Su iOS 17/18, gli indirizzi Private Wi-Fi utilizzano indirizzi MAC rotanti se configurati, oppure il dispositivo potrebbe rinegoziare il DHCP all'uscita dalla finestra modale. 2. Configurazione RADIUS CoA: Verifica che il controller elabori il RADIUS Change of Authorization (CoA) Disconnect secondo la norma RFC 3576 sulla porta UDP 3799, in modo che l'ACL pre-auth venga rimosso immediatamente dopo l'autenticazione. 3. Timeout di sessione e periodo di tolleranza: Aumenta il timeout della cache del bypass dell'autenticazione MAC (MAB) a 1440 minuti (24 ore) con una finestra di tolleranza per il lease di 15 minuti. 4. Risorse OAuth del Walled Garden: Verifica che tutti gli endpoint OAuth (Google, Apple, Microsoft) e i font/fogli di stile siano presenti nel walled garden in modo che la sessione completi interamente il caricamento prima di chiudere il WebSheet.
Commento dell'esaminatore: I cicli di reindirizzamento infinito derivano tipicamente da ritardi del RADIUS CoA nei casi in cui il controller non ha ancora aggiornato lo stato del client da pre-auth a post-auth nel momento in cui iOS invia il suo probe di verifica post-login.

Domande di esercitazione

Q1. Perché il tentativo di reindirizzare il traffico HTTPS (porta 443) causa errori del Captive Portal sui dispositivi iOS anziché aprire la pagina splash?

Suggerimento: Considera come la crittografia TLS, la verifica dei certificati e HSTS proteggono il traffico web.

Visualizza risposta modello

HTTPS stabilisce un tunnel TLS crittografato end-to-end tra il browser del client e il server web di destinazione. Quando un gateway wireless tenta di intercettare la porta 443 e fornire un reindirizzamento, il certificato SSL/TLS fornito dal gateway non corrisponde all'hostname richiesto (ad esempio google.com o apple.com). iOS applica HTTP Strict Transport Security (HSTS), costringendo Safari e WebKit a interrompere la connessione con un grave avviso di sicurezza anziché seguire il reindirizzamento.

Q2. In che modo una rete guest aziendale dovrebbe gestire iCloud Private Relay per garantire un reindirizzamento fluido del Captive Portal sui dispositivi iOS?

Suggerimento: Rivedi le linee guida ufficiali di Apple sulla rete relative alle risposte DNS per mask.icloud.com.

Visualizza risposta modello

Gli amministratori di rete devono configurare i propri server DNS ricorsivi locali per restituire una risposta NXDOMAIN (o un errore di risoluzione DNS) per i nomi di dominio mask.icloud.com e mask-h2.icloud.com. Quando iOS riceve una risposta NXDOMAIN per questi domini civetta, mostra un avviso di sistema che informa l'utente che la rete non supporta Private Relay e passa senza problemi alla gestione standard dei probe DNS e HTTP.

Q3. Qual è il vantaggio di distribuire l'API Captive Portal RFC 8908 rispetto alle tecniche tradizionali di dirottamento DNS e HTTP?

Suggerimento: Pensa alla chiarezza del protocollo, al segnale di Livello 3 e all'esperienza utente.

Visualizza risposta modello

L'RFC 8908 fornisce una JSON REST API standardizzata comunicata tramite DHCP Option 114 o IPv6 Router Advertisements. Invece di intercettare il traffico web dell'utente, il sistema operativo del client interroga direttamente l'API tramite HTTPS per sapere se la rete è captive, ottenere l'URL di login del portale, ispezionare la quota rimanente e ricevere una notifica personalizzata con il brand della sede. Ciò elimina gli avvisi relativi ai certificati SSL, supporta i gestori di password e preserva l'integrità della sicurezza del browser.

Domande frequenti

Why is my captive portal not popping up on iPhone?

Captive portals fail to pop up on iPhones when the Apple Captive Network Assistant (CNA) cannot complete its probe to http://captive.apple.com/hotspot-detect.html. Common causes include: 1) Pre-authentication firewalls blocking UDP port 53 DNS; 2) The network prematurely whitelisting captive.apple.com in the walled garden; 3) Gateways attempting HTTPS interception instead of HTTP 302 redirection; or 4) iCloud Private Relay interfering with DNS resolution.

How do I force the WiFi login screen to appear on iOS?

To manually trigger the captive portal on iPhone: 1) Open Safari and navigate to a plaintext HTTP URL such as http://captive.apple.com, http://neverssl.com, or http://1.1.1.1; 2) Go to Settings > Wi-Fi, tap the info (i) icon next to the network, and ensure Auto-Join and Auto-Login are toggled ON; 3) Turn Wi-Fi off and back on to trigger the CNA probe daemon.

What domains must be in the walled garden for Apple devices?

To support Apple iOS and macOS captive portal detection and assets, whitelist: captive.apple.com, www.airport.us, appleiphonecell.com, *.apple.com, *.purple.ai, *.purplewifi.net, and any third-party OAuth provider domains (e.g. accounts.google.com) or CDN assets used on the splash page.

How does RFC 8908 solve iOS captive portal issues?

RFC 8908 (Captive Portal API) and RFC 8910 (DHCP Option 114) pass the captive portal URL directly to iOS during the DHCP IP lease negotiation. This allows iOS 14+ to recognize network captivity instantly at Layer 3 without relying on fragile HTTP redirection or DNS hijacking.

How does MAC address randomisation affect captive portal authentication?

iOS Private Wi-Fi Addresses use unique MAC addresses per SSID. If the device rotates its MAC address or if session caching is tied strictly to physical MAC addresses without RADIUS accounting grace periods, the user may be forced to re-authenticate repeatedly. Configuring a 24-hour lease grace period and deploying Passpoint (Hotspot 2.0) resolves this issue.

Fonti

  1. Apple Developer Documentation - Captive Network Architecture and CNA
  2. Apple Support - Prepare Your Network for iCloud Private Relay
  3. IETF RFC 8908 - Captive Portal API Specification
  4. IETF RFC 8910 - Captive-Portal Identification in DHCP and Router Advertisements
  5. Wireless Broadband Alliance (WBA) - Captive Portal Standards and Best Practices
  6. Purple - Captive Portal Architecture & Troubleshooting Guide
  7. Purple - MAC Address Randomisation Impact Guide

Continua a leggere questa serie

Ubiquiti UniFi guest portal non reindirizza: cause e soluzioni

Questa guida isola un errore di reindirizzamento del portale ospiti UniFi analizzando in sequenza lo stato dell'ospite, il reindirizzamento, il percorso di pre-autorizzazione e l'autorizzazione del controller. Fornisce ai team IT locali un metodo collaudato per risolvere i dubbi tra rete ospiti e Hotspot, i passaggi ai portali esterni, i requisiti correnti degli account UniFi OS e i test di isolamento DNS.

Leggi la guida →

Cisco Meraki splash page non funzionante: un diagramma di flusso per la risoluzione dei problemi

Questa guida pratica per il secondo giorno isola i punti in cui un flusso splash Cisco Meraki ha fallito: autorizzazione del client, avvio del reindirizzamento HTTP, raggiungibilità del walled garden o sign-on RADIUS. Fornisce ai team IT delle sedi un percorso di verifica controllato, in modo da poter ripristinare il Guest WiFi senza apportare modifiche generiche a un'intera infrastruttura attiva.

Leggi la guida →

Guida alla configurazione del WiFi ospiti aziendale: segmentazione VLAN, sicurezza e Captive Portals

Questa guida tecnica mostra ai team IT come configurare il WiFi ospiti come servizio di accesso internet controllato, utilizzando la segmentazione VLAN, le policy del firewall e un Captive Portal. Spiega inoltre come i moduli di registrazione e i controlli di onboarding di Purple supportino un'esperienza per i visitatori proporzionata senza indebolire il perimetro che circonda il personale, i pagamenti e i sistemi operativi.

Leggi la guida →

Hai domande sulla tua configurazione specifica?

Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.