Starta om Sophos Firewall Services säkert

En omstart av enskilda Sophos Firewall Services kan hjälpa när en modul inte längre reagerar korrekt, en logg inte längre visar nya poster eller Sophos Support begär en riktad omstart. Den ersätter däremot inte ren troubleshooting. En felaktig service-omstart kan kort avbryta VPN-tunnlar, routing, WebAdmin, DNS, DHCP, reporting eller andra funktioner.

Artikeln förklarar hur man startar om Services via WebAdmin eller Advanced Shell, kontrollerar passande loggar i förväg och därefter kontrollerar att tjänsten kör rent igen. Om det först är oklart vilken teknisk service som hör till vilken modul hjälper översikten Sophos Firewall Troubleshooting: Services och loggar. För grundläggande CLI-säkerhet, debug och tcpdump passar även Sophos Firewall CLI Troubleshooting: viktiga kommandon.

⚠️ Viktigt: Service-omstarter bör planeras i produktionsmiljöer. I förväg bör det vara tydligt vilken tjänst som berörs, vilka användare eller tunnlar som kan avbrytas och om det finns alternativ åtkomst till brandväggen.

När en service-omstart är meningsfull

En riktad service-omstart är meningsfull när en konkret modul är berörd och resten av brandväggen i grunden kör stabilt.

Typiska exempel:

• WebAdmin laddar inte längre, men routing och firewallregler fungerar fortfarande.
• En VPN-tjänst hänger medan andra firewallfunktioner är utan anmärkning.
• En logg visar aktuella fel för en viss tjänst.
• Sophos Support anger en konkret service som ska startas om.
• En tjänst blev inte ren aktiv efter en konfigurationsändring.

Det är inte meningsfullt att blint starta om flera Services bara för att problemet ännu är oklart. Då bör man först kontrollera loggar, systemlast, lagringsutrymme, HA-status, routing och berörda moduler.

När man inte bör starta om Services

En service-omstart är lockande eftersom den verkar snabbt. I vissa situationer försämrar den dock analysen eller skapar ytterligare avbrott.

• Orsaken är fortfarande helt oklar: Omstarten förändrar tillståndet och kan dölja viktiga spår i loggar eller statusutdata.
• Flera centrala tjänster faller bort samtidigt: Då är ofta inte en enskild service problemet, utan systemlast, lagringsutrymme, databas, HA eller plattformstillstånd.
• Brandväggen är bara nåbar via just denna tjänst: En omstart kan göra att den sista fjärråtkomsten går förlorad.
• Produktiva VPN-, routing- eller DHCP-tjänster berörs: Befintliga användare, platser eller leases kan avbrytas kort.
• Debug kör redan och felet är reproducerbart: Säkra först relevanta loggar, starta sedan om.
• Servicen har redan startats om flera gånger: Då behövs orsaksanalys i stället för upprepning.

Om en omstart ändå behövs bör man minst notera aktuell tidpunkt, berörda användare eller platser, service-namn, loggfil och förväntad påverkan.

Kontrollera före omstart

Före en service-omstart bör man kort dokumentera vad som berörs. Det sparar tid om felet återkommer eller ett supportärende behövs.

Praktisk förkontroll:

1. Avgränsa berörd modul, till exempel WebAdmin, IPsec, DNS, DHCP, IPS eller WAF.
2. Kontrollera om brandväggen totalt sett är stabil eller om flera tjänster faller bort.
3. Kontrollera om admins, VPN-användare eller kritiska platser just nu är anslutna.
4. Vid HA-kluster, kontrollera på vilken node man arbetar och vilken node som är aktiv.
5. Öppna passande loggfil och säkra de senaste meddelandena.
6. Kontrollera lagringsutrymme om debug, stora loggar eller PCAP-filer är inblandade.
7. Exportera loggar före omstarten om det behövs.
8. Fastställ avbrottskriterium: När stoppas, skjuts upp eller eskaleras omstarten?

För HA-miljöer är dessutom förstå Sophos Firewall HA Cluster-varianter relevant. Om loggar behövs för en extern analys passar säkra Sophos Firewall-loggar för support och analys.

Säkra bevis först om felet återkommer

En service-omstart kan lösa ett symptom kortvarigt, men samtidigt ändra det tillstånd som vore viktigt för orsaksanalysen. Om ett problem uppträder upprepade gånger bör man därför säkra ett litet bevisfönster före nästa omstart.

Meningsfulla minimidata:

