Risoluzione dell'errore "Connesso ma senza Internet" sulla rete WiFi per ospiti

L'errore di connessione senza Internet sul WiFi per ospiti si verifica quando i controlli di connettività falliscono prima del caricamento del portale captive. Nelle strutture ad affluenza elevata, le query DNS sulla porta UDP 53 (RFC 1035) vanno in timeout a causa della congestione. Per risolvere il problema, è necessario puntare gli ambiti DHCP degli ospiti a un filtro DNS con caching, completare i domini del walled garden su tutti i controller come Cisco Meraki e verificare le regole di traffic shaping.

Come si presenta l'errore "Connesso, senza Internet" sul WiFi per ospiti?

L'ospite vede le tacche del segnale al massimo e risulta connesso alla rete, ma non viene caricato nulla. La pagina di login non compare mai, impedendo l'accettazione dei termini o l'accesso. Di conseguenza, l'utente si rivolge alla reception, al punto assistenza o al banco servizi.

Ogni sistema operativo formula l'avviso in modo diverso. Il team di supporto della struttura deve saperli riconoscere tutti:

• Windows mostra "Nessuna connessione Internet" sotto il nome della rete.
• Android mostra "Connesso senza Internet" oppure "Internet potrebbe non essere disponibile".
• iPhone e iPad mostrano "Nessuna connessione Internet" sotto il nome della rete.

Tutti e tre i comportamenti derivano dallo stesso meccanismo. Dopo l'associazione alla rete, il dispositivo richiede un indirizzo web noto per testare la connessione. Se il test restituisce la pagina prevista, il dispositivo considera la connessione funzionante. Se restituisce una pagina di login, il dispositivo apre il portale captive. Se non riceve alcuna risposta, il dispositivo segnala l'assenza di Internet.

Prima che il dispositivo possa richiedere una di queste pagine, deve risolvere l'hostname tramite DNS. Questa ricerca è il punto in cui si verifica la maggior parte dei guasti nelle reti ad alta densità.

Quali sono le cause principali degli errori di connessione senza Internet sul WiFi per ospiti?

Timeout DNS su una rete mezza congestionata

Il DNS (Domain Name System) trasforma un hostname in un indirizzo IP. La maggior parte delle query DNS viaggia sulla porta UDP 53, come definito in RFC 1035. Il protocollo UDP non prevede la ritrasmissione integrata, quindi una query persa attende semplicemente il timer di reinvio del dispositivo.

La congestione si presenta a picchi. Si pensi all'intervallo in uno stadio, al check-out della colazione in hotel o all'arrivo di un treno in stazione. Centinaia di dispositivi si connettono in pochi secondi e ciascuno invia una richiesta contemporaneamente. Se il resolver si trova a diversi hop di distanza attraverso un collegamento WAN saturo, le query subiscono ritardi o vengono perse. Il dispositivo desiste, il portale non si apre mai e l'ospite vede l'avviso di assenza di Internet.

Altre cause comuni

Sebbene il DNS sia la causa più frequente nelle strutture affollate, non è l'unica. È opportuno verificare anche quanto segue:

• Voci del walled garden mancanti. Il walled garden è l'elenco dei domini che un dispositivo può raggiungere prima di effettuare il login. Se il portale o le sue risorse non sono inclusi, la pagina non può essere caricata.
• Esaurimento del pool DHCP. Se il pool di indirizzi si esaurisce, i dispositivi si autoassegnano un indirizzo 169.254.x.x e non riescono a raggiungere alcuna risorsa.
• Limiti di frequenza o QoS throttling sulla porta UDP 53. Un limite troppo restrittivo per client o per SSID può causare il blocco del DNS durante i picchi di traffico.
• DNS crittografato. DNS over HTTPS (DoH, RFC 8484) e DNS over TLS (DoT, RFC 7858) inviano le ricerche a resolver esterni. Un walled garden che blocca tali resolver arresta la ricerca prima del login.
• Un'interruzione a monte. Se il collegamento WAN stesso è offline, tutti i dispositivi e tutte le porte cablate risulteranno non funzionanti.

Come individuare la causa specifica?

