Sophos Firewall restartuje się nieoczekiwanie: sprawdź przyczynę

Jeśli Sophos Firewall uruchomi się ponownie bez zaplanowanej ingerencji, nie należy od razu wykonywać kolejnego rebootu ani profilaktycznie restartować usług. Najpierw trzeba ustalić, czy rzeczywiście zrestartowało się całe urządzenie, czy niedostępne były tylko WebAdmin, pojedyncza usługa albo aktywna rola HA. Udany restart może przywrócić działanie, ale nie wyjaśnia jeszcze przyczyny.

⚠️ Zabezpieczyć dowody przed kolejnymi ingerencjami: Nie usuwać logów, nie wywoływać kolejnego rebootu, nie zmieniać stanu auto-reboot-on-hang ani nie uruchamiać na próbę Debug, działań na usługach, fsck, Factory Reset lub Reimage. Takie ingerencje mogą zmienić wskazówki, spowodować nowe przerwy albo ukryć właściwy błąd.

Bezpieczna szybka ścieżka wygląda następująco:

Zanotować czas ze strefą czasową, długość awarii i ostatnią znaną prawidłową obserwację.
Zapisać, czy jednocześnie niedostępne były ruch, WebAdmin, SSH i lokalna konsola.
W Control Center zabezpieczyć uptime, services, interfaces, VPNs, a przy HA także status klastra.
W Log viewer > System wyeksportować odpowiednie zdarzenia, a w Diagnostics > System graphs zabezpieczyć przebieg.
W Diagnostics > Tools pobrać CTR oraz sysinit.log, syslog.log, a przy HA także lokalne logi węzłów.
W Device Console odczytać uptime, build i stan Auto-Reboot:

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

Przy HA porównać role, status, Last status change oraz uptime obu węzłów.
Dopiero potem przejść do odpowiedniej gałęzi przyczyn i w pełni przetestować środowisko produkcyjne.

system auto-reboot-on-hang show niczego nie zmienia. SFOS domyślnie włącza tę funkcję i może automatycznie zrestartować firewall, gdy kernel przestanie odpowiadać. Wyświetlone enable potwierdza jednak tylko skonfigurowaną Recovery Policy, a nie to, że w tym konkretnym przypadku restart wywołał Kernel-Hang.

Sprawdzanie, co rzeczywiście przestało działać

Sama zaobserwowana przerwa nie potwierdza pełnego rebootu. Cztery przypadki wymagają różnych kolejnych działań:

Pełny reboot urządzenia: Uptime zaczyna się od nowa, kilka usług i połączeń zostało jednocześnie przerwanych, a SFOS ponownie wykonał start systemu. Wtedy obowiązuje triage rebootu z tego artykułu.
Problem dotyczył tylko WebAdmin lub jednej usługi: Uptime nadal rośnie, a ruch produkcyjny może częściowo działać bez zmian. Wtedy lepiej pasuje ukierunkowany restart WebAdmin GUI albo sprawdzenie pojedynczej usługi niż reboot całego urządzenia.
Failover HA: Użytkownicy mogą zauważyć krótką przerwę, mimo że zmieniły się tylko role. Uptime, rola i logi każdego węzła pokazują, czy urządzenie faktycznie się zrestartowało. Kontrola HA znajduje się dalej.
Tryb Failsafe: Firewall nie uruchamia się normalnie, a konsola pokazuje stan Recovery. Wtedy właściwym pierwszym poleceniem jest show failure-reason z runbooka Tryb Failsafe w Sophos Firewall.

Uptime jest więc mocnym dowodem czasu restartu, ale nie dowodem jego przyczyny. Krótka przerwa w zasilaniu, Kernel-Hang, błąd firmware i zaplanowany restart administratora również zerują uptime.

Zabezpieczanie dowodów po restarcie

Po nieplanowanym restarcie część ulotnych danych może już nie być dostępna. Mimo to należy w pełni zabezpieczyć osiągalny stan przed wprowadzeniem kolejnych zmian.

Dokumentacja incydentu powinna obejmować co najmniej:

model, numer seryjny i platformę: sprzęt, VM lub chmura
pełną wersję SFOS wraz z MR i buildem
dokładny czas, strefę czasową, długość i częstotliwość awarii
dotknięte funkcje: ruch, WebAdmin, SSH, konsolę, VPN i opublikowane usługi
ostatnią zmianę firmware, konfiguracji, hypervisora, storage lub zasilania
aktualny uptime oraz status usług, interfejsów, VPN i HA
przy HA: dotknięty węzeł, role przed zdarzeniem i po nim oraz status Peer
dostępne zdarzenia UPS, PDU, hypervisora, chmury, switcha i monitoringu z tego samego przedziału czasu

W Diagnostics > System graphs należy sprawdzić CPU, Memory, Load i Disk w pobliżu podejrzewanego czasu. Odchylenie może zawęzić poszukiwania. Prawidłowa wartość bieżąca nie dowodzi natomiast, że obciążenie przed rebootem również było prawidłowe.

W Log viewer > System zdarzenia Start, Restart, Shutdown i HA należy ograniczyć do tego samego przedziału czasu i wyeksportować. Log Viewer jest przydatnym źródłem czasu, ale nie stanowi pełnego dowodu crashu. Zdarzenia, które nie zostały jeszcze zapisane, mogą zniknąć przy zawieszeniu.

Odczyt stanu systemu w Device Console

Oprócz uptime i buildu aktualny stan pokazują te polecenia tylko do odczytu:

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

Wartości należy zapisać w notatce incydentu wraz z czasem odczytu. Opisują stan po restarcie i nie wolno interpretować ich wstecz jako przyczyny.

Sprawdzanie logów startowych i systemowych

W Advanced Shell można w całości i bez zmian odczytać najważniejsze pliki:

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

Klawisz q zamyka less. W pliku wpisanie /szukany-tekst rozpoczyna wyszukiwanie, na przykład /error; klawisz n przechodzi do następnego trafienia.

sysinit.log dokumentuje start systemu.
syslog.log zawiera zdarzenia kernela i systemu.
applog.log i csc.log pomagają powiązać działania wewnętrzne oraz zmiany z odpowiednim czasem.

Te same pliki należy dodatkowo pobrać w Diagnostics > Tools > Troubleshooting logs, aby zachować oryginalne dane poza urządzeniem. Który dodatkowy plik logu należy do danej usługi, wyjaśnia przyporządkowanie logów usług Sophos Firewall.

Dodatkowo w Diagnostics > Tools > Consolidated troubleshooting report tworzy się CTR z opcjami System snapshot i All log files. CTR zawiera bieżący stan systemu i wiele logów w zaszyfrowanym archiwum. Logi podsystemów usług obejmują domyślnie najwyżej 10'000 wierszy; przy dłuższych okresach nadal ważne są pełne pojedyncze logi. Całą procedurę opisuje artykuł Zabezpieczanie logów Sophos Firewall dla wsparcia.

Pusty fragment logu nie wyklucza crashu ani przerwy w zasilaniu. Informacje, które nie zostały jeszcze zapisane na nośniku, mogą zniknąć przy zawieszeniu, a lokalne logi mogą podlegać rotacji. Dlatego tak ważne są zewnętrzne źródła czasu i dokładna oś czasu incydentu.

Rozróżnianie failoveru HA i rebootu węzła

W System services > High availability należy zabezpieczyć Health, Mode, role, status, numery seryjne i Last status change. Dodatkowe szczegóły pokazuje w Device Console następujące polecenie:

system ha show details

Następnie należy sprawdzić uptime na obu węzłach. Krótki uptime tylko jednego węzła wskazuje na restart tego urządzenia. Jeśli uptime obu węzłów się nie zmienił, ale role zostały przełączone, należy najpierw zbadać wyzwalacz HA, na przykład Monitored Port lub problem z Peer. Ręczna zmiana aktywnej roli również może zrestartować dotychczasowy Primary, dlatego możliwa ingerencja administratora także należy do osi czasu.

Logi HA znajdują się lokalnie na odpowiednim węźle i nie są synchronizowane. Dlatego na obu urządzeniach istotne są co najmniej te pliki:

cd /log
less ha.log
less msync.log

