Sauvegarder les journaux de Sophos Firewall pour le support et l'analyse

En cas de dysfonctionnements, de problèmes VPN ou d’événements de pare-feu peu clairs, des captures d’écran individuelles de l’interface Web ne suffisent souvent pas. Pour une analyse approfondie, un cas de support nécessite des indications temporelles traçables, des fichiers journaux appropriés et parfois en plus une capture de paquets.

Le parcours officiel de téléchargement et de diagnostic s’applique à SFOS 22 et SFOS 23. Les archives manuelles complémentaires restent une méthode d’analyse distincte, et non un export standard confirmé pour les deux versions. Ce guide décrit le chemin officiel via Diagnostics > Tools et le distingue du chemin complémentaire des journaux bruts via l’Advanced Shell. Pour Sophos Support, le Consolidated Troubleshooting Report (CTR) est généralement le meilleur point de départ, car il regroupe les fichiers journaux et un instantané système dans une archive chiffrée. Une archive /log créée manuellement reste utile pour obtenir des journaux bruts complets, des données IPsec supplémentaires ou effectuer une analyse interne. Il ne s’agit toutefois ni d’un CTR chiffré ni de l’export standard documenté par Sophos.

Cette procédure ne remplace pas la première délimitation dans le Log Viewer. Si le module concerné n’est pas encore clair, l’aperçu Dépannage de Sophos Firewall : Services et journaux est d’abord utile.

Délimiter d’abord le cas de support

Une archive volumineuse n’est pas automatiquement un bon dossier de support. Il faut d’abord déterminer quel test a échoué, à quel moment et quel composant est probablement concerné.

Analyser d’abord ou déjà collecter les données ?

Selon le type de problème, une autre entrée peut être plus rapide :

• Quelle règle, règle NAT ou route concerne une tentative de connexion spécifique ?: Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture.
• Quel fichier journal local appartient au VPN, au Web, à l’IPS, à l’interface graphique ou aux services système ?: Dépannage de Sophos Firewall : Services et journaux.
• Le problème est connu et les données doivent être transmises : suivre cet article pour créer un CTR, des logs ciblés ou une archive de logs bruts.

Pour les rapports historiques ou les événements récurrents, utiliser Central Firewall Reporting. La conservation et la corrélation à long terme nécessitent Syslog ou SIEM. Une archive de support ponctuelle ne remplace aucune de ces solutions.

Choisir les données selon le type de problème

Tous les problèmes ne nécessitent pas immédiatement une archive de journaux complète. Plus le problème est clairement délimité, plus les données seront petites et utiles.

• Une règle de pare-feu ou une règle NAT s’applique de manière inattendue: Heure, IP source, IP de destination, ID de règle, ID NAT, exportation du Log Viewer et, si nécessaire, Packet Capture.
• Un service ne démarre pas ou WebAdmin affiche une erreur: Consolidated Troubleshooting Report, service concerné, heure et dernière étape de configuration.
• Le tunnel IPsec ne s’établit pas ou se déconnecte : archive de journaux normale, données de diagnostic IPsec, IP du pair, réseaux locaux et distants, moment de la tentative de connexion.
• Le trafic n’atteint pas la destination: Log Viewer, Packet Capture ou pour des analyses plus longues tcpdump-PCAP.
• Problème après un changement de configuration: Audit Trail, moment approximatif du changement, administrateur impliqué, objets concernés et CTR si nécessaire.

Pour de nombreux tickets, la combinaison du moment du problème, d’une brève description de l’erreur, d’une archive de journaux et d’une preuve supplémentaire ciblée est meilleure qu’un ensemble de données très large sans contexte. Lorsqu’un ticket officiel Sophos est créé, il est également utile de consulter Ouvrir un ticket de support Sophos : Préparation et portail.

Prérequis

Pour ce guide, vous aurez besoin de :

• Accès administratif au Sophos Firewall
• Accès à Diagnostics > Tools dans WebAdmin
• Pour les archives de journaux bruts, accès supplémentaire à l’Advanced Shell
• Un serveur cible, un portail de support ou une autre possibilité sécurisée pour transférer les archives
• Suffisamment d’espace libre sur le pare-feu pour les archives temporaires

Les commandes CLI sont exécutées directement sur le pare-feu. Il est donc important de travailler avec soin et de ne pas supprimer de fichiers sans savoir à quoi ils servent.