• exakt tidpunkt med tidszon
• berörd service och berörd funktion
• senaste relevanta meddelanden från passande loggfil
• statusutdata för tjänsten före omstarten
• systemlast, lagringsutrymme eller rapport-/databasindikationer om GUI är långsamt
• berörda användare, tunnlar, gränssnitt, regler eller platser
• senaste konfigurationsändring, firmwareändring, hotfix eller HA-händelse

Detta är särskilt viktigt om samma service redan har startats om flera gånger. Då är omstarten bara en omedelbar åtgärd. Den egentliga uppgiften är att förstå varför tjänsten återkommande hänger, kraschar, blockerar eller inte längre skriver nya loggar.

Dokumentera omstart i supportfall

Om en service-omstart är del av ett supportärende, underhållsfönster eller återkommande problem bör man dokumentera åtgärden kort. Det behöver inte vara en lång rapport. Viktigt är att det senare är tydligt vilken tjänst som startades om, när, varför och med vilket resultat.

Praktisk mall för notering:

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

Denna notering är särskilt hjälpsam om ett fel återkommer efter några timmar eller dagar. Då ser man direkt om samma tjänst alltid är berörd, om omstarten bara hjälper kortvarigt eller om ett djupare problem som lagringsutrymme, databastillstånd, HA-beteende eller ett produktfel blir mer sannolikt.

Starta om Services via WebAdmin

Vissa Services kan startas om direkt via WebAdmin. Det är den enklaste vägen när GUI fortfarande är nåbart och den önskade tjänsten syns där.

Den officiella menyvägen är System services > Services. Där kan man starta, stoppa och starta om services. Om en service inte är konfigurerad är knappen under Manage gråmarkerad.

WebAdmin erbjuder främst tydligt avgränsade services, till exempel Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, DHCPv6 server, Router advertisement service, Hotspot samt Packet capture and Live connections. Före klicket bör det vara tydligt om servicen ligger direkt i datapath, om aktiva användare påverkas och hur resultatet kontrolleras efteråt.

Två detaljer är viktiga i drift: Anti-spam kan bara startas om det finns en inbound eller outbound spam policy. Om Packet capture and Live connections stoppas avslutas inte bara pågående captures, utan live connections visas inte längre.

För en första bedömning är även Control Center > System användbart. Services-statusen visar där om alla services kör normalt eller om det finns en warning eller alert. Ett klick på ikonen visar berörda services. Det ersätter inte ett funktionstest, men hjälper till att skilja ett enskilt serviceproblem från ett bredare systemtillstånd.

För djupare troubleshooting, logganalys eller tjänster utan GUI-åtgärd behövs Advanced Shell.

Om bara själva WebAdmin GUI inte längre reagerar bör denna allmänna artikel inte vara första steget. För det finns den riktade guiden starta om Sophos Firewall WebAdmin GUI.

Öppna Advanced Shell

För service-kommandon behövs Advanced Shell. Åtkomst sker oftast via SSH med användaren admin.

Om SSH ännu inte är förberett hjälper anslut till Sophos Firewall via SSH. SSH-åtkomst bör endast tillåtas från betrodda adminnät. Före inloggning bör SSH-fingerprint kontrolleras, särskilt efter reimage, hårdvarubyte eller IP-byte. Passande härdning finns i Device Access och Local Service ACL på Sophos Firewall.

Sophos stänger inaktiva SSH-sessioner efter 15 minuter. Vid längre analyser bör man därför planera körande kommandon, öppna loggvyer och möjliga avbrott medvetet.

Efter inloggning öppnar man Advanced Shell via:

5. Device Management > Advanced Shell

Advanced Shell erbjuder långtgående systemåtkomst. Kommandon bör bara köras där när den berörda tjänsten och den förväntade påverkan är tydliga.

Om bara status ska kontrolleras eller en loggfil läsas bör man först hålla sig till läsande kommandon. Omstarter, Stop/Start och debug är ingrepp och hör hemma i ett medvetet analysfönster.

Lista Services

En lista över tillgängliga Services visas med:

service -S

Om en viss tjänst söks kan man filtrera utdata:

service -S | grep strongswan
service -S | grep zebra
service -S | grep dns

Tekniska tjänstenamn är inte alltid självförklarande. Före en omstart bör tjänstenamnet därför jämföras med det berörda funktionsområdet.

