Bezpieczny restart usług Sophos Firewall

Najłatwiej zrestartować pojedynczą usługę Sophos Firewall w sekcji System services > Services. Jeśli usługi tam nie ma, można użyć Advanced Shell. Najpierw trzeba jednak 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

1. Otworzyć System services > Services.
2. Sprawdzić właściwą usługę i jej bieżący stan.
3. W obszarze Manage kliknąć Restart.
4. Następnie sprawdzić stan i działanie powiązanej funkcji.

WebAdmin wyświetla między innymi Anti-spam, Antivirus, Authentication, DNS server, IPS, Web proxy, WAF, DHCP server, 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.

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.

Restart usługi przez Advanced Shell

Advanced Shell przydaje się, gdy usługa nie jest dostępna w WebAdmin lub Sophos Support podaje konkretną komendę. 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

Advanced Shell zapewnia szeroki dostęp do systemu. Dlatego najpierw należy wykonać kontrole tylko do odczytu, a dopiero potem restart.

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

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.

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. 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. Przed zdalnym rebootem trzeba potwierdzić backup, okno serwisowe i drogę odzyskania dostępu, np. lokalny kontakt, dostęp out-of-band lub działający peer HA. 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.