Sophos Firewall Redémarrer l'interface graphique de WebAdmin

Si l’interface graphique Sophos Firewall WebAdmin n’est plus accessible, il n’est pas nécessaire de redémarrer immédiatement l’ensemble du pare-feu. Il suffit souvent de redémarrer les services WebAdmin de manière contrôlée à l’aide du Advanced Shell. Cette opération est nettement moins invasive qu’un redémarrage complet et peut permettre de gagner un temps précieux pendant une fenêtre de support ou de maintenance.

Les symptômes typiques sont :

• L’interface graphique WebAdmin affiche Internal Server Error.
• La page de connexion ou le tableau de bord ne se charge plus complètement.
• WebAdmin répond très lentement ou se bloque après un clic.
• D’autres services tels que les règles de routage, de VPN ou de pare-feu continuent de fonctionner.
• SSH ou la console locale sont toujours accessibles.

En pratique, cela peut se produire après une charge importante de l’interface graphique, plusieurs sessions d’administration simultanées, une utilisation intensive de la capture de paquets ou des problèmes généraux de ressources. Si le pare-feu est généralement instable, les partitions sont pleines ou plusieurs services sont en panne, l’interface graphique WebAdmin ne devrait pas être la seule chose à prendre en compte. Alors Sophos Firewall Services et journaux, Sophos Firewall Redémarrer les services en toute sécurité et Vérifier l’espace de stockage et gérer les rapports conviennent également.> ⚠️ Important : Un redémarrage de service est une intervention sur le pare-feu. Avant d’apporter des modifications productives, il convient de savoir clairement qui est connecté, si une fenêtre de maintenance est nécessaire et si un accès alternatif via SSH, une console locale ou un partenaire HA est disponible.

Exigences

Pour un redémarrage ciblé il vous faut :

• Accès à l’utilisateur admin.
• Accès SSH ou accès à la console locale.
• Accès au Advanced Shell.
• Une image d’erreur claire : WebAdmin est concerné, mais il n’est pas nécessaire de redémarrer complètement le pare-feu.
• Un temps de maintenance ou de diagnostic le plus court possible si plusieurs administrateurs sont concernés.

Si SSH n’est pas encore préparé, Sophos Firewall se connecte via SSH vous aidera. L’accès lui-même est contrôlé via Administration > Device access. Configurez correctement Device Access est le bon article de base pour sécuriser HTTPS/WebAdmin et SSH.

Vérifiez brièvement avant de redémarrer

Avant de redémarrer les services, vous devez isoler le problème :

1. Vérifiez si seul WebAdmin est concerné ou si les règles VPN, de routage, DNS ou de pare-feu échouent également.
2. Si possible, testez avec un deuxième navigateur ou une fenêtre privée.
3. Vérifiez si d’autres administrateurs travaillent actuellement dans l’interface graphique.
4. Connectez-vous via SSH et ouvrez le Advanced Shell.
5. Si vous le souhaitez, affichez brièvement les journaux pertinents.

Les fichiers journaux les plus importants sont :

• Serveur web WebAdmin : /log/apache.log et /log/apache_access.log.
• Application WebAdmin : /log/tomcat.log.
• Erreur GUI/Système : /log/error_log.log.

Exemple d’une inspection visuelle rapide :

tail -n 80 /log/tomcat.log
tail -n 80 /log/apache.log

Si vous souhaitez sauvegarder les journaux pour un cas de support, vous devez les exporter avant de nouveaux redémarrages. Le processus se trouve dans Sophos Firewall Sauvegarder les journaux pour l’assistance et l’analyse.

Classer correctement le modèle d’erreur

Tous les problèmes WebAdmin ne sont pas causés par tomcat ou apache. Avant de redémarrer, un bref classement permettra :

Classement typique :

• WebAdmin affiche Internal Server Error : Cela est souvent dû à l’application GUI ou au serveur Web. Vérifiez tomcat.log et apache.log et redémarrez les services spécifiquement.
• Le navigateur signale un avertissement de certificat : Vérifiez d’abord le certificat, le nom et la chaîne de confiance, ne redémarrez pas les services directement.
• La connexion s’exécute dans un délai d’attente : Alors Device Access, le routage, l’ACL, le VPN ou le réseau de gestion sont plus probables. Vérifiez la disponibilité et Administration > Device access.
• La connexion fonctionne, le tableau de bord se bloque ensuite : Vérifiez la charge de l’interface graphique, la session, les rapports, la mémoire ou la base de données.
• WebAdmin et SSH ne sont pas accessibles : Il s’agit ensuite davantage du chemin d’accès, de Device Access ou de l’état du système. Vérifiez la console locale, le partenaire HA ou la gestion centrale.
• Plusieurs services échouent en même temps : Cela suggère un problème système plutôt qu’un simple problème d’interface graphique. Sauvegardez les journaux, vérifiez l’espace de stockage et évaluez le redémarrage ou le cas de support.

