Remplacer l'ancien balisage VLAN avant SFOS 22 MR2

Les interfaces bridge de Sophos Firewall sont utiles pour conserver la transparence d’un réseau de couche 2 existant ou effectuer une migration sans modifier immédiatement les adresses IP. Si des balises VLAN ont auparavant été configurées sur un bridge avec system vlan-tag, remplacez-les par des interfaces VLAN dans WebAdmin avant de passer à SFOS 22.0 MR2 ou à une version ultérieure. Il ne s’agit pas d’une modification purement esthétique : sous GA et MR1, le trafic destiné au pare-feu ou généré par celui-ci peut échouer, et à partir de MR2 cette ancienne configuration bloque la mise à niveau.

Le problème NC-181672 concerne les interfaces bridge avec des configurations CLI VLAN tag sous SFOS 22.0 GA et MR1 : le trafic VLAN tagué provenant de Sophos Firewall ou qui lui est destiné n’est pas traité correctement. Cela peut affecter Active Directory, DNS, Device Access, STAS, LDAP, RADIUS ou l’accès à la gestion, même si le trafic normal est acheminé via le bridge.

Cet ancien balisage VLAN par CLI est obsolète : il bloque la mise à niveau vers SFOS 22.0 MR2 ou une version ultérieure, et une sauvegarde qui le contient ne peut pas être restaurée sous SFOS 22.0 GA ou ultérieur. Effectuez donc cette vérification avant la mise à niveau et avant de créer la sauvegarde qui lui est destinée. Le contrôle de mise à niveau SFOS 22 documente la version cible vérifiée MR2 Build 546, son chemin de mise à niveau et d’autres blocages propres à la version. Si un autre build cible est prévu, ce contrôle interne doit être actualisé avant le changement ; les données de MR2 ne doivent pas être transposées sans vérification.

Cet article n’est pas un chapitre général sur les VLAN. Pour planifier les zones, les interfaces, les VLAN, les bridges et les LAG, commencer par Configurer les zones et les interfaces sur Sophos Firewall. La procédure normale de configuration, de sécurisation et de validation est décrite dans Configurer une interface bridge sur Sophos Firewall. Cet article traite spécifiquement du cas particulier des VLAN sur bridge après SFOS 22.

Quand ce sujet est pertinent

Le contrôle prend tout son sens lorsque plusieurs points se rejoignent :

• Le pare-feu fonctionne sur SFOS 22.0 GA ou SFOS 22.0 MR1.
• Il existe une interface pont, par exemple br0.
• Les VLAN ont été historiquement construits à l’aide d’une configuration de balise CLI VLAN comme system vlan-tag ou ont été repris à partir d’une ancienne configuration.
• Les services de pare-feu eux-mêmes doivent atteindre un VLAN balisé.
• Après une mise à niveau, AD, les accès DNS, authentification, surveillance ou gestion ne fonctionnent que partiellement.
• Une mise à niveau vers SFOS 22.0 MR2 ou une version ultérieure est prévue ou bloquée par le legacy CLI VLAN tagging.
• Le trafic client normal via le pont semble toujours fonctionner.

Le dernier point est important : si le pont continue à acheminer le trafic entre les réseaux, le problème ne semblera pas initialement être une défaillance du pont. En pratique, il est facile de chercher au mauvais endroit, comme dans les règles de pare-feu, DNS, STAS ou le contrôleur de domaine.

Comprendre le sens de circulation affecté

Il faut clairement séparer trois types de trafic.

Les types de trafic diffèrent considérablement :

• Trafic transitant par le pont : Un client dans VLAN 100 parle à un serveur dans VLAN 100. Cela peut toujours fonctionner, mais ne prouve pas que le trafic vers le pare-feu fonctionne.
• Trafic vers le pare-feu : Un client utilise le pare-feu comme serveur DNS ou destination WebAdmin. C’est précisément ce trafic qui peut être affecté car il aboutit au pare-feu.
• Trafic du pare-feu : Le pare-feu interroge les destinations AD, DNS, LDAP, RADIUS, NTP ou Syslog. Ceci est également essentiel car le pare-feu lui-même est l’expéditeur.

Si une seule application est testée entre deux hôtes, l’erreur ne peut pas être identifiée avec certitude. Le test doit volontairement inclure un service qui se termine sur le Sophos Firewall ou qui est créé par le pare-feu.

Symptômes typiques

