Configurer Surfing et Network Traffic Quota sur Sophos Firewall

Une Surfing quota limite le temps Internet utilisable par un utilisateur authentifié. Une Network traffic quota limite en revanche le volume de données transféré. Les deux stratégies sont attribuées à un utilisateur ou à un groupe et conviennent, par exemple, à des salles de formation, des invités ou des forfaits d’utilisation clairement définis.

Pour les invités temporaires, la création du compte, la validité, le Captive Portal et la purge sont planifiés séparément. Le cycle de vie complet est décrit dans Créer et exploiter en toute sécurité des utilisateurs invités sur Sophos Firewall ; cet article se concentre sur les quotas.

La procédure courte pour un déploiement contrôlé est la suivante :

1. Déterminer s’il faut limiter la consommation de temps, le volume de données ou les deux.
2. Créer une nouvelle stratégie pilote sous Profiles > Surfing quota ou Profiles > Network traffic quota.
3. Attribuer la stratégie à un petit groupe pilote sous Authentication > Groups ou à un utilisateur de test sous Authentication > Users.
4. Authentifier à nouveau l’utilisateur et vérifier l’identité reconnue sous Current activities > Live users.
5. Utiliser pour le test une règle de pare-feu basée sur l’utilisateur avec Log firewall traffic.
6. Ouvrir l’utilisateur sous Authentication > Users et contrôler la consommation avec View usage.
7. Tester la limite, le cycle suivant et le rollback avant d’ajouter d’autres utilisateurs.

⚠️ Reset user accounting réinitialise à la fois le temps de navigation consommé et les compteurs de trafic réseau. Il s’agit d’un changement d’état et non d’un bouton de diagnostic général. Avant toute réinitialisation, documenter l’utilisateur, les valeurs actuelles, l’heure et le motif. Un quota de production partagé n’est pas non plus modifié directement ; une stratégie pilote distincte est utilisée pour les tests.

Choisir la fonction adaptée au besoin

Quatre fonctions aux noms proches répondent à des besoins différents :

• Access Time autorise ou bloque les utilisateurs pendant des plages horaires fixes. Il ne comptabilise aucune consommation.
• Surfing quota accorde à un utilisateur un crédit de temps consommable pour l’accès à Internet.
• Network traffic quota accorde à un utilisateur un crédit de données consommable.
• Traffic Shaping limite ou priorise la bande passante. Un faible débit n’est pas un quota de données.

Une Web Policy propose également l’action Quota pour un accès limité dans le temps à certaines catégories web. Cette Policy Quota appartient à la logique du proxy web et n’est pas la même fonction que la Surfing Quota basée sur l’utilisateur décrite ici.

Un quota ne crée ni règle de pare-feu ni identité utilisateur. Le pare-feu doit reconnaître l’utilisateur, le chemin réseau doit être autorisé et le trafic de test doit correspondre à la règle attendue. Ce n’est qu’alors que le quota peut être vérifié de manière pertinente.

Pour le quota distinct des catégories web, Policy quota status affiche le temps restant par utilisateur et Web Policy sur une période de 24 heures. Pour une réinitialisation autorisée, y sélectionner les utilisateurs concernés, puis Reset. Documenter d’abord l’utilisateur, la stratégie et le temps restant ; vérifier ensuite l’affichage et une requête de test autorisée. Ne pas confondre cette réinitialisation avec Reset user accounting : l’épuisement d’un quota de catégories web ne justifie pas d’effacer les compteurs de navigation et de données de l’utilisateur.

Planifier l’exemple et les prérequis

L’exemple continu utilise un petit groupe pilote avec deux stratégies distinctes :

• Groupe : Quota_Pilot
• Utilisateur de test : quota-pilot
• Surfing Quota : Students_InternetTime
• Cycle type : Cyclic (repeat access)
• Cycle hours : 24
• Maximum access time : 02:00
• Network Traffic Quota : Students_DataVolume
• Restriction : Total network traffic
• Cycle type : Cyclic
• Cycle period : Day
• Quota per cycle : 5000 MB
• Maximum quota : Unlimited

Ces valeurs sont volontairement de petits exemples de documentation : chaque cycle de 24 heures fournit deux heures d’accès Internet et chaque jour 5000 MB de volume de données. Les noms, la durée, le volume, le cycle et la limite globale sont adaptés à l’accord d’utilisation réel. De petites limites de test ne doivent pas être reprises dans une stratégie de production sans en vérifier l’impact.

