Risolvere l'Errore Connesso ma Senza Internet sulla WiFi Ospiti

Risolvere l'errore "Connesso ma senza internet" sul WiFi per gli ospiti — Un briefing tecnico Purple [INTRODUZIONE E CONTESTO — circa 1 minuto] Benvenuti alla serie di briefing tecnici Purple. Sono il vostro presentatore e oggi affronteremo uno dei problemi più persistenti e frustranti nelle reti aziendali: l'errore "connesso, senza internet" sul WiFi per gli ospiti. Se gestite l'infrastruttura WiFi in un hotel, in una catena di negozi, in uno stadio o in un centro congressi, vi sarà sicuramente capitato. Il dispositivo di un ospite mostra il segnale al massimo, è associato al vostro access point, gli è stato assegnato un indirizzo IP - eppure il browser non carica nulla. Il Captive Portal non si apre mai. L'ospite chiama la reception. Il 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 installazioni aziendali, non si tratta di un guasto hardware, di una configurazione errata del firewall o di un problema di larghezza di banda nel senso tradizionale. Si tratta di un problema di tempistica DNS - ed è quasi sempre innescato 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 permanentemente questo collo di bottiglia. [APPROFONDIMENTO TECNICO — circa 5 minuti] Partiamo dalle basi. Quando il dispositivo di un ospite si connette alla vostra rete WiFi, la primissima cosa che deve fare - prima ancora 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 il 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 login 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 DNS.Ecco 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 si arrende. Su una rete WiFi per ospiti con centinaia o migliaia di dispositivi simultanei - si pensi a uno stadio durante una partita, un hotel al completo, un centro congressi durante un discorso di apertura - il collegamento a monte e il risolutore DNS possono saturarsi molto rapidamente. Il problema è aggravato dal fatto che le reti ospiti condividono in genere 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 simultaneamente il rilevamento del Captive Portal, esegue aggiornamenti delle app in background e invia query DNS per social media e servizi di streaming, quel singolo risolutore diventa un collo di bottiglia. I tempi di risposta delle query salgono dal normale intervallo inferiore a 50 millisecondi a centinaia o addirittura migliaia di millisecondi. Iniziano a verificarsi i timeout. Gli errori di "connesso, internet non disponibile" iniziano a tempestare la rete. 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 in ambienti 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 sforzo. Ora, la risposta tradizionale a questo problema consiste nell'aumentare la larghezza di banda - aggiornare il collegamento a monte, aggiungere più access point, implementare policy di 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 drastica riduzione della latenza delle query DNS - 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 vanno a buon fine al primo colpo, l'errore "connesso, internet non disponibile" 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 implementazioni ad alta densità e supporta la conformità ai requisiti di gestione dei dati GDPR consentendo di registrare e controllare le query DNS - il che è rilevante se si opera con una licenza per il settore pubblico o per l'ospitalità. Supporta inoltre i requisiti di segmentazione della rete PCI-DSS garantendo che il traffico DNS degli ospiti sia isolato dall'infrastruttura di risoluzione aziendale. [RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE DA EVITARE - circa 2 minuti] Ecco alcune linee guida pratiche per l'implementazione. Quando si distribuisce un filtro DNS aziendale su una rete WiFi per ospiti, ci sono tre decisioni di configurazione che determineranno il successo o il fallimento dell'operazione. In primo luogo, il posizionamento del risolutore. Il filtro DNS deve essere distribuito il più vicino possibile alla rete ospiti - idealmente sulla stessa VLAN o sottorete degli access point ospiti. Ogni hop tra il dispositivo ospite e il risolutore 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 - 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 ripresenterà esattamente lo stesso problema che si stava cercando di risolvere. Testate sempre esplicitamente la risoluzione del Captive Portal dopo aver implementato qualsiasi criterio di filtraggio DNS. In terzo luogo, la sintonizzazione del TTL. Configurate il risolutore DNS locale per servire TTL brevi per i domini di probing per il rilevamento del Captive Portal - Apple, Google, Microsoft - in modo che i dispositivi effettuino query frequenti e ottengano sempre una risposta locale rapida, piuttosto che attendere la scadenza di una voce memorizzata nella cache per poi colpire un risolutore upstream congestionato. Un TTL da 30 a 60 secondi per questi domini specifici è un buon punto di partenza. La trappola da evitare è il filtraggio eccessivo. Alcuni team implementano blacklist DNS aggressive che bloccano inavvertitamente domini utilizzati da applicazioni ospiti legittime - servizi di streaming, endpoint VPN aziendali, cloud storage. Questo genera una categoria diversa di ticket di supporto, ma è altrettanto dannoso per l'esperienza degli ospiti. Iniziate con un criterio conservativo, monitorate i log delle query DNS per i domini bloccati e perfezionate la configurazione nell'arco di due settimane prima di bloccarla definitivamente. [DANDE E RISPOSTE RAPIDE - circa 1 minuto] Esaminiamo le domande che mi vengono poste più spesso su questo argomento. "Posso usare semplicemente 8.8.8.8 come risolutore DNS per gli ospiti?" È possibile, ma sotto carico andrà in timeout. Un risolutore locale o regionale supererà sempre un risolutore pubblico su una rete congestionata. "Questo influisce sulle distribuzioni WPA3?" No - 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 ospiti durante il picco 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 WiFi ospiti è 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 un filtraggio basato su criteri per ridurre il carico delle query a monte. Le tre cose da fare questa settimana: eseguire un packet capture DNS durante il picco 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 ospiti. 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 WiFi ospiti su purple.ai meritano di essere esaminate insieme a questo briefing. Grazie per l'ascolto - ci vediamo alla prossima. [FINE DELL'EPISODIO]