Les signes possibles sont :

• Les règles basées sur l’utilisateur ne fonctionnent plus de manière fiable car AD, STAS ou LDAP ne peuvent pas être atteints de manière stable.
• Les requêtes DNS adressées au pare-feu échouent à partir de VLAN individuels.
• Ping ou HTTPS sur les services de pare-feu locaux ne fonctionnent pas à partir d’un VLAN, même si les règles de pare-feu semblent plausibles.
• La surveillance ou Syslog apparaît incomplète si le pare-feu doit atteindre une cible dans un VLAN balisé.
• Packet Capture indique que le trafic entre les systèmes finaux est visible, mais que les services de pare-feu eux-mêmes ne répondent pas comme prévu.
• Après une mise à niveau SFOS-22, les symptômes apparaissent sans rien changer consciemment sur les règles du switch ou du pare-feu.

De tels symptômes ne doivent pas être immédiatement traités par des règles d’autorisation générales ou des autorisations Device Access trop larges. Tout d’abord, il doit être clair si la conception de l’interface elle-même est affectée.

Démarcation rapide avant conversion

Avant de déplacer l’adresse IP d’un pont ou de créer de nouvelles interfaces VLAN sur le pont, vous devez en déterminer la cause. Tous les problèmes après une mise à niveau ne correspondent pas automatiquement au cas SFOS-22-Bridge-VLAN.

Classement pratique :

• Une seule application entre deux hôtes ne fonctionne pas : Il est plus probable qu’il s’agisse d’une règle de pare-feu, NAT, du système cible ou du chemin de retour. Tout d’abord tester la règle de pare-feu et, en cas de rejet, analyser les paquets rejetés.
• WebAdmin, DNS ou ping vers le pare-feu depuis un VLAN ne fonctionne pas : Vérifiez Device Access, la zone, le service local et le cas particulier des VLAN sur bridge. Testez ensuite le trafic vers le pare-feu séparément.
• Le pare-feu n’atteint pas AD, LDAP, RADIUS, DNS ou Syslog en VLAN : Vérifiez le trafic généré par le pare-feu, le routage, le DNS et le cas particulier des VLAN sur bridge. Utilisez les tests directement à partir de la configuration du pare-feu et des journaux de service appropriés.
• Le trafic client normal est en cours d’exécution, mais les services du pare-feu lui-même ne le sont pas : Le cas particulier du pont VLAN devient plus probable. Vérifiez la conception du pont, l’ancienne configuration des balises CLI VLAN et l’interface VLAN pour le pont.
• Il n’y a aucune entrée de journal correspondante : Vérifiez la journalisation, les filtres, le service local et le cas particulier des rejets non journalisés liés au bridge ou à NAT. Combinez Log Viewer, Packet Capture et les Sophos Firewall journaux de service.

Pour les problèmes DNS, il faut également vérifier si les clients utilisent le pare-feu comme résolveur ou si le pare-feu utilise lui-même des DNS Request Routes vers des serveurs internes. Le deuxième cas concerne le trafic provenant du pare-feu et peut apparaître différent du trafic client normal pour les problèmes Bridge VLAN. Les bases se trouvent dans Configuration des routes de requêtes DNS sur Sophos Firewall.

Si la démarcation rapide pointe clairement vers les services de pare-feu locaux ou le trafic généré par le pare-feu, la conversion doit quand même être planifiée. Une correction de pont sans sauvegarde, fenêtre de maintenance et chemin d’accès alternatif est trop risquée pour les réseaux productifs.

Documenter la configuration existante

Avant d’apporter des modifications, vous devez documenter l’état actuel. Sont particulièrement importants :

• Nom de l’interface du pont, par exemple br0.
• Membres du pont, c’est-à-dire les interfaces physiques participantes, les VLAN, les interfaces RED ou les LAG.
• Adresse IP du pont, si disponible.
• VLAN ID qui passent sur le pont.
• Profil de port du switch : Tagged VLAN, Native VLAN, Trunk ou port d’accès.
• Services se terminant sur le pare-feu : DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
• Services que le pare-feu doit atteindre : AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, Monitoring.

Si la structure provient d’une ancienne migration, vous devez également vérifier si les VLAN ont été configurés via la configuration CLI. C’est précisément cet héritage qui est souvent oublié lorsque le pare-feu n’a été mis à jour qu’au fil des années.

