Sophos Central Sprawdź kolejkę zadań zarządzania zaporą sieciową

Jeśli zmiana została zapisana w Sophos Central, ale nie dotarła do Sophos Firewall, lokalna zapora sieciowa nie zawsze jest pierwszym źródłem błędu. W przypadku centralnie zarządzanych zapór sieciowych powinieneś także sprawdzić Kolejkę zadań w Sophos Central. Tam możesz zobaczyć, czy Centrala nadal przetworzyła profil grupowy, zadanie firewalla opartego na API lub inną centralną zmianę, częściowo ją zastosowała, pominęła lub zakończyła z błędem.

Jest to szczególnie ważne, gdy w grupie zarządzanych jest wiele zapór sieciowych. Pojedyncze nieudane zadanie może opóźnić późniejsze zmiany lub skomplikować rozwiązywanie problemów, ponieważ konfiguracja na Sophos Central wygląda inaczej niż na zaporze, której dotyczy problem.

Kolejka zadań nie zastępuje więc logów, Packet Capture ani lokalnej kontroli na firewallu. Najpierw odpowiada na pytanie transportowe: czy Sophos Central przyjął zadanie, przetworzył je i zastosował na danym firewallu lub grupie? Dopiero potem ma sens właściwa analiza firewalla.

Gdy kolejka zadań jest istotna

Kolejka zadań ma znaczenie, gdy zmiany nie są przeprowadzane bezpośrednio lokalnie na firewallu, ale poprzez Sophos Central. Dotyczy to szczególnie środowisk, w których zapory sieciowe są podłączone do Sophos Central i aktywnie wykorzystywane jest Centralne zarządzanie zaporami sieciowymi.

Typowe sytuacje:

• zmieniono polisę grupową na Sophos Central
• zmiana pojawiła się w niektórych zaporach ogniowych, ale nie w innych
• zaplanowano lub uruchomiono aktualizację oprogramowania sprzętowego za pośrednictwem Sophos Central — Zadania zapory sieciowej MDR lub opartej na interfejsie API wydają się nie w pełni zaimplementowane
• zadanie jest na Pending lub In Progress przez długi czas
• zadanie to Failed, Skipped, Invalid license lub tylko częściowo zakończone sukcesem
• po wystąpieniu błędu kolejne zmiany nie są przetwarzane zgodnie z oczekiwaniami

Zapora sieciowa Log Viewer pozostaje ważna przy lokalnym rozwiązywaniu problemów na żywo. Ale kolejka zadań odpowiada na inne pytanie: czy Sophos Central pomyślnie przekazał zmianę do zapory ogniowej?

Gdzie znaleźć kolejkę zadań

Ścieżka Sophos Central to:

My Products > Firewall Management > Tasks Queue

Sophos rozróżnia dwie zakładki. To ważne rozdzielenie, ponieważ polityki grupowe i zadania API/MDR nie powinny być mieszane.

• Task Queue: status polityk grup firewalli stosowanych do firewalli przez Sophos Central.
• Firewall Task Queue: zadania firewalli z MDR Settings, MDR IOCs i Firewall Configuration API. Widok grupuje zadania między innymi według Pending, In Progress, Failed, Partial Successful i Successful.

W przypadku klasycznych problemów z zarządzaniem centralnym firewallem, Kolejka zadań jest zazwyczaj pierwszą rzeczą, która nas interesuje. Kolejka zadań zapory staje się ważniejsza, gdy zmiany zostały wywołane za pośrednictwem interfejsu API konfiguracji zapory lub funkcji zapory związanych z MDR.

W widoku kolejki zadań ważna jest także historia. Użyj Show History, aby wyświetlić zakończone lub pominięte zadania dla zapór sieciowych lub grup, które zostały usunięte. W przypadku przeglądów zmian lub przypadków pomocy technicznej należy mimo to niezwłocznie udokumentować istotne szczegóły zadania, ponieważ zadania Pending nie pozostają na stałe w interfejsie po długim czasie.

Jakie informacje są ważne

Pojedyncze zadanie jest przydatne tylko wtedy, gdy jest odpowiednio zorganizowane. Przed dokonaniem zmiany lub Retry powinieneś zanotować przynajmniej te pola:

• Numer zadania
• dotknięta grupa lub zapora sieciowa
• Stan
• czas
• Identyfikator administratora lub identyfikator poświadczeń
• Podjednostka i podjednostka
• wyświetlił się komunikat o błędzie
• Liczba pomyślnych i nieudanych zapór ogniowych

Moment nie zawsze jest równoznaczny z rozpoczęciem przetwarzania na każdej zaporze. W przypadku polityk grupowych Sophos Central najpierw pokazuje czas utworzenia lub modyfikacji, a później aktualizuje go, gdy polityka jest stosowana do zapór sieciowych. Dlatego nie powinieneś patrzeć tylko na dłuższe wdrożenia za pierwszym razem.

Źródło zadania jest ważne przy rozwiązywaniu problemów. Nazwa użytkownika z większym prawdopodobieństwem będzie wskazywać na zmianę w portalu Sophos Central. Identyfikator poświadczenia wskazuje zamówienie powiązane z interfejsem API lub MDR. W takim przypadku warto także sprawdzić, który system lub proces spowodował zmianę.

Przy politykach grupowych ważny jest także widok grupy: czy firewall naprawdę znajduje się w oczekiwanej grupie lub podgrupie, czy odziedziczył politykę, albo czy został dodany do grupy z Skip full sync? Pominięty full sync może być zamierzony, ale łatwo tworzy różnicę między Central a lokalnym firewallem.

Jeżeli firewall został świadomie dodany z Skip full sync, nie należy zakładać czystej bazy grupowej bez kontroli. W Sophos Central można uruchomić Force sync z poziomu statusu synchronizacji firewalla. W parach HA pełną synchronizację trzeba uruchomić na aktywnym firewallu, ponieważ Sophos nie pokazuje linku dla firewalli pasywnych.

Prawidłowo zinterpretuj status

• Pending: Zadanie nadal oczekuje na realizację. Jeśli czas trwania jest dłuższy, sprawdź łączność, licencję i połączenie centralne.
• In Progress: Centrala nadal przetwarza zadanie. Nie rozpoczynaj wielu poprawek równolegle, jeśli zadanie jest aktualnie uruchomione.
• Success: Centrala zgłasza zadanie jako zakończone powodzeniem. Następnie sprawdź na zaporze firewall, czy oczekiwany efekt jest widoczny.
• Partial Success: Niektóre zostały zastosowane, inne nie. Jest to szczególnie ważne w przypadku grup lub kilku obiektów.
• Failed: Zmiana nie została pomyślnie ukończona. Udokumentuj komunikat o błędzie i zaporę, której dotyczy problem.
• Skipped: Zadanie zostało celowo pominięte. Konieczna jest wówczas profesjonalna kontrola kontrolna.
• Invalid license: Licencja lub autoryzacja nie jest zgodna z planowanym działaniem. Nie należy próbować rozwiązać tego problemu poprzez wielokrotne Retry.

Sophos Central może automatycznie usuwać zadania ze statusem Pending po trzech tygodniach. Dlatego też należy niezwłocznie tworzyć kopie zapasowe istotnych błędów na potrzeby dokumentacji operacyjnej, spraw wsparcia lub przeglądów zmian.

Success oznacza tylko, że Sophos Central pomyślnie przetworzył zamówienie. Nie oznacza to automatycznie, że żądany ruch działa, że ​​reguła rzeczywiście pasuje lub że użytkownik może ponownie pracować. Do produktywnych zmian wymagane są zawsze trzy poziomy: sprawdzenie zadania centralnego, sprawdzenie konfiguracji lokalnej zapory sieciowej i przetestowanie efektu technicznego.

Polityka Central nie jest automatycznie lokalną prawdą

W przypadku reguł firewall i NAT zarządzanych przez Sophos Central istnieje ważna różnica operacyjna: pozycja Top lub Bottom opisuje najpierw kolejność wewnątrz polityki Central. Na firewallu reguły wysłane z Central są wstawiane na górze lokalnej listy reguł. Jeżeli równocześnie istnieją lokalne reguły, efektywna kolejność może wyglądać inaczej, niż oczekuje się w edytorze Central.

