Configurer le Traffic Shaping des applications sur Sophos Firewall

Le Traffic Shaping des applications permet à Sophos Firewall de prioriser ou de limiter des applications individuelles telles que Microsoft Teams, VoIP, OneDrive ou les services de sauvegarde. La procédure complète basée sur les applications est la suivante :

1. Sous System services > Traffic shaping, créer une politique avec Policy association > Applications.
2. Sous Applications > Application filter, configurer la détection de l’application souhaitée.
3. Sous Applications > Traffic shaping default, attribuer la politique à l’application ou à la catégorie.
4. Sous Rules and policies > Firewall rules, sélectionner l’Application Filter et activer Apply application-based traffic shaping policy.

Une politique avec Policy association > Rules dans le champ Shape traffic constitue une autre méthode : elle façonne l’ensemble du trafic correspondant à la règle de pare-feu, et pas uniquement l’application sélectionnée dans l’Application Filter.

⚠️ Le Traffic Shaping ne crée pas de bande passante supplémentaire. Il répartit un goulot d’étranglement de manière plus contrôlée. Si la connexion est constamment saturée, il faut tout de même examiner la capacité, les sauvegardes, les synchronisations cloud et les autres sources de charge.

Le Traffic Shaping limite un débit, pas le volume total de données transféré. Pour des crédits de temps ou de données consommables, on utilise plutôt Surfing Quota et Network Traffic Quota.

Planifier les prérequis et la bande passante

Avant la configuration, clarifier les points suivants :

• L’Application Control est nécessaire au shaping basé sur les applications. Il fait partie de Web Protection et est également inclus dans le bundle Standard Protection. Vérifier son état sous System > Administration > Licensing. En revanche, une politique Rules ne nécessite pas la détection d’applications.
• Le pare-feu détecte l’application concernée et le trafic passe par une règle de pare-feu connue.
• La journalisation est activée pour cette règle.
• Il est établi si la contrainte concerne l’upload, le download ou les deux directions, ainsi que la passerelle WAN ou le chemin SD-WAN utilisé.
• L’effet recherché est défini : Guarantee réserve une bande passante minimale et autorise le trafic jusqu’à la limite ; Limit fixe uniquement un plafond.

Sophos affiche les valeurs de shaping en KBps, tandis que les tests de débit utilisent généralement des kbps ou des Mbit/s. 1 KBps équivaut à 8 kbps. Ainsi, 100 Mbit/s correspondent à environ 12 500 KBps et 20 Mbit/s à environ 2 500 KBps.

Il faut se baser sur des mesures stables et non sur le débit annoncé par le fournisseur. Si une connexion nominale de 100/20 Mbit/s ne fournit de manière fiable que 80/15 Mbit/s, il convient de planifier environ 10 000/1 875 KBps. Des valeurs supérieures au goulot d’étranglement réel ne permettent pas de le contrôler efficacement.

Pour les connexions asymétriques, activer Limit upload/download separately. Teams, VoIP, VPN et les sauvegardes cloud sont souvent les premiers à souffrir lorsque l’upload est saturé. Les valeurs globales sous System services > Traffic shaping settings ne s’appliquent qu’au trafic sortant que le pare-feu transfère vers la zone WAN. Les politiques Traffic Shaping individuelles peuvent en revanche s’appliquer au trafic transféré entrant et sortant. La QoS ne s’applique par ailleurs pas au trafic généré par le système du pare-feu, comme les mises à jour de signatures ou les synchronisations de licence.

Distinguer les valeurs globales des politiques individuelles

Sous System services > Traffic shaping settings, Total available WAN bandwidth définit la capacité QoS commune à toutes les liaisons WAN. Il faut saisir la somme de la bande passante disponible de manière stable, en KBps, et non seulement le débit contractuel d’une seule liaison. Show bandwidth usage montre comment cette capacité est répartie entre les priorités. Ces valeurs globales n’affectent que le trafic WAN sortant transféré qui ne correspond à aucune politique Traffic Shaping individuelle.

Avec Optimize for real-time (VoIP), SFOS donne toujours la priorité au trafic en temps réel. Si cette option est désactivée, les politiques de garantie reçoivent d’abord la bande passante qui leur est promise, puis le trafic en temps réel utilise la capacité restante. Enforce guaranteed bandwidth active, pour le trafic sans politique propre, les valeurs Guarantee, Limit et Priority de 1 à 7 de la politique par défaut. Si Enforce guaranteed bandwidth est désactivé, ce trafic ne reçoit aucune bande passante minimale garantie, mais uniquement la capacité encore disponible. Pour Priority, 1 correspond à la priorité la plus élevée et 7 à la plus faible.