Avant la configuration, vérifier les points suivants :

1. L’utilisateur pilote peut se connecter avec la méthode d’authentification prévue.
2. Le nom d’utilisateur et l’adresse source apparaissent sous Current activities > Live users.
3. Pour les utilisateurs AD, le champ Group sous Authentication > Users est correct.
4. Une règle de pare-feu appropriée basée sur l’utilisateur autorise le trafic de test et active Log firewall traffic.
5. Les attributions existantes de Surfing quota, Network traffic, Access time et Traffic shaping sont documentées.
6. L’état précédent et un autre utilisateur de test sont connus.

Si l’utilisateur n’apparaît pas comme Live User, corriger d’abord l’authentification. Un quota ne peut pas attribuer de manière fiable un trafic inconnu ou traité uniquement par IP à un crédit utilisateur normal.

Créer une Surfing Quota

Une Surfing Quota comptabilise le temps Internet consommé. Dans l’aide de SFOS 22, le même objet est documenté sous Profiles > Surfing quota et sous Web > Surfing quotas. Utiliser l’entrée affichée dans WebAdmin sur le build déployé.

Les quotas par défaut existants peuvent également être utilisés ; ouvrir un quota de navigation existant avec Edit. Tenir compte des effets sur tous les utilisateurs et groupes auxquels il est attribué.

Choisir Cyclic ou Non-cyclic

• Cyclic (repeat access) : Le crédit de temps est de nouveau mis à disposition selon des cycles récurrents. Le temps inutilisé n’est pas reporté au cycle suivant.
• Non-cyclic (one-time access) : Le crédit de temps n’est fourni qu’une seule fois. L’utilisateur est déconnecté après l’avoir consommé.

En complément, Validity period limite le nombre de jours pendant lesquels la stratégie reste valide. Maximum access time définit le temps utilisable. Lorsque le maximum est atteint, l’utilisateur est déconnecté même si la période de validité du quota n’est pas encore expirée.

Si plusieurs Surfing Quotas s’appliquent à un utilisateur, le pare-feu restreint l’accès dès que la première de ces stratégies atteint sa limite. Il faut donc vérifier ensemble toutes les attributions directes et celles provenant des groupes ; une seconde stratégie plus généreuse n’annule pas une limite déjà atteinte.

Unlimited pour Maximum access time supprime uniquement la limite de temps consommé, pas la validité configurée séparément. Pour un accès illimité accordé une seule fois pendant une semaine, choisir par exemple Non-cyclic (one-time access), définir Validity period sur 7 jours et Maximum access time sur Unlimited. Ce besoin diffère de deux heures par cycle de 24 heures.

Pour l’exemple pilote :

1. Ouvrir Profiles > Surfing quota > Add. Si le build affiche la fonction sous Web > Surfing quotas, y sélectionner Add.
2. Définir Name sur Students_InternetTime.
3. Saisir par exemple Pilot: 2h per 24h, Owner IT dans Description.
4. Définir Cycle type sur Cyclic (repeat access).
5. Définir Cycle hours sur 24.
6. Définir explicitement la Validity period pour le pilote, ou sélectionner Unlimited uniquement si aucune limite d’expiration n’est nécessaire.
7. Définir Maximum access time sur 02:00.
8. Enregistrer avec Save.

La stratégie enregistrée n’a pas encore d’effet. Seule son attribution à un utilisateur ou à un groupe associe le crédit de temps à une identité.

Situer SurfingQuotaPolicy dans l’API XML

Pour les automatisations, le quota de temps lié à l’utilisateur porte le nom SurfingQuotaPolicy. Il ne s’agit ni d’une Network Traffic Quota ni de l’action Quota d’une Web Policy. La protection de l’accès, les opérations d’écriture explicites et la distinction entre transport HTTP et résultat XML sont expliquées dans Sécuriser l’accès à l’API XML. Avant toute modification, sauvegarder le nom exact de l’objet, toutes les valeurs enregistrées ainsi que les attributions aux utilisateurs et aux groupes ; ne modifier qu’une stratégie pilote distincte.

Les références XML pour SFOS 22.0 et 23.0 indiquent les champs suivants. Il s’agit d’informations documentées, et non d’une sérialisation testée sur un pare-feu :