Avanet zaleca więc jasną decyzję operacyjną dla firewalli zarządzanych centralnie: albo reguły są konsekwentnie zarządzane przez Sophos Central, albo lokalne wyjątki są świadomie dokumentowane i sprawdzane po każdej zmianie w Central. Tryb mieszany działa technicznie, ale jest bardziej podatny na błędy, ponieważ Task Queue, lokalny Rule ID, lokalny NAT Rule ID i Audit Trail trzeba czytać razem.

Czysty proces testowania

Jeśli zmiana centralna zostanie zablokowana, cichy proces pomoże bardziej niż wielokrotne klikanie Retry.

1. Otwórz Sophos Central My Products > Firewall Management > Tasks Queue.
2. Ogranicz okres i firewall lub grupę firewalli, których dotyczy zmiana.
3. Otwórz zadanie i sprawdź firewalle, których dotyczy problem.
4. Udokumentuj status, komunikat błędu, entity, sub-entity i czas.
5. W przypadku usuniętych firewalli lub grup włącz w razie potrzeby Show History.
6. Sprawdź grupę lub podgrupę, z której przyszła polityka.
7. Przy podejrzeniu różnicy grupowej sprawdź status synchronizacji i świadomie zdecyduj, czy Force sync ma sens.
8. Sprawdź na firewallu, czy zmiana jest widoczna, czy istnieje tylko w Central.
9. Przy regułach firewall lub NAT skontroluj lokalną pozycję reguły, Rule ID i NAT Rule ID.
10. Jeżeli chodzi o zmiany konfiguracji, sprawdź także Dzienniki audytu.
11. Oceń Log Viewer, Policy Test i właściwe logi usług pod kątem problemów z ruchem.
12. Dopiero potem zdecyduj, czy Retry, Skip albo zgłoszenie do supportu ma sens.

Jeśli nie jest jasne, który dziennik lokalny jest odpowiedni, pomocne będzie Sophos Firewall Rozwiązywanie problemów: Services i dzienniki. Do analizy reguł i ruchu odpowiednia jest również opcja Testuj regułę zapory sieciowej za pomocą Log Viewer, Policy Test i Packet Capture.

Partial Success czysto przetworzone

Partial Success jest bardziej niebezpieczny niż wyraźny błąd, ponieważ część środowiska została już zmieniona. Dlatego w przypadku zasad grupowych należy najpierw otworzyć i odłączyć zapory ogniowe, których to dotyczy:

• Zapory ogniowe z pomyślną aplikacją
• Zapory ogniowe z błędami
• Zapory ogniowe, które są offline, niemożliwe do zarządzania lub zablokowane przez licencję
• Zapory ogniowe z inną wersją lub platformą SFOS

Nie należy od razu ponownie wprowadzać tej samej zmiany w całej grupie. Lepiej jest dokonać ukierunkowanej korekty zapory ogniowej lub grupy, której dotyczy problem, a następnie sprawdzić Retry i następnie porównać konfigurację lokalnej zapory ogniowej. W przypadku większych zmian Sophos Firewall Użyj Config Studio pomaga w zrozumiałym porównaniu oczekiwanych i rzeczywistych konfiguracji.

Skip czy Retry?

Sophos Central oferuje promocje Skip i Retry w zależności od statusu. Obydwa są przydatne, ale nie należy ich postrzegać jako czystego czyszczenia.

• Retry: przyczyna została usunięta, np. połączenie, licencja, konflikt obiektów lub tymczasowa awaria centrali Czy jest jasne, dlaczego zadanie się nie powiodło?
• Skip: nieudane lub nieistotne bloki zadań, późniejsze zadania i wpływ techniczny jest zrozumiany Czy jest to celowe niezastosowanie planowanej zmiany polityki?
• Czekaj: zadanie jest aktualnie uruchomione lub Centrala przetwarza wiele zapór Czy są jakieś dowody na rzeczywistą blokadę, czy po prostu normalne opóźnienie?
• Sprawa wsparcia: błąd występuje wielokrotnie, wpływa na kilka produktywnych zapór ogniowych lub komunikat jest niejasny Czy szczegóły zadania, czas, nazwa zapory i dzienniki są zabezpieczone?