ha.log pokazuje tworzenie i zmiany stanu, a msync.log synchronizację. Nie należy uruchamiać jednoczesnego restartu obu węzłów ani wymuszać kolejnego failoveru w celu reprodukcji. Pełną diagnostykę ról i łączy opisuje artykuł Sophos Firewall High Availability.

Zawężanie przyczyny na podstawie kontekstu

Zaplanowany restart administratora lub firmware

Najpierw należy porównać kalendarz zmian, okna serwisowe, działania administratorów, zadania Sophos Central i powiadomienia z czasem zdarzenia. Wcześniejsze zmiany konfiguracji można powiązać za pomocą logów Audit Trail. Sophos Firewall generuje zdarzenia systemowe dla startu oraz Restart lub Shutdown przez WebAdmin. Jeśli skonfigurowano powiadomienia e-mail, wiadomość w skrzynce może dodatkowo potwierdzić czas i wysyłający firewall.

Jeśli restart wystąpił podczas procesu firmware lub Hotfix, należy zabezpieczyć wersję początkową, wersję docelową, build, czas aktualizacji i fwmgmt.log. Restart jest częścią normalnej zmiany firmware; kilka nieplanowanych rebootów albo nieoczekiwany build już nie. Dalszą analizę opisuje procedura Aktualizacja firmware Sophos Firewall.

Kernel-Hang lub błąd oprogramowania

Przy aktywnym auto-reboot-on-hang SFOS może sam się zrestartować, gdy kernel przestanie odpowiadać. Funkcja poprawia dostępność, ale nie zawsze pozostawia jednoznaczny lokalny dowód przyczyny. Wyświetlony stan należy udokumentować i nie zmieniać go podczas triage. Przypadek zawęża się na podstawie czasu, logów, System graphs, CTR i dokładnego buildu.

W SFOS 22.0 MR2 Build 546 Sophos naprawił kilka niezależnych przypadków crashu i restartu, na przykład:

NC-180974: Kernel-Crash w sdwan_profile z HA-Failover
NC-178354: Kernel-Crash podczas dopasowywania reguł SD-WAN
NC-178745: automatyczny restart urządzenia HA z powodu Out-of-Memory
NC-180433: powtarzający się crash przy ruchu Multicast przez tunel VPN

Te Issue-IDs pokazują, dlaczego Firewall się zrestartował nie jest jeszcze diagnozą. Dopiero gdy build, funkcja, ruch i czas błędu pasują do udokumentowanego przypadku, należy sprawdzić obsługiwaną ścieżkę aktualizacji do MR2 Build 546 lub nowszej zatwierdzonej wersji. Jeśli błąd powtórzy się na tym lub nowszym buildzie, nie należy nadal automatycznie przypisywać go do tej samej starej Issue-ID. Pozostałe poprawki opisano w przeglądzie SFOS 22.0 MR2.

Kernel-Crash nie powinien być celowo reprodukowany za pomocą testów obciążenia, Multicast, zmian SD-WAN ani wymuszonego failoveru. Należy udokumentować konfigurację i wzorce ruchu, a następnie przeanalizować je z Sophos Support.

Obciążenie, miejsce na dysku lub storage

Przebieg CPU, Memory, Load i Disk może pokazać, czy przed rebootem występowało już długotrwałe odchylenie. Sophos wskazuje również /log/system-monitor/cpu_trigger.log dla automatycznie zarejestrowanych stanów systemu przy wysokim obciążeniu CPU. Dokumentacja SFOS 22 dodaje /log/system-monitor/memory_trigger.log dla wysokiego użycia pamięci; w SFOS 21.5 nie należy zakładać obecności tego pliku.

Pełny nośnik, duże obciążenie I/O i błąd SSD to różne problemy. Nie należy więc usuwać raportów ani logów na próbę. Kontrolę tylko do odczytu i przewidziane czyszczenie opisuje Sprawdzanie miejsca na Sophos Firewall i zarządzanie raportami, a stan sprzętowy nośnika artykuł Sprawdzanie kondycji SSD Sophos Firewall przez SMART.

Zasilanie, temperatura lub sprzęt

