Sophos Firewall Start de WebAdmin GUI opnieuw

Als de Sophos Firewall WebAdmin GUI niet langer toegankelijk is, hoeft de hele firewall niet onmiddellijk opnieuw te worden opgestart. Vaak is het voldoende om de WebAdmin-services gecontroleerd opnieuw op te starten met behulp van de Advanced Shell. Dit is aanzienlijk minder ingrijpend dan een volledige herstart en kan waardevolle tijd besparen tijdens een ondersteunings- of onderhoudsvenster.

Typische symptomen zijn:

• De WebAdmin GUI toont Internal Server Error.
• Inlogpagina of dashboard worden niet meer volledig geladen.
• WebAdmin reageert erg traag of blijft hangen na een klik.
• Andere services zoals routing, VPN of firewallregels blijven actief.
• SSH of lokale console zijn nog steeds toegankelijk.

In de praktijk kan dit gebeuren na zware GUI-belasting, meerdere gelijktijdige beheerderssessies, intensief gebruik van pakketopname of algemene problemen met bronnen. Als de firewall over het algemeen onstabiel is, partities vol zijn of meerdere services niet beschikbaar zijn, zou de WebAdmin GUI niet het enige moeten zijn waar u rekening mee moet houden. Dan passen Sophos Firewall services en logs, Sophos Firewall Services veilig opnieuw starten en Controleer opslagruimte en beheer rapporten ook.

⚠️ Belangrijk: Een herstart van de service is een interventie op de firewall. Voordat productieve wijzigingen kunnen worden aangebracht, moet het duidelijk zijn wie er verbonden is, of er een onderhoudsvenster nodig is en of er alternatieve toegang via SSH, lokale console of HA-partner beschikbaar is.

Vereisten

Voor een gerichte herstart heeft u nodig:

• Toegang tot gebruiker admin.
• SSH-toegang of lokale consoletoegang.
• Toegang tot Advanced Shell.
• Een duidelijk foutbeeld: WebAdmin wordt getroffen, maar de firewall hoeft niet volledig opnieuw te worden opgestart.
• Een zo kort mogelijke onderhouds- of diagnosetijd als meerdere beheerders betrokken zijn.

Als SSH nog niet is voorbereid, zal Sophos Firewall via SSH verbinden helpen. De toegang zelf wordt beheerd via Administration > Device access. Device Access correct configureren is het juiste basisartikel voor het beveiligen van HTTPS/WebAdmin en SSH.

Na de SSH-login opent men Advanced Shell via 5. Device Management > 3. Advanced Shell. Sophos sluit inactieve SSH-sessies na 15 minuten. Bij een GUI-incident moeten logcontrole, servicestatus en herstart daarom zonder lange pauzes worden uitgevoerd, of moet de sessie indien nodig bewust opnieuw worden geopend.

Controleer kort voordat u opnieuw opstart

Voordat u de services opnieuw start, moet u het probleem isoleren:

1. Controleer of alleen WebAdmin getroffen wordt of dat VPN-, routing-, DNS- of firewallregels ook falen.
2. Test indien mogelijk met een tweede browser of privévenster.
3. Controleer of er momenteel andere beheerders in de GUI werken.
4. Log in via SSH en open de Advanced Shell.
5. Bekijk eventueel kort de betreffende logs.

De belangrijkste logbestanden zijn:

• WebAdmin-webserver: /log/apache.log en /log/apache_access.log.
• WebAdmin-applicatie: /log/tomcat.log.
• GUI/systeemfout: /log/error_log.log.

Voorbeeld van een snelle visuele inspectie:

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

Als u een back-up wilt maken van de logboeken voor een ondersteuningsaanvraag, moet u deze exporteren voordat u opnieuw opstart. Het proces bevindt zich in Sophos Firewall logs voor support en analyse veiligstellen.

Classificeer het foutpatroon correct

Niet elk WebAdmin-probleem wordt veroorzaakt door tomcat of apache. Voordat u opnieuw start, zal een korte classificatie helpen:

Typische classificatie:

• WebAdmin toont Internal Server Error: Vaak ligt dit aan de GUI-applicatie of webserver. Controleer tomcat.log en apache.log en start de services specifiek opnieuw.
• Browser rapporteert certificaatwaarschuwing: Controleer eerst het certificaat, de naam en de vertrouwensketen, start de services niet rechtstreeks opnieuw.
• Verbinding loopt in time-out: Dan zijn Device Access, routing, ACL, VPN of beheernetwerk waarschijnlijker. Controleer beschikbaarheid en Administration > Device access.
• Inloggen werkt, dashboard blijft daarna hangen: Controleer GUI-belasting, sessie, rapporten, geheugen of database.
• WebAdmin en SSH zijn niet toegankelijk: Dan gaat het meer om toegangspad, Device Access of systeemstatus. Controleer lokale console, HA-partner of centraal beheer.
• Verschillende services mislukken tegelijkertijd: Dit duidt eerder op een systeemprobleem dan op een puur GUI-probleem. Maak een back-up van logboeken, controleer de opslagruimte en evalueer het opnieuw opstarten of de ondersteuningsaanvraag.