⚠️ Nie pomijaj nieudanego zadania tylko po to, żeby kolejka wyglądała na czystą. Skip to decyzja operacyjna: Niewprowadzona zmiana musi zostać następnie świadomie sprawdzona lub osobno wdrożona.

Przed Retry powinieneś przynajmniej sprawdzić, czy zapora sieciowa w Sophos Central jest online, czy Zarządzaj z Sophos Central jest nadal aktywna, czy licencja i wersja oprogramowania sprzętowego odpowiadają planowanemu działaniu oraz czy lokalny firewall nie odrzuci zadania ze względu na różnice w obiekcie, polityce lub platformie. Powtórzenie Retry bez sprawdzania przyczyny źródłowej powoduje jedynie utworzenie nowych wpisów, ale rzadko zapewnia przejrzystość.

Typowe wzorce błędów

Zmiana jest widoczna w Centrali, ale nie na zaporze

W takim przypadku należy najpierw sprawdzić, czy odpowiednie zadanie zostało wykonane pomyślnie. Jeśli zadaniem nadal jest Pending, In Progress, Failed lub Partial Success, problem niekoniecznie leży w regule lokalnej zapory sieciowej. Dopiero gdy Central zgłosi zadanie jako zakończone sukcesem, należy zagłębić się w analizę lokalnych zasad, obiektów lub dzienników.

Jeśli zadanie się powiedzie, ale lokalna zapora wygląda inaczej, należy sprawdzić, czy zapora rzeczywiście należy do oczekiwanej grupy, czy lokalna zmiana utrudnia interpretację i czy pracujesz na właściwej zaporze ogniowej, czy na właściwym kliencie. Ten banalny czek jest zaskakująco cenny, zwłaszcza gdy istnieje wiele kont Sophos Central lub transferów kont.

Krótka kontrola praktyczna: wygenerować ruch testowy, filtrować w Log Viewer po source, destination i service, a następnie porównać rzeczywisty Firewall Rule ID oraz NAT Rule ID z oczekiwaną regułą. Jeżeli te ID się nie zgadzają, problemem nie jest samo zadanie Central, lecz lokalna kolejność reguł lub NAT.

Dotyczy to tylko pojedynczych zapór sieciowych w grupie

Dzięki zasadom grupy zmiana może zakończyć się powodzeniem na wielu zaporach sieciowych i zakończyć się niepowodzeniem na jednej zaporze. W takim przypadku nie powinieneś zmieniać całej grupy, ale raczej otworzyć zaporę ogniową, której dotyczy problem i sprawdzić różnice: licencję, wersję oprogramowania sprzętowego, połączenie centralne, konflikty obiektów lokalnych, platformę i znane problemy.

Zadanie oprogramowania sprzętowego za pośrednictwem Centrali nie uruchamia się poprawnie

Jeśli Sophos Firewall Aktualizacja oprogramowania układowego została zaplanowana za pośrednictwem Sophos Central, kolejka zadań powinna być częścią dalszych działań. Jeśli zapora sieciowa pozostaje w starej wersji, najpierw sprawdź, czy Central uruchomił i wykonał zadanie. W przypadku głównych wydań częścią przygotowań jest również Sprawdzanie aktualizacji SFOS 22.

Synchronizacja zasad sieciowych lub TLS nie powiodła się

W przypadku ochrony sieci, grup adresów URL lub wykluczeń TLS synchronizacja centralna może być szczególnie myląca, ponieważ centrala zaakceptowała zmianę, ale zapora ogniowa nie przetwarza jej w pełni. Następnie należy porównać obiekt z kolejki zadań, którego dotyczy problem, z konfiguracją lokalną. Do klasyfikacji technicznej odpowiednie są Sophos Firewall Wstaw poprawnie TLS Inspection i Sophos Firewall Utwórz politykę ochrony sieci.

XGS 88/w i lokalna lista wykluczeń TLS

Specyficzny problem z modelami XGS 88/w jest udokumentowany na liście znanych problemów: Podczas synchronizacji zasady Sophos Central przetwarzanie Listy wykluczeń lokalnego TLS może się nie powieść. Wyświetlany komunikat o błędzie dotyczy grupy adresów URL, której nie można zaktualizować. W takim przypadku możesz pominąć nieudaną transakcję z kolejki zadań, aby móc kontynuować wykonywanie późniejszych zadań.

