Configurare l'Application Traffic Shaping su Sophos Firewall

Con l’Application Traffic Shaping, Sophos Firewall assegna priorità o limiti a singole applicazioni come Microsoft Teams, VoIP, OneDrive o servizi di backup. Il flusso completo basato sulle applicazioni è il seguente:

1. In System services > Traffic shaping, creare una policy con Policy association > Applications.
2. In Applications > Application filter, configurare il riconoscimento dell’applicazione desiderata.
3. In Applications > Traffic shaping default, assegnare la policy all’applicazione o alla categoria.
4. In Rules and policies > Firewall rules, selezionare l’Application Filter e attivare Apply application-based traffic shaping policy.

Una policy con Policy association > Rules selezionata nel campo Shape traffic è una variante diversa: modella tutto il traffico corrispondente alla regola firewall, non soltanto l’applicazione selezionata nell’Application Filter.

⚠️ Il Traffic Shaping non crea larghezza di banda aggiuntiva. Distribuisce in modo più controllato una risorsa limitata. Se la linea è costantemente satura, occorre comunque verificare capacità, backup, sincronizzazioni cloud e altre possibili cause.

Il Traffic Shaping limita una velocità di trasmissione, non la quantità totale di dati trasferiti. Per crediti di tempo o dati consumabili si utilizzano invece Surfing Quota e Network Traffic Quota.

Pianificare prerequisiti e larghezza di banda

Prima della configurazione, occorre chiarire quanto segue:

• L’Application Control è necessario per lo shaping basato sulle applicazioni. Fa parte di Web Protection ed è incluso anche nel bundle Standard Protection. Lo stato è visibile in System > Administration > Licensing. Una policy basata unicamente su Rules non richiede invece il riconoscimento delle applicazioni.
• L’applicazione interessata viene riconosciuta dal firewall e il suo traffico passa attraverso una regola firewall nota.
• Il logging è attivo per questa regola.
• È noto se la risorsa limitata è l’upload, il download o entrambe le direzioni, nonché quale gateway WAN o percorso SD-WAN viene utilizzato.
• L’effetto desiderato è definito: Guarantee riserva una larghezza di banda minima e consente traffico fino al limite; Limit imposta soltanto un valore massimo.

Sophos mostra i valori di shaping in KBps, mentre gli speed test utilizzano normalmente kbps o Mbit/s. 1 KBps corrisponde a 8 kbps. Di conseguenza, 100 Mbit/s equivalgono a circa 12'500 KBps e 20 Mbit/s a circa 2'500 KBps.

I valori determinanti sono quelli misurati in modo stabile, non quelli dichiarati dal provider. Se una connessione nominale da 100/20 Mbit/s fornisce in modo affidabile soltanto 80/15 Mbit/s, la pianificazione dovrebbe basarsi su circa 10'000/1'875 KBps. Valori troppo elevati superano il collo di bottiglia reale e non consentono quindi di controllarlo correttamente.

Per le connessioni asimmetriche, è opportuno attivare Limit upload/download separately. Teams, VoIP, VPN e backup cloud risentono spesso per primi della saturazione dell’upload. I valori globali in System services > Traffic shaping settings si applicano solo al traffico in uscita che il firewall inoltra verso la zona WAN. Le singole policy Traffic Shaping possono invece essere applicate al traffico inoltrato sia in ingresso sia in uscita. Inoltre, il QoS non si applica al traffico generato dal sistema firewall, come gli aggiornamenti dei pattern o la sincronizzazione delle licenze.

Distinguere i valori globali dalle singole policy

In System services > Traffic shaping settings, Total available WAN bandwidth definisce la capacità QoS complessiva di tutti i collegamenti WAN. Va inserita la somma della larghezza di banda stabilmente disponibile, in KBps, e non soltanto la velocità contrattuale di un singolo collegamento. Show bandwidth usage mostra come questa capacità è distribuita tra le priorità. Questi valori globali si applicano solo al traffico WAN in uscita inoltrato che non corrisponde a una policy Traffic Shaping specifica.

Con Optimize for real-time (VoIP), SFOS assegna sempre la precedenza al traffico in tempo reale. Se l’opzione è disattivata, le policy che garantiscono banda ricevono prima la larghezza di banda loro assegnata e il traffico in tempo reale utilizza quella restante. Enforce guaranteed bandwidth attiva, per il traffico privo di una propria policy, i valori Guarantee, Limit e Priority da 1 a 7 della policy predefinita. Se Enforce guaranteed bandwidth è disattivato, questo traffico non riceve una larghezza di banda minima garantita, ma soltanto la capacità ancora disponibile. Per Priority, 1 indica la priorità più alta e 7 quella più bassa.

