Sophos Firewall Starta om WebAdmin GUI

Om Sophos Firewall WebAdmin GUI inte längre är tillgängligt, behöver inte hela brandväggen startas om omedelbart. Det räcker ofta att starta om WebAdmin-tjänsterna på ett kontrollerat sätt med hjälp av Advanced Shell. Detta är betydligt mindre invasivt än en fullständig omstart och kan spara värdefull tid under ett support- eller underhållsfönster.

Typiska symtom är:

• WebAdmin GUI visar Internal Server Error.
• Inloggningssidan eller instrumentpanelen laddas inte längre helt.
• WebAdmin svarar väldigt långsamt eller hänger sig efter ett klick.
• Andra tjänster som routing, VPN eller brandväggsregler fortsätter att köras.
• SSH eller lokal konsol är fortfarande tillgänglig.

I praktiken kan detta inträffa efter tung GUI-belastning, flera samtidiga administratörssessioner, tung paketfångningsanvändning eller allmänna resursproblem. Om brandväggen generellt är instabil, partitionerna är fulla eller flera tjänster är nere, bör WebAdmin GUI inte vara det enda att tänka på. Då passar även Sophos Firewall Tjänster och loggar, Sophos Firewall Starta om tjänsterna på ett säkert sätt och Kontrollera lagringsutrymme och hantera rapporter.

⚠️ Viktigt: En omstart av tjänsten är ett ingrepp på brandväggen. Före produktionsändringar bör det vara klart vem som är ansluten, om ett underhållsfönster behövs och om alternativ åtkomst via SSH, lokal konsol eller HA-partner finns tillgänglig.

Krav

För en riktad omstart behöver du:

• Tillgång till användaren admin.
• SSH-åtkomst eller lokal konsolåtkomst.
• Tillgång till Advanced Shell.
• En tydlig felbild: WebAdmin påverkas, men brandväggen behöver inte startas om helt.
• Så kort underhålls- eller diagnostid som möjligt om flera administratörer är berörda.

Om SSH ännu inte är förberett hjälper Sophos Firewall anslut via SSH. Själva åtkomsten styrs via Administration > Device access. Konfigurera Device Access korrekt är den rätta grundläggande artikeln för att säkra HTTPS/WebAdmin och SSH.

Efter SSH-inloggning öppnar man Advanced Shell via 5. Device Management > 3. Advanced Shell. Sophos stänger inaktiva SSH-sessioner efter 15 minuter. Vid en GUI-incident bör därför loggkontroll, servicestatus och omstart göras utan långa pauser, eller så bör sessionen öppnas igen medvetet vid behov.

Kontrollera kort innan du startar om

Innan du startar om tjänsterna bör du isolera problemet:

1. Kontrollera om endast WebAdmin påverkas eller om reglerna för VPN, routing, DNS eller brandvägg också misslyckas.
2. Testa om möjligt med en andra webbläsare eller ett privat fönster.
3. Kontrollera om andra administratörer för närvarande arbetar i GUI.
4. Logga in via SSH och öppna Advanced Shell.
5. Se eventuellt kort de relevanta loggarna.

De viktigaste loggfilerna är:

• WebAdmin webbserver: /log/apache.log och /log/apache_access.log.
• WebAdmin Application: /log/tomcat.log.
• GUI/systemfel: /log/error_log.log.

Exempel på en snabb visuell inspektion:

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

Om du vill säkerhetskopiera loggarna för ett supportärende bör du exportera dem innan ytterligare omstarter. Processen finns i Sophos Firewall Säkerhetskopiera loggar för support och analys.

Klassificera felmönstret korrekt

Inte alla WebAdmin-problem orsakas av tomcat eller apache. Innan du startar om hjälper en kort klassificering:

Typisk klassificering:

• WebAdmin visar Internal Server Error: Ofta beror det på GUI-applikationen eller webbservern. Kontrollera tomcat.log och apache.log och starta om tjänsterna specifikt.
• Webbläsaren rapporterar certifikatvarning: Kontrollera först certifikat, namn och förtroendekedja, starta inte om tjänster direkt.
• Anslutningen körs i timeout: Då är Device Access, routing, ACL, VPN eller hanteringsnätverk mer sannolikt. Kontrollera tillgänglighet och Administration > Device access.
• Inloggning fungerar, instrumentpanelen hänger sig efteråt: Kontrollera GUI-belastning, session, rapporter, minne eller databas.
• WebAdmin och SSH är inte tillgängliga: Då handlar det mer om åtkomstväg, Device Access eller systemstatus. Kontrollera lokal konsol, HA-partner eller central ledning.
• Flera tjänster misslyckas samtidigt: Detta tyder på ett systemproblem snarare än ett rent GUI-problem. Säkerhetskopiera loggar, kontrollera lagringsutrymme och utvärdera omstart eller supportfall.

