Sophos Firewall startar oväntat om: kontrollera orsaken

Om en Sophos Firewall startar om utan en planerad åtgärd bör man inte omedelbart göra ytterligare en reboot eller starta om tjänster i förebyggande syfte. Först måste det klargöras om hela appliance-enheten verkligen startade om eller om bara WebAdmin, en enskild tjänst eller den aktiva HA-rollen slutade fungera. En lyckad omstart kan återställa driften men förklarar ännu inte orsaken.

⚠️ Spara bevis före ytterligare åtgärder: Ta inte bort loggar, provocera inte fram ytterligare en reboot, ändra inte status för auto-reboot-on-hang och starta inte Debug, tjänsteåtgärder, fsck, Factory Reset eller Reimage på försök. Sådana åtgärder kan förändra ledtrådar, orsaka nya avbrott eller dölja det egentliga felet.

Den säkra snabbvägen är:

Anteckna tidpunkt med tidszon, avbrottets längd och den senaste kända fungerande observationen.
Dokumentera om trafik, WebAdmin, SSH och den lokala konsolen påverkades samtidigt.
Spara uptime, services, interfaces, VPNs och, vid HA, klusterstatus i Control Center.
Exportera relevanta händelser under Log viewer > System och spara historiken under Diagnostics > System graphs.
Ladda ned en CTR samt sysinit.log, syslog.log och, vid HA, de lokala nodloggarna under Diagnostics > Tools.
Läs uptime, build och Auto-Reboot-status i Device Console:

system diagnostics show uptime
system diagnostics show version-info
system auto-reboot-on-hang show

Jämför roller, status, Last status change och uptime för båda noderna vid HA.
Kontrollera först därefter lämplig orsaksgren och testa produktionsmiljön fullständigt.

system auto-reboot-on-hang show ändrar ingenting. SFOS aktiverar funktionen som standard och kan automatiskt starta om brandväggen när kernel inte längre svarar. Ett visat enable bevisar dock bara konfigurerad Recovery Policy och inte att en Kernel-Hang orsakade just denna omstart.

Kontrollera vad som faktiskt slutade fungera

Det observerade avbrottet bevisar inte i sig en fullständig reboot. Dessa fyra fall kräver olika nästa steg:

Fullständig reboot av appliance-enheten: Uptime börjar om, flera tjänster och anslutningar avbröts samtidigt och SFOS genomförde systemstarten på nytt. Då gäller reboot-triagen i denna artikel.
Endast WebAdmin eller en tjänst påverkades: Uptime fortsätter och produktiv trafik kan delvis fungera oförändrat. Då passar en riktad omstart av WebAdmin GUI eller kontroll av en enskild tjänst bättre än en reboot av hela appliance-enheten.
HA-failover: Användare kan märka ett kort avbrott trots att bara rollerna växlade. Uptime, roll och loggar för varje nod visar om en enhet faktiskt startade om. HA-kontrollen följer längre ned.
Failsafe-läge: Brandväggen startar inte normalt och konsolen visar ett Recovery-tillstånd. Då är show failure-reason från runbooken om Failsafe-läge i Sophos Firewall rätt första kommando.

Uptime är därmed ett starkt belägg för tidpunkten för omstarten, men inget bevis för orsaken. Även ett kort strömavbrott, en Kernel-Hang, ett firmwarefel och en planerad administratörsomstart nollställer uptime.

Spara bevis efter omstarten

Efter en oplanerad reboot kan flyktiga data redan saknas. Ändå bör det åtkomliga tillståndet sparas fullständigt innan ytterligare ändringar görs.

Incidenten bör minst omfatta:

modell, serienummer och plattform: hårdvara, VM eller moln
fullständig SFOS-version med MR och build
exakt tidpunkt, tidszon, avbrottets längd och frekvens
påverkade funktioner: trafik, WebAdmin, SSH, konsol, VPN och publicerade tjänster
senaste ändring av firmware, konfiguration, hypervisor, storage eller ström
aktuell uptime samt status för tjänster, gränssnitt, VPN och HA
vid HA: berörd nod, roller före och efter händelsen samt Peer-status
tillgängliga UPS-, PDU-, hypervisor-, moln-, switch- och övervakningshändelser i samma tidsintervall

Under Diagnostics > System graphs kontrolleras CPU, Memory, Load och Disk runt den misstänkta tidpunkten. En avvikelse kan avgränsa sökningen. Ett normalt aktuellt värde bevisar däremot inte att belastningen före rebooten också var normal.

Under Log viewer > System avgränsas och exporteras Start-, Restart-, Shutdown- och HA-händelser för samma tidsintervall. Log Viewer är en användbar tidskälla men inget fullständigt bevis på en crash. Händelser som ännu inte sparats kan saknas efter en hang.

Läs systemstatus i Device Console

Utöver uptime och build visar dessa skrivskyddade kommandon det aktuella tillståndet:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk

Värdena ska tillsammans med frågetidpunkten ingå i incidentanteckningen. De beskriver tillståndet efter omstarten och får inte i efterhand tolkas som orsak.