⚠️ Vous ne devez pas expérimenter spontanément les interfaces de pont et les VLAN lors des opérations quotidiennes. Une modification incorrecte peut affecter l’accès à la gestion, le DNS, l’authentification ou des réseaux clients entiers. Avant la correction, une sauvegarde, une fenêtre de maintenance et un chemin d’accès alternatif sont requis.

Pièges spécifiques aux bridges avant la correction

Trois restrictions liées aux bridges doivent être vérifiées attentivement avant le changement.

Premièrement : un bridge sans adresse IP peut supprimer du trafic si ce trafic correspond à une règle de pare-feu avec filtrage web proxy ou à une règle NAT. Ces suppressions ne sont pas journalisées. Si une règle NAT reste nécessaire, elle doit être limitée de façon que la traduction source pour le bridge sans adresse IP reste sur Original. Sinon, on risque de chercher dans Log Viewer une suppression qui n’y apparaît jamais.

Deuxièmement : le VLAN filtering sur le bridge s’applique uniquement au trafic bridgé, pas au trafic routé. Si Filter VLANs est activé, mais qu’aucun VLAN ID autorisé n’est saisi, le trafic tagué de tous les VLANs est supprimé ; le trafic non tagué n’est pas concerné. Pendant les tests, cela peut ressembler à un problème VLAN incohérent.

Troisièmement : les interfaces bridge ne remplacent pas tous les designs. Des restrictions s’appliquent à Dynamic DNS, DHCP client, PPPoE et IPsec VPN. Si l’une de ces fonctions fait partie du design cible, il ne faut pas appliquer le workaround bridge de manière isolée ; le design des interfaces doit être réévalué.

Créer des interfaces VLAN prises en charge

Le workaround pris en charge consiste à créer des interfaces VLAN dans Network > Interfaces avec le bridge comme parent. Les interfaces physiques, RED, bridge et LAG sont des parents autorisés.

Avant SFOS 18.0, system vlan-tag était nécessaire pour activer les communications VLAN taguées sur les interfaces bridge. Depuis SFOS 18.0, VLAN-over-bridge est entièrement disponible dans WebAdmin. Une limite importante doit toutefois être prise en compte pour l’inventaire et le nettoyage : la documentation des balises VLAN pour SFOS 22 et 23 décrit un reset avec des arguments d’interface tout en le présentant comme un affichage de la configuration. Cela ne permet de déduire ni qu’un system vlan-tag show autonome constitue une requête sans modification, ni que system vlan-tag reset sans arguments est une commande de nettoyage dont le périmètre est connu. La disponibilité d’une commande dans un contexte CLI ne confirme pas non plus ces propriétés.

Avant toute action CLI d’inventaire ou de nettoyage, une documentation explicite pour le build installé ou Sophos Support doit confirmer la méthode exacte permettant d’établir l’inventaire sans modifier la configuration et la syntaxe de nettoyage applicable. Cette confirmation doit couvrir le contexte CLI exact, les privilèges et arguments requis, les interfaces ou nœuds concernés, ainsi que les effets et le périmètre du nettoyage. Si ces points ne sont pas clarifiés, documentez uniquement l’inventaire visible dans WebAdmin sous Network > Interfaces et arrêtez-vous avant tout nettoyage ou toute mise à niveau. L’absence d’entrées dans WebAdmin ne prouve pas qu’aucune ancienne balise CLI n’existe ; clarifiez cette question d’inventaire avec Sophos Support plutôt que d’essayer une commande supposée d’affichage ou de reset.

Les conceptions nouvelles ou corrigées ne doivent plus s’appuyer sur system vlan-tag. Si de telles balises CLI existent encore, il faut les documenter, les migrer vers des interfaces VLAN dans WebAdmin, puis seulement poursuivre la mise à niveau du firmware. Cela réduit à la fois le cas particulier du pont SFOS 22 et les blocages de mise à niveau ultérieurs.

Exemples :

• VLAN 100 : br0.100
• VLAN 200 : br0.200

Lors de la création du VLAN dans WebAdmin, trois champs sont décisifs : Interface doit être le bridge, Zone doit correspondre à l’objectif de sécurité du VLAN et VLAN ID doit être unique. WebAdmin accepte les IDs VLAN de 1 à 4094 ; le même VLAN ID ne doit pas être planifié plusieurs fois sur le même parent interface.

Le processus dépend du fait que le pont lui-même possède déjà une adresse IP.