Si l’accès au Shell n’est pas encore configuré, le guide Connecter Sophos Firewall via SSH explique comment établir une connexion SSH au pare-feu.

⚠️ Les archives de journaux et les fichiers PCAP peuvent contenir des informations sensibles. Ces fichiers ne doivent être conservés que brièvement sur le pare-feu, être transférés en toute sécurité et supprimés après une transmission réussie.

Collecter les journaux

Selon le cas de support, un téléchargement WebAdmin ciblé, un CTR ou une archive de journaux bruts depuis l’Advanced Shell peut suffire. La procédure doit commencer par le plus petit jeu de données qui explique encore correctement l’erreur.

La conservation locale des journaux est limitée par l’espace alloué à chaque sous-système et par le modèle du pare-feu. Lorsqu’un fichier journal atteint sa limite de taille, il est compressé avec gzip ; lorsque le sous-système atteint sa limite de stockage, les rotations .gz les plus anciennes sont supprimées en premier. Si le pare-feu ne répond plus, les données de journal encore en RAM et non écrites dans le système de fichiers peuvent également être perdues. Il faut donc sauvegarder les journaux pertinents dès que possible : un export ne contient que les données encore disponibles et ne permet pas de récupérer les entrées perdues.

Les journaux de diagnostic sont stockés sur la partition /var et lus via /log. Les composants critiques reçoivent davantage d’espace ; deux rotations compressées ou plus sont conservées selon le sous-système. Après la rotation, le pare-feu continue d’écrire sous le nom initial. Sur une XGS Appliance, l’historique disponible dépend donc aussi du modèle et du service, et non d’une durée uniforme de conservation.

Chemin standard : créer un CTR dans WebAdmin

Pour de nombreux cas de support, il faut d’abord créer le Consolidated Troubleshooting Report. Le CTR contient un instantané système et des fichiers journaux dans une archive chiffrée. Sophos Support peut analyser directement cette archive dans le cas de support.

Pour créer le CTR :

1. Reproduire si possible l’erreur et noter l’heure exacte.
2. Dans WebAdmin, ouvrir Diagnostics > Tools.
3. Sous Consolidated troubleshooting report, sélectionner les options nécessaires.
4. Pour un cas de support large, activer System snapshot et All log files.
5. Indiquer un motif court, par exemple numéro de ticket, symptôme et fenêtre temporelle.
6. Sélectionner Generate.
7. Après la création, sélectionner Download.
8. Mettre le fichier à disposition via le portail de support, l’upload sécurisé convenu ou le chemin d’analyse interne.

System snapshot ne nécessite pas le mode debug et enregistre l’état actuel du système, notamment les processus actifs et l’utilisation des ressources. Le nom documenté est CTR_<APPKEY>_<MM_DD_YY>_<HH_MM_SS> : APPKEY est le numéro de série du pare-feu ; les autres champs indiquent la date de création en mois/jour/année et l’heure en heure/minute/seconde. Le nom du fichier lui-même est donc confidentiel. C’est pratique lorsque plusieurs pare-feux ou plusieurs essais aboutissent dans un même ticket.

La limite de lignes concerne uniquement les Service subsystem logs ; les Default subsystem logs sont inclus intégralement, dans la mesure où les données restent disponibles. Ne pas vérifier un CTR chiffré avec la commande tar -tzf présentée plus loin : contrôler la fin du téléchargement, une taille plausible, l’appareil et l’heure du test, puis joindre le fichier de manière sécurisée au dossier de support. Le déchiffrement et la vérification du contenu n’ont pas été testés ici. Si la génération ou le téléchargement échoue, documenter l’erreur et sauvegarder d’abord les journaux individuels concernés, plutôt que de supprimer des journaux.

⚠️ Le CTR n’est pas la même chose qu’un dump complet de données brutes. Les logs des sous-systèmes de service contiennent au maximum 10 000 lignes par défaut ; cette limite ne s’applique qu’au CTR. Pour obtenir des logs bruts plus anciens ou complets, télécharger individuellement les Troubleshooting Logs concernés ou sauvegarder les fichiers via l’Advanced Shell.

Vérifier la limite de lignes du CTR dans Device Console

La limite de lignes des logs de sous-systèmes de service dans le CTR peut être affichée et définie indépendamment des logs bruts. Dans le menu principal de la CLI, ouvrir 4. Device Console. SFOS 22 et SFOS 23 autorisent de 250 à 10000 lignes et utilisent 10000 par défaut :