Ces options ne doivent pas être activées comme correctif général de performance. Il faut d’abord documenter la bande passante réelle, les garanties existantes et la priorité souhaitée. Sinon, des garanties surdimensionnées se disputent une capacité qui n’existe pas physiquement.

Configurer le Traffic Shaping basé sur les applications

L’exemple suivant donne la priorité au trafic de quatre terminaux vidéo Teams actifs simultanément au maximum sur un petit site disposant d’une connexion stable d’environ 80/15 Mbit/s. Dans ses besoins en bande passante pour Teams, Microsoft recommande environ 2 500 kbps en upload et 4 000 kbps en download par terminal pour une réunion vidéo. Les valeurs de l’exemple réservent ce besoin commun, mais doivent être comparées aux mesures locales et au nombre réel de terminaux actifs simultanément.

Créer une politique de Traffic Shaping

Sous System services > Traffic shaping, créer une politique, par exemple avec les valeurs suivantes :

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

1 250 KBps correspondent à 10 Mbit/s et 2 000 KBps à 16 Mbit/s. Avec Shared, toutes les applications ou catégories auxquelles cette politique est attribuée partagent le même pool. Individual, en revanche, alloue la valeur uniquement à l’objet auquel la politique est attribuée en premier ; une politique Individual ne doit donc pas servir de modèle réutilisable pour plusieurs objets. Il ne faut pas répartir des valeurs de garantie élevées sur trop de politiques, car leur somme doit rester compatible avec la bande passante réellement disponible. Dans cet exemple, les garanties correspondent au besoin total recommandé pour quatre terminaux vidéo Teams. Lorsque de la bande passante est disponible, ils peuvent l’utiliser jusqu’aux limites supérieures. Les limites de 12/40 Mbit/s laissent délibérément de la capacité pour le reste du trafic sur la connexion mesurée à 80/15 Mbit/s. Ce sont des valeurs initiales, pas des exigences Teams universelles.

Dans la procédure d’interface décrite ici, les politiques de Traffic Shaping ne peuvent plus être modifiées après leur création. Cette restriction de l’interface ne signifie pas que l’API XML ne documente aucune opération de mise à jour. Si d’autres valeurs sont nécessaires par la suite, commencer par documenter toutes les affectations, créer une politique de remplacement sous un nouveau nom et ne migrer d’abord qu’un périmètre limité. Après vérification, migrer les autres affectations ; ne supprimer l’ancienne politique que lorsqu’aucune référence ne pointe plus vers elle. Pour revenir en arrière, réattribuer l’ancienne politique ou None.

Politique QoS : distinguer la procédure d’interface du contrat de l’API XML

Les références de l’API XML pour SFOS 22.0 et 23.0 documentent explicitement Add QoS policy / Update QoS policy pour QoSPolicy et décrivent l’ajout et la modification. Une opération d’API est donc documentée, mais cela ne confirme pas encore un contrat de mise à jour exécutable pour le build installé. Les indications suivantes expliquent la documentation ; elles ne constituent pas un modèle de requête testé. La procédure sûre de remplacement dans l’interface reste la marche à suivre pour les ajustements. L’accès, l’opération explicite et la vérification des réponses sont expliqués dans Utiliser l’API XML en toute sécurité et analyser les réponses.

Dans l’exemple, les champs de bande passante dépendent de PolicyType et de ImplementationOn ; ils ne sont pas tous requis simultanément pour chaque politique :

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

Dans l’exemple, chaque bande passante Burstable doit être supérieure à la garantie correspondante. Les commentaires des branches Individual ne mentionnent que User, Firewall et Application ; WebCategory apparaît pour Total, mais pas pour Individual. Cela ne confirme pas une combinaison Individual-WebCategory et ne constitue pas non plus une interdiction démontrée à l’exécution. De plus, ImplementationOn avec Total/Individual n’est pas le même champ que BandwidthUsageType avec Individual/Shared ; des tokens identiques ne sont pas des paramètres interchangeables.