Inizi analizzando il comportamento, non l'hardware. Utilizzi questa matrice per restringere le possibili cause prima di apportare qualsiasi modifica.

Tre verifiche che il team di supporto può eseguire

1. Verificare l'indirizzo IP del dispositivo. Un indirizzo 169.254.x.x indica un problema di DHCP, non di DNS. Un indirizzo standard nella subnet per gli ospiti conferma che il dispositivo si è connesso correttamente.
2. Misurare il tempo di risoluzione da un dispositivo di test. Eseguire nslookup captive.apple.com da un laptop sulla rete guest. Una risposta lenta o mancante durante un periodo di intenso traffico conferma una strozzatura a livello di DNS.
3. Catturare i pacchetti sulla VLAN guest. Una VLAN (LAN virtuale) separa il traffico degli ospiti dalle altre reti. Filtrare la cattura su udp port 53 e cercare le query che non ricevono una risposta corrispondente.

Successivamente, verificare quando si verificano gli errori. In WiFi Analytics, confrontare i volumi di connessione e di login con gli orari in cui gli ospiti segnalano i problemi. I malfunzionamenti che coincidono con le ore di punta indicano chiaramente una situazione di congestione.

In che modo un filtro DNS enterprise risolve la strozzatura?

Un filtro DNS enterprise è un resolver gestito direttamente dall'utente e posizionato vicino alla rete guest. Sostituisce il resolver pubblico o dell'ISP remoto assegnato attualmente dal DHCP ed esegue tre funzioni principali per eliminare i timeout.

Risponde tramite cache. Gli hostname relativi alle verifiche di connettività vengono richiesti migliaia di volte all'ora in una struttura affollata. Un filtro nelle vicinanze risponde alle ricerche ripetute direttamente dalla propria cache, evitando che attraversino il collegamento WAN congestionato.

Scarta tempestivamente il traffico non desiderato. Le query relative a categorie dannose o bloccate vengono rifiutate direttamente dal filtro. In questo modo si libera capacità WAN per le ricerche prioritarie.

Registra ogni query. Si ottiene uno storico di quali domini sono falliti, quando e con quale frequenza. Questo trasforma le supposizioni in prove concrete la prossima volta che un responsabile segnala un problema.

Dove posizionarlo

Per un'infrastruttura distribuita, come una catena del settore retail con centinaia di piccole sedi, un filtro basato su cloud con punti di presenza (edge location) nelle vicinanze è di norma la scelta più pratica. Per una singola sede di grandi dimensioni, come uno stadio o un centro congressi, un resolver ospitato in locale mantiene le ricerche del tutto all'esterno della rete WAN. In entrambi i casi, distribuire due indirizzi resolver tramite DHCP affinché un singolo guasto non comprometta la rete.

Due impostazioni che determinano il successo

In primo luogo, autorizzare i domini del portale captive nel filtro. Un filtro che blocca o ritarda il portale ricrea esattamente l'errore che si intendeva risolvere. In secondo luogo, mantenere il DNS ospiti separato dal DNS aziendale. Lo standard PCI DSS considera la segmentazione della rete come il metodo per escludere una rete ospiti dall'ambito dell'ambiente dei dati dei titolari di carta.

Come risolvere il problema su ciascun produttore e sistema operativo?

Sui punti di accesso e sul controller

Purple è indipendente dall'hardware e funziona come overlay cloud su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. La soluzione segue gli stessi tre passaggi su ciascuno di essi:

1. Aggiornare i server DNS nell'ambito DHCP ospiti impostando il filtro DNS aziendale.
2. Completare il walled garden. Cisco Meraki, HPE Aruba e Ruckus utilizzano tutti il termine "walled garden". Seguire l'articolo di configurazione di Purple relativo al proprio produttore, che elenca i domini esatti da autorizzare.
3. Verificare il traffic shaping degli ospiti in modo che i limiti per singolo client non rallentino la porta UDP 53 durante un picco di traffico.

Non copiare le impostazioni tra produttori diversi. I nomi dei menu e le impostazioni predefinite variano, pertanto si consiglia di consultare la documentazione specifica del produttore insieme all'articolo di configurazione di Purple.

Sul dispositivo dell'ospite