system diagnostics show ctr-log-lines
system diagnostics ctr-log-lines 5000

Il n’est normalement pas nécessaire de modifier la valeur par défaut. 5000 illustre uniquement la syntaxe d’un CTR volontairement plus petit : la plage est fixe, mais la valeur dépend du cas de support. Relever la valeur actuelle avec show avant toute modification, générer le CTR, puis rétablir la valeur précédente avec la même commande de définition. Ce réglage ne modifie que les futurs fichiers CTR, pas les logs bruts complets, et ne restaure aucune donnée déjà supprimée ou écrasée.

Télécharger des Troubleshooting Logs individuels

Si le module est déjà connu, un export de logs ciblé est souvent préférable à un jeu de données très large.

1. Ouvrir Diagnostics > Tools.
2. Sous Troubleshooting logs, sélectionner les fichiers journaux pertinents.
3. Sélectionner Download.
4. Transmettre le fichier compressé généré avec l’heure de l’erreur, le cas de test et le pare-feu concerné.

Cette méthode convient par exemple lorsque seul strongswan.log, charon.log, sslvpn.log, reverseproxy.log, applog.log ou un autre service clairement concerné est nécessaire. Contrairement au CTR, ces téléchargements individuels ne sont pas soumis à la limite de lignes. Le fichier correspondant à chaque module est indiqué dans Dépannage de Sophos Firewall : Services et journaux.

Ouvrir l’Advanced Shell

Connectez-vous au Sophos Firewall et ouvrez le Shell avancé :

1. Dans le menu principal de la CLI, sélectionner 5. Device Management.
2. Ouvrir ensuite 3. Advanced Shell.
3. Confirmez l’accès si le pare-feu affiche une demande supplémentaire.

Après la connexion, vous vous trouvez sur le Shell du pare-feu. À partir de là, vous pouvez archiver les fichiers journaux.

Sauvegarder un court extrait de journal en direct

Dans l’Advanced Shell, suivre les nouvelles entrées pendant un test délimité :

cd /log
tail -f /log/charon.log

charon.log est un exemple concret pour IPsec ; pour les autres problèmes, choisir le fichier existant approprié dans l’aperçu des journaux de services. Noter le début, la fin et le fuseau horaire du test, reproduire le problème et copier la sortie dans un fichier texte protégé sur le poste d’administration. Ctrl+C arrête l’affichage, pas le service du pare-feu. tail -f affiche les dernières lignes existantes et les nouvelles entrées, sans exporter le fichier complet. Si des entrées manquent, vérifier d’abord le nœud, le nom du fichier, l’heure et le service ; télécharger le fichier individuel complet si nécessaire. Transmettre l’extrait et son contexte au dossier de support.

Collecter les journaux avant la sauvegarde

Si le problème est reproductible, le déclencher à nouveau, si possible, juste avant d’archiver les journaux. Les entrées pertinentes seront ainsi aussi récentes que possible.

Pour des problèmes plus complexes, les journaux normaux ne suffisent parfois pas. Dans ce cas, il peut être utile d’activer un journal de débogage pour le service concerné avant l’archivage. Le debug ne doit fonctionner que de manière ciblée et brève, puis être désactivé après la collecte, car les fichiers journaux peuvent sinon croître rapidement. La procédure est décrite dans la section Activer un journal de débogage ciblé.

Quel fichier journal appartient à quel module de pare-feu est résumé dans Dépannage de Sophos Firewall : Services et journaux. Cet aperçu est utile si vous souhaitez vérifier spécifiquement si des journaux VPN, IPS, Web, Mail, GUI ou système sont pertinents pour un problème.

Si ce n’est pas un problème de service mais le flux de paquets lui-même qui est peu clair, une archive de journaux seule n’est souvent pas suffisante. Pour des tests courts, Packet Capture dans WebAdmin est approprié. Pour les fichiers PCAP, les captures plus longues ou les analyses de support, tcpdump sur Sophos Firewall est l’outil approprié.

Collecter le debug avec un retour contrôlé

Le debug est désactivé par défaut. Avant de le modifier, vérifier néanmoins avec les administrateurs et le support si une collecte est déjà en cours ; consigner le nœud, l’espace libre et une courte fenêtre de test. Traiter un seul sous-système pris en charge à la fois. Les données de debug sont disponibles par téléchargement individuel, CTR et CLI. Pour l’exemple de service documenté, exécuter dans 4. Device Console :