L’exemple et le tableau des paramètres ne concordent pas sur tous les points : l’exemple indique 2–2560000 KB, le tableau 2–10240000. Cela ne permet pas de déduire une limite supérieure universelle pour le build. Pour BandwidthUsageType, l’exemple présente Individual/Shared, tandis que le tableau indique Shared Bandwidth Usage Type avec on/off. Dans l’exemple, PolicyBasedOn utilise des tokens nommés, alors que Policy Based On est décrit dans le tableau comme un entier avec la valeur par défaut 0. Aucune correspondance des tokens ni aucune valeur par défaut sûre en cas d’omission n’en est déduite ici.

Les détails de planification présentent eux aussi deux représentations dont la correspondance n’est pas clairement établie : l’exemple présente SchedulebasedPolicyRuleList avec Rule, DetailId, PolicyType, les champs conditionnels de bande passante et Schedule ; DetailId figure également sur l’objet politique. Le tableau indique Implementation On comme un tableau avec 6/7, Policy Type comme un tableau avec 8/11, les listes de bande passante bandwidthlist, grntdbandwidthlist, burstbandwidthlist, upbandwidthlist, downbandwidthlist, grntdupbandwidthlist, grntddownbandwidthlist, ainsi que qosdetailnamelist et ScheduleDetail. Aucune correspondance entre les valeurs numériques d’énumération et les tokens nommés n’est établie ici ; l’ordre, l’identité des détails et le comportement lors d’une mise à jour ou d’une omission ne sont pas devinés.

Avant toute modification via l’API, API help du build installé doit clarifier ces limites, noms de champs et structures de planification encore indéterminés. Tant que le contrat n’est pas clair, ne pas assembler de requête d’écriture à partir de l’exemple. Sauvegarder l’état antérieur, les affectations et les détails de planification ; après une modification approuvée, relire séparément l’objet et les détails, puis vérifier l’effet du shaping dans la plage horaire concernée. La référence indique les statuts XML 200, 500 et 502 pour l’ajout comme pour la mise à jour. La source brute renvoie aux symboles non résolus Message.QOSAddSuccess, Message.QOSAddFail, Message.QOSEditSuccess, Message.QOSEditFail et Message.QOSRecordExist ; les messages sont absents du texte extrait. Ces symboles ne sont ni des textes de messages confirmés ici ni des codes HTTP. Un statut seul ne confirme ni l’ensemble des détails ni l’effet obtenu. En cas d’écart, sauvegarder la réponse et l’état réel, et ne pas répéter aveuglément l’opération ; ramener uniquement sa propre modification à l’état sauvegardé.

Créer un Application Filter

Sous Applications > Application filter, créer un filtre qui contient uniquement le trafic souhaité :

1. Attribuez un nom tel que Microsoft Teams.
2. Ajoutez une règle Application.
3. Recherchez microsoft teams dans Smart Filter.
4. Sélectionnez les applications Teams pertinentes et utilisez l’action Allow.
5. Enregistrez la règle Application avec Save, puis enregistrez également Application Filter avec Save.

Il ne faut pas traiter Microsoft 365 comme une seule application par défaut. Teams, Exchange, SharePoint et OneDrive génèrent des trafics différents et doivent d’abord être observés séparément. Si l’objectif est la détection et le blocage plutôt que la bande passante, consulter Configurer et tester l’Application Control sur Sophos Firewall.

Attribuer la politique à l’application

Sous Applications > Traffic shaping default, rechercher Microsoft Teams ou la catégorie d’applications correspondante. Une catégorie s’ouvre directement avec Edit. Pour une application individuelle, développer d’abord la catégorie avec Expand, puis sélectionner Edit pour l’application. Choisir ensuite Teams Guarantee et confirmer avec Save.

Une politique appliquée à une application individuelle est prioritaire sur une politique appliquée à sa catégorie. Lorsque plusieurs niveaux correspondent simultanément, la description générale de Shaping indique l’ordre suivant : application, catégorie d’application, catégorie web, utilisateur, groupe et, enfin, règle de pare-feu. En présence d’une Rules-Policy supplémentaire, la divergence suivante dans la documentation doit toujours être prise en compte.