Denna klassificering förhindrar att WebAdmin-tjänsterna startas om i onödan i händelse av problem med nätverks- eller enhetsåtkomst. Om endast åtkomst från ett specifikt nätverk misslyckas är Device Access och Local Service ACL till Sophos Firewall vanligtvis viktigare än en omstart av tjänsten.

När är det bättre att skjuta upp omstarten

Att starta om tomcat och apache är relativt målinriktat, men är fortfarande ett ingrepp i brandväggens administrativa nivå. I dessa situationer bör du först kort stabilisera eller dokumentera:

• Firmware-uppdatering, snabbkorrigering eller mönsteruppdatering körs: Ingrip inte i WebAdmin-tjänster samtidigt så länge uppdateringsprocessen är aktiv.
• HA-kluster synkroniserar för närvarande: Kontrollera HA-roll, synkronisering och aktiv nod först.
• Supportfelsökning eller loggsamling körs: Spara först relevanta loggar och starta sedan om tjänsterna.
• Central uppgift är för närvarande aktiv: Kontrollera uppgiftskön så att en pågående central förändring inte blandas med ett lokalt GUI-problem.
• Endast en administratörswebbläsare påverkas: Testa privat session, andra webbläsare eller annan klient först.

Denna korta broms sparar förklaringsarbete senare. Om det inte längre är klart direkt efter en omstart om felet kom från WebAdmin, Central, HA eller en pågående uppdatering blir analysen onödigt svår.

Starta om WebAdmin-tjänster

WebAdmin GUI beror främst på två tjänster:

• tomcat: WebAdmin-applikation.
• apache: WebAdmin webbserver.

Kontrollera status först före omstart:

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

Om en tjänst är STOPPED är en riktad start renare än en blind omstart:

service tomcat:start -ds nosync
service apache:start -ds nosync

Om tomcat eller apache visar DEAD, eller om de visar RUNNING men WebAdmin fortfarande inte fungerar, kan båda tjänsterna startas om efter varandra:

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

Vänta sedan några sekunder och öppna WebAdmin GUI igen. Om inloggningen fungerar igen bör du ändå kontrollera om det finns återkommande fel synliga i Log Viewer eller i systemloggarna.

Kontrollera status

Om det inte räcker med omstart kan du kontrollera statusen för tjänsterna:

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

Du kan också kontrollera om tjänsterna visas i tjänstelistan:

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

Den allmänna tilldelningen av tjänster, moduler och loggfiler finns i Sophos Firewall Felsökning: tjänster och loggar. Den förklarar också när Log Viewer, Advanced Shell eller individuella loggfiler är den bättre analyskällan.

Validera efter omstart

Om WebAdmin laddas igen har problemet ännu inte lösts helt. Du bör kort kontrollera om det grafiska användargränssnittet förblir stabilt och om orsaken blir synlig igen.

Användbar uppföljningskontroll:

1. Öppna WebAdmin från det avsedda hanteringsnätverket.
2. Logga in med ett adminkonto och testinstrumentpanel, Log Viewer och en icke-kritisk konfigurationssida.
3. Kontrollera tomcat.log, apache.log och error_log.log igen för nya fel.
4. Kontrollera lagringsutrymme och lokala rapporter om GUI tidigare var långsamt eller tomt.
5. Uteslut öppna administratörssessioner, webbläsarcache eller parallell administratörsåtkomst som orsak.
6. Begränsa tillfälligt tillåten SSH- eller enhetsåtkomst igen.
7. För HA-kluster, kontrollera om du arbetar på den förväntade noden.

Om problemet återkommer bör du inte starta om tomcat och apache varje dag. Då behövs en rotorsaksanalys: lagringsutrymme, databasstatus, rapporter, GUI-fel, systembelastning, HA-roll och senaste konfigurationsändringar. För ändringar strax före felet är Sophos Firewall Kontrollera loggar för revisionsspår till hjälp.