Pour les autres services pris en charge, la syntaxe est system diagnostics subsystems <subsystem> debug on et system diagnostics subsystems <subsystem> debug off. Remplacer <subsystem> par un nom CLI confirmé sur le build concerné, pas par un nom de fichier journal. Si une collecte debug est déjà en cours pour un autre dossier de support, ne pas modifier son état sans accord.

system diagnostics subsystems Pktcapd debug on

Exécuter uniquement le test prévu, télécharger le journal ou le CTR terminé, puis désactiver le debug dans la même Device Console :

system diagnostics subsystems Pktcapd debug off

Consigner les sorties d’activation et de désactivation ainsi que leurs heures ; effectuer un court test de contrôle pour vérifier l’absence de nouvelles entrées de debug et le retour à une croissance des journaux et une consommation d’espace normales. Si la commande est refusée, ne pas deviner les noms : vérifier la syntaxe du build et contacter le support. La désactivation ne supprime pas les fichiers collectés. Ces commandes et contrôles d’effets n’ont pas été exécutés ici sur un pare-feu.

Pour le contrôleur système, le guide des journaux indique la même commande, system diagnostics subsystems CSC debug, pour activer et désactiver le debug, sans on ni off. Ne pas utiliser ce commutateur comme requête d’état ni l’exécuter deux fois à l’aveugle. Si l’état initial ou le retour arrière est incertain, ne pas modifier le debug CSC ; suivre le parcours CSC contrôlé avec le support. Les noms de fichiers journaux ne sont pas des noms de sous-systèmes CLI.

L’aperçu de diagnostic SFOS 22/23 répertorie les Default logs suivants pour le debug ; ce groupe est également exempté de la limite de lignes du CTR :

syslog.log, postgres.log, reportdb.log, applog.log, access_server.log, awarrenhttp.log, awed.log, charon.log, csc.log, garner.log, heartbeatd.log, ips.log, iview.log, msync.log, nSXLd.log, networkd.log, red.log, reverseproxy.log, smtpd_main.log, sslvpn.log, tomcat.log, u2d.log, up2date_av.log, npu-startup.log.prev, npu_syslog.log, syslog-ng.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-pport-wait.log.

Les Service logs répertoriés sont :

awarrenhttp_access.log, httplogd.log, bwm.log, awarrensmtp.log, pktcapd.log, warren.log.

Cette liste décrit les fichiers pris en charge pour le debug, pas tous les journaux ni leur présence garantie sur chaque plateforme. Vérifier les fichiers NPU et XGS dans le contexte de la XGS Appliance concernée. Respecter la casse : pktcapd.log n’est pas le paramètre de commande Pktcapd.

Préserver les preuves avant de purger les journaux

Une purge n’est pas nécessaire pour créer un CTR ou télécharger des fichiers individuels. Le guide de diagnostic présente la purge d’un sous-système avant reproduction uniquement comme facultative. Clarifier d’abord les preuves, les besoins du support et les exigences de conservation, puis sauvegarder les fichiers nécessaires hors du pare-feu. Contrairement à la suppression des archives personnelles décrite plus loin, une purge efface l’historique de diagnostic ; aucun retour arrière n’est possible.

Les commandes globales de Device Console sont system diagnostics purge-old-logs pour tous les journaux compressés .gz et system diagnostics purge-all-logs pour tout le contenu des journaux. Selon l’aide CLI, une purge complète laisse des fichiers vides. Les actions globales affectent aussi les autres sous-systèmes et les dossiers de support en cours.

Conflit de syntaxe pour un sous-système individuel : L’aide d’administration SFOS 22/23 indique system diagnostics <subsystem> purge-log et system diagnostics <subsystem> purge-old-log ; l’aide CLI documente en revanche system diagnostics subsystems <subsystem> purge-log et system diagnostics subsystems <subsystem> purge-old-log. Aucune forme n’a été testée ici sur un appareil. Avant une purge autorisée dans 4. Device Console, vérifier la syntaxe complète et les noms avec l’aide CLI ou la complétion par Tab, puis clarifier le conflit avec le support. Ne pas essayer les deux variantes.

S’arrêter si la syntaxe, l’origine des fichiers ou une collecte en cours est incertaine, et suivre le parcours d’analyse du stockage et de purge contrôlée. Après une action convenue, contrôler l’espace libre, les nouvelles entrées normales et l’état des services ; une baisse de l’espace occupé ne prouve pas que la cause est résolue. Ne pas supprimer manuellement les journaux système avec rm ou des caractères génériques.