L’affectation sous Traffic shaping default n’active pas encore le shaping basé sur les applications ; il faut également activer Apply application-based traffic shaping policy dans la règle de pare-feu effectivement appliquée. Toutefois, lorsqu’une politique Rules est également définie, la documentation n’est pas univoque : pour Traffic shaping default, elle décrit une priorité de la règle de pare-feu, tandis que la description générale du shaping place les applications avant les règles de pare-feu. Cela ne permet pas de déduire une exception étayée de manière fiable en fonction de l’état du commutateur. Pour commencer par une configuration vérifiable sans ambiguïté, utiliser un seul niveau de shaping et contrôler son effet à l’aide de l’Application ID reconnue, de la règle appliquée et du débit mesuré. Lorsque plusieurs niveaux sont combinés, leur effet de priorité ne doit pas être présumé sans vérification.

Activer la règle de pare-feu

Sous Rules and policies > Firewall rules, ouvrir la règle par laquelle passe réellement le trafic Teams. Dans la section Other security features :

1. Sous Identify and control applications (App control), sélectionner le filtre Microsoft Teams.
2. Activer Apply application-based traffic shaping policy.
3. Enregistrer la règle et générer du trafic.

La politique Applications n’est pas sélectionnée dans le champ Shape traffic, mais provient de Traffic shaping default. La description générale du shaping indique l’ordre suivant : application, catégorie d’applications, catégorie web, utilisateur, groupe et, en dernier, règle de pare-feu. En raison de l’indication divergente concernant la priorité pour Traffic shaping default, cet ordre constitue, lorsque des politiques sont affectées simultanément, une indication de la documentation et non un effet de priorité confirmé ici. Plusieurs niveaux ne doivent être combinés que de manière délibérée et vérifiés avec du trafic réel.

L’ordre des règles reste déterminant : si le trafic correspond déjà à une règle plus générale située plus haut, ni le filtre ni le shaping de la règle suivante ne sont appliqués.

Limiter une application individuelle ou garantir une bande passante à une catégorie

Pour définir uniquement un plafond, la procédure reste identique, mais Rule type est défini sur Limit. Pour une application Zoom déjà reconnue, un exemple est une politique Zoom Limit avec Policy association > Applications, Rule type > Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) et Bandwidth usage type > Shared. 1000 KBps correspondent à 8 Mbit/s ; cette valeur de départ librement choisie n’est pas une recommandation de Zoom et doit être adaptée à la capacité mesurée de la connexion et à la qualité de communication souhaitée. Disable signifie ici qu’aucune limite distincte n’est définie pour l’envoi et le téléchargement, et non que le shaping est désactivé. Sous Applications > Traffic shaping default, ouvrir Conferencing avec Expand, puis affecter la politique à Zoom meetings avec Edit. Dans l’Application Filter, sélectionner l’application appropriée à l’aide du Smart Filter Zoom. Enregistrer la règle de filtrage, le filtre et la règle de pare-feu ; dans la règle de pare-feu, le filtre approprié et Apply application-based traffic shaping policy restent nécessaires. Avec un volume de trafic proposé suffisant, vérifier que le débit reste au niveau de la limite choisie et que l’Application ID reconnue correspond bien à Zoom.

Pour une garantie partagée par toute une catégorie d’applications, la politique Applications est plutôt affectée directement à la catégorie. Par exemple, ouvrir Remote Access sous Traffic shaping default avec Edit et affecter une politique Guarantee avec Shared. Dans l’Application Filter, créer une règle avec Category > Remote access ; enregistrer ensuite la règle et le filtre, puis définir le filtre et activer le commutateur de shaping dans la règle de pare-feu effectivement appliquée. Toutes les applications couvertes par cette politique partagent la réserve de bande passante ; elles ne reçoivent pas chacune la totalité de la garantie. La garantie et la limite sont choisies en fonction de la capacité disponible et des sessions simultanées réellement nécessaires. L’affectation à une catégorie n’autorise pas les applications d’accès à distance précédemment bloquées ; les exigences d’accès existantes restent déterminantes.

Traffic Shaping par règle pour une règle entière

Si tout le trafic d’une règle de pare-feu clairement délimitée doit recevoir les mêmes valeurs, une politique Rules est plus simple :

1. Sous System services > Traffic shaping, créer une politique avec Policy association > Rules.
2. Sous Rules and policies > Firewall rules, ouvrir la règle concernée.
3. Sous Shape traffic, sélectionner la politique Rules.
4. Ne pas activer Apply application-based traffic shaping policy, sauf si des politiques Applications supplémentaires sont utilisées.