Kontrollera start- och systemloggar

I Advanced Shell kan de viktigaste filerna läsas fullständigt och utan ändring:

cd /log
less sysinit.log
less syslog.log
less applog.log
less csc.log

q avslutar less. I filen startar /sökterm en sökning, till exempel /error; n går till nästa träff.

sysinit.log dokumenterar systemstarten.
syslog.log innehåller kernel- och systemhändelser.
applog.log och csc.log hjälper till att sätta interna åtgärder och närliggande ändringar i sitt sammanhang.

Under Diagnostics > Tools > Troubleshooting logs bör samma filer dessutom laddas ned, så att originaldata bevaras utanför appliance-enheten. Mappningen av Sophos Firewall-tjänsteloggar förklarar vilken ytterligare loggfil som hör till en tjänst.

Dessutom skapas en CTR med System snapshot och All log files under Diagnostics > Tools > Consolidated troubleshooting report. CTR innehåller det aktuella systemtillståndet och många loggar i ett krypterat arkiv. För Service-Subsystem-loggar ingår som standard högst 10'000 rader; för längre tidsperioder är fullständiga enskilda loggar fortfarande viktiga. Hela förfarandet beskrivs i Spara Sophos Firewall-loggar för support.

Ett tomt loggavsnitt utesluter inte en crash eller ett strömavbrott. Information som ännu inte skrivits till lagringsmediet kan gå förlorad vid en hang, och lokala loggar kan roteras. Därför är externa tidskällor och en exakt incidenttidslinje så viktiga.

Skilj HA-failover från reboot av en nod

Under System services > High availability sparas Health, Mode, roller, status, serienummer och Last status change. Följande kommando i Device Console visar dessutom detaljerna:

system ha show details

Därefter kontrolleras uptime på båda noderna. Om bara en nod har kort uptime tyder det på att den enheten startade om. Om uptime är oförändrad men rollerna växlade måste HA-utlösaren, till exempel en Monitored Port eller ett Peer-problem, undersökas först. Ett manuellt byte av aktiv roll kan också starta om den tidigare Primary; därför hör även en möjlig administratörsåtgärd till tidslinjen.

HA-loggarna finns lokalt på respektive nod och synkroniseras inte. På båda appliance-enheterna är därför minst dessa filer relevanta:

cd /log
less ha.log
less msync.log

ha.log visar uppbyggnad och statusändringar, medan msync.log visar synkroniseringen. Utlös inte en samtidig omstart av båda noderna och framtvinga inte ytterligare en failover för reproduktion. Den fullständiga roll- och länkdiagnostiken finns i Sophos Firewall High Availability.

Avgränsa orsaken utifrån sammanhanget

Planerad administratörs- eller firmwareomstart

Först jämförs ändringskalender, underhållsfönster, administratörsåtgärder, Sophos Central-uppgifter och meddelanden med tidpunkten för händelsen. Föregående konfigurationsändringar kan granskas med Audit Trail-loggar. Sophos Firewall skapar systemhändelser för Start och för Restart eller Shutdown via WebAdmin. Om e-postmeddelanden är konfigurerade kan meddelandet i inkorgen dessutom bekräfta tidpunkten och den sändande brandväggen.

Om omstarten inträffade under en firmware- eller Hotfix-process sparas ursprungsversion, målversion, build, uppdateringstidpunkt och fwmgmt.log. En omstart ingår i ett normalt firmwarebyte; flera oplanerade reboots eller en oväntad build gör det inte. Det fortsatta förfarandet beskrivs i Uppdatera firmware i Sophos Firewall.

Kernel-Hang eller programvarufel

Med aktiv auto-reboot-on-hang kan SFOS starta om sig självt när kernel inte längre svarar. Funktionen förbättrar tillgängligheten men lämnar inte alltid ett entydigt lokalt bevis på orsaken. Den visade statusen dokumenteras och ändras inte under triagen. Fallet avgränsas genom tidpunkt, loggar, System graphs, CTR och exakt build.

Sophos har i SFOS 22.0 MR2 Build 546 åtgärdat flera oberoende crash- och restartfall, till exempel:

NC-180974: Kernel-Crash i sdwan_profile med HA-Failover
NC-178354: Kernel-Crash vid matching av SD-WAN-regler
NC-178745: automatisk omstart av en HA-enhet på grund av Out-of-Memory
NC-180433: upprepad crash vid Multicast-trafik genom en VPN-tunnel

Dessa Issue-IDs visar varför Brandväggen startade om ännu inte är en diagnos. Endast om build, funktion, trafik och feltidpunkt motsvarar det dokumenterade fallet kontrolleras den supportade uppgraderingsvägen till MR2 Build 546 eller en nyare godkänd version. Om felet uppstår igen på denna eller en nyare build ska det inte fortsatt automatiskt tillskrivas samma gamla Issue-ID. Övriga korrigeringar beskrivs i översikten över SFOS 22.0 MR2.