Queste opzioni non vanno attivate come soluzione generica ai problemi di prestazioni. Prima si documentano la larghezza di banda reale, le garanzie esistenti e la priorità desiderata. Altrimenti, garanzie sovradimensionate competono per una capacità che fisicamente non esiste.

Configurare l’Application Traffic Shaping

L’esempio seguente assegna priorità al traffico di un massimo di quattro endpoint video Teams attivi contemporaneamente in una piccola sede con una connessione stabile di circa 80/15 Mbit/s. Nei requisiti di larghezza di banda per Teams, Microsoft indica per ogni endpoint di una videoriunione circa 2'500 kbps in upload e 4'000 kbps in download come valori consigliati. I valori di esempio riservano questo fabbisogno complessivo, ma devono essere confrontati con le proprie misurazioni e con il numero effettivo di endpoint attivi contemporaneamente.

Creare la policy di Traffic Shaping

In System services > Traffic shaping, creare una nuova policy, ad esempio con i valori seguenti:

• Name: Teams Guarantee
• Policy association: Applications
• Rule type: Guarantee
• Limit upload/download separately: Enable
• Priority: 1 (priorità massima)
• Upload Guarantee / Limit: 1'250 / 1'500 KBps
• Download Guarantee / Limit: 2'000 / 5'000 KBps
• Bandwidth usage type: Shared

1'250 KBps corrispondono a 10 Mbit/s e 2'000 KBps a 16 Mbit/s. Con Shared, tutte le applicazioni o categorie a cui è assegnata la policy condividono lo stesso pool. Individual, invece, assegna il valore solo all’oggetto a cui la policy viene associata per primo; una policy Individual non va quindi pianificata come modello riutilizzabile per più oggetti. Non si dovrebbero distribuire valori di garanzia elevati su molte policy, perché la loro somma deve rientrare nella larghezza di banda effettivamente disponibile. In questo esempio, le garanzie corrispondono al fabbisogno complessivo consigliato di quattro endpoint video Teams. Quando è disponibile altra larghezza di banda, gli endpoint possono utilizzarla fino ai limiti superiori. I limiti di 12/40 Mbit/s lasciano volutamente capacità per altro traffico sulla connessione misurata di 80/15 Mbit/s. Sono valori iniziali, non requisiti Teams validi per ogni ambiente.

Nel flusso dell’interfaccia utente qui descritto, le policy di Traffic Shaping non possono essere modificate dopo la creazione. Questa limitazione dell’interfaccia utente non significa che l’XML API non documenti un’operazione di aggiornamento. Se in seguito servono valori diversi, documentare prima tutte le assegnazioni, creare una policy sostitutiva con un nuovo nome e applicarla inizialmente a un ambito limitato. Dopo la verifica, procedere con le altre assegnazioni; rimuovere la vecchia policy soltanto quando non vi sono più riferimenti ad essa. Per il rollback, assegnare nuovamente la vecchia policy oppure None.

Policy QoS: distinguere il flusso dell’interfaccia utente dal contratto dell’XML API

I riferimenti dell’XML API per SFOS 22.0 e 23.0 documentano esplicitamente Add QoS policy / Update QoS policy per QoSPolicy e descrivono Add/Edit. È quindi documentata un’operazione API, ma non è ancora confermato un contratto di aggiornamento eseguibile per il build installato. Le indicazioni seguenti sugli oggetti non costituiscono un modello di richiesta completo. La procedura sicura di sostituzione nell’interfaccia utente rimane la guida per la regolazione successiva. Accesso, operazione esplicita e verifica delle risposte sono spiegati in Utilizzare l’XML API in sicurezza e valutare le risposte.

Nell’esempio, i campi della larghezza di banda dipendono da PolicyType e ImplementationOn; non sono tutti richiesti contemporaneamente per ogni policy:

• Strict con Total: TotalBandwidth.
• Committed con Total: GuaranteedBandwidth e BurstableBandwidth.
• Strict con Individual: UploadBandwidth e DownloadBandwidth.
• Committed con Individual: GuaranteedUploadBandwidth, BurstableUploadBandwidth, GuaranteedDownloadBandwidth e BurstableDownloadBandwidth.