Un Application Filter ne restreint pas automatiquement une politique Rules à cette application. Pour cela, la règle de pare-feu elle-même doit être strictement délimitée par la source, la destination et les services, ou il faut utiliser la procédure basée sur les applications. DSCP marking ne remplace pas non plus le shaping : DSCP marque les paquets pour les équipements en aval, tandis que la politique de shaping sur le pare-feu garantit ou limite la bande passante.

Une politique Rules peut ainsi également appliquer le shaping à des connexions VPN, à des hôtes individuels, à des groupes d’hôtes ou à des services. Pour le trafic provenant d’un VPN, utiliser Source zone > VPN dans la règle appropriée ; pour les hôtes IP ou MAC, ou les groupes d’hôtes, sélectionner les objets souhaités sous Source networks and devices. Les services délimitent les ports et les protocoles. Ces critères déterminent quel trafic correspond à la règle avant que Shape traffic n’agisse. Il ne faut pas restreindre inconsidérément une règle existante en production uniquement pour un test de shaping, mais vérifier au préalable quelles connexions autorisées ne seraient alors plus couvertes par cette règle.

Appliquer le Traffic Shaping à d’autres objets

Policy association détermine dès la création où une politique peut être sélectionnée : Applications, Web categories, Users ou Rules. Dans la procédure d’interface, une politique ne peut pas ensuite être convertie en un autre type ; aucune migration de type via l’API n’en est déduite. Une planification facultative limite sa validité dans le temps, mais ne remplace ni l’affectation à un objet ni le test fonctionnel. Lors de la création, Add schedule se trouve plus bas dans la politique : définir les horaires souhaités avec Add, puis enregistrer la politique avec Save. Avec ou sans planification, seule l’affectation à une application, une catégorie, un utilisateur ou une règle rend la politique effective. En cas de problème dépendant de l’heure, vérifier également que le test se déroule dans la plage horaire configurée.

Appliquer le shaping aux catégories web

Pour un site web ou une catégorie, créer une politique avec Policy association > Web categories et l’affecter à la catégorie concernée sous Web > Categories. La catégorie doit figurer dans une Web Policy effective. Dans la règle de pare-feu effectivement appliquée, activer cette Web Policy et Apply web category-based traffic shaping. Une affectation à une catégorie simplement enregistrée n’applique pas encore de shaping au trafic.

Pour un seul site web précis, une catégorie dédiée est plus facile à contrôler qu’une catégorie existante étendue. À titre d’exemple, créer une politique Website Limit avec Web categories, Limit, Priority > 1, Limit upload/download separately > Disable, Limit > 1000 (KBps) et Shared. Les 8 Mbit/s constituent un plafond d’exemple ajustable, et non une valeur générale prescrite pour le web ; toutes les catégories affectées à cette politique partagent la réserve de bande passante. Une politique Limit ne garantit aucune bande passante minimale.

1. Sous Web > Categories > Add, créer une catégorie telle que Example Website, puis sélectionner Classification > Productive, la politique Website Limit et Configure category > Local.
2. Sous Domain/keyword, ajouter le domaine d’exemple www.example.com avec le bouton plus et enregistrer avec Save. En exploitation, le remplacer par le domaine réellement souhaité. Un mot-clé supplémentaire tel que example n’est pertinent que si une correspondance plus large par mot-clé est également souhaitée ; il ne doit pas être repris aveuglément d’un exemple.
3. Sous Web > Policies, ouvrir la Web Policy effective et ajouter une règle appropriée avec Add. Sous Activities > Show only > Web categories, sélectionner la nouvelle catégorie et l’appliquer avec Apply selected items. Avant Save, vérifier l’autorisation d’accès existante et l’ordre des règles ; le shaping n’est pas une raison d’autoriser des sites web bloqués.
4. Dans la règle de pare-feu effectivement appliquée, sous Security features > Web filtering, sélectionner cette Web Policy, activer Apply web category-based traffic shaping et enregistrer la règle.

Vérifier ensuite, avec un site web autorisé de la catégorie, que la règle de pare-feu et la catégorie web attendues s’appliquent et que le débit reste au niveau de la limite avec un trafic suffisant. Un site web n’appartenant pas à la catégorie sert de contre-vérification. En cas de correspondance inattendue, contrôler l’affectation par domaine ou mot-clé, l’ordre des règles de la Web Policy et les autres affectations de shaping.