Quando il problema riguarda un singolo ospite mentre tutti gli altri navigano correttamente, l'help desk può provare i seguenti passaggi:

• Disconnettere la rete e riconnettersi per avviare un nuovo controllo di connettività.
• Aprire un semplice indirizzo http:// nel browser per forzare la visualizzazione del portale.
• Su Android, impostare il DNS privato su Automatico. Un provider di DNS privato fisso può bloccare la ricerca prima dell'accesso.
• Sospendere qualsiasi app VPN fino a quando l'ospite non ha effettuato l'accesso.

Scenari pratici

Le cifre riportate di seguito sono a titolo illustrativo e non derivano da un'infrastruttura specifica. Possono essere utilizzate come modello per ciò che occorre misurare presso la propria struttura.

Un hotel da 200 camere durante la colazione

Situazione. Le segnalazioni alla reception relative a "Internet non funzionante" si concentrano tra le 07:00 e le 09:00, quando gli ospiti controllano l'e-mail prima del check-out. I punti di accesso mostrano un segnale ottimale e tempo d'antenna libero. Il DHCP ospiti assegna il resolver dell'ISP, distante diversi hop attraverso una linea satura.

Intervento effettuato. Il responsabile IT ha eseguito nslookup durante l'orario di picco e ha riscontrato l'immediato fallimento delle ricerche. Il team ha quindi configurato il DHCP ospiti affinché puntasse a un filtro DNS cloud, ha aggiunto i domini del portale al walled garden e ha mantenuto il DNS ospiti separato dalla rete di gestione della struttura.

Risultato. In base alle misurazioni di WiFi Analytics e al registro della reception, i completamenti del portale durante i picchi sono saliti dall'81% al 97%. Le lamentele relative al WiFi alla reception sono scese da circa 15 a mattina a due. Per ulteriori informazioni sulle reti per ospiti per gli hotel, consulti le nostre pagine dedicate al settore dell'ospitalità.

Uno stadio con una capienza di 30.000 persone durante l'intervallo

Situazione. I tifosi segnalavano l'errore "connesso senza Internet" durante ogni intervallo, mentre i primi dieci minuti di ciascun tempo si svolgevano senza problemi. Le acquisizioni di pacchetti sulla rete VLAN per ospiti hanno mostrato query DNS senza risposta durante il picco di traffico.

Azione intrapresa. L'architetto di rete ha distribuito un resolver in loco con fallback nel cloud. Il team ha rimosso un limite di frequenza per client che limitava la porta UDP 53 e ha spostato l'ambito DHCP sul nuovo resolver.

Risultato. Nelle acquisizioni successive, le query DNS senza risposta durante l'intervallo sono scese dal 12% a meno dell'1%. Gli accessi dei tifosi durante l'intervallo sono aumentati del 40% rispetto alla partita precedente.

Come evitare che gli errori di connessione senza Internet si ripetano?

• Non fare mai affidamento solo su un resolver pubblico distante. Il DNS pubblico garantisce generalmente buone prestazioni, ma un resolver distante diversi hop aggiunge un ritardo non controllabile durante i picchi di traffico.
• Configuri avvisi per le query DNS senza risposta. Configuri il firewall o lo switch principale per segnalare l'aumento dei pacchetti scartati sulla porta UDP 53 nella rete per ospiti, che indicano time-out prima che gli ospiti se ne accorgano.
• Riveda ogni mese gli elenchi di blocco del filtro DNS. Le categorie troppo aggressive bloccano applicazioni legittime e generano nuove richieste di supporto.
• Imposti un periodo di conservazione dei registri. I log DNS collegano gli indirizzi IP ai domini visitati, pertanto devono essere trattati come dati personali ai sensi del GDPR.
• Adotti lo standard RFC 8910 se l'hardware lo supporta. Consente al DHCP di indicare al dispositivo dove si trova il portale captive, riducendo la dipendenza del dispositivo dal controllo di connettività.
• Valuti Passpoint per i visitatori che ritornano. Passpoint (chiamato anche Hotspot 2.0) e OpenRoaming consentono ai dispositivi di connettersi in modo sicuro senza passare da un portale captive, eliminando completamente questo tipo di errore.