Nell’esempio, ciascuna larghezza di banda Burstable deve essere maggiore della garanzia corrispondente. I rami Individual citano nei propri commenti soltanto User, Firewall e Application; WebCategory compare per Total, non per Individual. Ciò non conferma una combinazione Individual-WebCategory, né dimostra un divieto a runtime. Inoltre, ImplementationOn con Total/Individual non è lo stesso campo di BandwidthUsageType con Individual/Shared; token con lo stesso nome non sono impostazioni intercambiabili.

L’esempio e la tabella dei parametri non coincidono in tutti i punti: l’esempio indica 2–2560000 KB, la tabella 2–10240000. Da ciò non deriva un limite massimo universale per il build. Per BandwidthUsageType, l’esempio mostra Individual/Shared, mentre la tabella riporta Shared Bandwidth Usage Type con on/off. Nell’esempio, PolicyBasedOn utilizza token denominati, mentre nella tabella Policy Based On è descritto come intero con valore predefinito 0. Da queste indicazioni non si deducono né la conversione dei token né un valore predefinito sicuro in caso di omissione.

Anche i dettagli della pianificazione presentano due rappresentazioni non raccordate in modo univoco: l’esempio mostra SchedulebasedPolicyRuleList con Rule, DetailId, PolicyType, i campi condizionali della larghezza di banda e Schedule; inoltre, DetailId compare nell’oggetto policy. La tabella indica Implementation On come array con 6/7, Policy Type come array con 8/11, gli elenchi di larghezza di banda bandwidthlist, grntdbandwidthlist, burstbandwidthlist, upbandwidthlist, downbandwidthlist, grntdupbandwidthlist, grntddownbandwidthlist, nonché qosdetailnamelist e ScheduleDetail. Non è definita una corrispondenza tra i valori enumerati numerici e i token denominati; ordine, identità dei dettagli e comportamento in caso di aggiornamento o omissione devono essere chiariti per la build di destinazione.

Prima di una modifica tramite API, API help del build installato deve chiarire questi limiti, nomi di campo e strutture di pianificazione ancora irrisolti. Finché il contratto non è chiaro, non comporre una richiesta di scrittura a partire dall’esempio. Salvare lo stato precedente, le assegnazioni e i dettagli della pianificazione; dopo una modifica approvata, rileggere separatamente l’oggetto e i dettagli e verificare l’effetto dello shaping nella finestra temporale interessata. Il riferimento elenca gli stati XML 200, 500 e 502 sia per Add sia per Update. Il riferimento usa i simboli non risolti Message.QOSAddSuccess, Message.QOSAddFail, Message.QOSEditSuccess, Message.QOSEditFail e Message.QOSRecordExist; i testi dei messaggi non sono specificati. I simboli sono identificatori non risolti dei messaggi, non codici HTTP. Uno stato da solo non conferma né tutti i dettagli né l’effetto. In caso di discrepanze, salvare la risposta e lo stato effettivo e non ripetere alla cieca l’operazione; riportare allo stato salvato soltanto la propria modifica.

Creare l’Application Filter

In Applications > Application filter, creare un filtro che includa soltanto il traffico desiderato:

1. Assegnare un nome come Microsoft Teams.
2. Aggiungere una regola Application.
3. Cercare microsoft teams in Smart Filter.
4. Selezionare le applicazioni Teams pertinenti e utilizzare l’azione Allow.
5. Salvare la regola Application con Save, quindi salvare anche Application Filter con Save.

Microsoft 365 non dovrebbe essere gestito indistintamente come un’unica applicazione. Teams, Exchange, SharePoint e OneDrive generano traffico diverso e dovrebbero essere osservati separatamente in una prima fase. Se l’obiettivo è il riconoscimento e il blocco invece della larghezza di banda, consultare Configurare e verificare Sophos Firewall Application Control.

Assegnare la policy all’applicazione

In Applications > Traffic shaping default, cercare Microsoft Teams o la categoria applicativa appropriata. Una categoria si apre direttamente con Edit. Per una singola applicazione, espandere prima la categoria con Expand, quindi selezionare Edit per l’applicazione. Scegliere poi Teams Guarantee e confermare con Save.