Cette classification évite que les services WebAdmin soient redémarrés inutilement en cas de problème d’accès au réseau ou aux appareils. Si seul l’accès à partir d’un réseau spécifique échoue, Device Access et Local Service ACL à Sophos Firewall est généralement plus important qu’un redémarrage du service.

Quand est-il préférable de reporter le redémarrage

Le redémarrage de tomcat et apache est relativement ciblé, mais reste une intervention au niveau administratif du pare-feu. Dans ces situations, vous devez d’abord stabiliser ou documenter brièvement :

• Une mise à jour du micrologiciel, du correctif ou du modèle est en cours : N’intervenez pas dans les services WebAdmin en même temps tant que le processus de mise à jour est actif.
• Le cluster HA est en cours de synchronisation : Vérifiez d’abord le rôle HA, la synchronisation et le nœud actif.
• Le débogage du support ou la collecte de journaux est en cours : Enregistrez d’abord les journaux pertinents, puis redémarrez les services.
• La tâche centrale est actuellement active : Vérifiez la file d’attente des tâches afin qu’un changement central en cours ne soit pas mélangé à un problème d’interface graphique locale.
• Un seul navigateur administrateur est concerné : Testez d’abord la session privée, le deuxième navigateur ou un autre client.

Ce court freinage évite le travail d’explication plus tard. S’il n’est plus clair immédiatement après un redémarrage si l’erreur provient de WebAdmin, Central, HA ou d’une mise à jour en cours, l’analyse devient inutilement difficile.

Redémarrez les services WebAdmin

L’interface graphique WebAdmin dépend principalement de deux services :

• **tomcat :**Application WebAdmin.
• apache : Serveur Web WebAdmin.

Dans le Advanced Shell, les deux services peuvent être redémarrés l’un après l’autre :

service tomcat:restart -ds nosync
service apache:restart -ds nosync

Attendez ensuite quelques secondes et ouvrez à nouveau l’interface graphique WebAdmin. Si la connexion fonctionne à nouveau, vous devez toujours vérifier s’il y a des erreurs récurrentes visibles dans le Log Viewer ou dans les journaux système.

Vérifier l’état

Si le redémarrage ne suffit pas, vous pouvez vérifier l’état des services :

service tomcat:status -ds nosync
service apache:status -ds nosync

Vous pouvez également vérifier si les services apparaissent dans la liste des services :

service -S | grep -E 'tomcat|apache'

L’affectation générale des services, modules et fichiers journaux se trouve dans Sophos Firewall Dépannage : services et journaux. Il explique également quand Log Viewer, Advanced Shell ou des fichiers journaux individuels constituent la meilleure source d’analyse.

Valider après redémarrage

Si WebAdmin se charge à nouveau, le problème n’est pas encore complètement résolu. Vous devez vérifier brièvement si l’interface graphique reste stable et si la cause redevient visible.

Vérification de suivi utile :

1. Ouvrez WebAdmin à partir du réseau de gestion prévu.
2. Connectez-vous avec un compte administrateur et un tableau de bord de test, Log Viewer et une page de configuration non critique.
3. Vérifiez à nouveau tomcat.log, apache.log et error_log.log pour détecter de nouvelles erreurs.
4. Vérifiez l’espace de stockage et les rapports locaux si l’interface graphique était auparavant lente ou vide.
5. Excluez les sessions d’administration ouvertes, le cache du navigateur ou l’accès administrateur parallèle comme cause.
6. Restreignez à nouveau temporairement l’accès autorisé à SSH ou à l’appareil.
7. Pour les clusters HA, vérifiez si vous travaillez sur le nœud attendu.

Si le problème persiste, vous ne devez pas redémarrer tomcat et apache tous les jours. Ensuite, une analyse des causes profondes est nécessaire : espace de stockage, état de la base de données, rapports, erreurs de l’interface graphique, charge du système, rôle HA et modifications récentes de la configuration. Pour les modifications peu de temps avant l’erreur, Sophos Firewall Vérifier les journaux de piste d’audit est utile.

Si WebAdmin est toujours indisponible

