Starta om Sophos Firewall Services säkert

En enskild Sophos Firewall Service startas säkrast om under System services > Services. Om servicen inte finns där är det inte ett skäl att köra ett godtyckligt shellkommando: använd Advanced Shell endast med aktuella, servicespecifika Sophos-instruktioner eller inom ett supportärende. Identifiera först den berörda servicen och avgör vilka anslutningar en omstart kan avbryta.

⚠️ Viktigt: En serviceomstart ändrar systemets tillstånd och kan avbryta VPN, routing, DNS, DHCP, webbåtkomst eller administratörsåtkomst. Spara status och loggar i förväg och ha en alternativ åtkomstväg för fjärrplatser.

Starta om en service via WebAdmin

Före klicket ska aktuell status, exakt tidpunkt för felet och det funktionstest som misslyckas dokumenteras. Relevanta filer kan hämtas separat under Diagnostics > Tools > Troubleshooting logs. För ett supportärende innehåller en Consolidated troubleshooting report (CTR) även systemstatus, processer och resursanvändning. För en fjärrplats ska förkontrollen dessutom omfatta underhållsfönster och alternativ åtkomst.

1. Öppna System services > Services.
2. Kontrollera berörd service och dess aktuella status. Starta inte en service som avsiktligt är stoppad eller inte konfigurerad.
3. Klicka på Restart under Manage.
4. Vänta tills servicen återgår till sin tidigare status Running och testa därefter berörd funktion.

WebAdmin visar bland annat Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, DHCPv6 server, Router advertisement service, Hotspot samt Packet capture and Live connections. Om en service inte är konfigurerad förblir knappen inaktiverad. Anti-spam kräver en inkommande eller utgående spam policy. Om Packet capture and Live connections stoppas avslutas pågående captures och vyn Live Connections blir otillgänglig. Om Packet Capture inte startar trots att reglaget är aktiverat anger Sophos uttryckligen denna WebAdmin-omstart som återställningssteg.

En serviceomstart har ingen rollback som återställer aktiva sessioner. Tillståndet som ska bevaras är därför den servicestatus som dokumenterades i förväg. Om en tidigare aktiv service inte återgår till Running ska man inte klicka på Restart upprepade gånger. Dokumentera en ny tidpunkt, hämta loggen eller CTR och undersök felet eller kontakta Sophos Support.

Under Control Center > System visar servicestatus om en service har stoppats eller inte kunde starta. Det är en bra utgångspunkt men ersätter inte ett funktionstest. Om endast WebAdmin-gränssnittet har slutat svara, följ Starta om Sophos Firewall WebAdmin GUI.

Antivirustjänsten stoppad efter misslyckade mönsteruppdateringar

Om Antivirus-servicen förblir stoppad efter misslyckade uppdateringar av SAVI- och AVIRA-mönster ska man inte klicka på Restart flera gånger. Spara först firmwareversion och build, tidpunkten för felet samt de tillhörande filerna avd.log och up2date_av.log. Under Backup & firmware > Pattern updates dokumenteras även den senaste lyckade uppdateringen och aktuell status: Ready to install, Downloading, Success eller Failed. Det allmänna flödet för att kontrollera dessa tillstånd finns i Konfigurera och kontrollera mönsteruppdateringar i Sophos Firewall.

Sophos registrerar problemet som NC-180066; det är åtgärdat i SFOS 22.0 MR2 Build 546. Om symptomen stämmer på en äldre SFOS 22-build ska den stödda uppgraderingsvägen kontrolleras med förberedelserna för firmwareuppdatering och systemet först uppdateras till MR2 Build 546 eller en senare godkänd version. En enstaka omstart under System services > Services är generellt tillgänglig, men Sophos dokumenterar den varken som workaround eller som åtgärd för NC-180066, och den ersätter inte firmwareuppdateringen.

Klicka först efter firmwareuppdateringen på Update pattern now under Backup & firmware > Pattern updates. Uppdateringen av det berörda Antivirus-mönstret måste nå statusen Success och Antivirus-servicen måste förbli aktiv. Enbart den visade servicestatusen räcker inte: även mönsteruppdateringen måste slutföras utan fel. Om problemet återkommer i MR2 Build 546 eller senare ska sparade loggar och tidpunkter lämnas till Sophos Support i stället för att fortsatt anta att det är NC-180066.

Starta om IPsec via VPN Management

CLI-huvudmenyn erbjuder under 6. VPN Management > Restart VPN Service en stödd omstart av VPN-tjänstens daemon. Sophos varnar för att åtgärden kopplar ned alla VPN-tunnlar. Om bara en VPN-anslutning ska återupprättas används i stället dess åtgärd i WebAdmin. Spara tunnelstatus, exakt tidpunkt och strongswan.log före daemonomstarten och kontrollera sedan Child SAs, peers och verklig applikationstrafik på nytt. Ett proposal-, routing- eller NAT-fel löses inte av omstarten.