Una policy applicata a una singola applicazione ha la precedenza su una policy applicata alla relativa categoria. Quando più livelli corrispondono contemporaneamente, la descrizione generale di Shaping indica il seguente ordine: applicazione, categoria di applicazione, categoria web, utente, gruppo e, infine, regola del firewall. In presenza di una Rules-Policy aggiuntiva, occorre comunque tenere conto della seguente discrepanza nella documentazione.

L’assegnazione in Traffic shaping default non attiva ancora lo shaping basato sulle applicazioni; è inoltre necessario abilitare Apply application-based traffic shaping policy nella regola firewall effettivamente corrispondente al traffico. Tuttavia, se è impostata contemporaneamente una policy di tipo Rules, la documentazione non è univoca: per Traffic shaping default viene descritta una prevalenza della regola firewall, mentre la descrizione generale dello shaping colloca le applicazioni prima delle regole firewall. Da ciò non è possibile dedurre un’eccezione comprovata in modo affidabile che dipenda dallo stato dell’interruttore. Per iniziare in modo chiaramente verificabile, si utilizza un solo livello di shaping e se ne controlla l’effetto mediante l’Application ID riconosciuto, la corrispondenza con la regola e la velocità di trasferimento misurata. Se si combinano più livelli, non si deve presumere la loro precedenza senza verificarla.

Attivare la regola firewall

In Rules and policies > Firewall rules, aprire la regola attraverso cui passa effettivamente il traffico Teams. Nella sezione Other security features:

1. In Identify and control applications (App control), selezionare il filtro Microsoft Teams.
2. Attivare Apply application-based traffic shaping policy.
3. Salvare la regola e generare traffico.

La policy di tipo Applications non viene selezionata nel campo Shape traffic, ma proviene da Traffic shaping default. La descrizione generale dello shaping indica l’ordine applicazione, categoria di applicazioni, categoria web, utente, gruppo e infine regola firewall. A causa dell’indicazione divergente sulla prevalenza per Traffic shaping default, in presenza di policy assegnate contemporaneamente la precedenza effettiva deve essere chiarita per la build di destinazione. Più livelli devono essere combinati solo consapevolmente e verificati con traffico reale.

L’ordine delle regole rimane determinante: se il traffico corrisponde già a una regola più generale posta più in alto, non vengono applicati né il filtro né lo shaping della regola successiva.

Limitare una singola applicazione o garantire banda a una categoria

Per un semplice limite massimo, la procedura rimane la stessa, ma Rule type viene impostato su Limit. Un esempio per un’applicazione Zoom già riconosciuta è una policy Zoom Limit con Policy association > Applications, Rule type > Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) e Bandwidth usage type > Shared. 1000 KBps corrispondono a 8 Mbit/s; questo valore iniziale scelto liberamente non è una raccomandazione di Zoom e deve essere adeguato alla capacità misurata della linea e alla qualità delle chiamate desiderata. Disable significa qui che non vengono impostati limiti separati per upload e download, non che lo shaping sia disattivato. In Applications > Traffic shaping default, si apre Conferencing con Expand e si assegna la policy a Zoom meetings con Edit. Nell’Application Filter si seleziona l’applicazione appropriata tramite lo Smart Filter Zoom. Si salvano la regola del filtro, il filtro e la regola firewall; nella regola firewall rimangono necessari il filtro appropriato e Apply application-based traffic shaping policy. In presenza di traffico offerto sufficiente, si verifica che la velocità di trasferimento rimanga al limite scelto e che l’Application ID riconosciuto appartenga effettivamente a Zoom.

Per una garanzia condivisa da un’intera categoria di applicazioni, la policy di tipo Applications viene invece assegnata direttamente alla categoria. Ad esempio, si apre Remote Access in Traffic shaping default con Edit e si assegna una policy Guarantee con Shared. Nell’Application Filter si crea una regola con Category > Remote access; successivamente si salvano la regola e il filtro e, nella regola firewall corrispondente al traffico, si impostano il filtro e l’interruttore dello shaping. Tutte le applicazioni incluse in questa policy condividono il pool di banda e non ricevono ciascuna l’intera banda garantita. La garanzia e il limite vengono scelti in base alla capacità disponibile e alle sessioni simultanee effettivamente necessarie. L’assegnazione a una categoria non consente applicazioni di accesso remoto precedentemente bloccate; le disposizioni di accesso esistenti rimangono vincolanti.

Traffic Shaping basato su regola per un’intera regola

Se tutto il traffico di una regola firewall chiaramente delimitata deve utilizzare gli stessi valori, una policy Rules è più semplice:

1. In System services > Traffic shaping, creare una policy con Policy association > Rules.
2. In Rules and policies > Firewall rules, aprire la regola interessata.
3. In Shape traffic, selezionare la policy Rules.
4. Non attivare Apply application-based traffic shaping policy, a meno che non vengano utilizzate policy Applications aggiuntive.

Un Application Filter non limita automaticamente una policy di tipo Rules a questa applicazione. A tale scopo, la regola firewall stessa deve essere circoscritta mediante origine, destinazione e servizi, oppure si deve utilizzare la procedura basata sulle applicazioni. Anche DSCP marking non sostituisce lo shaping: DSCP contrassegna i pacchetti per i dispositivi a valle, mentre la policy di shaping sul firewall garantisce o limita la larghezza di banda.

Una policy di tipo Rules può quindi applicare lo shaping anche a connessioni VPN, singoli host, gruppi di host o servizi. Per il traffico proveniente da una VPN, nella regola appropriata si utilizza Source zone > VPN; per host IP o MAC oppure gruppi di host, si selezionano gli oggetti desiderati in Source networks and devices. I servizi circoscrivono le porte e i protocolli. Questi criteri determinano quale traffico corrisponde alla regola prima che intervenga Shape traffic. Non si restringe senza cautela una regola esistente in produzione al solo scopo di eseguire un test di shaping; si verifica prima quali connessioni consentite cesserebbero di corrispondere alla regola.

Applicare il Traffic Shaping ad altri oggetti

Policy association determina già durante la creazione dove una policy può essere selezionata: Applications, Web categories, Users o Rules. Nel flusso dell’interfaccia utente, una policy non può successivamente essere convertita in un altro tipo; da ciò non si deduce una migrazione del tipo tramite API. Una pianificazione facoltativa ne limita la validità temporale, ma non sostituisce né l’assegnazione all’oggetto né il test funzionale. Durante la creazione, Add schedule si trova più in basso nella policy: con Add si impostano le indicazioni temporali desiderate, quindi si salva la policy con Save. Con o senza pianificazione, soltanto l’assegnazione a un’applicazione, una categoria, un utente o una regola rende efficace la policy. In caso di errore legato all’orario, si controlla inoltre che il test si svolga all’interno della finestra temporale configurata.

Applicare lo shaping alle categorie web

Per un sito web o una categoria, si crea una policy con Policy association > Web categories e la si assegna alla categoria interessata in Web > Categories. La categoria deve essere presente in una Web Policy effettivamente applicata. Nella regola firewall effettivamente corrispondente al traffico, si attivano questa Web Policy e Apply web category-based traffic shaping. La sola assegnazione salvata a una categoria non applica ancora lo shaping ad alcun traffico.

Per un solo sito web specifico, una categoria dedicata è più facilmente verificabile rispetto a una categoria esistente ampia. Come esempio, si crea una policy Website Limit con Web categories, Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) e Shared. Gli 8 Mbit/s sono un limite massimo di esempio adattabile, non un’impostazione generale per il web; tutte le categorie assegnate a questa policy condividono il pool di banda. Una policy di tipo Limit non garantisce una larghezza di banda minima.

1. In Web > Categories > Add, creare una categoria come Example Website, selezionare Classification > Productive, la policy Website Limit e Configure category > Local.
2. In Domain/keyword, aggiungere il dominio di esempio www.example.com con il pulsante più e salvare con Save. Nell’utilizzo operativo, viene sostituito con il dominio effettivamente desiderato. Una parola chiave aggiuntiva come example è utile solo se si intende anche effettuare un’associazione più ampia basata su parole chiave; non deve essere copiata ciecamente da un esempio.
3. In Web > Policies, aprire la Web Policy effettivamente applicata e aggiungere una regola appropriata con Add. In Activities > Show only > Web categories, scegliere la nuova categoria e confermare con Apply selected items. Prima di Save, verificare l’autorizzazione di accesso esistente e l’ordine delle regole; lo shaping non è un motivo per consentire siti web bloccati.
4. Nella regola firewall effettivamente corrispondente al traffico, selezionare questa Web Policy in Security features > Web filtering, attivare Apply web category-based traffic shaping e salvare la regola.

