Bezpieczny restart usług Sophos Firewall

Najbezpieczniej zrestartować pojedynczą usługę Sophos Firewall w sekcji System services > Services. Brak usługi na tej liście nie uzasadnia uruchomienia dowolnej komendy shell: Advanced Shell należy używać wyłącznie na podstawie aktualnej instrukcji Sophos dla konkretnej usługi albo w ramach zgłoszenia wsparcia. Najpierw trzeba ustalić, której usługi dotyczy problem i jakie połączenia może przerwać jej restart.

⚠️ Ważne: Restart usługi zmienia stan systemu i może przerwać VPN, routing, DNS, DHCP, dostęp do stron lub dostęp administratora. Wcześniej należy zapisać stan i logi, a dla lokalizacji zdalnych przygotować alternatywny dostęp.

Restart usługi przez WebAdmin

Przed kliknięciem należy zapisać bieżący stan, dokładny czas błędu i test działania, który się nie powiódł. Odpowiednie pliki można pobrać pojedynczo w Diagnostics > Tools > Troubleshooting logs. Na potrzeby zgłoszenia Consolidated troubleshooting report (CTR) zawiera również stan systemu, procesy i wykorzystanie zasobów. W zdalnej lokalizacji kontrola wstępna musi też obejmować okno serwisowe i alternatywny dostęp.

1. Otworzyć System services > Services.
2. Sprawdzić właściwą usługę i jej bieżący stan. Nie uruchamiać usługi celowo zatrzymanej lub nieskonfigurowanej.
3. W obszarze Manage kliknąć Restart.
4. Poczekać, aż usługa wróci do poprzedniego stanu Running, a następnie sprawdzić działanie powiązanej funkcji.

WebAdmin wyświetla między innymi Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, DHCPv6 server, Router advertisement service, Hotspot oraz Packet capture and Live connections. Jeśli usługa nie jest skonfigurowana, jej przycisk pozostaje nieaktywny. Anti-spam wymaga przychodzącej lub wychodzącej polityki spamu. Zatrzymanie Packet capture and Live connections kończy aktywne przechwytywanie i wyłącza widok Live Connections. Jeśli Packet Capture nie uruchamia się mimo włączonego przełącznika, Sophos wskazuje właśnie ten restart przez WebAdmin jako krok odzyskiwania.

Restart usługi nie ma rollbacku przywracającego aktywne sesje. Stanem, który należy zachować, jest więc wcześniej zapisany stan usługi. Jeśli wcześniej działająca usługa nie wróci do Running, nie należy wielokrotnie klikać Restart. Trzeba zapisać nowy czas, pobrać log lub CTR i zbadać błąd albo skontaktować się z Sophos Support.

W Control Center > System stan usług pokazuje, czy usługa jest zatrzymana lub nie mogła się uruchomić. To dobry punkt wyjścia, ale nie zastępuje testu działania. Jeśli nie odpowiada tylko interfejs WebAdmin, należy skorzystać z instrukcji Restart interfejsu Sophos Firewall WebAdmin.

Usługa antywirusowa zatrzymana po nieudanych aktualizacjach sygnatur

Jeśli usługa Antivirus pozostaje zatrzymana po nieudanych aktualizacjach sygnatur SAVI i AVIRA, nie należy wielokrotnie klikać Restart. Najpierw trzeba zapisać wersję i build firmware’u, czas wystąpienia błędu oraz powiązane pliki avd.log i up2date_av.log. W Backup & firmware > Pattern updates należy również zanotować ostatnią udaną aktualizację i bieżący stan: Ready to install, Downloading, Success albo Failed. Ogólną procedurę sprawdzania tych stanów opisuje artykuł Konfiguracja i sprawdzanie aktualizacji wzorców Sophos Firewall.