I samma meny kan RSA-nyckelparet som används för IPsec-autentisering genereras på nytt. Det är inte en tjänsteomstart utan ett nyckelbyte. För anslutningar med RSA key behöver peers därefter den nya offentliga nyckeln, och fjärråtkomstanvändare måste hämta sin VPN-konfiguration på nytt. Sophos dokumenterar ingen återgång till det gamla nyckelparet med ett klick. Använd åtgärden endast som en planerad rotation med fullständig tunnelinventering, underhållsfönster och alternativ administratörsåtkomst, inte som ett allmänt troubleshootingsteg. Den löser inte heller problem med PSK eller certifikat.

Starta om en service via Advanced Shell

Använd Advanced Shell endast när aktuella Sophos-instruktioner anger exakt service och kommando eller när Sophos Support tillhandahåller dem. För SSH-åtkomst och kontroll av värdnyckeln, följ Anslut till Sophos Firewall via SSH. SSH bör endast tillåtas från betrodda administrationsnät; relevanta inställningar beskrivs i Device Access och Local Service ACL. Inaktiva SSH-sessioner stängs efter 15 minuter.

Öppna följande efter inloggning:

5. Device Management > 3. Advanced Shell

Device Console under menyalternativ 4 validerar sina dokumenterade kommandon och är avsedd för stödd nätverks- och systemdiagnostik. Advanced Shell under 5. Device Management > 3. Advanced Shell är däremot ett Linux-shell med fullständig åtkomst till databaser och systemservices. Konfigurationsändringar som görs där är inte beständiga och ingår inte i backuper. Utför först skrivskyddade kontroller och starta om först när servicenamn, påverkan, underhållsfönster och återställningsåtkomst har kontrollerats.

1. Kontrollera servicenamn och status

Kända services och deras aktuella status visas med:

service -S

Utdata kan filtreras efter misstänkt service. För IPsec exempelvis:

service -S | grep -i strongswan

RUNNING betyder att servicen körs. STOPPED, UNREGISTERED eller UNTOUCHED innebär inte automatiskt ett fel: beroende på firmware och konfiguration kan en service avsiktligt vara inaktiv eller oregistrerad. Kontrollera först om tillhörande funktion, policy eller licens faktiskt används.

Om det tekniska servicenamnet är oklart, se Sophos Firewall troubleshooting: services och loggar. Där kopplas funktionsområden till sina loggfiler.

2. Kontrollera loggar före ingreppet

En omstart kan dölja viktiga ledtrådar om orsaken. För IPsec bör man därför först läsa strongswan.log och spara relevanta meddelanden:

less /log/strongswan.log

Avsluta less med q. Vid större analyser kan loggarna först exporteras enligt Spara Sophos Firewall-loggar för support och analys. I HA-kluster lagrar varje nod bara loggar för trafiken den behandlar; båda noderna kan behöva kontrolleras separat.

3. Starta om servicen på en fristående brandvägg

Följande exempel förutsätter en fristående brandvägg. Före körning måste service -S | grep -i strongswan bekräfta servicen. Omstarten kan avbryta site-to-site- och Remote Access IPsec-anslutningar. Kontrollera tunnlar, peers och underhållsfönster först.

Sophos dokumenterar detta mönster:

service <service>:restart -ds nosync

Ett fullständigt exempel för IPsec-servicen är:

service strongswan:restart -ds nosync

Den generiska syntaxen och service -S är dokumenterade i den aktuella SFOS 22-hjälpen, där strongswan kopplas till IPsec-servicen. Exemplet har inte körts på en brandvägg och beskrivs därför inte som labbtestat. Gissa inte namnet på någon annan service från en lista.

För vidare analys, se Sophos Firewall IPsec troubleshooting.

⚠️ HA-kluster: Använd inte kommandot för en fristående brandvägg utan kontroll. Beroende på service och situation använder Sophos instruktioner sync eller nosync; någon tillräcklig allmän regel är inte offentligt dokumenterad. Service, nod, SFOS-build och synkroniseringsläge måste framgå av en aktuell servicespecifik Sophos-instruktion eller ett supportärende.

Separata stop- och start-kommandon ska endast användas när Sophos Support instruerar det för den aktuella servicen. Mellan de båda kommandona förblir servicen helt stoppad.

