Ponowne uruchamianie interfejsu WebAdmin Sophos Firewall

Jeśli interfejs WebAdmin Sophos Firewall przestanie odpowiadać, nie trzeba od razu uruchamiać ponownie całej zapory. Dopóki routing, VPN i reguły zapory nadal działają, a SSH lub konsola lokalna pozostają dostępne, można oddzielnie sprawdzić i ponownie uruchomić dwie usługi WebAdmin: tomcat i apache.

Poniższe polecenia są przeznaczone dla autonomicznej zapory sieciowej. W klastrze HA właściwy tryb synchronizacji zależy od usługi, węzła, kompilacji SFOS oraz konkretnego problemu. Nie należy używać -ds nosync w HA bez wcześniejszego sprawdzenia, czy jest to właściwe.

⚠️ Ponowne uruchomienie usługi zmienia stan systemu, kończy aktywne sesje WebAdmin i może również na krótko przerwać działanie User Portal. Najpierw należy zabezpieczyć odpowiednie logi, poinformować innych administratorów i przygotować alternatywny dostęp do lokalizacji zdalnych.

Szybka procedura dla autonomicznej zapory

Ta procedura jest odpowiednia, gdy WebAdmin wyświetla Internal Server Error, HTTP 503, niepełną stronę logowania lub trwale nie odpowiadający interfejs, a SSH i pozostałe funkcje zapory są nadal dostępne.

Zalogować się jako admin przez SSH lub konsolę lokalną. Jeśli SSH nie zostało jeszcze skonfigurowane, artykuł Łączenie z Sophos Firewall przez SSH wyjaśnia, jak przygotować bezpieczny dostęp.
Otworzyć 5. Device Management > 3. Advanced Shell. Device Console w opcji 4 menu głównego jest innym środowiskiem poleceń. Polecenia service i polecenia linuksowe należy wykonywać w Advanced Shell, a nie w Device Console.

SFOS 22 dokumentuje w Advanced Shell polecenia tail -f <logfilename>.log, service -S | grep <servicename> oraz service <service name>:<start/restart/stop/debug> -ds nosync. Każdy podgląd logu na żywo należy zakończyć klawiszami Ctrl+C przed otwarciem następnego. Poniższe kontrole stanu są obowiązkowe: jeśli nie ma tomcat lub apache, nie wolno wykonywać polecenia pochodnego. Polecenia w tej wersji artykułu nie zostały przetestowane laboratoryjnie na zaporze.

Wyświetlić ostatnie błędy WebAdmin i skopiować istotne dane wyjściowe do dokumentacji zmiany lub zgłoszenia do pomocy technicznej:

cd /log
tail -f tomcat.log

Należy raz odtworzyć problem z dostępem, zanotować czas i zatrzymać dane wyjściowe klawiszami Ctrl+C. W razie potrzeby należy powtórzyć to samo oficjalnie udokumentowane polecenie z plikami apache.log i error_log.log. Dzięki temu test pozostaje powiązany z konkretnym czasem bez mieszania trzech strumieni danych na żywo.

Sprawdzić aktualny stan usług:

service -S | grep tomcat
service -S | grep apache

Jeśli usługa ma stan STOPPED, wykonać tylko odpowiadające jej polecenie uruchomienia:

# Jeśli tomcat ma stan STOPPED:
service tomcat:start -ds nosync

# Jeśli apache ma stan STOPPED:
service apache:start -ds nosync

Jeśli usługa ma stan DEAD, uruchomić ponownie tylko tę usługę. Jeśli obie mają stan RUNNING, ale WebAdmin nadal nie działa prawidłowo, rozpocząć od tomcat:

service tomcat:restart -ds nosync

Ponownie przetestować WebAdmin. Następujące polecenie wykonać tylko wtedy, gdy apache ma stan DEAD lub problem nie ustąpił po ponownym uruchomieniu tomcat:

service apache:restart -ds nosync

Poczekać, aż obie usługi osiągną stabilny stan, ponownie otworzyć WebAdmin z właściwej sieci zarządzającej i jeszcze raz sprawdzić ich stan:

service -S | grep tomcat
service -S | grep apache