En Kernel-Crash ska inte avsiktligt reproduceras med belastningstester, Multicast, SD-WAN-ändringar eller en framtvingad failover. Konfiguration och trafikmönster dokumenteras och analyseras därefter tillsammans med Sophos Support.

Belastning, lagringsutrymme eller storage

Utvecklingen för CPU, Memory, Load och Disk kan visa om en längre avvikelse redan fanns före rebooten. Sophos anger dessutom /log/system-monitor/cpu_trigger.log för automatiskt registrerade systemtillstånd vid hög CPU-belastning. I dokumentationen för SFOS 22 tillkommer /log/system-monitor/memory_trigger.log för hög minnesbelastning; på SFOS 21.5 ska man inte förutsätta att filen finns.

Ett fullt lagringsmedium, hög I/O-belastning och ett SSD-fel är olika problem. Reports eller loggar ska därför inte tas bort på försök. För skrivskyddad kontroll och avsedd rensning används Kontrollera lagringsutrymme och hantera reports i Sophos Firewall; lagringsmediets hårdvarutillstånd beskrivs i Kontrollera SSD-hälsa i Sophos Firewall via SMART.

Ström, temperatur eller hårdvara

På en fysisk XGS kontrolleras strömförsörjning, nätaggregat, UPS/PDU, racktemperatur, luftflöde, fläktar, lysdioder, SSD och lokal konsol. Avsaknad av ett korrekt Shutdown-spår kan passa ett plötsligt strömavbrott men bevisar det inte. Den gemensamma tidslinjen från brandvägg, UPS/PDU, övervakning och miljö är avgörande.

Även en aktuell temperatur efter rebooten är bara ett ögonblicksvärde. Kontrollen av temperatur, fläktar och xgs-healthmond.log förklarar den termiska orsaksgrenen. Återkommande boot-, I/O-, nätaggregats-, NPU- eller fläktfel ska tillsammans med sparade data ingå i förberedelsen av ett hårdvaru- och RMA-ärende.

Virtuell brandvägg eller Cloud Appliance

För en VM kontrolleras dessutom hypervisor-händelser, värdomstarter, datastore-latens, snapshot- eller backupjobb, vCPU, RAM, disks och vNICs vid samma tidpunkt. För AWS eller Azure ingår plattformshändelser, instansstatus och planerat underhåll i incidenttidslinjen.

En värd- eller plattformshändelse kan starta om VM:n utan att SFOS självt orsakade problemet. Omvänt bevisar en hypervisor utan anmärkning inte att gästsystemet var felfritt. Därför bedöms båda tidslinjerna tillsammans. De aktuella skillnaderna mellan plattformar och resurser förklaras i Sophos Firewall som hårdvara, VM eller Cloud Appliance.

Kontrollera driften efter omstarten

En åtkomlig inloggningssida är ännu inte ett fullständigt acceptanstest. Efter att bevisen har sparats kontrolleras följande utifrån miljön:

Control Center utan nya varningar för services, interfaces, VPN eller performance; kontrollera dessutom System graphs och Notifications efter avvikelser i Memory och Disk
WAN, routing, DNS och internetåtkomst via förväntad väg
viktiga Site-to-Site VPN- och Remote-Access VPN-anslutningar
centrala DNAT-, WAF- eller serverpubliceringar
DHCP, RED och Wireless om brandväggen tillhandahåller dessa tjänster
vid HA: Health, roller, synkronisering och uptime för båda noderna
nya system-, kernel- eller hårdvarufel sedan starten

De viktigaste verkliga affärsflödena bör testas medvetet och dokumenteras med tidpunkt. Stabil uptime visar bara att ingen ytterligare reboot har inträffat. Den ursprungliga orsaken anses klarlagd först när tidslinjen, loggarna och plattformsobservationerna ger en tillförlitlig förklaring.

Förbered supportärende och framtida detektering

Ett Sophos-supportärende är lämpligt om rebooten förblir oklar, återkommer, har orsakat ett HA- eller platsavbrott eller om det finns tecken på problem med kernel, minne, storage, NPU eller hårdvara. Ärendet ska innehålla incidenttidpunkt med tidszon, plattform, fullständig build, uptime, påverkade funktioner, senaste ändringar, HA-roller, CTR, fullständiga relevanta loggar och den externa tidslinjen för ström eller hypervisor.

För nästa incident förbättrar förberedd övervakning bevisläget:

Leverera e-postmeddelanden för System started, Restart/Shutdown och HA-statusändringar.
Skicka system- och HA-händelser till Syslog eller SIEM, så att tidslinjen bevaras utanför brandväggen.
Övervaka uptime och hårdvarutillstånd med SNMP Monitoring.
Använd samma tidsserver och tydlig platsidentifiering för UPS/PDU-, hypervisor- och molnlarm.

Vid nästa händelse går det därmed snabbare att avgöra om avbrottet orsakades av SFOS självt, en enskild nod, plattformen eller ström- och hårdvarumiljön.