Affecter les catégories web via l’API XML

Pour les affectations récurrentes de catégories, la référence XML décrit WebFilterCategory avec QoSPolicy. Ce champ renvoie à la politique de bande passante existante ; pour cette procédure, elle doit être associée à Web categories. Il ne s’agit ni d’une Web Policy ni d’une action Allow/Block. Avant toute écriture, sauvegarder le contenu de la catégorie, l’affectation de shaping actuelle et les références aux Web Policies. L’accès, l’opération explicite, le contrat propre au build et le statut XML sont expliqués dans Utiliser l’API XML en toute sécurité et analyser les réponses. Les indications suivantes décrivent des relations entre objets à titre documentaire ; elles ne constituent pas un modèle de requête exécutable ou testé sur un build de pare-feu.

Pour ConfigureCategory, Local utilise la hiérarchie DomainList/Domain et KeywordList/Keyword ; External utilise URLList/URL pour une liste de catégories externe. L’URL d’une liste externe n’est pas le domaine de l’entreprise dont le trafic doit être limité. Vérifier la provenance, la mise à jour et le contenu de la liste, et ne pas mélanger les deux modes de saisie sans vérification préalable. Le tableau mentionne également 0, sans en expliquer clairement la signification ; ne pas en déduire une solution de remplacement pour les deux modes nommés.

Classification classe la catégorie, mais n’autorise ni ne bloque l’accès. Le tableau des valeurs d’énumération indique Productive, Unproductive, Acceptable et Objectionable, tandis que la description utilise parfois d’autres désignations. Ne pas utiliser de noms de classification traduits comme valeurs d’API ; si le contrat n’est pas clair, consulter d’abord API help du build installé et ne procéder à aucune écriture. Le tableau de référence indique que QoSPolicy est un champ obligatoire, limité à 50 caractères et ne devant pas contenir de virgule ; l’exemple présente None. Cet exemple ne constitue ni une valeur par défaut à l’exécution attestée ni une confirmation que l’omission du champ conserve ou supprime l’affectation actuelle. Pour le shaping, vérifier la politique existante correctement associée et son nom réellement enregistré.

Même après une affectation via l’API, la procédure dans l’interface décrite ci-dessus reste intégralement nécessaire : la catégorie doit être utilisée dans la Web Policy effective, et cette politique ainsi que Apply web category-based traffic shaping doivent être définies dans la règle de pare-feu effectivement appliquée. La classification, le contenu de la catégorie, l’accès et la bande passante restent des décisions distinctes. À l’aide d’un site web autorisé appartenant à la catégorie, d’une contre-vérification sans correspondance et d’une cible toujours bloquée, vérifier que seule l’affectation de bande passante prévue a été modifiée. Une catégorie enregistrée ne prouve pas encore que le shaping est effectif.

Les réponses relatives aux catégories diffèrent selon l’opération. Les valeurs suivantes sont des codes de statut XML et des symboles de référence non résolus, conservés tels quels ; il ne s’agit ni de codes HTTP ni de textes de messages confirmés ici :

Pour les réponses concernant les détails, relire séparément l’objet catégorie et chaque ensemble requis de domaines, de mots-clés ou de listes : un code XML 2xx ne signifie pas automatiquement que tous les détails ont été enregistrés. Le nom de symbole commun aux deux codes de réussite Add n’explique pas leur différence. Les symboles contenant « MaxFive » n’attestent pas d’une limite actuelle universelle de cinq entrées ; déterminer le nombre autorisé à partir de l’aide du build. Avant une suppression, vérifier les références aux Web Policies, puis établir quelles catégories subsistent réellement ; en cas de sélection multiple, ne pas présumer que toutes les suppressions ont réussi.

Avant chaque nouvelle tentative, sauvegarder la réponse, l’état réel et l’Audit Trail. Comparer ensuite le contenu de la catégorie, QoSPolicy et les références à l’état antérieur documenté, puis ne planifier que la correction encore nécessaire de sa propre modification. Ne pas recréer, mettre à jour ou supprimer aveuglément une modification partiellement enregistrée. Pour revenir en arrière, restaurer uniquement sa propre affectation de catégorie/politique à l’état sauvegardé ; pour les valeurs de bande passante modifiées, la politique de remplacement reste la procédure sûre dans ce guide opérationnel pour l’interface. L’opération de mise à jour de QoSPolicy documentée doit être distinguée de cette procédure et reste soumise aux contrats d’API non clarifiés expliqués ci-dessus.

