Sophos Firewall Uruchom ponownie interfejs graficzny WebAdmin

Jeśli interfejs GUI Sophos Firewall WebAdmin nie jest już dostępny, nie trzeba natychmiast uruchamiać całej zapory ogniowej. Często wystarczy zrestartować usługi WebAdmin w kontrolowany sposób za pomocą Advanced Shell. Jest to znacznie mniej inwazyjne niż całkowite ponowne uruchomienie i może zaoszczędzić cenny czas w okresie wsparcia lub konserwacji.

Typowe objawy to:

• W interfejsie GUI WebAdmin wyświetlany jest komunikat Internal Server Error.
• Strona logowania lub pulpit nawigacyjny nie ładują się już całkowicie.
• WebAdmin odpowiada bardzo wolno lub zawiesza się po kliknięciu.
• Inne usługi, takie jak routing, VPN lub reguły zapory sieciowej, nadal działają.
• SSH lub konsola lokalna są nadal dostępne.

W praktyce może się to zdarzyć po dużym obciążeniu interfejsu GUI, wielu jednoczesnych sesjach administracyjnych, intensywnym użyciu przechwytywania pakietów lub ogólnych problemach z zasobami. Jeśli zapora sieciowa jest ogólnie niestabilna, partycje są zapełnione lub kilka usług nie działa, graficzny interfejs użytkownika WebAdmin nie powinien być jedyną rzeczą do rozważenia. Wtedy pasują również Sophos Firewall Usługi i logi, Sophos Firewall Bezpiecznie uruchom ponownie usługi i Sprawdź miejsce na dysku i zarządzaj raportami.

⚠️ Ważne: Ponowne uruchomienie usługi to ingerencja w zaporę sieciową. Przed wprowadzeniem produktywnych zmian powinno być jasne, kto jest podłączony, czy konieczne jest okno konserwacji i czy dostępny jest alternatywny dostęp przez SSH, konsolę lokalną lub partnera HA.

Wymagania

Do ukierunkowanego ponownego uruchomienia potrzebujesz:

• Dostęp do użytkownika admin.
• Dostęp SSH lub dostęp do konsoli lokalnej.
• Dostęp do Advanced Shell.
• Wyraźny obraz błędu: problem dotyczy programu WebAdmin, ale zapora sieciowa nie musi być całkowicie restartowana.
• Jak najkrótszy czas konserwacji lub diagnostyki, jeśli problem dotyczy kilku administratorów.

Jeśli SSH nie jest jeszcze przygotowany, pomoże Sophos Firewall połącz się przez SSH. Sam dostęp kontrolowany jest poprzez Administration > Device access. Skonfiguruj poprawnie Device Access to właściwy, podstawowy artykuł dotyczący zabezpieczania protokołów HTTPS/WebAdmin i SSH.

Po zalogowaniu przez SSH Advanced Shell otwiera się przez 5. Device Management > 3. Advanced Shell. Sophos zamyka nieaktywne sesje SSH po 15 minutach. Podczas incydentu GUI należy więc wykonać sprawdzenie logów, status usług i restart bez długich przerw albo świadomie otworzyć sesję ponownie, jeśli jest to potrzebne.

Sprawdź krótko przed ponownym uruchomieniem

Przed ponownym uruchomieniem usług należy wyizolować problem:

1. Sprawdź, czy problem dotyczy tylko WebAdmin, czy też nie działają reguły VPN, routingu, DNS lub zapory sieciowej.
2. Jeśli to możliwe, przetestuj w drugiej przeglądarce lub prywatnym oknie.
3. Sprawdź, czy w GUI pracują obecnie inni administratorzy.
4. Zaloguj się przez SSH i otwórz plik Advanced Shell.
5. Opcjonalnie wyświetl krótko odpowiednie logi.

Najważniejsze pliki dziennika to:

• Serwer WWW WebAdmin: /log/apache.log i /log/apache_access.log.
• Aplikacja WebAdmin: /log/tomcat.log.
• Błąd interfejsu użytkownika/systemu: /log/error_log.log.

Przykład szybkiej kontroli wizualnej:

tail -n 80 /log/tomcat.log
tail -n 80 /log/apache.log

Jeśli chcesz utworzyć kopię zapasową dzienników zgłoszenia do pomocy technicznej, wyeksportuj je przed ponownym uruchomieniem. Proces odbywa się w Sophos Firewall Utwórz kopię zapasową dzienników w celu wsparcia i analizy.

Prawidłowo sklasyfikowaj wzór błędu

Nie każdy problem WebAdmin jest spowodowany przez tomcat lub apache. Przed ponownym uruchomieniem pomoże krótka klasyfikacja:

Typowa klasyfikacja:

• WebAdmin pokazuje Internal Server Error: Często jest to spowodowane aplikacją GUI lub serwerem WWW. Sprawdź tomcat.log i apache.log i specjalnie zrestartuj usługi.
• Przeglądarka raportuje ostrzeżenie o certyfikacie: Najpierw sprawdź certyfikat, nazwę i łańcuch zaufania, nie uruchamiaj bezpośrednio usług ponownie.
• Upłynął limit czasu połączenia: W takim przypadku bardziej prawdopodobne jest, że Device Access, routing, ACL, VPN lub sieć zarządzająca. Sprawdź dostępność i Administration > Device access.
• Logowanie działa, panel kontrolny zawiesza się później: Sprawdź obciążenie GUI, sesję, raporty, pamięć lub bazę danych.
• WebAdmin i SSH nie są dostępne: W takim razie bardziej chodzi o ścieżkę dostępu, Device Access lub stan systemu. Sprawdź konsolę lokalną, partnera HA lub centralne zarządzanie.
• Kilka usług przestaje działać w tym samym czasie: Sugeruje to raczej problem systemowy niż czysty problem z GUI. Utwórz kopię zapasową dzienników, sprawdź miejsce na dysku i oceń ponowne uruchomienie lub przypadek pomocy technicznej.

Ta klasyfikacja zapobiega niepotrzebnemu ponownemu uruchamianiu usług WebAdmin w przypadku problemów z dostępem do sieci lub urządzenia. Jeśli nie powiedzie się dostęp tylko z określonej sieci, Device Access i Local Service ACL do Sophos Firewall jest zwykle ważniejszy niż ponowne uruchomienie usługi.

Kiedy lepiej odłożyć ponowne uruchomienie

Ponowne uruchomienie tomcat i apache jest stosunkowo ukierunkowane, ale nadal stanowi interwencję na poziomie administracyjnym zapory ogniowej. W takich sytuacjach należy najpierw krótko ustabilizować lub udokumentować:

• Trwa aktualizacja oprogramowania sprzętowego, poprawka lub aktualizacja wzorca: Nie ingeruj w usługi WebAdmin w tym samym czasie, dopóki proces aktualizacji jest aktywny.
• Klaster HA jest obecnie synchronizowany: Najpierw sprawdź rolę HA, synchronizację i aktywny węzeł.
• Trwa debugowanie pomocy technicznej lub zbieranie dzienników: Najpierw zapisz odpowiednie logi, a następnie uruchom ponownie usługi.
• Zadanie centralne jest obecnie aktywne: Sprawdź kolejkę zadań, aby trwająca zmiana centralna nie została pomieszana z lokalnym problemem GUI.
• Dotyczy to tylko jednej przeglądarki administratora: Najpierw przetestuj sesję prywatną, drugą przeglądarkę lub innego klienta.

Ta krótka przerwa oszczędza późniejszą pracę wyjaśniającą. Jeśli natychmiast po ponownym uruchomieniu nie jest już jasne, czy błąd pochodzi z WebAdmin, Central, HA, czy z trwającej aktualizacji, analiza staje się niepotrzebnie trudna.

Uruchom ponownie usługi WebAdmin

Interfejs GUI WebAdmin zależy przede wszystkim od dwóch usług:

• tomcat: Aplikacja WebAdmin.
• apache: Serwer WWW WebAdmin.

Przed restartem warto najpierw sprawdzić status:

service -S | grep -iE 'tomcat|apache'