Obie usługi powinny mieć stan RUNNING. Decydujący jest jednak test działania: logowanie, panel, Log Viewer i niekrytyczna strona konfiguracji muszą ładować się stabilnie. Sam działający proces nie dowodzi, że WebAdmin działa prawidłowo.

Nieaktywne sesje SSH są zamykane po 15 minutach. Przed otwarciem Advanced Shell należy więc przygotować sprawdzenie logów, restart i kontrolę, aby wygaśnięcie sesji nie przerwało procedury. Jeśli SSH tymczasowo zezwolono dla dodatkowej strefy lub przez Local service ACL exception rule, należy później przywrócić dokładnie zapisany wcześniej stan i sprawdzić dostęp z właściwego źródła administracyjnego.

Sprawdzenie, czy restart usługi jest właściwym działaniem

Za nazwą usługi tomcat kryje się serwer aplikacji internetowych Jetty; apache jest serwerem HTTP Apache. Oba komponenty są używane przez WebAdmin oraz User Portal. Ich logi znajdują się w Advanced Shell:

Serwer aplikacji: /log/tomcat.log
Serwer WWW: /log/apache.log i /log/apache_access.log
Pozostałe błędy serwera WWW: /log/error_log.log

Nie każdy problem z WebAdmin ma źródło w tych usługach. Rodzaj błędu określa następny krok:

Internal Server Error, HTTP 503 lub niepełna strona logowania: Sprawdzić tomcat, apache i wymienione logi. W tym przypadku ukierunkowany restart jest uzasadniony.
Ostrzeżenie dotyczące certyfikatu: Sprawdzić nazwę, ważność i łańcuch zaufania certyfikatu. Restart usługi nie naprawi nieprawidłowego certyfikatu.
Przekroczenie limitu czasu lub brak dostępu tylko z jednej sieci: Sprawdzić trasę, sieć zarządzającą i Administration > Device access. Lokalne usługi zapory udostępnia się przez Device Access, a nie za pomocą zwykłej reguły zapory. Artykuł Device Access i Local Service ACL opisuje bezpieczną konfigurację.
Problem dotyczy tylko jednej przeglądarki: Przed ingerencją w zaporę przetestować sesję prywatną, drugą przeglądarkę lub innego klienta administracyjnego.
WebAdmin, SSH, VPN lub inne usługi przestają działać jednocześnie: Wskazuje to raczej na obciążenie systemu, pamięć masową, bazę danych, HA lub ogólny problem systemowy. Nie należy losowo restartować usług.

Jeśli trwa aktualizacja firmware, hotfixa lub wzorców, synchronizacja HA, sesja debugowania dla pomocy technicznej albo aktywne zadanie Central, należy najpierw zidentyfikować ten proces i, jeśli to możliwe, poczekać na jego zakończenie. W przeciwnym razie trudno będzie później ustalić, czy problem spowodowała aktualizacja, Central, HA czy restart usługi.

Zabezpieczenie danych diagnostycznych przed ingerencją

Restart może usunąć bieżące komunikaty o błędach z widocznego kontekstu. W przypadku powtarzającego się problemu lub zgłoszenia do pomocy technicznej należy zapisać co najmniej czas, kompilację SFOS, dotkniętą ścieżkę dostępu oraz ostatnie wpisy z tomcat.log, apache.log i error_log.log.

Jeśli WebAdmin działa jeszcze częściowo, w Diagnostics > Tools można pobrać pojedyncze logi lub Consolidated Troubleshooting Report. Jeśli dostępna jest już tylko powłoka, artykuł Zapisywanie logów Sophos Firewall na potrzeby pomocy technicznej i analizy opisuje procedurę. W klastrze HA każdy węzeł zapisuje własne logi; w razie potrzeby należy sprawdzić oddzielnie Primary i Auxiliary.

Przed restartem w środowisku produkcyjnym należy również potwierdzić:

czy zmiana wpłynie na innych administratorów lub trwające prace;
czy SSH, konsola lokalna, Sophos Fusion (dawniej Sophos Central) lub inne połączenie zarządzające zapewnia drogę powrotu;
czy WebAdmin jest jedyną dotkniętą usługą;
czy dla klastra HA dostępny jest właściwy węzeł oraz aktualna instrukcja Sophos dotycząca konkretnej usługi.