Si le pont n’a pas besoin d’une adresse IP

Si le pont est uniquement censé transmettre de manière transparente, il peut être utilisé sans sa propre adresse IP. L’adresse IP du VLAN concerné se trouve alors sur l’interface VLAN, par exemple br0.100.

Processus pratique :

1. Exportez une sauvegarde à titre documentaire, mais ne comptez pas sur sa restauration pour revenir en arrière sous SFOS 22.
2. Documentez le pont actuel et la configuration VLAN.
3. Dans Network > Interfaces, choisir Add interface > Add VLAN.
4. Sélectionnez le pont comme interface parent, par exemple br0.
5. Saisissez l’ID VLAN.
6. Choisissez consciemment votre zone.
7. Définissez l’adresse IP sur l’interface VLAN si le pare-feu doit servir de passerelle ou fournir un service local dans ce VLAN.
8. Vérifiez Device Access pour la zone.
9. Vérifiez les règles de pare-feu et les règles NAT.
10. Validez la modification avec un client de test et ne créez une nouvelle sauvegarde qu’après la réussite des tests.

La zone n’est pas seulement un ordre dans le WebAdmin. Cette décision affecte les règles de pare-feu, Device Access, les journaux et de nombreuses étapes de dépannage ultérieures. Si un VLAN est destiné à être un réseau de gestion, de serveur ou de client, celui-ci doit être visible dans la zone.

Si le bridge avait auparavant l’adresse IP de production

Si le pont utilise actuellement l’adresse IP, qui devra être accessible dans VLAN à l’avenir, vous devez être particulièrement prudent. Il existe deux variantes propres pour la conversion : le pont reçoit une adresse IP différente, ou le pont reste sans adresse IP. L’adresse productive précédente est alors attribuée à l’interface VLAN.

C’est un changement avec un risque d’échec. Il convient de préciser au préalable :

• Quelle adresse est utilisée pour joindre WebAdmin ?
• Quels clients utilisent le pare-feu comme passerelle par défaut ?
• Quels paramètres DNS ou DHCP pointent vers cette adresse ?
• Quelles règles d’accès aux appareils s’appliquent à la zone précédente ?
• Existe-t-il un deuxième accès de gestion depuis un réseau non concerné ?

Pour les sites éloignés, ce changement ne doit pas être planifié sans un chemin de retour local. Si WebAdmin et SSH passent exactement par l’adresse IP du pont concerné, une erreur peut interrompre l’accès administratif.

Supprimer l’ancienne configuration et préparer la mise à niveau

L’ordre des opérations est déterminant : après avoir obtenu les confirmations décrites ci-dessus, créez d’abord toutes les interfaces VLAN nécessaires dans Network > Interfaces, avec le bridge comme Parent Interface, déplacez si nécessaire l’adresse IP actuelle du bridge vers l’interface VLAN appropriée et vérifiez les nouveaux chemins de trafic et de gestion. Dans un environnement HA, vérifiez au préalable, à l’aide de l’affichage d’état pris en charge, que le pair et la synchronisation ne présentent aucune erreur, et sauvegardez chaque nœud dans la mesure prévue par la plateforme et les procédures de support. Si l’état du pair ou de la synchronisation présente une erreur ou reste incertain, arrêtez-vous avant le nettoyage ou la mise à niveau et faites remonter le problème. N’inventez aucune commande HA ou de synchronisation.

L’ancien paramètre ne peut être supprimé qu’une fois la correspondance documentée, un accès alternatif actif et tous les prérequis HA satisfaits, au moyen de la procédure confirmée pour le build installé par la documentation ou par Sophos Support. La confirmation de la syntaxe exacte, du contexte CLI, des effets et du périmètre des interfaces et des nœuds concernés doit être obtenue avant l’exécution ; cet article n’autorise pas l’exécution d’une commande de reset sans ces réserves. Sans cette confirmation, limitez-vous à l’inventaire WebAdmin et arrêtez-vous avant le nettoyage ou la mise à niveau.

Vérifiez ensuite de manière ciblée, avec la méthode d’inventaire préalablement confirmée comme n’apportant aucune modification, que l’ancien paramètre a été supprimé dans le périmètre prévu. Les tests de trafic seuls ne le prouvent pas. Si une ancienne configuration reste visible, si le nettoyage échoue ou si l’inventaire n’est pas sans ambiguïté, arrêtez la procédure : ne lancez pas encore la mise à niveau et ne validez pas la nouvelle sauvegarde comme point de restauration nettoyé. Conservez les éléments attestant l’inventaire, les éventuelles sorties de commandes, le contrôle préalable à la mise à niveau et la configuration actuelle, puis faites remonter le problème à Sophos Support ; n’essayez aucune commande CLI non documentée.