Sophos rejestruje ten problem jako NC-180066; został on naprawiony w SFOS 22.0 MR2 Build 546. Jeśli objawy odpowiadają temu błędowi na wcześniejszym buildzie SFOS 22, należy sprawdzić obsługiwaną ścieżkę za pomocą przewodnika przygotowania aktualizacji firmware’u i najpierw zaktualizować system do MR2 Build 546 lub nowszej zatwierdzonej wersji. Pojedynczy restart w System services > Services jest ogólnie dostępny, ale Sophos nie dokumentuje go jako obejścia ani poprawki dla NC-180066 i nie zastępuje on aktualizacji firmware’u.

Dopiero po aktualizacji firmware’u należy kliknąć Update pattern now w Backup & firmware > Pattern updates. Aktualizacja odpowiedniej sygnatury Antivirus musi osiągnąć stan Success, a usługa Antivirus musi pozostać aktywna. Sam wyświetlany stan usługi nie wystarcza: aktualizacja sygnatury również musi zakończyć się powodzeniem. Jeśli problem wystąpi ponownie w MR2 Build 546 lub nowszej wersji, należy przekazać Sophos Support zapisane logi i czasy zdarzeń, zamiast nadal zakładać, że chodzi o NC-180066.

Ponowne uruchomienie IPsec przez VPN Management

W menu głównym CLI pod 6. VPN Management > Restart VPN Service dostępny jest obsługiwany restart demona usługi VPN. Sophos ostrzega, że rozłącza on wszystkie tunele VPN. Jeśli trzeba ponownie zestawić tylko jedno połączenie VPN, należy użyć jego akcji w WebAdmin. Przed restartem trzeba zapisać stan tuneli, dokładny czas i strongswan.log, a następnie ponownie sprawdzić Child SA, peerów i rzeczywisty ruch aplikacyjny. Restart nie naprawia błędu proposal, routingu ani NAT.

W tym samym menu można ponownie wygenerować parę kluczy RSA używaną do uwierzytelniania IPsec. Nie jest to restart usługi, lecz zmiana kluczy. W połączeniach z RSA key peery będą następnie potrzebować nowego klucza publicznego, a użytkownicy dostępu zdalnego muszą ponownie pobrać konfigurację VPN. Sophos nie dokumentuje możliwości przywrócenia starej pary kluczy jednym kliknięciem. Tej funkcji należy używać wyłącznie w ramach planowanej rotacji z pełną inwentaryzacją tuneli, oknem serwisowym i alternatywnym dostępem administracyjnym, a nie jako ogólnego kroku troubleshooting. Nie naprawia ona również problemów z PSK ani certyfikatami.

Restart usługi przez Advanced Shell

Advanced Shell należy używać tylko wtedy, gdy aktualna instrukcja Sophos podaje konkretną usługę i komendę albo przekazuje je Sophos Support. Dostęp SSH i weryfikację klucza hosta opisuje Połączenie z Sophos Firewall przez SSH. SSH należy zezwalać tylko z zaufanych sieci administracyjnych; odpowiednie ustawienia opisano w Device Access i Local Service ACL. Nieaktywne sesje SSH są zamykane po 15 minutach.

Po zalogowaniu otworzyć:

5. Device Management > 3. Advanced Shell

Device Console w opcji 4 menu sprawdza poprawność udokumentowanych komend i służy do obsługiwanej diagnostyki sieci i systemu. Natomiast Advanced Shell w 5. Device Management > 3. Advanced Shell jest powłoką Linux z pełnym dostępem do baz danych i usług systemowych. Zmiany konfiguracji wprowadzone w tej powłoce nie są trwałe ani uwzględniane w backupach. Najpierw należy wykonać kontrole tylko do odczytu, a restart dopiero po sprawdzeniu nazwy usługi, skutków, okna serwisowego i dostępu awaryjnego.

1. Sprawdzenie nazwy i stanu usługi

Znane usługi i ich bieżący stan pokazuje:

service -S

Wynik można odfiltrować według podejrzewanej usługi. Dla IPsec na przykład:

service -S | grep -i strongswan