• Name est obligatoire : chaîne de caractères, 60 caractères au maximum, sans virgule ; UTF-8 est autorisé. Cela s’applique aussi à Delete Surfing Quota Policy. Description est facultatif et limité à 255 caractères. La colonne des valeurs par défaut n’indique aucune valeur pour ces champs ; ne pas en déduire une valeur par défaut à l’exécution.
• CycleType apparaît dans le modèle sous la forme Cyclic/NonCyclic ; pour une requête, il faudrait choisir exactement une valeur confirmée, et non l’expression avec la barre oblique. Le tableau des paramètres indique toutefois à la fois le type chaîne de caractères et la plage 1–87840. Ne pas déplacer cette indication de plage contradictoire vers un autre champ ni l’interpréter comme un codage numérique du cycle.
• CycleHours est décrit comme une chaîne de caractères facultative pour les heures du cycle, sans plage numérique. CycleMinutes est décrit comme un champ obligatoire de type entier comportant au maximum quatre chiffres. Cela ne confirme notamment pas une plage 0–59 pour ce champ. Le modèle contient également PerDay avec Days/Weekly/Monthly/Yearly, mais le tableau des paramètres n’explique pas ce champ. Ne pas convertir sans vérification le réglage Cycle hours de l’interface et la durée du cycle du pilote en valeurs pour ces champs XML.
• Pour une validité limitée, Validity est décrit comme une chaîne de caractères avec une plage de 0–3660 jours. MaximumHours décrit un total limité d’heures de navigation sous forme de chaîne de caractères comportant au maximum sept caractères ; Minutes est la valeur supplémentaire en minutes, sous forme de chaîne de caractères dans la plage 0–59. La validité en jours et le temps consommable en heures/minutes restent des limites distinctes ; la validité n’est pas un crédit de temps.

Un extrait de champs pour des valeurs limitées, qui n’est expressément ni une requête complète ni une requête prête à être envoyée, illustre cette dernière distinction :

<Validity>7</Validity>
<MaximumHours>2</MaximumHours>
<Minutes>0</Minutes>

Les valeurs de l’exemple correspondent à sept jours de validité et à deux heures de navigation au total, sans minutes supplémentaires. Elles ne montrent pas la mise en œuvre complète du pilote cyclique configuré dans l’interface, « deux heures par 24 heures ». Les champs du cycle, l’attribution et l’opération explicite sont volontairement absents. Les jours et le crédit de temps sont choisis selon l’accord d’utilisation approuvé ; pour la sérialisation complète, comparer d’abord API help du build installé avec un objet pilote relevé par une opération de lecture.

Pour les valeurs illimitées, le modèle affiche pour Validity et MaximumHours le texte Unlimited/{Days} ; des lignes distinctes du tableau pour Validity et Maximum Hours indiquent en revanche -11 et la chaîne vide ''. Cela ne confirme ni que ces notations sont interchangeables, ni que des champs vides conservent les valeurs existantes, ni que Maximum Hours avec une espace est une balise XML. De plus, la description des heures ne correspond pas au paramètre fictif {Days} pour MaximumHours. Tant que la représentation du cycle ou le codage d’Unlimited restent non clarifiés, ne pas envoyer de requête d’écriture et demander une clarification propre au build.

Vérifier les réponses avant une nouvelle tentative d’écriture

Pour Add Surfing Quota Policy, Edit Surfing Quota Policy et Delete Surfing Quota Policy, l’opération, le code XML et le symbole de référence doivent être considérés ensemble. Les références pour SFOS 22.0 et 23.0 contiennent les mêmes correspondances :

Message.* désigne ici des clés littérales non résolues de la référence, et non des messages constatés à l’exécution. Un succès HTTP n’est pas un succès de l’opération XML. Même un code XML 200 ne dispense pas de relire l’objet cible enregistré : le nom, le cycle, la validité, les heures et les minutes doivent correspondre à l’état attendu approuvé. Ce n’est qu’ensuite qu’il faut valider l’attribution et l’effet avec View usage, une nouvelle authentification et le test limité de consommation et de limite décrit dans cet article ; l’enregistrement seul ne prouve pas l’application effective du quota.