La description contradictoire du reset ne permet pas non plus de déduire une procédure fiable de retour arrière au niveau des commandes. La réussite des contrôles d’inventaire et des tests de trafic confirme le nettoyage, pas la possibilité de revenir en arrière. Après le nettoyage, ne recréez pas l’ancien paramètre avec une commande devinée. Si le changement doit être annulé, arrêtez-vous et sollicitez Sophos Support pour une restauration approuvée par le fabricant sur le firmware d’origine pris en charge ; n’annulez les modifications WebAdmin que dans le cadre de ce plan approuvé.

Si les tests de validation et la nouvelle vérification de l’inventaire réussissent, créez une nouvelle sauvegarde, répétez le contrôle préalable à la mise à niveau, puis seulement passez à SFOS 22.0 MR2 ou à une version ultérieure. Pour obtenir un état restaurable à l’avenir, la même procédure de nettoyage confirmée s’applique : supprimez l’ancien paramètre sur le pare-feu source, créez si nécessaire une interface VLAN avec le bridge comme parent, vérifiez le résultat, puis seulement créez une nouvelle sauvegarde. Cela ne répare pas une ancienne sauvegarde contenant system vlan-tag.

Vérifier ensuite Device Access et les règles de pare-feu

Après avoir créé l’interface VLAN, il ne suffit pas de simplement tester l’adresse IP. Device Access et les règles de pare-feu doivent correspondre à la nouvelle conception de l’interface et de la zone.

Pour vérifier :

• Administration > Device access : les services Ping/Ping6, DNS, HTTPS, SSH, User Portal et VPN Portal sont-ils autorisés uniquement dans les zones appropriées ?
• Rules and policies > Firewall rules : Y a-t-il des règles pour la nouvelle zone ?
• Rules and policies > NAT rules : le trafic est-il traduit de manière inattendue ?
• Network > DNS ou routes de requête DNS : le pare-feu atteint-il les bons serveurs DNS ou AD ?
• Authentication > Servers : AD, LDAP ou RADIUS sont-ils accessibles après le changement ? Pour les services de pare-feu locaux, Device Access configurer en toute sécurité Sophos Firewall est l’article approfondi approprié. Sophos Firewall Tester la règle avec Log Viewer et Packet Capture facilite l’analyse des règles.

Validation après correction

Un test propre doit contenir plus d’un ping.

Test du VLAN concerné

Vérifiez auprès d’un client dans le VLAN concerné :

1. Vérifiez que la passerelle par défaut est joignable.
2. Testez par ping l’adresse IP du pare-feu sur la nouvelle interface VLAN, si cela est autorisé.
3. Testez DNS par rapport au pare-feu si le pare-feu sert de résolveur DNS.
4. Testez WebAdmin ou le portail uniquement à partir des réseaux de gestion autorisés.
5. Vérifiez une application typique ou une connexion au serveur.
6. Vérifiez Log Viewer pour faire correspondre l’ID de règle et la zone.

Test depuis le pare-feu

Des tests distincts sont requis pour le trafic généré par le pare-feu lui-même :

• Testez les serveurs AD ou LDAP dans Authentication > Servers.
• Vérifiez la résolution DNS via le pare-feu.
• Vérifiez NTP, Syslog ou la cible de surveillance si ces services sont en VLAN.
• Sous Diagnostics > Packet capture, vérifiez l’interface VLAN. Generated identifie les paquets créés par le pare-feu et Consumed ceux qui lui sont destinés ; comparez aussi In interface, Out interface, Rule ID, Status et Reason.

Si STAS ou les règles basées sur l’utilisateur sont affectées, Configurer STAS sur Sophos Firewall doit également être consulté. Pour les mises à niveau SFOS-22, ce point appartient également au SFOS 22 Upgrade Check.

Retour arrière et clôture

