Starta om WebAdmin GUI på Sophos Firewall

Om WebAdmin GUI på Sophos Firewall slutar svara behöver inte hela brandväggen startas om omedelbart. Så länge routing, VPN och brandväggsregler fortsätter att fungera och SSH eller den lokala konsolen är tillgänglig kan de två WebAdmin-tjänsterna tomcat och apache kontrolleras och startas om separat.

Följande kommandon är avsedda för en fristående brandvägg. I ett HA-kluster beror rätt synkroniseringsläge på tjänsten, noden, SFOS-builden och det konkreta felet. Använd inte -ds nosync i HA utan att först kontrollera att det är lämpligt.

⚠️ En omstart av en tjänst ändrar systemets tillstånd, avslutar aktiva WebAdmin-sessioner och kan även avbryta User Portal kortvarigt. Spara först relevanta loggar, informera andra administratörer och förbered en alternativ åtkomstmetod för fjärrplatser.

Snabb procedur för en fristående brandvägg

Proceduren är lämplig när WebAdmin visar Internal Server Error, HTTP 503, en ofullständig inloggningssida eller ett gränssnitt som inte svarar alls, samtidigt som SSH och brandväggens övriga funktioner är tillgängliga.

Logga in som admin via SSH eller den lokala konsolen. Om SSH ännu inte har konfigurerats förklarar Anslut till Sophos Firewall via SSH hur säker åtkomst förbereds.
Öppna 5. Device Management > 3. Advanced Shell.
Visa de senaste WebAdmin-felen och kopiera relevant utdata till ändringsdokumentationen eller ett supportärende:

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

Kontrollera tjänsternas aktuella status:

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

Om en tjänst visar STOPPED kör du endast motsvarande startkommando:

# Om tomcat är STOPPED:
service tomcat:start -ds nosync

# Om apache är STOPPED:
service apache:start -ds nosync

Om en tjänst visar DEAD startar du endast om den tjänsten. Om båda visar RUNNING men WebAdmin fortfarande inte går att använda börjar du med tomcat:

service tomcat:restart -ds nosync

Testa WebAdmin igen. Kör följande kommando endast om apache visar DEAD eller om problemet kvarstår efter omstarten av tomcat:

service apache:restart -ds nosync

Vänta några sekunder, öppna WebAdmin igen från det avsedda hanteringsnätverket och kontrollera tjänsternas status på nytt:

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

Båda tjänsterna ska visa RUNNING. Funktionstestet är dock avgörande: inloggningen, instrumentpanelen, Log Viewer och en icke-kritisk konfigurationssida måste läsas in stabilt. En process som körs bevisar inte i sig att WebAdmin fungerar korrekt.

Inaktiva SSH-sessioner stängs efter 15 minuter. Förbered därför loggkontrollen, omstarten och verifieringen innan du öppnar Advanced Shell, så att en utgången session inte avbryter proceduren.

Kontrollera om en omstart av tjänsten är lämplig

Bakom tjänstenamnet tomcat körs webbapplikationsservern Jetty; apache är Apache HTTP Server. Båda komponenterna används av WebAdmin och User Portal. Deras loggar finns i Advanced Shell:

Applikationsserver: /log/tomcat.log
Webbserver: /log/apache.log och /log/apache_access.log
Ytterligare webbserverfel: /log/error_log.log

Alla WebAdmin-problem uppstår inte i dessa tjänster. Feltypen avgör nästa steg:

Internal Server Error, HTTP 503 eller en ofullständig inloggningssida: Kontrollera tomcat, apache och de angivna loggarna. En riktad omstart är rimlig i det här fallet.
Certifikatvarning: Kontrollera certifikatets namn, giltighet och förtroendekedja. En omstart av tjänsten korrigerar inte ett felaktigt certifikat.
Tidsgräns eller åtkomstfel endast från ett nätverk: Kontrollera routen, hanteringsnätverket och Administration > Device access. Lokala brandväggstjänster tillåts via Device Access och inte genom en vanlig brandväggsregel. Device Access och Local Service ACL förklarar den säkra konfigurationen.
Endast en webbläsare påverkas: Testa en privat session, en annan webbläsare eller en annan administratörsklient innan du ändrar något på brandväggen.
WebAdmin, SSH, VPN eller andra tjänster slutar fungera samtidigt: Det tyder snarare på systembelastning, lagring, databasen, HA eller ett övergripande systemproblem. Starta inte om tjänster på måfå.