En cas de 500, 502, 504, de réponse ambiguë ou de dépassement du délai d’attente, conserver d’abord la réponse expurgée des données sensibles et lire l’état réel de l’objet avant d’envisager toute nouvelle tentative. En cas de 502, vérifier si l’objet souhaité ou un autre objet est déjà enregistré sous le nom exact ; ne pas passer automatiquement d’Add à Edit. Pour Delete avec 504, vérifier les références existantes et les attributions aux utilisateurs et aux groupes, sans supprimer à l’aveugle des règles dépendantes. Avant une suppression approuvée, migrer les attributions de manière contrôlée, vérifier à nouveau les dépendances, puis confirmer que seule la stratégie pilote visée a disparu et que les services précédents fonctionnent toujours. Un code d’erreur ne prouve ni que l’état est resté inchangé ni qu’une répétition est sans risque. Une réinitialisation de l’accounting ne permet pas d’annuler une mise à jour par API ou une suppression.

Créer une Network Traffic Quota

Une Network Traffic Quota comptabilise le volume de données transféré. Elle ne limite pas le débit. Un utilisateur peut donc consommer son crédit rapidement ou lentement ; lorsqu’une limite de bande passante est requise, une stratégie de Traffic Shaping adaptée est planifiée en plus.

Limiter le trafic total ou séparer l’envoi et le téléchargement

• Total network traffic : Un crédit commun comptabilise ensemble l’envoi et le téléchargement.
• Individual network traffic (Upload & download) : L’envoi et le téléchargement reçoivent des limites distinctes. Ce choix ne convient que si le besoin traite réellement les deux directions séparément.

Deux modèles de cycle sont également disponibles :

• Cyclic : Le crédit s’applique à chaque cycle sélectionné. Les périodes disponibles sont Day, Week, Month et Year. Le volume inutilisé n’est pas reporté.
• Non-cyclic : Le crédit s’applique à une seule période de cycle.

Quota per cycle définit le crédit de chaque cycle. Un Maximum quota facultatif ajoute une limite globale et doit être supérieur au quota du cycle. Lorsque la limite du cycle ou la limite globale est épuisée, le pare-feu déconnecte l’utilisateur. Reset user accounting est nécessaire pour le reconnecter avant la réinitialisation normale.

Pour l’exemple pilote :

1. Ouvrir Profiles > Network traffic quota > Add.
2. Définir Name sur Students_DataVolume.
3. Saisir par exemple Pilot: 5000 MB per day, Owner IT dans Description.
4. Définir Restriction sur Total network traffic.
5. Définir Cycle type sur Cyclic.
6. Définir Cycle period sur Day.
7. Définir Quota per cycle sur 5000 MB.
8. Laisser Maximum quota sur Unlimited pour cet exemple récurrent. Si une limite globale est nécessaire, elle doit être supérieure au quota du cycle.
9. Enregistrer avec Save.

Les 5000 MB sont une valeur de saisie pour cet exemple, et non une valeur imposée ou une aide à la conversion. Dans une stratégie réelle, la valeur est dérivée du crédit approuvé et saisie dans l’unité attendue par WebAdmin. Une stratégie séparant l’envoi et le téléchargement reçoit plutôt des valeurs propres et justifiées pour chaque direction.

Des stratégies Network Traffic par défaut sont également disponibles ; ouvrir les stratégies existantes avec Edit. Pour un Maximum quota fini, décocher la case Unlimited correspondante et saisir une valeur supérieure au quota du cycle. Après l’enregistrement, rouvrir et vérifier les valeurs ; ne pas modifier une stratégie de production partagée pour un test pilote.

Attribuer les quotas à un groupe ou à un utilisateur

Utiliser un groupe comme méthode d’exploitation normale

Pour des utilisateurs ayant le même crédit, une stratégie de groupe est plus facile à exploiter qu’un grand nombre de valeurs individuelles :

1. Ouvrir Authentication > Groups.
2. Créer le groupe Quota_Pilot ou modifier un groupe pilote clairement délimité.
3. Sélectionner Students_InternetTime pour Surfing quota.
4. Sélectionner Students_DataVolume pour Network traffic.
5. Ne pas modifier au passage d’autres valeurs d’Access Time, de Traffic Shaping, de Remote Access ou de portail.
6. Enregistrer.
7. Authentifier à nouveau l’utilisateur pilote et vérifier le groupe réellement utilisé.