Avant le changement, consignez l’adresse IP actuelle du bridge, la zone, les VLAN IDs, la configuration des ports du switch ainsi que les règles et services dépendants. Un accès de gestion alternatif ou local et un plan de restauration approuvé par le fabricant sont également nécessaires. Tant que le nettoyage CLI confirmé n’a pas été exécuté, les modifications WebAdmin prévues peuvent être annulées dans l’ordre documenté : retirez d’abord l’adresse IP déplacée de la nouvelle interface VLAN, puis seulement réattribuez-la au bridge ; rétablissez ensuite la zone, les règles, Device Access et le profil du port du switch, puis vérifiez l’accessibilité de la gestion et de la passerelle. Cela n’annule pas un nettoyage CLI.

La description contradictoire du reset ne prouve pas qu’une annulation soit possible au niveau des commandes. Si les tests de validation échouent après le nettoyage confirmé, arrêtez-vous et ne recréez pas l’ancien paramètre. Faites remonter le problème pour obtenir une restauration approuvée par le fabricant sur le firmware d’origine pris en charge. En HA, ne nettoyez ni ne mettez à niveau aucun nœud tant que l’état du pair ou de la synchronisation présente une erreur ou reste incertain ; conservez la sauvegarde requise de chaque nœud. Sans la confirmation préalable requise de la méthode d’inventaire, de la syntaxe de nettoyage, du contexte, des effets et du périmètre, limitez-vous à l’inventaire WebAdmin et arrêtez-vous avant le nettoyage ou la mise à niveau.

Après la réussite des tests de validation, créez une nouvelle sauvegarde. L’ancienne sauvegarde contenant le balisage VLAN hérité configuré par CLI ne constitue pas une solution de retour arrière pour SFOS 22.0 GA ou une version ultérieure. Si l’ancienne configuration subsiste malgré la migration WebAdmin ou si le contrôle préalable à la mise à niveau la signale encore, n’expérimentez pas d’autres modifications CLI : conservez la configuration et le message, puis sollicitez Sophos Support.

Erreurs courantes

Pièges typiques :

• Tester le trafic client-serveur uniquement : Le pont semble sain, bien que les services de pare-feu locaux soient affectés. Testez également le trafic vers et depuis le pare-feu.
• Déplacer l’adresse IP du pont sans plan : WebAdmin, DNS ou Gateway peuvent échouer. Préparez la sauvegarde, les fenêtres de maintenance et les accès alternatifs.
• Zone incorrecte pour la nouvelle interface VLAN : Les règles, Device Access et les journaux ne correspondent pas. Choisissez une zone en fonction de raisons de sécurité et non d’habitude.
• Autorisations Device Access trop larges : Le problème semble résolu, mais les services de gestion sont inutilement accessibles. Planifiez une Local Service ACL ciblée.
• Port du commutateur non vérifié : le VLAN arrive incorrectement ou sans tag. Validez le profil Tagged/Untagged, Native VLAN et Trunk.
• Ignorer l’ancienne configuration CLI : L’erreur reste inexpliquée après la mise à niveau. Documentez l’ancienne conception et migrez vers les interfaces WebAdmin-VLAN.

Liste de contrôle

• Version SFOS et pertinence des problèmes connus vérifiées.
• Interface du pont, membres du pont et identifiants VLAN documentés.
• Clarification si l’ancienne configuration de balise CLI VLAN était utilisée.
• Suppressions spécifiques au bridge via NAT/web proxy et VLAN filtering vérifiées.
• Mise à niveau prévue vers SFOS 22.0 MR2 ou une version ultérieure vérifiée par rapport aux legacy CLI VLAN tags.
• Services concernés vers et depuis le pare-feu identifiés.
• Sauvegarde de chaque nœud concerné et accès de gestion alternatif disponibles ; pair et synchronisation HA sains.
• Interface VLAN prévue avec bridge comme interface parent.
• Zone, Device Access, règles de pare-feu et règles NAT vérifiées.
• Tests effectués depuis le VLAN et depuis le pare-feu.
• Méthode d’inventaire sans modification ainsi que syntaxe exacte de nettoyage, contexte CLI, effets et périmètre confirmés pour le build installé par la documentation ou par Sophos Support avant toute action CLI ; à défaut, inventaire WebAdmin uniquement et arrêt avant le nettoyage ou la mise à niveau.
• Limite de restauration documentée : aucune procédure de retour arrière au niveau des commandes ne peut être déduite de la description contradictoire du reset ; nouvelle sauvegarde créée après le nettoyage confirmé et la réussite des tests de validation.
• Résultat enregistré dans le journal des modifications ou dans la documentation réseau.

FAQ