Om en firmware-, snabbkorrigerings- eller mönsteruppdatering, HA-synkronisering, supportfelsökning eller aktiv Central-uppgift pågår ska processen först identifieras och om möjligt slutföras. Annars blir det svårt att senare avgöra om problemet kom från uppdateringen, Central, HA eller omstarten av tjänsten.

Spara underlag före ingreppet

En omstart kan flytta aktuella felmeddelanden ur den synliga kontexten. Vid ett återkommande problem eller ett supportärende bör åtminstone tidpunkten, SFOS-builden, den berörda åtkomstvägen och de senaste meddelandena i tomcat.log, apache.log och error_log.log dokumenteras.

Om WebAdmin fortfarande fungerar delvis kan enskilda loggar eller en Consolidated Troubleshooting Report hämtas under Diagnostics > Tools. Om endast skalet är tillgängligt förklarar Spara Sophos Firewall-loggar för support och analys proceduren. I ett HA-kluster lagrar varje nod sina egna loggar; kontrollera Primary och Auxiliary separat vid behov.

Före en omstart i produktion ska du även kontrollera:

om andra administratörer eller en pågående ändring påverkas;
om SSH, den lokala konsolen, Sophos Central eller en annan hanteringsanslutning erbjuder en returväg;
om WebAdmin är den enda berörda tjänsten;
om rätt nod och aktuella tjänstespecifika Sophos-anvisningar finns för ett HA-kluster.

Starta om Sophos Firewall-tjänster på ett säkert sätt förklarar den allmänna hanteringen av tjänstenamn, status, loggar och HA-gränser. Felsökning av Sophos Firewall: tjänster och loggar innehåller fler kopplingar mellan funktioner och loggfiler.

Verifiera resultatet och utred återkommande problem

Läs loggarna igen efter omstarten. Nya fel direkt efter starten är mer användbara än gamla meddelanden utan tidsreferens:

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

Öppna sedan instrumentpanelen, Log Viewer och en icke-kritisk sida. Begränsa tillfälligt tillåten SSH- eller Device Access-åtkomst igen till de avsedda administratörskällorna.

Om problemet återkommer var omstarten av tjänsten endast en tillfällig återställning. Grundorsaksanalysen bör då omfatta:

ledigt utrymme på partitioner, lokala rapporter och databasstatus;
CPU- och RAM-belastning samt ovanliga systemloggar;
samtidiga administratörssessioner eller intensiv användning av paketinsamling;
aktiva eller misslyckade Central-uppgifter;
HA-roll, synkronisering och berörd nod;
ändringar av konfiguration, certifikat, gränssnitt eller Device Access omedelbart före problemet.

Hantera lagring och rapporter i Sophos Firewall hjälper vid lagrings- och rapportproblem. Ändringar före avbrottet kan spåras med Audit Trail-loggar i Sophos Firewall.

En kort driftanteckning förhindrar att ett återkommande problem endast hanteras med upprepade omstarter:

Datum, tid och tidszon:
Brandvägg och eventuell HA-nod:
SFOS-version och build:
Symtom:
Kontrollerade loggar:
Kört kommando:
Resultat och nästa åtgärd:

Om WebAdmin fortfarande inte är tillgängligt

Om en tjänst fortsätter att visa STOPPED eller DEAD, omstarten returnerar ett fel eller problemet återkommer omedelbart ska tomcat.log, apache.log, error_log.log, systemstatusen och CTR sparas för analys tillsammans med Sophos Support. Att starta om andra tjänster på måfå försämrar sannolikt främst underlaget.

Om varken WebAdmin eller SSH är tillgängligt beror återställningsvägen på miljön: lokal konsol via konsolkabel eller Micro-USB på modeller som stöder det, Sophos Central, en förberedd HA-reservväg eller en planerad omstart. På fjärrplatser måste det vara klart vem som kan få lokal åtkomst om brandväggen inte startar korrekt. I ett HA-kluster ska du inte initiera en overifierad failover enbart för att WebAdmin inte svarar, så länge produktionstrafiken fortsätter att flöda normalt.

En fullständig omstart är mer ingripande än att starta om de berörda tjänsterna. Överväg den endast om flera centrala tjänster påverkas, brandväggen förblir instabil, en firmware- eller hotfixprocess kräver det eller Sophos Support rekommenderar det. Kontrollera först säkerhetskopian, underhållsfönstret och påverkan på VPN, routing, RED, wireless och publicerade tjänster. Planera säkerhetskopiering och återställning av Sophos Firewall korrekt förklarar förberedelserna.