RUNNING oznacza, że usługa działa. STOPPED, UNREGISTERED lub UNTOUCHED nie oznaczają automatycznie usterki: zależnie od firmware’u i konfiguracji usługa może celowo być nieaktywna albo niezarejestrowana. Najpierw należy sprawdzić, czy powiązana funkcja, polityka lub licencja jest w ogóle używana.

Jeśli techniczna nazwa usługi nie jest jasna, pomocny jest artykuł Troubleshooting Sophos Firewall: usługi i logi, który przypisuje obszary funkcjonalne do plików logów.

2. Sprawdzenie logów przed zmianą

Restart może ukryć ważne ślady przyczyny. Dla IPsec należy najpierw odczytać strongswan.log i zapisać istotne komunikaty:

less /log/strongswan.log

q zamyka less. Przy większej analizie logi można wcześniej wyeksportować zgodnie z instrukcją Zapisywanie logów Sophos Firewall do wsparcia i analizy. W klastrze HA każdy węzeł przechowuje tylko logi przetwarzanego przez siebie ruchu; może być konieczne osobne sprawdzenie obu węzłów.

3. Restart usługi na samodzielnym firewallu

Poniższy przykład zakłada samodzielny firewall. Przed wykonaniem należy potwierdzić usługę za pomocą service -S | grep -i strongswan. Restart może przerwać połączenia IPsec site-to-site i Remote Access. Wcześniej należy sprawdzić tunele, zdalnych peerów i okno serwisowe.

Sophos dokumentuje następujący wzorzec:

service <service>:restart -ds nosync

Pełny przykład dla usługi IPsec:

service strongswan:restart -ds nosync

Ogólna składnia i service -S są udokumentowane w aktualnej pomocy SFOS 22, gdzie strongswan jest przypisany do usługi IPsec. Tego przykładu nie wykonano na firewallu, dlatego nie jest opisywany jako przetestowany laboratoryjnie. Nazwy innej usługi nie wolno zgadywać na podstawie listy.

Dalszą analizę opisuje Troubleshooting IPsec w Sophos Firewall.

⚠️ Klaster HA: Nie należy stosować komendy dla samodzielnego firewalla bez weryfikacji. Zależnie od usługi i sytuacji instrukcje Sophos używają sync lub nosync; publiczna dokumentacja nie zawiera wystarczającej reguły ogólnej. Usługa, węzeł, build SFOS i tryb synchronizacji muszą wynikać z aktualnej instrukcji Sophos dla danej usługi lub zgłoszenia wsparcia.

Osobnych komend stop i start należy używać tylko wtedy, gdy Sophos Support zaleci je dla konkretnej usługi. Między obiema komendami usługa pozostaje całkowicie zatrzymana.

Ten restart również nie ma rollbacku zachowującego stan: rozłączonych Security Associations i sesji nie można przywrócić. Bezpiecznym kryterium przerwania jest porównanie z kontrolą wstępną. Jeśli strongswan nie wróci do poprzedniego stanu lub tunele nie zostaną zestawione, nie należy wykonywać drugiego restartu. Trzeba zapisać logi i CTR oraz eskalować problem.

4. Walidacja wyniku

Po restarcie należy sprawdzić stan, log i rzeczywiste działanie:

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

tail -f stale wyświetla nowe komunikaty i kończy się go przez Ctrl+C. Komunikaty trzeba porównać z czasem zapisanym przed restartem; niefiltrowany grep może pokazywać także stare błędy. Następnie należy sprawdzić tunele IPsec i host po drugiej stronie. Sam stan RUNNING nie dowodzi, że połączenie znów działa.

Jeśli restart się nie powiedzie, należy również sprawdzić csc.log. Przy problemach HA, zależnie od objawów, istotne mogą być też ha.log, msync.log i applog.log.

Typowe usługi i odpowiednie testy działania

Dokładną nazwę usługi trzeba potwierdzić na danym firewallu za pomocą service -S. Najważniejsze powiązania:

• strongswan: IPsec site-to-site i Remote Access. Następnie sprawdzić stan tuneli, strongswan.log i osiągalność drugiej strony.
• dnsd: Usługa DNS. Następnie przetestować wewnętrzne i zewnętrzne rozwiązywanie nazw, dnsd.log oraz skonfigurowane DNS Request Routes.
• dhcpd: Serwer DHCP. Podczas restartu nowi klienci lub klienci odnawiający dzierżawę mogą nie otrzymać odpowiedzi. Następnie przetestować przydział dzierżaw i dhcpd.log.
• awed: Komunikacja firewalla z urządzeniami AP/APX. Następnie sprawdzić stan połączenia punktów dostępowych i awed.log.
• zebra: Instaluje dynamiczne i statyczne trasy w jądrze. Restart jest więc inwazyjny i powinien być wykonywany tylko na podstawie konkretnej instrukcji Sophos; następnie przetestować tablicę routingu, bramy i rzeczywiste ścieżki.
• smtpd: Proxy SMTP w trybie MTA. Starszy transparentny proxy korzysta z innej usługi; przed zmianą sprawdzić tryb pracy i logi smtpd_*. Następnie kontrolnie przetestować wysyłanie i odbieranie poczty.

Dla WAF, Web proxy, IPS, Authentication i usług dostępnych w WebAdmin restart przez System services > Services jest zwykle czytelniejszy niż komenda shell.

Kiedy restart usługi nie jest właściwy

Restart pojedynczej usługi ma sens, gdy dotyczy konkretnego modułu, a reszta firewalla jest stabilna. Nie należy restartować w ciemno, gdy:

• przyczyna lub usługa nie są jeszcze znane;
• jednocześnie przestaje działać kilka centralnych usług;
• dana usługa zapewnia ostatni dostęp zdalny;
• błąd jest powtarzalny, a logi nie zostały zapisane;
• ta sama usługa była już wielokrotnie restartowana;
• rola HA, węzeł lub wymagany tryb synchronizacji nie są jasne.

Przy kilku dotkniętych usługach najpierw sprawdzić obciążenie systemu, miejsce na dysku, stan bazy danych, HA oraz ostatnie zmiany konfiguracji lub firmware’u. Powtarzane restarty często tylko ukrywają przyczynę.

Pełny reboot jest bardziej inwazyjny i należy go rozważać dopiero, gdy cały firewall pozostaje niestabilny, wymaga go proces firmware lub hotfix albo zaleca go Sophos Support. W Device Console polecenie system restart restartuje firewall, a w klastrze HA powoduje failover. Natomiast system shutdown tylko wyłącza urządzenie. Przed obiema akcjami trzeba zweryfikować urządzenie docelowe i węzeł HA, backup, okno serwisowe oraz dostęp lokalny lub out-of-band; przy wyłączeniu ta metoda odzyskiwania musi faktycznie umożliwiać ponowne włączenie urządzenia. Po restarcie należy sprawdzić rolę i synchronizację HA, stan usług oraz dotknięte ścieżki danych. Przerwanych sesji nie można przywrócić. Jeśli urządzenie nie wróci do pracy, nie należy powtarzać polecenia, lecz użyć przygotowanego dostępu awaryjnego i w razie potrzeby skontaktować się z Sophos Support. Zobacz Prawidłowe planowanie backupu i restore Sophos Firewall.

Krótka dokumentacja zmiany

Przy powracających problemach lub zgłoszeniu wsparcia wystarczy krótka notatka. Pozwala później ocenić, czy restart trwale pomógł, czy tylko ukrył objaw:

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

Przed zmianą należy zapisać czas, dotkniętą funkcję i istotne komunikaty logów. Po zmianie odnotować stan usługi, test działania i kolejny krok. Po analizie usunąć tymczasowe reguły SSH lub Device Access i wyłączyć tryby debug.