• strongswan: Site-to-Site IPsec och IPsec Remote Access; tunnelstatus, motpart, planerat avbrott, strongswan.log
• zebra: routing och statiska routes; routingtabell, SD-WAN/gatewaystatus, berörda platser
• dnsd: firewallens DNS-service; DNS Request Routes, klienttest, dnsd.log
• dhcpd: DHCP-lease-tilldelning; berörd zon, lease-intervall, testklient, dhcpd.log
• awed: Wireless Controller; berörda Access Points, Central- eller lokal hantering, wireless-loggar

Den mer utförliga kopplingen finns i Sophos Firewall Troubleshooting: Services och loggar.

Starta om service

Grundmönstret för en omstart är:

service <service>:restart -ds nosync

Exempel för routing-servicen zebra:

service zebra:restart -ds nosync

Viktigt är syntaxen med mellanslag: -ds nosync. Varianter som -dsnosync är inte samma sak och bör inte tas över från gamla anteckningar.

Vid en omstart stoppas tjänsten och startas igen. Beroende på tjänst kan det avbryta aktiva anslutningar. Vid routing, VPN, DNS, DHCP, Web Proxy, WAF eller Wireless bör man därför i förväg bedöma vem som kan beröras.

Om tjänsten hör till en säkerhetsrelevant modul bör man inte bara kontrollera status efter omstarten. Avgörande är om den förväntade skydds- eller anslutningsfunktionen fungerar igen och om nya felmeddelanden uppstår i loggen.

Stoppa och starta service

Om en tjänst inte reagerar rent på restart eller Sophos Support anger det kan Stop och Start köras separat:

service zebra:stop -ds nosync
service zebra:start -ds nosync

Mellan Stop och Start bör man inte vänta onödigt länge om tjänsten behövs i produktion. Därefter bör status kontrolleras och ett funktionstest genomföras.

Kontrollera service-status

service zebra:status -ds nosync

Dessutom bör den passande loggfilen kontrolleras. För routing är det till exempel:

tail -n 80 /log/zebra.log

En lyckad status räcker inte alltid. Avgörande är om den berörda funktionen fungerar igen: VPN-tunnlar ansluter, DNS svarar, DHCP delar ut leases, WebAdmin laddar eller routing fungerar.

Exempel på vanliga Services

Följande exempel visar typiska service-omstarter och ersätter inte analys av orsaken.

Starta om Wireless Controller

service awed:restart -ds nosync

Starta om SMTP Service

service smtpd:restart -ds nosync

Starta om VPN IPsec Service

service strongswan:restart -ds nosync

Starta om DNS Service

service dnsd:restart -ds nosync

Vid IPsec-problem bör dessutom Sophos Firewall IPsec Troubleshooting användas. Vid DNS-problem är ofta konfigurera DNS Request Routes på Sophos Firewall eller DNS-/DHCP-kopplingen i Sophos Firewall Troubleshooting: Services och loggar mer relevant än en ren service-omstart.

Behandla känsliga tjänsteområden medvetet

Alla service-omstarter har inte samma påverkan. Vissa tjänster berör bara ett administrationsgränssnitt, andra ligger direkt i datapath eller styr autentisering, VPN, routing eller lokala tjänster. Ju närmare en tjänst ligger produktiv trafik, desto viktigare är underhållsfönster, loggkontroll och återgångsplan.

• IPsec / SSL VPN: Tunnlar eller Remote-Access-sessioner kan brytas; Informera användare och platser i förväg, kontrollera tunnlar aktivt efteråt
• DNS / DHCP: Namnuppslagning eller lease-tilldelning kan störas kort; Planera klienttest och loggkontroll efter omstarten
• Routing / SD-WAN: Vägar, gateway-monitoring eller platsförbindelser kan beröras; Kontrollera routingtabell, gatewaystatus och nåbarhet
• Web Proxy / IPS / TLS Inspection: Webbåtkomst eller Inspection kan påverkas kort; Kontrollera Log Viewer och berörda policies efter omstarten
• WAF / Reverse Proxy: Publicerade applikationer kan kort vara onåbara; Testa extern URL och backend-nåbarhet
• WebAdmin: Adminåtkomst avbryts kort; Håll alternativ åtkomst via SSH eller lokal konsol redo
• Reporting / databas / lagring: Analys, rapporter eller GUI-stabilitet kan beröras; starta inte om blint, kontrollera först lagringsutrymme och loggar

