Gestione della larghezza di banda per il WiFi del personale: Shaping, QoS e riduzione del traffico

Gestione della larghezza di banda per il WiFi del personale: Shaping, QoS e riduzione del traffico. Un briefing tecnico di Purple. Benvenuti. Se state ascoltando questo briefing, probabilmente avete a che fare con una delle lamentele più comuni nell'IT aziendale: il personale che si lamenta del fatto che il WiFi è lento. Forse si tratta del team del back-of-house di un hotel che fatica a elaborare i check-in. Forse è una catena di negozi in cui i terminali POS vanno in timeout. O forse è un centro congressi in cui il team AV non riesce a ottenere una connessione stabile durante un evento dal vivo. Qualunque sia il contesto, la causa principale è quasi sempre la stessa: avete più traffico di quello che la vostra rete è progettata per gestire, e il traffico sbagliato sta ottenendo la priorità. In questo briefing tratteremo tre aspetti: come funzionano effettivamente il traffic shaping e il QoS in un ambiente WiFi per il personale, come si presenta un'implementazione pratica in diversi tipi di strutture e come l'implementazione di Purple Shield per l'ad-blocking può ridurre il carico complessivo della rete in modo significativo, senza toccare la velocità della linea o spendere per aggiornamenti infrastrutturali. Entriamo nel vivo. Sezione uno: Comprendere il problema. La maggior parte delle strutture aziendali gestisce una connessione internet condivisa. Il WiFi del personale, il WiFi per gli ospiti, i sistemi di back-office, la videosorveglianza, i sistemi di gestione dell'edificio: condividono tutti lo stesso canale a monte. Quando quel canale si intasa, tutto subisce un rallentamento. Ma non tutto il traffico è uguale. Una chiamata VoIP che si interrompe a metà frase è catastrofica. Un aggiornamento software che richiede due minuti in più è irrilevante. Il problema è che, senza una gestione attiva, la vostra rete non conosce la differenza. Il traffic shaping è il meccanismo che si utilizza per indicare alla rete quale traffico è prioritario. Il Quality of Service, o QoS, è il framework che definisce le regole. Insieme, consentono di garantire la larghezza di banda alle applicazioni critiche e di limitare tutto il resto. Lo standard IEEE 802.11e ha introdotto il QoS nelle reti wireless attraverso un meccanismo chiamato WMM - Wireless Multimedia. Il WMM definisce quattro categorie di accesso: voce, video, best effort e background. Ogni access point moderno di Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist e Ubiquiti UniFi supporta il WMM. La domanda è se lo state utilizzando correttamente. Sul lato cablato, il QoS viene implementato utilizzando i contrassegni DSCP - Differentiated Services Code Point - nell'intestazione IP. Il DSCP EF, che sta per Expedited Forwarding, viene utilizzato per il traffico vocale. Il DSCP AF41 viene utilizzato per le videoconferenze. Il DSCP CS1 è la classe di background: aggiornamenti software, trasferimenti di massa, qualsiasi cosa possa attendere. Quando mappate il traffico delle vostre applicazioni sui contrassegni DSCP corretti e configurate i vostri switch e access point per rispettarli, ottenete prestazioni prevedibili per le applicazioni che contano. Sezione due: Architettura e segmentazione. Prima di configurare la QoS, è necessario segmentare correttamente la rete. Il WiFi del personale deve risiedere su una propria VLAN - una Virtual Local Area Network - completamente isolata dal WiFi per gli ospiti e dai dispositivi IoT. Questo non è solo un requisito di sicurezza ai sensi di PCI DSS e GDPR; è un prerequisito per una QoS efficace, poiché consente di applicare policy diverse a VLAN diverse. Un'architettura tipica per una sede aziendale si presenta così. C'è uno switch centrale collegato al gateway internet. Da quello switch si diramano più VLAN: una per i dispositivi del personale, una per l'accesso degli ospiti, una per i sistemi POS e di pagamento, una per la gestione dell'edificio. Ogni VLAN ha la propria policy QoS. Alla VLAN del personale viene assegnata la massima larghezza di banda garantita. La VLAN degli ospiti riceve un limite di velocità per utente - in genere da due a cinque megabit al secondo in downstream - in modo che nessun singolo visitatore possa saturare la connessione. Sulla VLAN del personale stessa, si applica una QoS basata sulle applicazioni. Le transazioni POS e il traffico di autenticazione RADIUS ottengono il DSCP EF - la priorità massima. Il sistema ERP e gli strumenti di videoconferenza ottengono il DSCP AF41. La navigazione web generale ottiene il "best effort". Gli aggiornamenti software e i download delle patch del sistema operativo ottengono il DSCP CS1 - vengono eseguiti in background e non competono con il traffico operativo. Per l'autenticazione, i dispositivi del personale dovrebbero autenticarsi utilizzando lo standard 802.1X con EAP-TLS - basato su certificati - o PEAP con MSCHAPv2 sul server RADIUS. Se si utilizza Microsoft Entra ID, Okta o Google Workspace, Purple si integra direttamente con tutti e tre tramite SAML e SCIM, in modo che l'identity provider diventi l'unica fonte di verità per l'accesso alla rete. Quando un dipendente lascia l'azienda, si revoca il suo accesso in Entra ID e l'accesso alla rete scompare automaticamente. Sezione tre: Il consumo nascosto di larghezza di banda - e come Shield lo risolve. Ecco un aspetto a cui la maggior parte dei team IT non pensa. Una parte significativa del traffico sul WiFi del personale non ha nulla a che fare con la vostra attività. Ogni pagina web visitata da un dipendente carica decine di reti pubblicitarie di terze parti, pixel di tracciamento, script di analisi ed endpoint di telemetria. Le ricerche di Ghostery e di analoghi strumenti di analisi del blocco degli annunci mostrano costantemente che le richieste di annunci e tracker rappresentano tra il 25% e il 40% delle richieste HTTP totali in una tipica sessione di navigazione. Quel traffico consuma larghezza di banda reale. Consuma capacità di query DNS. Aggiunge latenza a ogni caricamento di pagina. E introduce rischi per la sicurezza: il malvertising, i download drive-by e l'esfiltrazione di dati tramite pixel di tracciamento sono tutti vettori di attacco reali. Purple Shield affronta questo problema a livello di rete. Invece di affidarsi a estensioni del browser che il personale potrebbe o meno aver installato, Shield opera come un filtro a livello DNS. Ogni query DNS proveniente dalla VLAN del personale passa attraverso la blocklist di Shield prima di essere risolta. I domini delle reti pubblicitarie, gli endpoint dei tracker noti e i domini dannosi vengono bloccati prima che venga scaricato un singolo byte di contenuto. Il dispositivo non stabilisce mai la connessione. La larghezza di banda non viene mai consumata. In concreto, le location che implementano Shield sulla propria rete WiFi per il personale registrano una riduzione del volume totale di query DNS di circa il 30%. Si tratta di banda precedentemente sprecata in annunci e tracker, ora disponibile per il vostro sistema ERP, le videochiamate e i terminali POS. Otterrete l'equivalente di un upgrade della larghezza di banda del 30% senza dover pagare per una linea più veloce. Shield riduce inoltre l'esposizione ai rischi di sicurezza. Bloccando i domini dannosi noti a livello di DNS, eliminate una categoria di minacce che spesso sfugge agli antivirus degli endpoint, in particolare per i dispositivi IoT e i terminali condivisi che non eseguono i software di sicurezza tradizionali. Sezione quattro: Implementazione nel mondo reale. Vi illustro due scenari. Primo: un hotel da 200 camere. Il team del back-of-house gestisce il software di gestione della proprietà, un sistema telefonico VoIP e una piattaforma di videosorveglianza sulla stessa rete. Il WiFi per gli ospiti si trova su una VLAN separata con un limite di cinque megabit per utente, ma la VLAN del personale non ha alcuna policy QoS. Durante i periodi di picco dei check-in, il sistema di gestione della proprietà rallenta drasticamente perché il personale trasmette musica in streaming e il sistema di sorveglianza sta caricando i filmati. La soluzione: applicare DSCP EF al traffico del sistema di gestione della proprietà e al sistema VoIP. Applicare DSCP AF41 al traffico di caricamento della sorveglianza (è importante, ma non sensibile alla latenza). Applicare DSCP CS1 a tutto il resto. Implementare Shield sulla VLAN del personale per eliminare il traffico di annunci e tracker. Risultato: i tempi di risposta del sistema di gestione della proprietà si riducono di oltre il 40% durante i periodi di picco. La qualità delle chiamate VoIP migliora sensibilmente sulla scala Mean Opinion Score utilizzata per valutare la qualità della voce. Secondo: una catena di vendita al dettaglio con 50 negozi. Ogni negozio dispone di una singola connessione a banda larga da 100 megabit condivisa tra WiFi del personale, WiFi degli ospiti e terminali POS. Durante i periodi di maggiore attività commerciale, la navigazione del personale sui dispositivi personali satura la connessione e le transazioni POS iniziano ad andare in timeout. La catena sta valutando la possibilità di passare a linee da 200 megabit con un costo di circa 18.000 sterline all'anno per l'intero patrimonio immobiliare. La soluzione: segmentare i terminali POS su una VLAN dedicata con larghezza di banda garantita. Applicare limiti di tariffa per utente sulla VLAN WiFi del personale: 10 megabit per utente in download, due megabit in upload. Implementare Shield per eliminare il traffico pubblicitario. Questa combinazione riduce l'utilizzo di picco del 35%, i timeout dei POS scendono a zero e l'upgrade della linea viene rimandato a tempo indeterminato. Il risparmio annuale sui soli costi di linea è di 18.000 sterline. La configurazione di Shield e QoS costa solo una frazione di questa cifra. Sezione cinque: Errori di implementazione. Alcuni aspetti a cui prestare attenzione. Rimarcatura DSCP. Molti ISP e alcuni switch aziendali rimuovono o rimarcano i valori DSCP al confine di rete. Verificate che le marcature QoS sopravvivano all'intero percorso dal dispositivo all'applicazione. Utilizzate un packet capture sul gateway per verificare. Dispositivi WMM e legacy. Alcuni dispositivi più vecchi, in particolare i terminali condivisi e i sensori IoT, non supportano correttamente il WMM. Potrebbero ignorare i contrassegni QoS o generare traffico con valori DSCP errati. Esegui un audit dell'inventario dei tuoi dispositivi prima di implementare le policy QoS. Limitazione della larghezza di banda e picchi di traffico. Un limite rigido di 10 megabit per utente sembra ragionevole, ma se 20 membri dello staff avviano contemporaneamente gli aggiornamenti software, raggiungerai il limite aggregato. Utilizza lo shaping con token bucket con una tolleranza per i picchi (burst) piuttosto che un controllo rigido (policer). Ciò consente brevi picchi limitando al contempo l'uso prolungato di un'elevata larghezza di banda. Shield e DNS-over-HTTPS. Se i dispositivi dello staff utilizzano il DNS-over-HTTPS per bypassare il tuo risolutore DNS, il filtraggio di Shield non verrà applicato. È necessario bloccare il DNS-over-HTTPS sul firewall o configurare i dispositivi tramite MDM per utilizzare il risolutore DNS interno. Si tratta di un passaggio di configurazione una tantum, non di un onere di gestione continuo. Sezione sei: Domande rapide. Ho bisogno del QoS se ho molta larghezza di banda? Sì. La larghezza di banda non equivale alle prestazioni. Una connessione a 1 gigabit senza QoS offrirà comunque una qualità VoIP scadente se un singolo dispositivo sta eseguendo un trasferimento di file di grandi dimensioni. Il QoS garantisce che il traffico sensibile alla latenza ottenga la priorità di coda di cui ha bisogno, indipendentemente dal throughput totale. Posso implementare Shield senza modificare l'hardware esistente? Sì. Shield funziona come un overlay DNS. È sufficiente puntare il server DHCP sui risolutori DNS di Purple e Shield si applica immediatamente. Funziona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet, senza richiedere alcuna modifica all'hardware. Come posso misurare l'impatto? Monitora tre metriche prima e dopo l'implementazione: la percentuale di utilizzo di picco sul tuo uplink, il volume di query DNS all'ora e i tempi di risposta delle applicazioni per i tuoi sistemi critici. La dashboard di Purple mostra tutti e tre i dati in tempo reale. Sezione sette: Riepilogo e prossimi passi. Per riassumere. Gestire la larghezza di banda per il WiFi dello staff non significa acquistare più banda. Significa assicurarsi che la banda a disposizione vada nei posti giusti. Il traffic shaping e il QoS ti offrono il controllo. Purple Shield ti offre la riduzione. Insieme, offrono miglioramenti misurabili nelle prestazioni delle applicazioni senza spese per l'infrastruttura. I tuoi prossimi passi: esegui un audit della tua attuale struttura VLAN e conferma che il WiFi dello staff sia isolato dal traffico guest e IoT. Mappa le tue applicazioni critiche sulle classi DSCP. Distribuisci Shield sulla VLAN dello staff e misura la riduzione delle query DNS. Rivedi i limiti di larghezza di banda per utente trimestralmente al variare del numero di dispositivi. Se desideri approfondire uno di questi argomenti, la guida scritta completa è disponibile su purple.ai. Copre in dettaglio l'architettura tecnica, include esempi di configurazione per le principali piattaforme hardware e illustra il calcolo del ROI per l'implementazione di Shield. Grazie per l'ascolto. Questo è stato un briefing tecnico Purple.