Purple gestisce il WiFi per ospiti in oltre 80.000 strutture attive in più di 90 Paesi, con 500 milioni di utenti e accessi all'anno. Dalle sale d'attesa delle strutture sanitarie ai treni, la regola non cambia: risolva i problemi di DNS prima di acquistare ulteriore larghezza di banda.

Domande frequenti

Sono necessari nuovi access point per risolvere gli errori di connessione senza Internet?

No, nella maggior parte dei casi non è necessario. Quando l'errore si verifica nei momenti di picco, la causa è solitamente la risoluzione DNS e non l'hardware degli access point. La soluzione consiste in una modifica della configurazione: reindirizzi il DHCP degli ospiti verso un filtro DNS aziendale nelle vicinanze, completi il walled garden e riveda le regole di traffic shaping. Sostituisca l'hardware solo dopo che le acquisizioni di pacchetti mostrano che gli access point stessi scartano il traffico a carichi normali, e dopo aver escluso problemi legati a DHCP e DNS.

Purple è compatibile con l'hardware già in nostro possesso?

Sì, Purple funziona sugli access point già in uso. Purple è indipendente dall'hardware e si distribuisce come overlay cloud su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Non è necessario sostituire l'infrastruttura esistente. Purple pubblica un articolo sulla configurazione per ciascun fornitore, indicando i domini walled garden richiesti dal controller per caricare il portale captive prima dell'accesso degli ospiti.

Un filtro DNS enterprise rallenta la rete WiFi per ospiti?

No, un filtro DNS posizionato in modo corretto rende solitamente la ricerca più rapida. Trovandosi più vicino alla rete ospiti rispetto a un ISP o a un resolver pubblico, risponde alle ricerche ripetute attingendo dalla propria cache. Il rischio risiede nel posizionamento e nella configurazione, non nel filtraggio in sé. È consigliabile distribuire due indirizzi resolver per garantire la ridondanza e autorizzare i domini del portale captive in modo che il filtro non ritardi mai la pagina di login.

Perché non fornire agli ospiti semplicemente un resolver pubblico come 8.8.8.8?

È possibile farlo, ma ciò non risolve i timeout dovuti alla congestione. Un resolver pubblico si trova comunque dall'altra parte della connessione WAN, quindi ogni ricerca entra in competizione con i picchi di traffico che causano l'errore. Inoltre, non offre alcun filtraggio né log di query per la risoluzione dei problemi. Un filtro enterprise locale risponde dalla cache, rifiuta le categorie non desiderate e registra ogni ricerca non riuscita, operazioni che un DNS pubblico non può eseguire.

Come vengono gestiti i log delle query DNS in conformità con il GDPR?

I log DNS devono essere trattati come dati personali, in quanto collegano gli indirizzi IP ai domini visitati da un dispositivo. È necessario definire un periodo di conservazione specifico, limitare l'accesso al team di rete e sicurezza e indicare la finalità nell'informativa sulla privacy. Purple possiede la certificazione ISO 27001 ed è conforme al GDPR; anche il fornitore del filtro DNS dovrebbe mostrare certificazioni equivalenti prima di instradare il traffico degli ospiti.

Quanto sforzo richiede la distribuzione?

La modifica in sé è contenuta; la fase di test richiede la maggior parte dell'impegno. È necessario aggiornare i server DNS nello scope DHCP degli ospiti, aggiungere i domini del portale all'elenco dei consentiti del filtro e verificare il walled garden. Si consiglia di pianificare i test durante un picco reale, come l'ora di punta della colazione o l'intervallo di una partita, poiché un pomeriggio poco affollato non riprodurrà la congestione che ha causato l'errore.

Passpoint o OpenRoaming rimuoveranno l'errore?

Sì, per i dispositivi che li utilizzano. Passpoint e OpenRoaming consentono ai dispositivi di connettersi in modo sicuro senza un portale captive, eliminando così il rischio di errore del portale. I visitatori al primo accesso e i dispositivi privi di un profilo Passpoint utilizzano comunque il portale captive, pertanto sono ancora necessari un DNS rapido e un walled garden completo. È consigliabile utilizzarli entrambi: Passpoint per i visitatori abituali e un portale ottimizzato per tutti gli altri.