Sauvegarder les journaux bruts via l’Advanced Shell

Si le CTR ne suffit pas ou si tous les journaux bruts actuellement disponibles sont nécessaires pour une analyse interne, le répertoire /log peut être archivé manuellement. Cette méthode dans le shell ne remplace ni le CTR officiel ni le téléchargement individuel sous Troubleshooting logs. Avant l’archivage, vérifier que l’espace libre sous /var est suffisant :

Avant d’utiliser ce parcours complémentaire par shell, vérifier les répertoires présents et l’espace libre. Si /log est un lien symbolique, la commande tar ci-dessous peut n’archiver que le lien au lieu des journaux : ne pas poursuivre avec une archive apparemment terminée ; utiliser le téléchargement individuel officiel ou convenir du parcours avec le support. Un répertoire encore alimenté en écritures n’est pas non plus une sauvegarde cohérente. Résoudre d’abord les chemins absents, erreurs de lecture ou problèmes d’espace ; ne pas supprimer des journaux système pour faire de la place. Cette méthode manuelle n’a pas été testée ici sur SFOS 22/23.

ls -ld /log
df -h /var

Ensuite, créez une archive compressée avec les fichiers du répertoire /log :

tar -cvzf /var/Sophos-Firewall-Logs.tar.gz -C / log

La commande crée le fichier :

/var/Sophos-Firewall-Logs.tar.gz

Les éléments clés de la commande :

• tar crée une archive.
• -c crée une nouvelle archive.
• -v affiche les fichiers traités.
• -z compresse l’archive avec gzip.
• -f spécifie le nom de fichier de l’archive.
• -C / change pour le répertoire racine pour l’archivage.
• log est le répertoire contenant les fichiers journaux de Sophos Firewall.

L’avantage de -C / est que la commande fonctionne indépendamment du répertoire de travail actuel. Un cd / préalable n’est donc pas nécessaire. Si le fichier existe déjà, il sera écrasé par la commande.

Selon la taille et la charge du pare-feu, l’archivage peut prendre un certain temps. La sortie de tar montre pendant ce temps quels fichiers sont écrits dans l’archive.

Ensuite, vous pouvez vérifier la taille de l’archive :

ls -lh /var/Sophos-Firewall-Logs.tar.gz

De plus, vous devriez vérifier brièvement si l’archive est lisible et contient bien le répertoire de journaux :

tar -tzf /var/Sophos-Firewall-Logs.tar.gz

La sortie devrait montrer des chemins sous log/. Si la commande signale une erreur ou si l’archive est inhabituellement petite, elle ne doit pas être transmise. Vérifiez d’abord l’espace libre, les droits d’écriture et l’exécution précédente de tar.

Copier l’archive de journaux sur un serveur Linux

Si un serveur Linux est accessible via SSH, l’archive peut être transférée avec scp.

Exemple :

scp /var/Sophos-Firewall-Logs.tar.gz root@192.0.2.10:/root/

L’adresse IP, l’utilisateur et le chemin cible doivent être adaptés à votre environnement.

Après le transfert, l’archive se trouve sur le serveur cible sous :

/root/Sophos-Firewall-Logs.tar.gz

De là, elle peut être transmise en interne ou mise à disposition du support Sophos ou d’Avanet.

Sauvegarder séparément les données de diagnostic IPsec

En cas de problème VPN ou IPsec, les données de connexion de /tmp/ipsec/connections/ peuvent également être utiles. Les guides SFOS 22/23 examinés ne présentent pas ce parcours manuel comme un export standard. L’utiliser uniquement pour une analyse interne ou à la demande expresse du support, et vérifier d’abord que le répertoire existe.

Pour cela, créez une archive séparée :

ls -ld /tmp/ipsec/connections
tar -cvzf /var/Sophos-Firewall-IPsec-Connections.tar.gz -C /tmp/ipsec connections

Ici aussi, vous pouvez vérifier brièvement le fichier généré :

ls -lh /var/Sophos-Firewall-IPsec-Connections.tar.gz

Cette archive peut également être copiée sur un serveur cible via scp :

scp /var/Sophos-Firewall-IPsec-Connections.tar.gz root@192.0.2.10:/root/