Inte heller denna omstart har någon tillståndsbevarande rollback: frånkopplade Security Associations och sessioner kan inte återställas. Det säkra stoppkriteriet är jämförelsen med förkontrollen. Om strongswan inte återgår till sitt tidigare tillstånd eller om tunnlarna inte återupprättas ska ingen andra omstart göras. Spara loggar och CTR och eskalera problemet.

4. Validera resultatet

Efter omstarten kontrolleras status, logg och den faktiska funktionen:

service -S | grep -i strongswan
tail -f /log/strongswan.log
grep -i 'error' /log/strongswan.log

tail -f visar nya meddelanden fortlöpande och stoppas med Ctrl+C. Jämför meddelandena med tidpunkten som noterades före omstarten; en ofiltrerad grep kan även visa gamla fel. Kontrollera därefter IPsec-tunnlarna och testa en värd på fjärrplatsen. Statusen RUNNING bevisar inte i sig att anslutningen fungerar igen.

Om omstarten misslyckas bör även csc.log kontrolleras. Vid HA-problem kan beroende på felbilden även ha.log, msync.log och applog.log vara relevanta.

Vanliga services och lämpliga funktionstester

Det exakta servicenamnet måste bekräftas på den berörda brandväggen med service -S. De viktigaste kopplingarna är:

• strongswan: Site-to-site- och Remote Access IPsec. Kontrollera därefter tunnelstatus, strongswan.log och nåbarheten till fjärrplatsen.
• dnsd: DNS-service. Testa därefter intern och extern namnuppslagning, dnsd.log och befintliga DNS Request Routes.
• dhcpd: DHCP-server. Under en omstart kan nya eller förnyande klienter bli utan svar. Testa därefter lease-tilldelning och dhcpd.log.
• awed: Kommunikation mellan brandväggen och AP/APX-enheter. Kontrollera därefter accesspunkternas anslutningsstatus och awed.log.
• zebra: Installerar dynamiska och statiska routes i kärnan. En omstart är därför ingripande och bör endast utföras med en konkret Sophos-instruktion; testa därefter routingtabell, gateways och faktiska sökvägar.
• smtpd: SMTP-proxy i MTA-läge. Den transparenta legacy-proxyn använder en annan service; kontrollera driftsläge och smtpd_*-loggar före ingreppet. Testa därefter kontrollerad sändning och mottagning av e-post.

För WAF, Web proxy, IPS, Authentication och services som finns i WebAdmin är omstart via System services > Services vanligtvis tydligare än ett shellkommando.

När en serviceomstart inte är lämplig

En enskild omstart passar när en specifik modul berörs och resten av brandväggen är stabil. Starta inte om services blint när:

• orsaken eller berörd service fortfarande är oklar;
• flera centrala services slutar fungera samtidigt;
• just denna service ger den sista fjärråtkomsten;
• felet kan återskapas och loggarna ännu inte har sparats;
• samma service redan har startats om flera gånger;
• HA-roll, nod eller nödvändigt synkroniseringsläge är oklart.

Om flera services berörs, kontrollera först systembelastning, lagringsutrymme, databasstatus, HA samt de senaste konfigurations- eller firmwareändringarna. Upprepade omstarter döljer ofta bara orsaken.

En fullständig reboot är mer ingripande och bör endast övervägas om brandväggen förblir instabil som helhet, om en firmware- eller hotfixprocess kräver den eller om Sophos Support instruerar det. I Device Console startar system restart om brandväggen; i ett HA-kluster orsakar kommandot en failover. system shutdown stänger däremot bara av den. Före båda åtgärderna ska målenheten och HA-noden, backupen, underhållsfönstret samt lokal åtkomst eller out-of-band-åtkomst kontrolleras; vid avstängning måste den återställningsmetoden faktiskt kunna slå på enheten igen. Efter omstarten kontrolleras HA-roll och synkronisering, servicestatus och berörda datavägar. Avbrutna sessioner kan inte återställas. Om enheten inte kommer tillbaka ska kommandot inte upprepas; använd den förberedda återställningsåtkomsten och kontakta Sophos Support vid behov. Se Planera backup och restore av Sophos Firewall korrekt.

Dokumentera ingreppet kortfattat

Vid återkommande problem eller ett supportärende räcker en kort notering. Den visar senare om omstarten gav en varaktig lösning eller bara dolde ett symptom:

Date/time and time zone:
Firewall / HA node:
Service and command:
Reason:
Users/sites affected:
Logs checked before restart:
Result after restart:
Next action:

Före ingreppet dokumenteras tidpunkt, berörd funktion och relevanta loggmeddelanden. Därefter noteras servicestatus, funktionstest och nästa åtgärd. Ta bort tillfälliga SSH- eller Device Access-regler och inaktivera debuglägen efter analysen.