Gérer les groupes d’utilisateurs Sophos Firewall en sécurité explique l’interaction entre les groupes locaux et importés, le groupe principal et les exceptions utilisateur. L’importation AD proprement dite reste décrite dans Connecter Active Directory à Sophos Firewall.

Vérifier ensemble la dérogation utilisateur et la sélection dans la règle

Sous Authentication > Users, Surfing quota et Network traffic peuvent être définis différemment pour un utilisateur individuel. Toutefois, la documentation décrit la priorité différemment : le guide de création d’utilisateurs donne généralement priorité à la stratégie de l’utilisateur, tandis que la vue d’ensemble des utilisateurs la fait dépendre de la sélection dans les règles et stratégies. Elle indique les valeurs du groupe lorsque seul le groupe est sélectionné, et celles de l’utilisateur lorsque l’utilisateur et son groupe sont sélectionnés. Il ne faut donc pas supposer qu’une dérogation s’applique sans condition.

Pour le pilote, documenter la sélection réelle des utilisateurs et groupes dans la règle ou stratégie concernée ainsi que les deux valeurs de quota. Avec une nouvelle connexion, View usage et un flux de test limité, déterminer quelle valeur s’applique sur ce build et ce chemin. Si l’affichage et la limite attendue ne concordent pas, arrêter le déploiement ; ne pas élargir une règle de production ni réordonner les groupes comme correctif rapide. Rétablir ensuite les attributions et la sélection précédentes, puis vérifier de nouveau.

Si une modification de groupe n’agit pas sur un utilisateur, contrôler d’abord son objet utilisateur. Une dérogation convient à une exception documentée ou à un pilote, mais peut créer avec le temps des cas particuliers cachés. Pour revenir à la stratégie de groupe, rétablir de manière contrôlée l’état d’héritage précédent de l’utilisateur.

Seule la Main Group compte dans Active Directory

Pour les utilisateurs AD, Surfing Quota et Network Traffic n’utilisent pas les Other group memberships. La valeur applicable provient de la Main Group affichée dans le champ Group sous Authentication > Users, ou d’une stratégie explicite attribuée à l’utilisateur.

L’ordre sous Authentication > Groups > Reorder peut modifier la Main Group et donc affecter plusieurs stratégies en même temps. Il ne doit pas être changé comme correctif rapide d’un quota. Après une modification planifiée de groupe, authentifier à nouveau l’utilisateur et vérifier de nouveau la Main Group.

Les Clientless Users sont exclus

Les Clientless Users ne prennent en charge ni Surfing Quota ni Network Traffic. Pour un appareil fixe sans connexion utilisateur, le chemin réseau, le planning et, si nécessaire, le Traffic Shaping sont planifiés dans une règle de pare-feu étroite. Les quotas utilisateur ne servent pas de substitut basé sur l’IP.

Contrôler la consommation et valider la limite

View usage dans WebAdmin

Pour afficher la consommation, Sophos exige une règle de pare-feu basée sur l’utilisateur avec Log firewall traffic activé. Ensuite :

1. Authentifier à nouveau l’utilisateur pilote.
2. Vérifier le nom d’utilisateur et l’adresse source sous Current activities > Live users.
3. Ouvrir Authentication > Users et sélectionner l’utilisateur pilote.
4. Ouvrir View usage.
5. Pour Surfing Quota, contrôler le temps attribué, l’expiration et le temps Internet consommé.
6. Pour Network Traffic, contrôler Cycle renewal, l’envoi, le téléchargement et le quota attribué.
7. Générer un petit transfert de test autorisé et contrôler de nouveau l’évolution.
8. Dans Log Viewer, corréler l’utilisateur, Source, Destination, Service, Firewall Rule ID, Action et l’horodatage.

La vue mensuelle affiche également l’IP source, le début, la fin, la durée, l’envoi et le téléchargement. Une valeur de consommation seule ne prouve toutefois pas que le chemin prévu et la bonne règle ont été utilisés. Il faut donc combiner View usage, Log Viewer et un flux de test réel. Tester proprement une règle Sophos Firewall explique la validation des règles.

Dans View usage, distinguer les différentes sections :