Artykuł Bezpieczne ponowne uruchamianie usług Sophos Firewall wyjaśnia ogólne zasady pracy z nazwami usług, stanem, logami i ograniczeniami HA. Rozwiązywanie problemów z Sophos Firewall: usługi i logi zawiera dodatkowe powiązania między funkcjami a plikami logów.

Weryfikacja wyniku i analiza powtarzających się problemów

Po restarcie należy ponownie odczytać logi. Nowe błędy pojawiające się bezpośrednio po uruchomieniu są bardziej przydatne niż stare komunikaty bez odniesienia do czasu:

cd /log
tail -f tomcat.log

Należy raz przeprowadzić test działania, zatrzymać dane wyjściowe klawiszami Ctrl+C i w razie potrzeby powtórzyć polecenie z plikiem apache.log lub error_log.log.

Następnie otworzyć panel, Log Viewer i niekrytyczną stronę. Tymczasowo dozwolony dostęp SSH lub Device Access należy ponownie ograniczyć do właściwych źródeł administracyjnych.

Jeśli problem powróci, restart usługi był tylko rozwiązaniem tymczasowym. Analiza przyczyny powinna wtedy obejmować:

wolne miejsce na partycjach, lokalne raporty i stan bazy danych;
obciążenie CPU i RAM oraz nietypowe logi systemowe;
równoległe sesje administratorów lub intensywne przechwytywanie pakietów;
aktywne lub nieudane zadania Central;
rolę HA, synchronizację i dotknięty węzeł;
zmiany konfiguracji, certyfikatu, interfejsu lub Device Access bezpośrednio przed problemem.

Artykuł Zarządzanie pamięcią masową i raportami Sophos Firewall pomaga w przypadku problemów z pamięcią masową i raportami. Zmiany wprowadzone przed awarią można prześledzić w logach Audit Trail Sophos Firewall.

Krótka notatka operacyjna pozwala uniknąć obsługi powtarzającego się problemu wyłącznie przez kolejne restarty:

Data, godzina i strefa czasowa:
Zapora i węzeł HA, jeśli dotyczy:
Wersja i kompilacja SFOS:
Objawy:
Sprawdzone logi:
Wykonane polecenie:
Wynik i następne działanie:

Jeśli WebAdmin nadal jest niedostępny

Jeśli usługa pozostaje w stanie STOPPED lub DEAD, restart zwraca błąd albo problem natychmiast powraca, należy zabezpieczyć tomcat.log, apache.log, error_log.log, stan systemu i CTR do analizy z Sophos Support. Losowe restartowanie kolejnych usług najprawdopodobniej pogorszy materiał diagnostyczny.

Jeśli ani WebAdmin, ani SSH nie są dostępne, ścieżka odzyskiwania zależy od środowiska: konsola lokalna przez kabel konsolowy lub Micro-USB w obsługiwanych modelach, Sophos Fusion, przygotowana ścieżka awaryjna HA albo planowany restart. W lokalizacjach zdalnych trzeba ustalić, kto może uzyskać dostęp lokalny, jeśli zapora nie uruchomi się prawidłowo. W klastrze HA nie należy bez weryfikacji przełączać awaryjnie tylko dlatego, że WebAdmin nie odpowiada, dopóki ruch produkcyjny nadal działa stabilnie.

Pełny restart jest bardziej inwazyjny niż ponowne uruchomienie dotkniętych usług. Oficjalnie udokumentowane polecenie system restart wykonuje się w Device Console, a nie w Advanced Shell; w klastrze HA powoduje ono przełączenie awaryjne. Należy go rozważyć dopiero wtedy, gdy problem dotyczy kilku centralnych usług, zapora pozostaje niestabilna, wymaga go proces firmware lub hotfix albo zaleca go Sophos Support. Najpierw należy potwierdzić kopię zapasową, okno konserwacyjne oraz wpływ na VPN, routing, RED, wireless i opublikowane usługi. Po potwierdzeniu nie ma drogi powrotnej przez CLI; jeśli zapora nie wróci, trzeba użyć przygotowanego dostępu lokalnego lub out-of-band, zamiast ponawiać restart w ciemno. Artykuł Prawidłowe planowanie kopii zapasowej i przywracania Sophos Firewall opisuje przygotowanie.