W fizycznym urządzeniu XGS należy sprawdzić zasilanie, zasilacze, UPS/PDU, temperaturę szafy, przepływ powietrza, wentylatory, diody LED, SSD i lokalną konsolę. Brak prawidłowego śladu Shutdown może pasować do nagłego zdarzenia zasilania, ale go nie dowodzi. Decyduje wspólna oś czasu firewalla, UPS/PDU, monitoringu i otoczenia.

Bieżąca temperatura po restarcie jest również tylko wartością chwilową. Sprawdzanie temperatury, wentylatorów i xgs-healthmond.log opisuje termiczną gałąź przyczyn. Powtarzające się błędy boot, I/O, zasilacza, NPU lub wentylatora należy wraz z zabezpieczonymi danymi uwzględnić w przygotowaniu przypadku sprzętowego i RMA.

Wirtualny firewall lub Cloud Appliance

W przypadku VM należy dodatkowo sprawdzić zdarzenia hypervisora, restarty hosta, opóźnienia datastore, zadania snapshot lub backup, vCPU, RAM, disks i vNICs z tego samego czasu. W AWS lub Azure do osi czasu incydentu należą zdarzenia platformy, status instancji i zaplanowana konserwacja.

Zdarzenie hosta lub platformy może zrestartować VM, mimo że SFOS sam nie był przyczyną. Z drugiej strony brak nieprawidłowości w hypervisorze nie dowodzi, że system gościa działał bezbłędnie. Obie osie czasu trzeba więc oceniać łącznie. Aktualne różnice między platformami i zasobami wyjaśnia artykuł Sophos Firewall jako sprzęt, VM lub Cloud Appliance.

Kontrola działania po restarcie

Dostępna strona logowania nie jest jeszcze pełnym testem odbiorczym. Po zabezpieczeniu dowodów należy, odpowiednio do środowiska, sprawdzić:

Control Center bez nowych ostrzeżeń dotyczących services, interfaces, VPN lub performance; dodatkowo sprawdzić System graphs i Notifications pod kątem odchyleń Memory i Disk
WAN, routing, DNS i dostęp do internetu przez oczekiwaną ścieżkę
ważne połączenia Site-to-Site VPN i Remote-Access VPN
kluczowe publikacje DNAT, WAF lub serwerów
DHCP, RED i Wireless, jeśli firewall udostępnia te usługi
przy HA: Health, role, synchronizację i uptime obu węzłów
nowe błędy systemowe, kernela lub sprzętu od czasu uruchomienia

Najważniejsze rzeczywiste przepływy biznesowe należy świadomie przetestować i udokumentować wraz z czasem. Stabilny uptime pokazuje tylko, że nie wystąpił kolejny reboot. Pierwotną przyczynę można uznać za wyjaśnioną dopiero wtedy, gdy oś czasu, logi i obserwacje platformy dają wiarygodne wyjaśnienie.

Przygotowanie zgłoszenia i wykrywania przyszłych zdarzeń

Zgłoszenie do Sophos Support jest uzasadnione, gdy reboot pozostaje niewyjaśniony, powtarza się, spowodował awarię HA lub lokalizacji albo istnieją wskazówki dotyczące kernela, pamięci, storage, NPU lub sprzętu. Zgłoszenie powinno zawierać czas incydentu ze strefą czasową, platformę, pełny build, uptime, dotknięte funkcje, ostatnie zmiany, role HA, CTR, pełne odpowiednie logi i zewnętrzną oś czasu zasilania lub hypervisora.

Na potrzeby kolejnego zdarzenia przygotowany monitoring poprawia materiał dowodowy:

Skonfigurować dostarczanie powiadomień e-mail dla System started, Restart/Shutdown i zmian statusu HA.
Wysyłać zdarzenia systemowe i HA do Syslog lub SIEM, aby zachować oś czasu poza firewallem.
Monitorować uptime i stan sprzętu przez SNMP Monitoring.
Używać tego samego serwera czasu i jasnego przypisania lokalizacji dla alarmów UPS/PDU, hypervisora i chmury.

Dzięki temu przy kolejnym zdarzeniu można szybciej rozstrzygnąć, czy awarię wywołał sam SFOS, pojedynczy węzeł, platforma czy środowisko zasilania i sprzętu.