De WebAdmin GUI van Sophos Firewall opnieuw starten
Als de WebAdmin GUI van Sophos Firewall niet meer reageert, hoeft niet meteen de hele firewall opnieuw te worden opgestart. Zolang routing, VPN en firewallregels blijven werken en SSH of de lokale console bereikbaar is, kunnen de twee WebAdmin-services tomcat en apache afzonderlijk worden gecontroleerd en herstart.
De volgende opdrachten zijn bedoeld voor een standalonefirewall. In een HA-cluster hangt de juiste synchronisatiemodus af van de service, de node, de SFOS-build en het concrete probleem. Gebruik -ds nosync in HA niet zonder eerst te controleren of dit passend is.
⚠️ Een serviceherstart verandert de systeemstatus, beëindigt actieve WebAdmin-sessies en kan ook het User Portal kort onderbreken. Sla eerst de relevante logbestanden op, informeer andere beheerders en zorg bij externe locaties voor een alternatieve toegangsmethode.
Snelle procedure voor een standalonefirewall
Deze procedure is geschikt wanneer WebAdmin een Internal Server Error, HTTP 503, een onvolledige aanmeldpagina of een blijvend vastgelopen interface toont, terwijl SSH en de overige firewallfuncties beschikbaar blijven.
- Meld u als
adminaan via SSH of de lokale console. Als SSH nog niet is geconfigureerd, legt Via SSH verbinding maken met Sophos Firewall uit hoe u veilige toegang voorbereidt. - Open 5. Device Management > 3. Advanced Shell.
- Toon de meest recente WebAdmin-fouten en kopieer relevante uitvoer voor de wijzigingsdocumentatie of een supportcase:
tail -n 80 /log/tomcat.log
tail -n 80 /log/apache.log
tail -n 80 /log/error_log.log
- Controleer de huidige servicestatus:
service -S | grep -iE 'tomcat|apache'
- Als een service
STOPPEDtoont, voert u alleen de bijbehorende startopdracht uit:
# Als tomcat STOPPED is:
service tomcat:start -ds nosync
# Als apache STOPPED is:
service apache:start -ds nosync
- Als een service
DEADtoont, herstart u alleen die service. Als beideRUNNINGtonen maar WebAdmin onbruikbaar blijft, begint u mettomcat:
service tomcat:restart -ds nosync
Test WebAdmin opnieuw. Voer de volgende opdracht alleen uit als apache DEAD toont of als het probleem na de herstart van tomcat blijft bestaan:
service apache:restart -ds nosync
- Wacht enkele seconden, open WebAdmin opnieuw vanuit het bedoelde beheernetwerk en controleer nogmaals de servicestatus:
service -S | grep -iE 'tomcat|apache'
Beide services moeten RUNNING tonen. De functietest is echter doorslaggevend: de aanmelding, het dashboard, Log Viewer en een niet-kritieke configuratiepagina moeten stabiel laden. Een actief proces bewijst op zichzelf niet dat WebAdmin correct werkt.
Inactieve SSH-sessies worden na 15 minuten gesloten. Bereid daarom de logcontrole, herstart en validatie voor voordat u Advanced Shell opent, zodat een verlopen sessie de procedure niet onderbreekt.
Controleren of een serviceherstart passend is
Achter de servicenaam tomcat draait de Jetty-webapplicatieserver; apache is de Apache HTTP Server. WebAdmin en het User Portal gebruiken beide componenten. De bijbehorende logbestanden staan in Advanced Shell:
- Applicatieserver:
/log/tomcat.log - Webserver:
/log/apache.logen/log/apache_access.log - Overige webserverfouten:
/log/error_log.log
Niet elk WebAdmin-probleem ontstaat in deze services. Het type fout bepaalt de volgende stap:
Internal Server Error,HTTP 503of een onvolledige aanmeldpagina: Controleertomcat,apacheen de genoemde logbestanden. Een gerichte herstart is hier zinvol.- Certificaatwaarschuwing: Controleer de certificaatnaam, geldigheid en vertrouwensketen. Een serviceherstart corrigeert geen onjuist certificaat.
- Time-out of alleen vanuit één netwerk geen toegang: Controleer de route, het beheernetwerk en Administration > Device access. Lokale firewallservices worden toegestaan via Device Access en niet via een gewone firewallregel. Device Access en Local Service ACL legt de veilige configuratie uit.
- Slechts één browser is getroffen: Test een privésessie, een tweede browser of een andere beheerclient voordat u iets op de firewall wijzigt.
- WebAdmin, SSH, VPN of andere services vallen tegelijk uit: Dit wijst eerder op systeembelasting, opslag, de database, HA of een algemeen systeemprobleem. Herstart niet willekeurig services.
Als er een firmware-, hotfix- of patroonupdate, HA-synchronisatie, supportdebugsessie of actieve Central-taak loopt, moet dat proces eerst worden vastgesteld en waar mogelijk worden voltooid. Anders is later moeilijk te bepalen of het probleem door de update, Central, HA of de serviceherstart is veroorzaakt.
Bewijsmateriaal bewaren vóór de ingreep
Een herstart kan actuele foutmeldingen uit de zichtbare context laten verdwijnen. Noteer voor een terugkerend probleem of een supportcase ten minste het tijdstip, de SFOS-build, het getroffen toegangspad en de meest recente meldingen uit tomcat.log, apache.log en error_log.log.
Als WebAdmin nog gedeeltelijk werkt, kunnen afzonderlijke logbestanden of een Consolidated Troubleshooting Report worden gedownload via Diagnostics > Tools. Als alleen de shell nog beschikbaar is, legt Sophos Firewall-logbestanden opslaan voor support en analyse de procedure uit. In een HA-cluster bewaart elke node zijn eigen logbestanden; controleer Primary en Auxiliary indien nodig afzonderlijk.
Controleer vóór een herstart in productie ook:
- of andere beheerders of een actieve wijziging worden getroffen;
- of SSH, de lokale console, Sophos Central of een andere beheerverbinding een terugweg biedt;
- of WebAdmin de enige getroffen service is;
- of voor een HA-cluster de juiste node en actuele servicespecifieke Sophos-instructies beschikbaar zijn.
Sophos Firewall-services veilig opnieuw starten legt de algemene omgang met servicenamen, status, logbestanden en HA-grenzen uit. Problemen met Sophos Firewall oplossen: services en logbestanden bevat meer koppelingen tussen functies en logbestanden.
Het resultaat controleren en terugkerende problemen onderzoeken
Lees de logbestanden na de herstart opnieuw. Nieuwe fouten direct na het starten zijn nuttiger dan oude meldingen zonder tijdsaanduiding:
tail -n 80 /log/tomcat.log
tail -n 80 /log/apache.log
tail -n 80 /log/error_log.log
Open daarna het dashboard, Log Viewer en een niet-kritieke pagina. Beperk tijdelijk toegestane SSH- of Device Access-toegang opnieuw tot de bedoelde beheerbronnen.
Als het probleem terugkeert, was de serviceherstart slechts een tijdelijk herstel. Het onderzoek naar de hoofdoorzaak moet dan het volgende omvatten:
- vrije ruimte op partities, lokale rapporten en databasestatus;
- CPU- en RAM-belasting en opvallende systeemlogboeken;
- gelijktijdige beheerderssessies of intensief gebruik van packet capture;
- actieve of mislukte Central-taken;
- HA-rol, synchronisatie en de getroffen node;
- wijzigingen aan configuratie, certificaat, interface of Device Access vlak voor het probleem.
Opslag en rapporten van Sophos Firewall beheren helpt bij opslag- en rapportageproblemen. Wijzigingen vóór de storing kunnen worden nagegaan met de Audit Trail-logbestanden van Sophos Firewall.
Een korte operationele notitie voorkomt dat een terugkerend probleem alleen met herhaalde herstarts wordt behandeld:
Datum, tijd en tijdzone:
Firewall en eventuele HA-node:
SFOS-versie en build:
Symptomen:
Gecontroleerde logbestanden:
Uitgevoerde opdracht:
Resultaat en volgende actie:
Als WebAdmin nog steeds niet beschikbaar is
Als een service STOPPED of DEAD blijft, de herstart een fout oplevert of het probleem onmiddellijk terugkeert, sla dan tomcat.log, apache.log, error_log.log, de systeemstatus en het CTR op voor analyse met Sophos Support. Het willekeurig herstarten van andere services verslechtert waarschijnlijk vooral het bewijsmateriaal.
Als zowel WebAdmin als SSH niet bereikbaar zijn, hangt het herstelpad af van de omgeving: de lokale console via een consolekabel of Micro-USB op ondersteunde modellen, Sophos Central, een voorbereide HA-terugvaloptie of een geplande herstart. Bepaal op externe locaties wie lokale toegang kan verkrijgen als de firewall niet correct opstart. Start in een HA-cluster niet zonder controle een failover uitsluitend omdat WebAdmin niet reageert, zolang het productieverkeer normaal blijft doorstromen.
Een volledige herstart is ingrijpender dan het herstarten van de getroffen services. Overweeg deze alleen als meerdere centrale services zijn getroffen, de firewall instabiel blijft, een firmware- of hotfixproces dit vereist of Sophos Support dit aangeeft. Controleer eerst de back-up, het onderhoudsvenster en de gevolgen voor VPN, routing, RED, wireless en gepubliceerde services. Back-up en herstel van Sophos Firewall correct plannen legt de voorbereiding uit.