Successivamente, verificare con un sito web consentito appartenente alla categoria che vengano applicate la regola firewall e la categoria web previste e che, in presenza di traffico sufficiente, la velocità di trasferimento rimanga al limite. Un sito web non appartenente alla categoria serve come controprova. In caso di corrispondenza inattesa, si controllano l’associazione dominio/parola chiave, l’ordine delle regole della Web Policy e le altre assegnazioni di shaping.

Assegnare le categorie web tramite XML API

Per le assegnazioni ricorrenti delle categorie, il riferimento XML descrive WebFilterCategory con QoSPolicy. Il campo fa riferimento alla policy di larghezza di banda esistente; per questa procedura, la policy deve essere associata a Web categories. Non si tratta né di una Web Policy né di un’azione Allow/Block. Prima di scrivere, salvare il contenuto della categoria, l’assegnazione di shaping precedente e i riferimenti alle Web Policy. Accesso, operazione esplicita, contratto del build e stato XML sono spiegati in Utilizzare l’XML API in sicurezza e valutare le risposte. Le relazioni tra oggetti seguenti non costituiscono un modello di richiesta eseguibile.

Per ConfigureCategory, Local utilizza la gerarchia DomainList/Domain e KeywordList/Keyword; External utilizza URLList/URL per un elenco esterno di categorie. L’URL di un elenco esterno non è il dominio aziendale di cui si vuole limitare il traffico. Verificare provenienza, aggiornamento e contenuto dell’elenco e non combinare i due percorsi di inserimento senza averli verificati. La tabella riporta anche 0, senza spiegarne chiaramente il significato; non dedurne un’alternativa ai due percorsi denominati.

Classification classifica la categoria, ma non consente né blocca l’accesso. La tabella dei valori enumerati riporta Productive, Unproductive, Acceptable e Objectionable, mentre la descrizione utilizza in parte denominazioni diverse. Non utilizzare nomi di classificazione tradotti come valori API; se il contratto non è chiaro, consultare prima API help del build installato e non eseguire scritture. La tabella di riferimento indica QoSPolicy come campo obbligatorio con un massimo di 50 caratteri e senza virgole; l’esempio mostra None. Questo esempio non costituisce un valore predefinito a runtime comprovato, né conferma che l’omissione del campo mantenga o rimuova l’assegnazione precedente. Per lo shaping, verificare la policy esistente con l’associazione appropriata e il suo nome effettivamente salvato.

Anche dopo un’assegnazione tramite API, l’intera procedura nell’interfaccia utente descritta sopra rimane necessaria: la categoria deve essere utilizzata nella Web Policy effettivamente applicata e, nella regola firewall effettivamente corrispondente al traffico, devono essere impostate sia questa policy sia Apply web category-based traffic shaping. Classificazione, contenuto della categoria, accesso e larghezza di banda rimangono decisioni separate. Utilizzare un sito web consentito appartenente alla categoria, una controprova senza corrispondenza e una destinazione che rimanga bloccata per verificare che sia stata modificata soltanto l’assegnazione di larghezza di banda prevista. Una categoria salvata non dimostra ancora che lo shaping sia efficace.

Le risposte relative alle categorie variano in base all’operazione. I valori seguenti sono codici di stato XML e simboli di riferimento non risolti, riportati senza modifiche, non codici HTTP né testi risolti dei messaggi:

Per le risposte relative ai dettagli, rileggere separatamente l’oggetto categoria e ciascun insieme necessario di domini, parole chiave o elenchi: un codice XML 2xx non significa automaticamente che tutti i dettagli siano stati salvati. Il nome del simbolo comune ai due codici di successo Add non ne spiega la differenza. I simboli contenenti «MaxFive» non dimostrano l’esistenza di un limite attuale universale di cinque voci; chiarire la quantità consentita consultando la guida del build. Prima di un’eliminazione, verificare i riferimenti alle Web Policy e, dopo l’operazione, accertare quali categorie rimangano effettivamente; in caso di selezione multipla, non presumere che tutte le eliminazioni siano riuscite.

Prima di ogni nuovo tentativo, salvare la risposta, lo stato effettivo e l’Audit Trail. Quindi confrontare il contenuto della categoria, QoSPolicy e i riferimenti con lo stato precedente documentato e pianificare soltanto la propria correzione ancora necessaria. Non ripetere alla cieca la creazione, l’aggiornamento o l’eliminazione di una modifica salvata solo parzialmente. Per il ripristino, riportare allo stato salvato soltanto la propria assegnazione di categoria/policy; per modificare i valori di larghezza di banda, la policy sostitutiva rimane la procedura sicura in questo runbook dell’interfaccia utente. L’operazione di aggiornamento di QoSPolicy documentata va distinta da questa procedura ed è soggetta ai contratti API non chiariti illustrati sopra.