• Policy information : Pour AD, Group affiche uniquement la Main Group. Time allotted to user est le temps de navigation attribué, Surfing quota expiry date sa date d’expiration et Internet usage time la consommation depuis le début ou la dernière réinitialisation. Data transfer cycle renewal indique le renouvellement d’un quota de données récurrent ; les quotas non récurrents affichent N.A..
• Usage information : Upload network traffic et Download network traffic affichent la consommation totale et celle de la session actuelle. Ici, Allotted désigne le quota maximal de données attribué.
• Current cycle usage information : Pour les quotas récurrents, Cycle upload network traffic et Cycle download network traffic concernent uniquement le cycle quotidien, hebdomadaire, mensuel ou annuel en cours. Ici, Allotted désigne le quota du cycle, pas le maximum global. Pour consulter les sessions passées, sélectionner le mois souhaité dans la liste de View usage.

Contrôle par l’utilisateur dans User Portal

La vue utilisateur sous Internet usage doit être distinguée de la vue administrative View usage :

• Policy information affiche le groupe de l’utilisateur, les heures de navigation attribuées, la date d’expiration de la Surfing Quota, la date de renouvellement du cycle de données et le temps Internet déjà consommé. Pour un compte invité, la date d’expiration du compte s’y ajoute ; l’expiration du compte et la consommation du quota répondent à des questions différentes.
• Usage information affiche le quota de données attribué, consommé et restant pour l’envoi et le téléchargement.
• Monthly usage affiche le temps de navigation et les transferts de données mensuels, ce qui permet de retracer la consommation passée plutôt que de consulter uniquement le quota restant actuel.

Tous les utilisateurs ne voient pas tous les champs : le type de compte et les stratégies attribuées déterminent l’affichage. L’absence de date d’expiration de compte invité pour un compte normal ne prouve donc pas une erreur de quota. Cette vue utilisateur sert à contrôler la consommation ; elle ne constitue pas une procédure de modification de la stratégie ou de réinitialisation des compteurs.

Dans User Portal, sous Internet usage, un utilisateur peut contrôler, selon le type de compte et la stratégie, le temps de navigation attribué et consommé, le renouvellement du cycle ainsi que l’envoi, le téléchargement et le crédit restant. Cette visibilité réduit les demandes, mais ne remplace pas la validation administrative de l’attribution, de la Main Group, de la règle et des logs.

Tester la limite de consommation de manière contrôlée

Pour un test de limite, utiliser une stratégie pilote distincte avec un crédit volontairement faible mais suffisant. Le test ne doit toucher aucun groupe de production.

1. Documenter les valeurs initiales dans View usage.
2. Démarrer un flux de test HTTP ou HTTPS clairement limité.
3. Observer la consommation et Log Viewer pendant le test.
4. Confirmer que l’atteinte de la limite provoque la déconnexion attendue.
5. Après la déconnexion, rouvrir View usage et documenter la valeur du compteur et l’heure.
6. Tester le cycle normal suivant ou une réinitialisation explicitement approuvée.
7. Rétablir ensuite la stratégie pilote et l’attribution précédente.

Utiliser Reset user accounting en sécurité

Reset user accounting réinitialise le temps de navigation et la consommation de trafic réseau de l’utilisateur. Lorsqu’une Network Traffic Quota est épuisée, cette réinitialisation est nécessaire si l’utilisateur doit se reconnecter avant le cycle normal suivant. Cette procédure ne permet pas de restaurer les valeurs précédentes des compteurs ; les valeurs relevées auparavant servent de preuve, et non de sauvegarde restaurable.

Une réinitialisation contrôlée se déroule ainsi :

1. Documenter l’utilisateur, le ticket, le motif, les valeurs actuelles des quotas et l’heure.
2. Vérifier s’il est possible d’attendre le changement de cycle normal.
3. S’assurer que le bon utilisateur est sélectionné.
4. Ouvrir l’utilisateur sous Authentication > Users.
5. Ouvrir View usage et conserver les valeurs initiales.
6. Déclencher Reset user accounting uniquement avec l’autorisation prévue.
7. Authentifier à nouveau l’utilisateur et contrôler les nouveaux compteurs.
8. Vérifier un petit flux de test, la Firewall Rule ID et les logs.

La réinitialisation ne corrige ni une Main Group incorrecte, ni une reconnaissance utilisateur absente, ni une stratégie de pare-feu ou web bloquante. Si ces causes ne sont pas clarifiées au préalable, le problème réapparaît malgré la remise à zéro des compteurs.

Délimiter les erreurs systématiquement

Le quota ne semble pas être comptabilisé