Deze classificatie voorkomt dat WebAdmin-services onnodig opnieuw worden opgestart in het geval van een netwerk- of apparaattoegangsprobleem. Als alleen de toegang vanaf een specifiek netwerk mislukt, is Device Access en Local Service ACL tot Sophos Firewall meestal belangrijker dan een herstart van de service.

Wanneer is het beter om de herstart uit te stellen

Het herstarten van tomcat en apache is relatief gericht, maar is nog steeds een interventie op het administratieve niveau van de firewall. In deze situaties moet u eerst het volgende kort stabiliseren of documenteren:

• Firmware-update, hotfix of patroonupdate is actief: Interveneer niet tegelijkertijd in de WebAdmin-services zolang het updateproces actief is.
• HA-cluster is momenteel aan het synchroniseren: Controleer eerst de HA-rol, synchronisatie en actief knooppunt.
• Ondersteuning voor foutopsporing of logboekverzameling is actief: Sla eerst de relevante logboeken op en start vervolgens de services opnieuw.
• Centrale taak is momenteel actief: Controleer de takenwachtrij zodat een voortdurende centrale wijziging niet gepaard gaat met een lokaal GUI-probleem.
• Er wordt slechts één beheerdersbrowser getroffen: Test eerst de privésessie, tweede browser of andere client.

Deze korte rem scheelt uitlegwerk achteraf. Als na een herstart niet meer duidelijk is of de fout afkomstig is van WebAdmin, Central, HA of een lopende update, wordt de analyse onnodig moeilijk.

Start de WebAdmin-services opnieuw

De WebAdmin GUI is voornamelijk afhankelijk van twee services:

• tomcat: WebAdmin-applicatie.
• apache: WebAdmin-webserver.

Controleer vóór de herstart eerst de status:

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

Als een service STOPPED is, is gericht starten netter dan blind opnieuw starten:

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

Als tomcat of apache DEAD tonen, of als ze RUNNING tonen maar WebAdmin nog steeds niet werkt, kunnen beide services na elkaar opnieuw worden gestart:

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

Wacht vervolgens een paar seconden en open de WebAdmin GUI opnieuw. Als het inloggen weer werkt, controleer dan alsnog of er terugkerende fouten zichtbaar zijn in de Log Viewer of in de systeemlogboeken.

Controleer de status

Als opnieuw opstarten niet voldoende is, kunt u de status van de services controleren:

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

U kunt ook controleren of de services in de servicelijst verschijnen:

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

De algemene toewijzing van services, modules en logbestanden vindt u in Sophos Firewall Troubleshooting: services en logs. Er wordt ook uitgelegd wanneer Log Viewer, Advanced Shell of individuele logbestanden de betere analysebron zijn.

Valideren na opnieuw opstarten

Als WebAdmin opnieuw laadt, is het probleem nog niet volledig opgelost. Controleer even of de GUI stabiel blijft en of de oorzaak weer zichtbaar wordt.

Nuttige vervolgcontrole:

1. Open WebAdmin vanuit het beoogde beheernetwerk.
2. Log in met een beheerdersaccount en testdashboard, Log Viewer en een niet-kritieke configuratiepagina.
3. Controleer tomcat.log, apache.log en error_log.log opnieuw op nieuwe fouten.
4. Controleer opslagruimte en lokale rapporten als de GUI voorheen traag of leeg was.
5. Sluit open beheerderssessies, browsercache of parallelle beheerderstoegang uit als oorzaak.
6. Beperk de toegestane SSH- of apparaattoegang tijdelijk opnieuw.
7. Controleer voor HA-clusters of u op het verwachte knooppunt werkt.

Als het probleem zich opnieuw voordoet, mag u tomcat en apache niet elke dag opnieuw opstarten. Dan is een root-cause analyse nodig: opslagruimte, databasestatus, rapporten, GUI-fouten, systeembelasting, HA-rol en recente configuratiewijzigingen. Voor wijzigingen kort voor de fout is Sophos Firewall Audit Trail-logs controleren nuttig.

Als WebAdmin nog steeds niet beschikbaar is