Jeśli usługa ma stan STOPPED, celowe uruchomienie jest czystsze niż restart w ciemno:

service tomcat:start -ds nosync
service apache:start -ds nosync

Jeśli tomcat lub apache pokazują DEAD, albo pokazują RUNNING, ale WebAdmin nadal nie działa, można zrestartować obie usługi jedna po drugiej:

service tomcat:restart -ds nosync
service apache:restart -ds nosync

Następnie poczekaj kilka sekund i ponownie otwórz interfejs GUI WebAdmin. Jeśli logowanie znów zadziała, warto jeszcze sprawdzić, czy w Log Viewer lub w logach systemowych nie widać powtarzających się błędów.

Sprawdź stan

Jeśli ponowne uruchomienie nie wystarczy, możesz sprawdzić status usług:

service tomcat:status -ds nosync
service apache:status -ds nosync

Możesz także sprawdzić, czy usługi pojawiają się na liście usług:

service -S | grep -E 'tomcat|apache'

Ogólne przypisanie usług, modułów i plików dziennika znajduje się w Sophos Firewall Rozwiązywanie problemów: usługi i dzienniki. Wyjaśnia również, kiedy Log Viewer, Advanced Shell lub pojedyncze pliki dziennika są lepszym źródłem analizy.

Sprawdź po ponownym uruchomieniu

Jeśli WebAdmin załaduje się ponownie, problem nie został jeszcze całkowicie rozwiązany. Powinieneś krótko sprawdzić, czy GUI pozostaje stabilny i czy przyczyna znów staje się widoczna.

Przydatna kontrola następcza:

1. Otwórz WebAdmin z wybranej sieci zarządzania.
2. Zaloguj się na konto administratora i przetestuj panel kontrolny, Log Viewer i niekrytyczną stronę konfiguracji.
3. Sprawdź ponownie tomcat.log, apache.log i error_log.log pod kątem nowych błędów.
4. Sprawdź miejsce na dysku i raporty lokalne, czy GUI nie było wcześniej wolne lub puste.
5. Wyklucz otwarte sesje administracyjne, pamięć podręczną przeglądarki lub równoległy dostęp administratora jako przyczynę.
6. Ponownie tymczasowo ogranicz dozwolony dostęp przez SSH lub dostęp do urządzenia.
7. W przypadku klastrów HA sprawdź, czy pracujesz na oczekiwanym węźle.

Jeśli problem będzie się powtarzał, nie należy codziennie uruchamiać tomcat i apache. Następnie konieczna jest analiza głównych przyczyn: przestrzeń dyskowa, stan bazy danych, raporty, błędy GUI, obciążenie systemu, rola HA i ostatnie zmiany w konfiguracji. W przypadku zmian na krótko przed błędem pomocny jest Sophos Firewall Sprawdź dzienniki ścieżki audytu.

Jeśli WebAdmin jest nadal niedostępny

Jeśli interfejs GUI jest nadal niedostępny po ponownym uruchomieniu tomcat i apache, nie powinieneś ponownie uruchamiać dowolnej liczby usług. Ustrukturyzowane ograniczenie ma większy sens:

• Sprawdź Device Access: Czy protokół HTTPS/WebAdmin jest dozwolony w bieżącej strefie i źródle?
• Wyklucz przeglądarkę: Testuj pamięć podręczną, sesję prywatną lub drugą przeglądarkę.
• Sprawdź certyfikat: Wygasły lub nieprawidłowy certyfikat może utrudnić dostęp, ale zwykle nie powoduje prawdziwego wewnętrznego błędu serwera.
• Sprawdź obciążenie systemu: Wysokie użycie procesora, pamięci RAM lub dysku może mieć wpływ na program WebAdmin.
• Sprawdź miejsce na dysku: Pełne partycje mogą powodować problemy z GUI i raportowaniem.
• Sprawdź logi: Przeskanuj tomcat.log, apache.log i error_log.log pod kątem bieżących błędów.
• Uwaga kontekst HA: W przypadku klastrów HA sprawdź, nad którym węzłem pracujesz i który węzeł jest aktywny.
• Sprawdź ostatnie zmiany: Ścieżka audytu i Studio konfiguracji mogą pokazać, czy ostatnio zmieniono Device Access, certyfikat, interfejs lub ustawienia administratora.