Vérifier d’abord sous Current activities > Live users si l’identité et l’adresse source attendues sont visibles. Contrôler ensuite que le trafic correspond à une règle de pare-feu basée sur l’utilisateur avec Log firewall traffic. Si la journalisation manque ou si le flux utilise une autre règle, View usage peut rester incomplet.

Comparer ensuite la stratégie de groupe, la dérogation utilisateur et, pour AD, la Main Group. Le quota n’est pas réduit précipitamment dans le seul but de produire un effet visible.

Le quota de groupe n’agit que sur certains utilisateurs

Ne pas supposer qu’une stratégie explicite de l’utilisateur constitue une dérogation effective sans vérifier la sélection des utilisateurs et groupes. Sous Authentication > Users, vérifier les deux champs de quota et la Main Group, ainsi que la sélection dans la règle ou stratégie réellement utilisée. Pour AD, les Other group memberships ne sont pas évalués. Authentifier à nouveau l’utilisateur après une modification de groupe.

L’utilisateur est déconnecté de manière inattendue

Sous View usage, vérifier si Cycle quota, Maximum quota ou Maximum access time a été atteint. Contrôler ensuite séparément Access Time, Web Policy, la règle de pare-feu et l’authentification. Captive Portal peut également apparaître en raison d’identifiants incorrects ou d’autres problèmes d’authentification ; le quota n’en est pas automatiquement la cause. Configurer et tester Captive Portal sur Sophos Firewall explique le parcours de connexion complet.

La consommation ne correspond pas aux attentes

Vérifier si Total network traffic ou des limites distinctes d’envoi et de téléchargement sont configurées. Comparer ensuite les détails mensuels, l’IP source, la Firewall Rule ID et le transfert de test réel. Une Network Traffic Quota comptabilise le volume de données, pas seulement les téléchargements visibles dans le navigateur ; le trafic en arrière-plan de l’utilisateur authentifié peut aussi contribuer à la consommation.

La réinitialisation n’aide que brièvement

Si l’utilisateur est de nouveau déconnecté peu après la réinitialisation, contrôler les valeurs de la stratégie, le cycle, le maximum, la dérogation utilisateur et la consommation réelle. Le compteur n’est pas réinitialisé à plusieurs reprises avant que la cause soit comprise.

Rollback et exploitation

Un rollback contrôlé rétablit les attributions de stratégies précédentes. Une réinitialisation de l’accounting déjà effectuée reste toutefois en vigueur :

1. Rétablir les attributions Surfing et Network Traffic précédentes pour l’utilisateur ou le groupe pilote.
2. Pour AD, authentifier à nouveau l’utilisateur et vérifier la Main Group.
3. Documenter View usage et la consommation actuelle.
4. Réinitialiser l’accounting de manière contrôlée uniquement si cela a été convenu pour le test.
5. Exécuter un petit flux de test et vérifier la Firewall Rule ID et les logs.
6. Supprimer les stratégies pilotes uniquement lorsqu’aucune dépendance d’utilisateur ou de groupe ne subsiste.
7. Mettre à jour le ticket, l’owner, les limites et le résultat du test.

En exploitation, chaque quota partagé a besoin d’un nom compréhensible, d’une Description, d’un owner et d’une justification documentée pour le cycle, le crédit et la limite globale. Les modifications sont validées avec un utilisateur pilote, un test positif de consommation et un test négatif de limite.

Liste de contrôle opérationnelle

• La consommation de temps et la consommation de données ont été planifiées séparément.
• Surfing Quota et Network Traffic Quota ont des noms et des owners compréhensibles.
• Cycle, Validity, Quota per cycle et Maximum sont justifiés.
• Les stratégies sont attribuées au bon groupe ou au bon utilisateur.
• Les dérogations utilisateur ont été contrôlées.
• Pour AD, la Main Group est correcte ; les Other group memberships ne sont pas supposés.
• Les Clientless Users ne sont pas planifiés avec des quotas utilisateur.
• L’utilisateur pilote apparaît comme Live User.
• La règle de pare-feu basée sur l’utilisateur journalise le trafic de test.
• View usage, User Portal, Firewall Rule ID et la consommation réelle concordent.
• Reset user accounting est utilisé uniquement avec documentation et autorisation.
• L’état précédent et le rollback sont documentés.

Questions fréquentes