Utilisateurs, groupes et règles WAF

Une politique avec Policy association > Users est affectée sous Authentication > Users ou Authentication > Groups. Dans la règle de pare-feu, activer Match known users et sélectionner les utilisateurs ou groupes concernés ; l’identité effectivement reconnue doit correspondre à cette sélection. Pour une règle WAF, en revanche, une politique Rules est affectée sous Advanced settings > Traffic shaping à la règle avec Action > Protect with web server protection.

Lorsque plusieurs niveaux sont utilisés, la description générale du shaping indique l’ordre suivant : application, catégorie d’applications, catégorie web, utilisateur, groupe et, en dernier, règle de pare-feu. L’indication divergente pour Traffic shaping default, expliquée ci-dessus, reste à prendre en compte lorsque des affectations sont combinées. Il faut donc vérifier quelle politique agit à l’aide d’un flux réel, de l’utilisateur reconnu ou de l’Application ID et de la règle effectivement appliquée.

Vérifier l’effet et ajuster la politique en toute sécurité

Après la modification, ne pas se fier uniquement à un test de débit. Vérifier si :

• Le trafic correspond à la règle de pare-feu attendue.
• Les journaux Application Control affichent l’application ou l’Application ID attendue.
• Les rapports comme Top Applications et les compteurs de règles confirment l’attribution attendue.
• La direction concernée est réellement saturée pendant le test.
• La bande passante, la latence, la perte de paquets ou la qualité des appels évoluent comme prévu.
• Le test utilise la même passerelle WAN et le même chemin SD-WAN que le trafic de production.
• Les retours des utilisateurs de services en temps réel confirment également les mesures techniques en pratique.

Pour une comparaison avant/après fiable, utiliser la même source, la même destination, la même direction et, si possible, la même période. Le guide Tester les performances de Sophos Firewall avec iPerf et Speedtest présente des méthodes de mesure adaptées. Avec plusieurs connexions, consulter également Vérifier le routage SD-WAN de Sophos Firewall pour les Reply Packets et le System Traffic.

Pour effectuer des ajustements dans l’interface, créer une nouvelle version de la politique avec des valeurs modifiées de manière prudente, au lieu de modifier la politique existante. L’affecter d’abord à une application, une catégorie ou une règle au périmètre restreint, surveiller les journaux et les retours des utilisateurs, puis ne supprimer l’ancienne politique qu’après une vérification réussie. L’objectif, la règle concernée, les valeurs, le responsable et la date de révision doivent être documentés.

Lorsque le Traffic Shaping ne fonctionne pas comme prévu

L’application n’est pas détectée

Vérifier d’abord que le bon Application Filter est sélectionné dans la règle de pare-feu réellement utilisée par le trafic. Pour les services cloud étendus ou chiffrés, confirmer la classification dans le journal Application Control à l’aide de l’Application ID détectée.

Le shaping ne produit aucune différence

Si la connexion n’est pas saturée pendant le test, aucun goulot d’étranglement visible ne peut être contrôlé. Parmi les autres causes fréquentes figurent des valeurs supérieures à la bande passante réelle, la mauvaise direction, une règle de pare-feu plus générale placée plus haut ou un autre chemin SD-WAN.

Le shaping basé sur les applications exige également que les trois attributions soient correctes : une politique avec Applications, son attribution sous Traffic shaping default et l’option activée dans la règle de pare-feu. L’option seule n’attribue aucune bande passante.

Le trafic applicatif s’interrompt par intermittence

SFOS 22.0 MR2 Build 546 corrige NC-178197, un défaut susceptible d’interrompre par intermittence le trafic applicatif lorsqu’une politique de bande passante basée sur les applications était appliquée. Si ce symptôme apparaît sous SFOS 22.0 GA ou MR1, vérifier la version du firmware avant de remanier les politiques et effectuer la mise à jour vers MR2 ou une version ultérieure approuvée.

Microsoft 365 ou le réseau invité reste problématique

Évaluer séparément Teams, Exchange, SharePoint et OneDrive au lieu de garantir ou de limiter aveuglément toute la catégorie Microsoft 365. Pour le réseau invité, vérifier que son trafic correspond bien à la règle prévue et que l’upload comme le download sont limités lorsque cela est nécessaire.