Risolvere l'errore "Connesso ma senza Internet" sulle reti WiFi ospiti

Risolvere l'errore "Connesso ma senza Internet" sul WiFi ospiti — Un briefing tecnico di Purple [INTRODUZIONE E CONTESTO — circa 1 minuto] Benvenuti alla serie di briefing tecnici di Purple. Sono il vostro ospite e oggi affronteremo uno dei problemi più persistenti e frustranti nel networking delle sedi aziendali: l'errore "connesso, senza internet" sul WiFi ospiti. Se gestite l'infrastruttura WiFi in un hotel, una catena di negozi, uno stadio o un centro congressi, avrete sicuramente riscontrato questo problema. Il dispositivo di un ospite mostra tutte le barre del segnale, è associato al vostro access point, gli è stato assegnato un indirizzo IP — eppure il browser non carica nulla. Il Captive Portal non si avvia mai. L'ospite chiama la reception. Il vostro team di supporto esegue un test di ping, sulla carta tutto sembra a posto, eppure il problema continua a ripresentarsi. Il punto è questo: nella stragrande maggioranza dei casi che riscontro nelle implementazioni aziendali, non si tratta di un guasto hardware, né di una configurazione errata del firewall, né di un problema di larghezza di banda in senso tradizionale. Si tratta di un problema di tempistica del DNS — ed è quasi sempre scatenato dalla congestione della rete. Oggi voglio spiegarvi esattamente perché succede, come diagnosticarlo in modo affidabile e come l'implementazione di un filtro DNS aziendale risolva definitivamente questo collo di bottiglia. [APPROFONDIMENTO TECNICO — circa 5 minuti] Iniziamo con i concetti fondamentali. Quando il dispositivo di un ospite si connette alla vostra rete WiFi, la primissima cosa che deve fare — prima di poter caricare una singola pagina web, prima che il vostro Captive Portal possa reindirizzarlo, prima che possa avvenire qualsiasi autenticazione — è risolvere un nome di dominio in un indirizzo IP tramite DNS. Il Domain Name System è la rubrica telefonica di Internet. Senza di esso, il dispositivo non ha modo di sapere dove inviare il traffico. Ora, ecco dove inizia il problema. La maggior parte dei dispositivi consumer — iPhone, telefoni Android, laptop Windows — dispone di un meccanismo integrato chiamato sonda di rilevamento del Captive Portal. Su iOS, ad esempio, il dispositivo invia una richiesta HTTP a un endpoint Apple noto, come captive.apple.com. Su Android, interroga connectivitycheck.gstatic.com. Su Windows, sonda msftconnecttest.com. Queste sonde sono progettate per rilevare se la rete richiede una pagina di accesso prima di concedere l'accesso a Internet. Il punto cruciale è questo: queste sonde dipendono dal DNS. Il dispositivo deve prima risolvere il nome di dominio dell'endpoint della sonda prima di poter inviare la richiesta HTTP. E quella query DNS ha un timeout — in genere compreso tra uno e cinque secondi a seconda del sistema operativo. Se il risolutore DNS sulla vostra rete non risponde entro quella finestra temporale, il dispositivo conclude che la rete non ha connettività Internet, anche se è completamente associato e ha un indirizzo IP valido. Questo è l'errore "connesso, senza internet". Non si tratta di un errore di connettività — si tratta di un errore di risposta del DNS. Quindi, perché il DNS fallisce su una rete congestionata? Questa è la parte che coglie di sorpresa molti team. Le query DNS vengono inviate tramite UDP per impostazione predefinita, sulla porta 53. UDP è un protocollo senza connessione: non c'è handshake, né conferma, né ritrasmissione a livello di trasporto. Se un pacchetto DNS viene perso a causa della congestione della rete, il client attende semplicemente la scadenza del timeout e poi riprova o rinuncia. Su una rete WiFi per ospiti con centinaia o migliaia di dispositivi simultanei (si pensi a uno stadio durante una partita, a un hotel al completo, a un centro congressi durante un keynote) il collegamento a monte e il risolutore DNS possono saturarsi molto rapidamente. Il problema è aggravato dal fatto che le reti ospiti in genere condividono un unico risolutore DNS a monte, spesso quello predefinito dell'ISP o un risolutore pubblico come 8.8.8.8. Quando ogni dispositivo sulla rete tenta contemporaneamente il rilevamento del Captive Portal, esegue aggiornamenti di app in background ed effettua query DNS per social media e servizi di streaming, quel singolo risolutore diventa un collo di bottiglia. I tempi di risposta delle query salgono dalla normale gamma inferiore a 50 millisecondi a centinaia o addirittura migliaia di millisecondi. Iniziano a verificarsi i timeout. Gli errori "connesso, senza internet" iniziano a fioccare. C'è anche un secondo meccanismo che vale la pena comprendere: l'esaurimento del TTL. Le risposte DNS includono un valore Time To Live che indica al dispositivo ricevente per quanto tempo memorizzare nella cache l'indirizzo IP risolto. Su una rete congestionata in cui i dispositivi si associano e si disassociano costantemente (cosa comune nei luoghi ad alta densità), le voci memorizzate nella cache scadono e devono essere risolte frequentemente. Ciò aumenta il carico di query DNS sul risolutore proprio quando la rete è sottoposta al massimo stress. Ora, la risposta tradizionale a questo problema è aumentare la larghezza di banda: aggiornare il collegamento a monte, aggiungere più access point, implementare policy QoS. Queste sono tutte misure valide, ma non affrontano la causa principale. La causa principale è che il percorso di risoluzione DNS non è ottimizzato per ambienti ospiti ad alta densità. Ed è esattamente questo che risolve un filtro DNS aziendale. Un filtro DNS aziendale, come la funzionalità di filtraggio DNS all'interno della piattaforma WiFi per ospiti di Purple, opera come un risolutore DNS locale ad alte prestazioni posizionato tra i dispositivi degli ospiti e la rete internet a monte. Invece di inoltrare ogni query a un risolutore pubblico remoto, mantiene una cache locale dei domini risolti di frequente, gestisce i tentativi di rilevamento del Captive Portal in modo nativo e applica un filtraggio basato su policy per bloccare i domini dannosi o non conformi prima ancora che raggiungano il risolutore a monte. Il risultato è una latenza delle query DNS drasticamente ridotta (in genere da timeout di due o tre secondi a risposte inferiori a 200 millisecondi), il che significa che i tentativi di rilevamento del Captive Portal hanno successo al primo colpo, l'errore "connesso, senza internet" scompare e il tempo di onboarding degli ospiti si riduce notevolmente. Dal punto di vista degli standard, questa architettura si allinea alle raccomandazioni IEEE 802.11 per le distribuzioni ad alta densità e supporta la conformità ai requisiti di gestione dei dati GDPR consentendo di registrare e verificare le query DNS — il che è rilevante se si opera con una licenza per il settore pubblico o per l'hospitality. Supporta inoltre i requisiti di segmentazione della rete PCI DSS garantendo che il traffico DNS degli ospiti sia isolato dall'infrastruttura del resolver aziendale. [RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE DA EVITARE — circa 2 minuti] Permettetemi di fornirvi una guida pratica alla distribuzione. Quando si implementa un filtro DNS aziendale su una rete WiFi per ospiti, ci sono tre decisioni di configurazione che determineranno il successo o il fallimento. In primo luogo, il posizionamento del resolver. Il filtro DNS deve essere distribuito il più vicino possibile alla rete ospiti — idealmente sulla stessa VLAN o subnet degli access point ospiti. Ogni hop tra il dispositivo ospite e il resolver aggiunge latenza. Se il filtro DNS si trova in un data center remoto e la rete ospiti è in un hotel a Manchester, si aggiunge un tempo di andata e ritorno che vanifica lo scopo. Utilizzate un'appliance locale o un filtro DNS fornito via cloud con un punto di presenza regionale. In secondo luogo, il passthrough DNS del Captive Portal. Questa è la configurazione errata più comune che riscontro. Quando si distribuisce un filtro DNS, è necessario assicurarsi che il dominio del Captive Portal stesso — l'URL a cui gli ospiti vengono reindirizzati per l'autenticazione — sia inserito nella whitelist del filtro. Se il filtro blocca o ritarda la risoluzione del dominio del Captive Portal, si ricreerà esattamente il problema che si stava cercando di risolvere. Testate sempre esplicitamente la risoluzione del Captive Portal dopo aver distribuito qualsiasi criterio di filtraggio DNS. In terzo luogo, la sintonizzazione del TTL. Configurate il resolver DNS locale per servire TTL brevi per i domini di rilevamento del Captive Portal — Apple, Google, Microsoft — in modo che i dispositivi effettuino query frequenti e ottengano sempre una risposta locale rapida, anziché attendere la scadenza di una voce memorizzata nella cache per poi colpire un resolver a monte congestionato. Un TTL da 30 a 60 secondi per questi domini specifici è un punto di partenza ragionevole. La trappola da evitare è il filtraggio eccessivo. Alcuni team distribuiscono blocklist DNS aggressive che bloccano inavvertitamente domini utilizzati da applicazioni ospiti legittime — servizi di streaming, endpoint VPN aziendali, cloud storage. Questo genera una classe diversa di ticket di supporto, ma è altrettanto dannoso per l'esperienza degli ospiti. Iniziate con una policy conservativa, monitorate i log delle query DNS per i domini bloccati e perfezionatela nell'arco di due settimane prima di bloccare definitivamente la configurazione. [D&R RAPIDE — circa 1 minuto] Passiamo in rassegna le domande che mi vengono poste più spesso su questo argomento. "Posso usare semplicemente 8.8.8.8 come resolver DNS per gli ospiti?" Potete farlo, ma sotto carico andrà in timeout. Un resolver locale o regionale supererà sempre un resolver pubblico su una rete congestionata. "Questo influisce sulle distribuzioni WPA3?" No — il WPA3 migliora la sicurezza dell'autenticazione ma non modifica il percorso di risoluzione DNS. Lo stesso problema di timeout DNS si verifica indipendentemente dallo standard di crittografia in uso. "Come faccio a sapere se il DNS è la causa effettiva dei miei errori 'connesso, senza internet'?" Esegui un packet capture sulla VLAN guest durante i picchi di carico. Filtra per il traffico sulla porta UDP 53. Se vedi query DNS senza una risposta corrispondente entro due secondi, il timeout DNS è il colpevole. "Un filtro DNS aziendale aiuta con la conformità?" Sì — la registrazione delle query DNS fornisce una traccia di controllo che supporta gli obblighi di rendicontazione del GDPR e può assistere nella risposta agli incidenti. La piattaforma di Purple include questa registrazione in modo nativo. [RIASSUNTO E PROSSIMI PASSI — circa 1 minuto] Per riassumere: l'errore "connesso, senza internet" sul Wi-Fi guest è nella stragrande maggioranza dei casi un problema di tempistica DNS causato dalla congestione della rete che sovraccarica un percorso di risoluzione non ottimizzato. La soluzione non è una maggiore larghezza di banda — è un filtro DNS aziendale locale ad alte prestazioni che risolve rapidamente i probe di rilevamento del Captive Portal, mantiene una cache locale e applica filtri basati su policy per ridurre il carico delle query a monte. Le tre cose da fare questa settimana: eseguire un packet capture DNS durante i picchi di carico per confermare la diagnosi; verificare il posizionamento attuale del resolver DNS e identificare se è locale o remoto; e valutare l'implementazione di un filtro DNS aziendale sulla VLAN guest. Se desideri approfondire uno di questi aspetti, la documentazione della piattaforma Purple copre in dettaglio la configurazione del filtro DNS, e le guide all'ottimizzazione del Wi-Fi guest su purple.ai meritano di essere esaminate insieme a questo briefing. Grazie per l'ascolto — ci vediamo alla prossima puntata. [FINE DELL'EPISODIO]