Om WebAdmin fortfarande inte är tillgänglig

Om det grafiska gränssnittet fortfarande är otillgängligt efter omstart av tomcat och apache bör du inte starta om så många tjänster som du vill. En strukturerad begränsning är mer meningsfull:

• Kontrollera Device Access: Är HTTPS/WebAdmin tillåtet från den aktuella zonen och källan?
• Uteslut webbläsare: Testa cache, privat session eller andra webbläsare.
• Kontrollera certifikat: Ett utgånget eller felaktigt certifikat kan försvåra åtkomsten, men orsakar vanligtvis inte ett riktigt internt serverfel.
• Kontrollera systembelastningen: Hög CPU-, RAM- eller diskanvändning kan påverka WebAdmin.
• Kontrollera diskutrymme: Fullständiga partitioner kan orsaka GUI och rapporteringsproblem.
• Kontrollera loggar: Skanna tomcat.log, apache.log och error_log.log efter aktuella fel.
• Notera HA-kontext: För HA-kluster, kontrollera vilken nod du arbetar på och vilken nod som är aktiv.
• Kontrollera de senaste ändringarna: Audit Trail och Config Studio kan visa om Device Access, certifikat, gränssnitt eller administratörsinställningar nyligen har ändrats.

Om WebAdmin och SSH inte är tillgängliga, beroende på platsen, återstår endast lokal konsol, Sophos Central-hantering, HA-failover eller en planerad omstart. I produktiva miljöer bör detta fall förberedas i drift- och återställningsprocessen.

Fjärrplatser och HA-kluster

Med en enda brandvägg på huvudplatsen är en WebAdmin-omstart vanligtvis lätt att kontrollera. För avlägsna platser eller HA-kluster bör du kontrollera mer i detalj i förväg vilken väg åtkomsten sker och vilken reservnivå som är tillgänglig.

Viktiga frågor:

• Är åtkomst direkt från hanteringsnätverket, via VPN, via Sophos Central eller via en hoppvärd?
• Är SSH verkligen tillgängligt, eller fungerar bara en befintlig WebAdmin-session?
• Finns det någon på plats som kan kontrollera apparaten vid behov?
• För HA: Vilken nod arbetar du på och vilken nod är för närvarande primär?
• Kommer en planerad failover att skapa större risk än den riktade omstarten av tomcat och apache?
• Dokumenteras loggar och tid innan en failover eller omstart gör analysen svår?

I HA-miljöer bör du inte automatiskt failover bara för att WebAdmin hänger på den aktiva noden. Om trafiken fortsätter är en riktad omstart av GUI-tjänsten ofta mindre invasiv. Men om flera tjänster påverkas, den aktiva noden verkar instabil eller åtkomsten är helt förlorad, hör ärendet till en kontrollerad HA- eller platsåterställningsprocess.

När en fullständig omstart är mer meningsfull

En omstart är inte den första åtgärden för ett hängande WebAdmin-gränssnitt. Men det kan vara användbart om:

• Flera centrala tjänster svarar inte längre
• brandväggen förblir instabil efter att tjänsten startar om
• Minnes- eller databasproblem har lösts och en ren uppstart krävs
• Sophos Support eller ett underhållsfönster anger detta
• ett HA-kluster kan failover på ett kontrollerat sätt

Före omstart bör säkerhetskopiering, underhållsfönster, platsåtkomst och påverkan på VPN, routing, RED, trådlösa och publicerade tjänster vara kända.

Checklista

• Dokumenterad felbild: Internal Server Error, timeout eller tom WebAdmin-sida.
• SSH eller lokal konsol tillgänglig.
• Advanced Shell öppen.
• tomcat.log och apache.log kontrolleras kort.
• Status kontrollerad med service -S | grep -iE 'tomcat|apache'.
• service tomcat:restart -ds nosync körd.
• service apache:restart -ds nosync körd.
• WebAdmin testade igen.
• Kontrollerat lagringsutrymme, Device Access och systemloggar för återkommande fel.
• Loggar sparas för support i händelse av produktiva störningar.
• Kontrollerade pågående uppdateringar, HA-synkronisering, centrala uppgifter eller supportfelsökning innan omstart.
• Tillfälliga SSH- eller enhetsåtkomstdelningar har tagits bort igen.
• Återkommande fel döljs inte bara vid omstarter av tjänsten.

Vanliga frågor