Om ett tjänsteområde inte är entydigt bör man först titta i Sophos Firewall Troubleshooting: Services och loggar innan en omstart körs. Vid databas-, lagrings- eller reporting-teman är en oriktad omstart sällan den bästa första åtgärden.

Validera efter omstarten

Efter en service-omstart bör man inte bara kontrollera om kommandot återkommer utan felmeddelande. Det viktiga är det funktionella testet.

Meningsfulla kontroller:

• Kontrollera service-status med service <service>:status -ds nosync.
• Kontrollera passande loggfil i /log för nya fel.
• Validera berörd funktion med ett verkligt test.
• Kontrollera Log Viewer om firewallregler, NAT, webb, IPS eller VPN är berörda.
• Vid HA-kluster, kontrollera om den aktiva noden fortsatt arbetar som väntat.
• Deaktivera debug om det aktiverades före eller under omstarten.
• Ta bort temporära SSH- eller Device-Access-frigivningar om de bara sattes för supportfallet.
• Vid återkommande fel, säkra loggar och analysera orsaken i stället för att starta om Services upprepade gånger.

Beroende på tjänst är olika funktionstester meningsfulla:

• IPsec / strongswan: tunnelstatus, Log Viewer, strongswan.log, nåbarhet till en host på motsidan
• DNS / dnsd: intern och extern namnuppslagning, DNS Request Routes, dnsd.log
• Routing / zebra: routingtabell, gateway-monitoring, ping eller traceroute via berörd väg
• WAF / Reverse Proxy: testa publicerad URL externt, reverseproxy.log, backend-nåbarhet
• WebAdmin / tomcat och apache: kontrollera login, dashboard, Log Viewer och tomcat.log
• DHCP / dhcpd: kontrollera lease-tilldelning med testklient och dhcpd.log

När en reboot är bättre

En komplett reboot är mer invasiv än en service-omstart, men kan bli meningsfull när flera centrala tjänster hänger, lagrings- eller databasproblem har åtgärdats, Sophos Support kräver det eller brandväggen fortfarande är instabil efter riktade omstarter.

Beslutet bör inte tas på magkänsla. En service-omstart är bättre när en enskild modul är tydligt berörd och brandväggen i övrigt arbetar stabilt. En reboot passar snarare när tillståndet är oklart systembrett eller fortsatt skadat efter en riktad omstart.

• Enskild tjänst hänger: Ja, om tjänst och påverkan är tydliga; Bara om omstarten inte hjälper
• Flera tjänster visar fel: Kontrollera först loggar och lagringsutrymme; Ja, om systemtillståndet totalt sett är instabilt
• Firmware- eller hotfix-fönster pågår: Inte som ersättning för planerad omstart; Ja, om uppdateringsprocessen förutsätter det
• HA-kluster är instabilt: Bara efter rollkontroll och supportgodkännande; Bara med underhållsfönster och HA-plan
• Lagringsutrymme eller databas har rensats: Bara för berörd tjänst; Ja, om Sophos Support kräver det som avslut
• Fjärråtkomst är osäker: Försiktigt, sista åtkomst kan brytas; Bara med lokal eller alternativ åtkomst

Före en reboot bör backup, underhållsfönster, platsåtkomst, HA-beteende och påverkan på VPN, RED, Wireless, routing och publicerade tjänster vara kända. Vid fjärrplatser behövs dessutom en returväg om brandväggen inte kommer online rent efter omstarten: lokal kontakt, out-of-band-åtkomst, fungerande HA-motpart eller en tydlig supportprocess.

Efter reboot bör samma validering göras som efter en service-omstart, men bredare: HA-status, licensstatus, VPN-tunnlar, SD-WAN-gateways, centrala loggar, WebAdmin, Central-anslutning och de viktigaste publicerade tjänsterna kontrolleras. För recovery-teman passar dessutom planera Sophos Firewall Backup och Restore korrekt.

Driftchecklista

• Berörd modul och tjänstenamn identifierade.
• Passande loggfil kontrollerad före omstarten.
• Möjlig påverkan på användare, VPN, routing eller platser bedömd.
• Underhållsfönster eller HA-kontext klargjord vid behov.
• SSH-åtkomst och host-key-kontroll rent förberedda om Advanced Shell behövs.
• Service startad om riktat.
• Status och loggfil kontrollerade efter omstarten.
• Funktion validerad med ett verkligt test.
• Debug och temporära åtkomster återställda efter analysen.
• Återkommande fel dokumenterade och inte maskerade genom upprepade omstarter.

FAQ