Surtout en cas de problèmes IPsec, il est judicieux de fournir cette archive avec les journaux de pare-feu normaux, afin que le statut du tunnel, les informations de connexion et les entrées de journal puissent être évalués ensemble.

Ce qu’une archive de support ne remplace pas

Un CTR et une archive /log sont des instantanés du pare-feu local. Ils aident à analyser les erreurs de service et de système, mais ne fournissent pas automatiquement un historique à long terme et ne prouvent pas qu’un paquet précis a traversé le pare-feu. Pour l’historique et la recherche, utiliser Central Firewall Reporting ou Syslog et SIEM. Les changements de configuration se retracent plus directement avec les Audit Trail Logs.

Traiter séparément les captures de paquets

Les archives de journaux et les captures de paquets sont des preuves différentes. L’archive de journaux montre les messages de service, les erreurs, les états VPN et les événements système. Une capture de paquets ou tcpdump montre si les paquets arrivent réellement, sont transmis ou si des réponses manquent.

Pour les cas de support, il ne faut pas envoyer les captures de paquets sans filtre. Il est préférable de :

1. Noter le cas de test avec IP source, IP de destination, port, protocole et heure.
2. Vérifier d’abord le Log Viewer et la capture de paquets WebAdmin si cela suffit.
3. Uniquement si nécessaire, créer une capture tcpdump avec un filtre ciblé et l’enregistrer au format PCAP.
4. Transférer le fichier PCAP en toute sécurité.
5. Supprimer le fichier PCAP du pare-feu après un transfert réussi.

Le fichier PCAP ne fait pas partie de l’archive /log, mais est créé et transféré séparément. Cela permet de garder clair quel fichier contient les journaux de service et quel fichier contient les paquets réseau.

Sécurité, protection des données et nettoyage

Les fichiers journaux peuvent contenir des informations sensibles, par exemple :

• Adresses IP publiques et internes
• Noms d’utilisateur
• Noms d’hôte
• Informations VPN
• Messages d’erreur avec détails techniques
• Indications sur les structures réseau internes

Les archives de journaux doivent donc être transférées uniquement par des canaux sécurisés et ne doivent être mises à disposition que des personnes ou organisations impliquées dans l’analyse. Si les journaux sont envoyés à un partenaire externe, il doit d’abord être clarifié en interne si le transfert est autorisé selon les politiques de protection des données et de sécurité internes.

Dans un cluster HA, les logs et les rapports ne sont pas automatiquement synchronisés entre les appliances Primary et Auxiliary. Chaque appliance contient les logs et les rapports du trafic qu’elle traite. En cas de problème HA ou pour une période de basculement, consigner le nœud dont provient l’archive et déterminer si les logs du second nœud sont également nécessaires.

Supprimer les archives temporaires

Après le transfert, vérifier l’archive sur le système cible, puis la supprimer du pare-feu pour libérer l’espace temporaire. Les commandes suivantes ne suppriment que les noms d’archives fixes créés dans ce guide :

rm /var/Sophos-Firewall-Logs.tar.gz

Si une archive IPsec séparée a également été créée, elle doit également être supprimée :

rm /var/Sophos-Firewall-IPsec-Connections.tar.gz

Avant de supprimer, vérifiez que les fichiers sont arrivés avec succès sur le système cible.

Liste de contrôle pour les cas de support

• Problème brièvement décrit : Qu’est-ce qui ne fonctionne pas, depuis quand, à quelle fréquence ?
• Heure exacte avec fuseau horaire notée.
• IP source, IP de destination, utilisateur, service ou nom de tunnel concerné noté.
• Module pertinent vérifié dans le Log Viewer.
• Si nécessaire : débogage activé brièvement et désactivé à nouveau.
• CTR créé sous Diagnostics > Tools si Sophos Support ou un instantané système est nécessaire.
• Si nécessaire, Troubleshooting Logs individuels ou archive /log complète créés.
• En cas de problèmes IPsec, données de diagnostic IPsec également sauvegardées.
• En cas de problèmes de flux de paquets, Packet Capture ou tcpdump créé séparément.
• Vérification des fichiers journaux réels avec tar -tzf uniquement pour les archives gzip manuelles ; pour le CTR chiffré, contrôle du téléchargement, de l’appareil et de l’heure.
• Pour HA, vérifié de quel nœud proviennent les logs.
• Archive et PCAP transférés uniquement par des canaux sécurisés.
• Fichiers temporaires sur le pare-feu supprimés après un transfert réussi.

FAQ