Si l’interface graphique n’est toujours pas disponible après le redémarrage de tomcat et apache, vous ne devez pas redémarrer autant de services que vous le souhaitez. Une limitation structurée est plus logique :

• Vérifiez Device Access : HTTPS/WebAdmin est-il autorisé à partir de la zone et de la source actuelles ?
• Exclure le navigateur : Testez le cache, la session privée ou le deuxième navigateur.
• Vérifier le certificat : Un certificat expiré ou incorrect peut rendre l’accès plus difficile, mais ne produit généralement pas de véritable erreur interne du serveur.
• Vérifiez la charge du système : Une utilisation élevée du processeur, de la RAM ou du disque peut affecter WebAdmin.
• Vérifiez l’espace disque : Des partitions complètes peuvent entraîner des problèmes d’interface graphique et de création de rapports.
• Vérifiez les journaux : Scannez tomcat.log, apache.log et error_log.log pour les erreurs actuelles.
• Notez le contexte HA : Pour les clusters HA, vérifiez sur quel nœud vous travaillez et quel nœud est actif.
• Vérifiez les modifications récentes : Audit Trail et Config Studio peuvent indiquer si Device Access, le certificat, l’interface ou les paramètres d’administration ont été modifiés récemment.

Si WebAdmin et SSH ne sont pas accessibles, selon l’emplacement, il ne reste que la console locale, la gestion Sophos Central, le basculement HA ou un redémarrage planifié. Dans les environnements productifs, ce cas doit être préparé dans le processus d’exploitation et de récupération.

Sites distants et clusters HAAvec un seul pare-feu à l’emplacement principal, un redémarrage de WebAdmin est généralement facile à contrôler. Pour les emplacements distants ou les clusters HA, vous devez vérifier au préalable plus en détail quel chemin d’accès s’effectue et quel niveau de secours est disponible.

Questions importantes :

• L’accès s’effectue-t-il directement depuis le réseau de gestion, via VPN, via Sophos Central ou via un jump host ?
• SSH est-il vraiment accessible, ou seule une session WebAdmin existante fonctionne-t-elle ?
• Y a-t-il quelqu’un sur place qui peut vérifier l’appareil si nécessaire ?
• Pour HA : sur quel nœud travaillez-vous et quel nœud est actuellement principal ?
• Un basculement planifié créera-t-il plus de risques que le redémarrage ciblé de tomcat et apache ?
• Les journaux et l’heure sont-ils documentés avant qu’un basculement ou un redémarrage ne rende l’analyse difficile ?Dans les environnements haute disponibilité, vous ne devez pas basculer automatiquement simplement parce que WebAdmin est bloqué sur le nœud actif. Si le trafic continue, un redémarrage ciblé du service GUI est souvent moins invasif. Cependant, si plusieurs services sont affectés, que le nœud actif semble instable ou que l’accès est complètement perdu, le cas appartient à un processus contrôlé de haute disponibilité ou de récupération de site.

Quand un redémarrage complet a plus de sens

Un redémarrage n’est pas la première mesure en cas de blocage de l’interface graphique WebAdmin. Mais cela peut être utile si :

• plusieurs services centraux ne répondent plus
• le pare-feu reste instable après le redémarrage du service
• Les problèmes de mémoire ou de base de données ont été résolus et un démarrage en mode minimal est requis
• Le support Sophos ou une fenêtre de maintenance le précise
• un cluster HA peut basculer de manière contrôlée

Avant le redémarrage, la sauvegarde, les fenêtres de maintenance, l’accès à l’emplacement et l’impact sur les services VPN, de routage, RED, sans fil et publiés doivent être connus.

Liste de contrôle- Image d’erreur documentée : Internal Server Error, timeout ou page WebAdmin vide.

• SSH ou console locale disponible. -Advanced Shell ouvert.
• tomcat.log et apache.log ont été brièvement vérifiés. -service tomcat:restart -ds nosync exécuté. -service apache:restart -ds nosync exécuté.
• WebAdmin a de nouveau testé.
• Vérification de l’espace de stockage, de Device Access et des journaux système pour les erreurs récurrentes.
• Journaux enregistrés pour assistance en cas de perturbations de production.
• Vérification des mises à jour en cours, de la synchronisation HA, des tâches centrales ou du support du débogage avant de redémarrer.
• Les partages temporaires d’accès SSH ou aux appareils ont été à nouveau supprimés.
• Les erreurs récurrentes ne sont pas seulement masquées lors des redémarrages du service.

FAQ