W praktyce jednak nie należy po prostu ruszać dalej. Kontrola kontrolna jest ważna:

• Czy żądany wyjątek TLS występuje lokalnie na zaporze?
• Czy zasady sieciowe i TLS w zaporze są nadal technicznie prawidłowe?
• Czy problem dotyczy tylko jednego XGS 88/w, czy kilku zapór sieciowych?
• Czy zmiana musi zostać tymczasowo wdrożona lokalnie, czy też przełożona?
• Czy dla wersji, której dotyczy problem, dostępna jest wersja konserwacyjna lub powiadomienie Sophos?

Dalsza kontrola zapory ogniowej

Pomyślne wykonanie zadania centralnego jest dobrym sygnałem, ale nie pełnym testem operacyjnym. W zależności od zmiany należy sprawdzić lokalnie:

• Czy widoczna jest zmieniona reguła, polityka, lista lub wersja oprogramowania?
• Czy Log Viewer pokazuje oczekiwane zdarzenia?
• Czy zmiana została zarejestrowana w ścieżce audytu?
• Czy połączenie centralne i raportowanie są nadal aktywne?
• Czy użytkownicy, których dotyczy problem, VPN, dostęp do sieci lub aplikacje działają?

W przypadku zmian istotnych dla bezpieczeństwa należy również zdefiniować krótki punkt wycofania. Dotyczy to szczególnie ochrony sieci, TLS Inspection, reguł zapory ogniowej, klastrów VPN, HA i aktualizacji oprogramowania sprzętowego.

Operacyjna lista kontrolna

• Przed wprowadzeniem zmian za pomocą Sophos Central należy wyjaśnić, których zapór lub grup dotyczy.
• Sprawdź kolejkę zadań po zmianach w Centrali.
• Dokumentuj nieudane zadania z komunikatem o błędzie, czasem i nazwą zapory.
• Nie traktuj Partial Success jako kompletnego.
• W przypadku usuniętych zapór sieciowych lub grup sprawdź Show History.
• Przy Skip full sync lub różnicach grupowych sprawdzić, czy Force sync jest technicznie właściwy i bezpieczny.
• Używaj Retry dopiero po sprawdzeniu przyczyny.
• Używaj Skip tylko wtedy, gdy rozumiesz wpływ techniczny.
• Success potwierdzony testem lokalnym oraz dowodem z logu lub audytu.
• W przypadku zadań API lub MDR przypisz identyfikator uwierzytelnienia i system wyzwalający.
• Planuj okna konserwacji, tworzenie kopii zapasowych i dostęp lokalny do zadań oprogramowania sprzętowego.
• W przypadku powtarzających się błędów wykonaj kopię zapasową ścieżki audytu, Log Viewer i informacji pomocy technicznej Sophos.

Potwierdź Success scenariuszem testowym

Success w Task Queue zawsze powinien być połączony z odpowiednim scenariuszem testowym. W przeciwnym razie wiadomo tylko, że Central przetworzył zadanie, ale nie czy dana funkcja naprawdę działa.

Praktyczna walidacja:

• Zmieniono regułę firewall: wygeneruj ruch testowy z source, destination, service i oczekiwanym Rule ID.
• Zmieniono NAT lub DNAT: przetestuj dostęp zewnętrzny lub wewnętrzny i sprawdź Firewall Rule ID oraz NAT Rule ID w Log Viewer.
• Zmieniono politykę Web lub TLS: porównaj klienta testowego, domenę docelową, log Web i log SSL/TLS-inspection.
• Zmiana VPN lub Remote Access: sprawdź logowanie, adres z puli, dostępność wewnętrzną i mapowanie użytkownika.
• Zadanie firmware lub backupu: sprawdź wersję, status startu, rolę HA, połączenie Central i czas ostatniego backupu.
• Zadanie MDR, ATR lub API: udokumentuj Credential ID, system wyzwalający, widoczność lokalną i oczekiwane zdarzenie logu.

Do przeglądu zmiany wystarczy krótki dowód: status zadania, objęty firewall, test lokalny, dowód z logu lub audytu oraz punkt otwarty. Zapobiega to traktowaniu udanego zadania Central jako pełnej walidacji technicznej.

Często zadawane pytania