Als de GUI nog steeds niet beschikbaar is nadat u tomcat en apache opnieuw hebt opgestart, moet u niet zoveel services opnieuw opstarten als u wilt. Een gestructureerde beperking is logischer:

• Controleer Device Access: Is HTTPS/WebAdmin toegestaan ​​vanuit de huidige zone en bron?
• Browser uitsluiten: Testcache, privésessie of tweede browser.
• Certificaat controleren: Een verlopen of onjuist certificaat kan de toegang bemoeilijken, maar veroorzaakt doorgaans geen echte interne serverfout.
• Controleer de systeembelasting: Hoog CPU-, RAM- of schijfgebruik kan van invloed zijn op WebAdmin.
• Controleer schijfruimte: Volledige partities kunnen GUI- en rapportageproblemen veroorzaken.
• Controleer logboeken: Scan tomcat.log, apache.log en error_log.log op huidige fouten.
• Let op HA-context: Controleer voor HA-clusters op welk knooppunt u werkt en welk knooppunt actief is.
• Controleer recente wijzigingen: Audit Trail en Config Studio kunnen laten zien of Device Access, certificaat-, interface- of beheerdersinstellingen onlangs zijn gewijzigd.

Als WebAdmin en SSH niet toegankelijk zijn, blijft er, afhankelijk van de locatie, alleen de lokale console, Sophos Central-beheer, HA-failover of een geplande herstart over. In productieve omgevingen moet deze casus worden voorbereid tijdens het bedienings- en herstelproces.

Externe sites en HA-clusters

Met een enkele firewall op de hoofdlocatie is een herstart van WebAdmin doorgaans eenvoudig te controleren. Voor externe locaties of HA-clusters dient u vooraf meer in detail te controleren via welk pad de toegang plaatsvindt en welk terugvalniveau beschikbaar is.

Belangrijke vragen:

• Vindt de toegang rechtstreeks plaats vanuit het beheernetwerk, via VPN, via Sophos Central of via een jumphost?
• Is SSH echt toegankelijk, of werkt alleen een bestaande WebAdmin-sessie?
• Is er iemand ter plaatse die het toestel eventueel kan controleren?
• Voor HA: aan welk knooppunt werkt u en welk knooppunt is momenteel primair?
• Zal een geplande failover meer risico met zich meebrengen dan het gericht opnieuw opstarten van tomcat en apache?
• Worden logboeken en tijd gedocumenteerd voordat een failover of reboot de analyse bemoeilijkt?

In HA-omgevingen mag u niet automatisch een failover uitvoeren alleen maar omdat WebAdmin op het actieve knooppunt blijft hangen. Als het verkeer doorgaat, is een gerichte herstart van de GUI-service vaak minder ingrijpend. Als echter meerdere services worden getroffen, het actieve knooppunt instabiel lijkt of de toegang volledig verloren gaat, hoort de zaak thuis in een gecontroleerd HA- of siteherstelproces.

Wanneer een volledige herstart logischer is

Opnieuw opstarten is niet de eerste maatregel voor een hangende WebAdmin GUI. Maar het kan nuttig zijn als:

• diverse centrale diensten reageren niet meer
• de firewall blijft instabiel nadat de service opnieuw is opgestart
• Geheugen- of databaseproblemen zijn opgelost en een schone start is vereist
• Sophos Support of een onderhoudsvenster geeft dit aan
• een HA-cluster kan gecontroleerd failoveren

Voordat u opnieuw opstart, moeten de back-up, onderhoudsvensters, locatietoegang en de impact op VPN, routing, RED, draadloze en gepubliceerde services bekend zijn.

Controlelijst

• Foutafbeelding gedocumenteerd: Internal Server Error, time-out of lege WebAdmin-pagina.
• SSH of lokale console beschikbaar.
• Advanced Shell geopend.
• tomcat.log en apache.log kort gecontroleerd.
• Status gecontroleerd met service -S | grep -iE 'tomcat|apache'.
• service tomcat:restart -ds nosync uitgevoerd.
• service apache:restart -ds nosync uitgevoerd.
• WebAdmin opnieuw getest.
• Gecontroleerde opslagruimte, Device Access en systeemlogboeken op terugkerende fouten.
• Logboeken opgeslagen voor ondersteuning bij productieverstoringen.
• Doorlopende updates, HA-synchronisatie, centrale taken of ondersteuningsdebug gecontroleerd voordat opnieuw werd opgestart.
• Tijdelijke SSH- of Device Access-machtigingen zijn opnieuw verwijderd.
• Terugkerende fouten worden niet alleen verborgen wanneer de service opnieuw wordt opgestart.

Veelgestelde vragen