Jeśli WebAdmin i SSH nie są dostępne, w zależności od lokalizacji pozostaje tylko konsola lokalna, zarządzanie Sophos Central, przełączanie awaryjne HA lub planowane ponowne uruchomienie. W środowiskach produkcyjnych taki przypadek powinien być przygotowany w procesie eksploatacji i odtwarzania.

Lokalizacje zdalne i klastry HA

Dzięki pojedynczej zaporze sieciowej w głównej lokalizacji ponowne uruchomienie programu WebAdmin jest zwykle łatwe do kontrolowania. W przypadku zdalnych lokalizacji lub klastrów HA należy wcześniej dokładniej sprawdzić, jaką ścieżką odbywa się dostęp i jaki poziom rezerwowy jest dostępny.

Ważne pytania:

• Czy dostęp odbywa się bezpośrednio z sieci zarządzania, przez VPN, przez Sophos Central czy przez host skoku?
• Czy SSH jest naprawdę dostępny, czy działa tylko istniejąca sesja WebAdmin?
• Czy na miejscu jest ktoś, kto w razie potrzeby może sprawdzić urządzenie?
• W przypadku HA: nad którym węzłem pracujesz i który węzeł jest obecnie podstawowy?
• Czy planowane przełączenie awaryjne spowoduje większe ryzyko niż docelowe ponowne uruchomienie tomcat i apache?
• Czy dzienniki i czas udokumentowane przed przełączeniem awaryjnym lub ponownym uruchomieniem utrudniają analizę?

W środowiskach HA nie należy automatycznie przełączać awaryjnego tylko dlatego, że WebAdmin zawiesza się na aktywnym węźle. Jeśli ruch będzie się utrzymywał, ukierunkowane ponowne uruchomienie usługi GUI jest często mniej inwazyjne. Jeśli jednak problem dotyczy wielu usług, aktywny węzeł wydaje się niestabilny lub dostęp zostanie całkowicie utracony, sprawa należy do kontrolowanego procesu HA lub odzyskiwania lokalizacji.

Kiedy całkowity restart ma większy sens

Ponowne uruchomienie nie jest pierwszym rozwiązaniem w przypadku zawieszającego się interfejsu GUI WebAdmin. Ale może się przydać, jeśli:

• kilka centrali już nie odpowiada
• zapora sieciowa pozostaje niestabilna po ponownym uruchomieniu usługi
• Rozwiązano problemy z pamięcią lub bazą danych i wymagany jest czysty rozruch
• Określa to wsparcie Sophos lub okno konserwacji
• klaster HA może przełączać awaryjnie w kontrolowany sposób

Przed ponownym uruchomieniem należy znać tworzenie kopii zapasowych, okna konserwacji, dostęp do lokalizacji i wpływ na VPN, routing, RED, usługi bezprzewodowe i opublikowane.

Lista kontrolna

• Udokumentowany obraz błędu: Internal Server Error, przekroczenie limitu czasu lub pusta strona WebAdmin.
• Dostępna konsola SSH lub lokalna.
• Advanced Shell otwarte.
• Krótko sprawdzone tomcat.log i apache.log.
• Status sprawdzony przez service -S | grep -iE 'tomcat|apache'.
• service tomcat:restart -ds nosync wykonano.
• service apache:restart -ds nosync wykonano.
• WebAdmin przetestowany ponownie.
• Sprawdzono przestrzeń dyskową, Device Access i logi systemowe pod kątem powtarzających się błędów.
• Dzienniki zapisywane w celu wsparcia w przypadku przerw w produkcji.
• Przed ponownym uruchomieniem sprawdzano bieżące aktualizacje, synchronizację HA, zadania centralne lub debugowanie wsparcia.
• Tymczasowe uprawnienia SSH lub Device Access zostały ponownie usunięte.
• Powtarzające się błędy nie są ukrywane tylko przy ponownym uruchomieniu usługi.

Często zadawane pytania