Utenti, gruppi e regole WAF

Una policy con Policy association > Users viene assegnata in Authentication > Users o Authentication > Groups. Nella regola firewall si attiva Match known users e si selezionano gli utenti o i gruppi interessati; l’identità effettivamente riconosciuta deve corrispondere a questa selezione. Per una regola WAF, invece, si assegna una policy di tipo Rules in Advanced settings > Traffic shaping alla regola con Action > Protect with web server protection.

In presenza di più livelli, la descrizione generale dello shaping indica l’ordine applicazione, categoria di applicazioni, categoria web, utente, gruppo e infine regola firewall. In caso di assegnazioni combinate, occorre continuare a tenere conto dell’indicazione divergente per Traffic shaping default illustrata sopra. Pertanto, si verifica quale policy abbia effetto utilizzando un flusso reale, l’utente riconosciuto o l’Application ID e la regola effettivamente corrispondente al traffico.

Verificare l’effetto e modificare la policy in sicurezza

Dopo la modifica, non basta eseguire uno speed test. Occorre verificare:

• Il traffico corrisponde alla regola firewall prevista?
• I log di Application Control mostrano l’applicazione o l’Application ID previsto?
• I report come Top Applications e i contatori delle regole confermano l’assegnazione prevista?
• La direzione interessata è effettivamente satura durante il test?
• Larghezza di banda, latenza, perdita di pacchetti o qualità delle chiamate cambiano come previsto?
• Il test utilizza lo stesso gateway WAN e lo stesso percorso SD-WAN del traffico di produzione?
• Gli utenti dei servizi in tempo reale confermano nella pratica il risultato delle misurazioni tecniche?

Per un confronto attendibile prima e dopo la modifica, utilizzare la stessa origine, la stessa destinazione, la stessa direzione e, se possibile, lo stesso intervallo di tempo. La guida Verificare le prestazioni di Sophos Firewall con iPerf e Speedtest illustra metodi di misurazione adeguati. In presenza di più linee, consultare anche Verificare il routing SD-WAN di Sophos Firewall per Reply Packets e System Traffic.

Per una regolazione successiva nell’interfaccia utente, creare una nuova versione della policy con valori modificati in modo prudente, anziché modificare la policy esistente. Assegnarla prima a un’applicazione, una categoria o una regola ben delimitata, osservare i log e il feedback degli utenti e rimuovere la vecchia policy soltanto dopo una verifica riuscita. È opportuno documentare scopo, regola interessata, valori, responsabile e data di revisione.

Se il Traffic Shaping non funziona come previsto

L’applicazione non viene riconosciuta

Verificare anzitutto che nella regola firewall effettivamente utilizzata sia selezionato l’Application Filter corretto. Per i servizi cloud estesi o cifrati, controllare l’Application ID rilevato nel log di Application Control.

Lo shaping non mostra differenze

Se la linea non è satura durante il test, non esiste un collo di bottiglia visibile da controllare. Altre cause frequenti sono valori superiori alla larghezza di banda reale, la direzione errata, una regola firewall più generica posizionata sopra o un percorso SD-WAN diverso.

Per lo shaping basato sulle applicazioni, devono inoltre essere corrette tutte e tre le assegnazioni: una policy con Applications, l’assegnazione in Traffic shaping default e l’opzione attivata nella regola firewall. La sola selezione dell’opzione non assegna alcuna larghezza di banda.

Il traffico applicativo si interrompe temporaneamente

SFOS 22.0 MR2 Build 546 corregge NC-178197, un errore che poteva interrompere in modo intermittente il traffico applicativo quando veniva applicata una application-based bandwidth policy. Se questo sintomo si verifica con SFOS 22.0 GA o MR1, prima di modificare le policy occorre verificare la versione del firmware e aggiornare a MR2 o a una versione successiva approvata.

Microsoft 365 o la rete guest continuano a presentare problemi

Microsoft 365 dovrebbe essere analizzato separatamente per Teams, Exchange, SharePoint e OneDrive, invece di garantire o limitare indiscriminatamente l’intera categoria. Per la rete guest, verificare che il traffico utilizzi effettivamente la regola prevista e che non sia limitato soltanto il download, ma anche l’upload.