Reguła Sophos Firewall nie działa: sprawdź przyczyny

Gdy reguła Sophos Firewall nie działa, nie należy od razu przesuwać reguł ani rozszerzać obiektów. Najpierw trzeba odtworzyć i obserwować jeden przepływ danych: czy pakiet dociera, które Firewall Rule ID i NAT Rule ID go przetwarzają, czy jest przekazywany dalej i czy wraca odpowiedź?

Najczęściej okazuje się, że warunek wygląda inaczej niż oczekiwano, bardziej ogólna reguła znajdująca się wyżej dopasowuje się jako pierwsza albo problem występuje dopiero po podjęciu decyzji przez regułę. Sama zapora jest przyczyną znacznie rzadziej niż niedokładnie zdefiniowany test.

Szybka decyzja: Jeśli prawidłowo uruchomiony i odfiltrowany Packet Capture nie pokazuje pakietu, najpierw sprawdza się klienta, VLAN, bramę lub wcześniejszą część ścieżki. Inna Rule ID kieruje analizę do kolejności i dopasowania. Jeśli Rule ID i NAT ID są prawidłowe, analizę kontynuuje się w obszarze routingu, trasy zwrotnej, systemu docelowego lub modułu bezpieczeństwa.

Szybka ścieżka: śledzenie konkretnego przepływu

Do pierwszego zawężenia wystarczy sześć kroków:

1. Określić przepływ testowy: Zanotować Source IP, Source zone, User, Destination, protokół, port i czas.
2. Potwierdzić wejście: Uruchomić Packet Capture z precyzyjnym Capture Filter i wywołać ten sam przepływ.
3. Sprawdzić Firewall Rule ID: Porównać w Log Viewer lub Packet Capture z oczekiwaną regułą.
4. Sprawdzić NAT Rule ID: Jeśli używany jest NAT, skontrolować rzeczywistą regułę NAT i jej translację.
5. Sprawdzić przekazanie i odpowiedź: Wyszukać Forwarded, interfejs wyjściowy oraz pakiety zwrotne.
6. Dopiero potem przejść głębiej: Zbadać routing, SD-WAN, User Matching, TLS Inspection, IPS, Web Policy lub system docelowy.

Taki przebieg rozdziela poszczególne warstwy. Reguła firewalla decyduje o dostępie i funkcjach ochronnych, NAT tłumaczy adresy lub porty, routing wybiera dalszą ścieżkę, a system docelowy musi znać trasę zwrotną. Gdy wszystkie warstwy zmienia się jednocześnie, objaw może czasem zniknąć, ale przyczyna pozostaje niejasna.

Jeśli test dotyczy WebAdmin, User Portal, VPN Portal, SSH, DNS, SNMP lub innej usługi samej zapory, nie obowiązują te same reguły co dla ruchu tranzytowego. W takim przypadku ścieżka diagnostyczna prowadzi bezpośrednio do Administration > Device access i Local Service ACL.

Definiowanie powtarzalnego przypadku testowego

Stwierdzenie „internet nie działa” albo „reguła VPN nie działa” jest zbyt ogólne. Użyteczny przypadek testowy wygląda na przykład tak:

• Source IP: 10.10.20.35
• Source zone: LAN
• User: admin@example.com lub świadomie bez User Matching
• Destination: app.example.net, obecnie rozwiązywana na 203.0.113.20
• Service: TCP 443
• Oczekiwana reguła firewalla: LAN-App-HTTPS, Rule ID 37
• Oczekiwana reguła NAT: NAT Rule ID 12 lub wyraźnie brak reguły NAT
• Czas testu: 2026-08-08 10:15:00

Adresy IP, identyfikatory, nazwy i czas są wartościami przykładowymi i należy je zastąpić wartościami z własnego środowiska. Ważna jest forma: podczas diagnostyki Source, docelowy adres IP, port i użytkownik pozostają bez zmian. Jeśli w trakcie zmieni się rozwiązywanie DNS, klient lub aplikacja, nie jest już porównywany ten sam przepływ.

Interpretacja pierwszych obserwacji

• Aktywny Packet Capture nie pokazuje pakietu mimo pasującego filtra: Najpierw sprawdzić stan przechwytywania, filtr i bufor. Jeśli są prawidłowe, przyczyna prawdopodobnie znajduje się przed zaporą, na przykład po stronie klienta, VLAN-u, przełącznika, bramy, dostawcy lub Cloud Security Group.
• Log Viewer pokazuje inną Rule ID: Wcześniej oceniana jest reguła bardziej ogólna, utworzona automatycznie lub dopasowana według innych warunków.
• Firewall Rule ID jest prawidłowy, NAT Rule ID nie: Sprawdzić kolejność NAT oraz Original source, destination i service.
• Rule ID i NAT ID są prawidłowe, ale nie widać Forwarded: Sprawdzić działanie reguły, Reason, routing lub moduł bezpieczeństwa.
• Widać Forwarded, ale nie wraca odpowiedź: Sprawdzić trasę zwrotną, system docelowy, lokalną zaporę serwera lub blokadę zewnętrzną.
• Problem dotyczy tylko określonych użytkowników: Osobno sprawdzić uwierzytelnianie i User Matching rzeczywistego przepływu danych.

Pełny połączony przebieg opisuje Testowanie reguły firewalla za pomocą Log Viewer, Policy Tester i Packet Capture. Ten artykuł koncentruje się na wyjaśnieniu nieoczekiwanego dopasowania reguły.

Sprawdzanie kolejności i dopasowania reguł

Reguła firewalla działa tylko wtedy, gdy spełnione są wszystkie istotne kryteria i żadna wcześniejsza reguła nie przetwarza już tego samego ruchu.

Wygrywa pierwsza pasująca reguła

Sophos Firewall ocenia reguły od góry do dołu i kończy wyszukiwanie przy pierwszej pasującej regule. Dlatego decydująca jest pozycja na liście; Rule ID jest tylko stałym identyfikatorem i nie odpowiada pozycji.

Dodatkowo należy uwzględnić następujące kwestie:

• Ogólna reguła znajdująca się wyżej może całkowicie zasłonić bardziej szczegółową regułę poniżej.
• Rule Groups poprawiają przejrzystość, ale nie tworzą własnej logiki dopasowania. Oceniane są reguły zawarte w grupach.
• Reguły tworzone automatycznie, na przykład dla MTA, IPsec lub hotspotów, mogą zostać wstawione wyżej i sprawdzone jako pierwsze.
• Aktywny filtr w tabeli reguł może ukrywać istotne reguły. Przed analizą należy użyć Reset filter.
• Niezmienna reguła Default Drop ma Rule ID 0, znajduje się na końcu i nie ma zwykłego Usage Counter. Filtry tabeli jej nie dotyczą.

Pełne omówienie podstawowej logiki znajduje się w artykule Zrozumienie i prawidłowe konfigurowanie reguł Sophos Firewall.

Wspólne odczytywanie wszystkich kryteriów dopasowania

Reguła wyglądająca na prawidłową może nie zostać dopasowana z powodu jednego pola:

• Source zones: Klient pochodzi z innej strefy, na przykład VPN zamiast LAN, albo VLAN jest przypisany inaczej.
• Source networks and devices: Obiekt IP, grupa hostów lub podsieć nie zawiera rzeczywistego Source IP.
• Destination zones: Strefa docelowa jest nieprawidłowa, zwłaszcza przy DNAT, VPN lub sieciach routowanych.
• Destination networks: Rzeczywiście używany adres IP nie odpowiada obiektowi albo pomylono widok przed i po NAT.
• Services: Brakuje portu, zamieniono TCP z UDP albo aplikacja otwiera dodatkowe połączenia.
• Users or groups: Zapora nie może przypisać użytkownika do Source IP albo zaimportowana grupa jest nieprawidłowa.
• Schedule: Harmonogram nie jest aktywny w czasie testu.
• Exclusions: Przepływ jest wykluczony z reguły, a następnie sprawdzany względem kolejnych reguł.

W przypadku ruchu webowego częścią testu jest również protokół. Przeglądarki mogą używać QUIC przez UDP 443, podczas gdy oczekiwana reguła lub kontrola WWW obejmuje tylko klasyczny HTTPS przez TCP 443. Skutki opisuje Kontrolowanie QUIC na Sophos Firewall.

Kontrolowane zerowanie przesłanego wolumenu danych

Opcja Reset data transfer count może pomóc w teście, ale często jest błędnie interpretowana. Zeruje wolumen danych przesłanych przez regułę; nie jest to licznik sesji ani trafień.

1. Otworzyć Rules and policies > Firewall rules.
2. Znaleźć odpowiednią regułę i otworzyć menu z trzema kropkami.
3. Wybrać Reset data transfer count.
4. Ponownie wywołać zdefiniowany przepływ testowy.
5. Wspólnie ocenić wolumen danych, Rule ID i Packet Capture.

Jeśli wartość rośnie po kontrolowanym teście, wskazuje to na ruch przesłany przez tę regułę. Jeżeli pozostaje bez zmian, samo w sobie nie dowodzi to, że reguła nigdy nie została dopasowana. Wiarygodna ocena wymaga sprawdzenia rzeczywistej Rule ID w Log Viewer oraz ścieżki pakietu w Packet Capture. Dla reguły Default Drop o ID 0 ten licznik danych nie jest dostępny.

Prawidłowe odczytywanie Log Viewer, Policy Tester i Packet Capture

Narzędzia odpowiadają na różne pytania:

• Log Viewer: Która sesja, reguła, reguła NAT i akcja zostały zarejestrowane oraz którego użytkownika rozpoznano?
• Policy Tester: Jaka logika polityki obowiązywałaby dla wprowadzonych wartości?
• Packet Capture: Jakie pakiety rzeczywiście przychodzą, jak zapora je przetwarza i czy ponownie wychodzą?

Żadne z narzędzi nie zastępuje całkowicie pozostałych. Jeśli symulacja przeczy rzeczywistemu przepływowi pakietów, większą wagę mają dane z logów i pakietów pochodzące z powtarzalnego testu.

Log Viewer: rzeczywista Rule ID i NAT Rule ID

W regule firewalla musi być włączone Log firewall traffic. Dodatkowo pod System services > Log settings musi być aktywny odpowiedni typ logu dla widoku lokalnego, Sophos Central lub Syslog.

W teście przydatne są filtry następujących pól:

• Source IP i Destination IP
• port lub Service
• Rule ID i Rule name
• NAT rule ID
• Action i User
• zanotowany czas testu

Brak wpisu nie dowodzi jeszcze, że zapora niczego nie widziała. Sesje firewalla są logowane między innymi wtedy, gdy połączenie kończy się zdarzeniem Destroy. Przy nagłym przerwaniu połączenia oczekiwany wpis może więc nie wystąpić albo pojawić się później. Packet Capture daje wówczas bardziej bezpośredni wynik. Odpowiednie usługi i pliki logów opisuje Rozwiązywanie problemów z Sophos Firewall: usługi i logi.

Policy Tester: logika polityki bez rzeczywistego przepływu pakietów

W Diagnostics > Tools > Policy tester celowo ustawia się URL, User, czas, Source IP i Source zone. Protokół i port powinny wynikać z pełnego adresu URL, na przykład https://app.example.net:8443/. Bez protokołu narzędzie testuje HTTP; dla HTTPS domyślnie używany jest port 443, a inny port trzeba podać w adresie URL.

Policy Tester jest przydatny, ale ma wyraźne ograniczenia:

• Nie generuje rzeczywistego przepływu pakietów i nie sprawdza systemu docelowego ani trasy zwrotnej.
• Wyniki nie uwzględniają tras SD-WAN.
• Nie można dopasować reguł z adresami MAC w Source networks and devices.
• Problemy dostawcy, przełącznika, bramy i utraty pakietów pozostają niewidoczne.

⚠️ W SFOS 22.0 GA Build 411 błędy NC-177587 i NC-176083 mogły powodować nieprawidłowe wyniki Policy Test. Ruch wyglądał na zablokowany lub dopasowany do niewłaściwej reguły, mimo że w rzeczywistości przepływał prawidłowo. MR1 Build 490 zawiera udokumentowane poprawki. Przy sprzecznych wynikach przed zmianą reguł produkcyjnych należy najpierw sprawdzić wersję firmware, Log Viewer i Packet Capture.

Packet Capture: sprawdzanie rzeczywistej ścieżki pakietu

W Diagnostics > Packet capture najpierw ustawia się precyzyjny BPF Capture Filter, na przykład według Source IP, Destination IP i portu przepływu testowego. Następnie należy włączyć Trace On, wyczyścić listę i wywołać dokładnie zdefiniowany przepływ.

Pusty Packet Capture ma znaczenie dopiero po spełnieniu następujących warunków:

1. Trace On jest aktywne.
2. BPF Capture Filter odpowiada rzeczywistemu celowi i nie ukrywa przepływu.
3. Bufor nie nadpisał już istotnego ruchu testowego. Bez Wrap capture buffer once full rejestrowanie zatrzymuje się po zapełnieniu bufora 2048 KB i jest kontynuowane po użyciu Clear. Przy włączonej opcji Wrap rejestrowanie trwa dalej i nadpisuje najstarsze pakiety.

Dodatkowy Display Filter nie zmienia zarejestrowanych danych, ale może ukrywać istniejące wpisy. Dlatego Capture Filter i Display Filter należy kontrolować oddzielnie.

Wartości statusu oznaczają:

• Incoming: Pakiet został odebrany na interfejsie.
• Forwarded: Zapora przekazuje pakiet przez interfejs wyjściowy.
• Consumed: Pakiet jest przeznaczony dla samej zapory lub jest przez nią używany.
• Generated: Zapora sama wygenerowała pakiet.
• Violation: Naruszenie polityki prowadzi do odrzucenia; pole Reason dokładniej wyjaśnia przyczynę.

Rule ID, NAT ID, Reason oraz interfejs wejściowy i wyjściowy zawsze odczytuje się łącznie. Consumed i Generated są prawidłowymi wynikami i nie oznaczają automatycznie błędu.

⚠️ W SFOS 22.0 MR1 Build 490 błąd NC-178387 może pokazywać pakiety odrzucane przez regułę Default o ID 0 tylko jako Incoming. Oczekiwany wpis Violation Firewall oraz wpis w drppkt nie występują, chociaż zapora nadal odrzuca przepływ. W tej wersji pomagają Policy Tester albo świadomie umieszczona i logowana reguła Drop na końcu własnej listy reguł. W aktualnej informacji Known Issues nie wskazano wersji z poprawką.

Szczegółową procedurę przechwytywania opisuje Korzystanie z Packet Capture w Sophos Firewall WebAdmin. Odrzucone pakiety i kontrolowaną regułę końcową omawia Analizowanie pakietów odrzuconych przez Sophos Firewall.

Sprawdzanie NAT, DNAT, routingu i trasy zwrotnej

NAT nie zezwala na ruch. Tłumaczy adresy lub porty dla ruchu dozwolonego przez regułę firewalla. Dlatego Firewall Rule ID i NAT Rule ID muszą być prawidłowe niezależnie od siebie.

Wspólna ocena Firewall Rule ID i NAT Rule ID

• Firewall Rule ID jest prawidłowy, NAT Rule ID błędny: Sprawdzić kolejność NAT, pola Original i bardziej ogólne reguły NAT.
• NAT Rule ID jest prawidłowy, Firewall Rule ID błędny: Porównać kolejność reguł firewalla, strefy, Source, Destination, Service i Schedule.
• Oba ID są prawidłowe, ale połączenie nie działa: Sprawdzić routing, trasę zwrotną, serwer docelowy, moduł bezpieczeństwa lub aplikację.
• NAT Rule ID nie jest widoczna, choć oczekiwany jest NAT: Sprawdzić kierunek, Inbound/Outbound Interface oraz kryteria Original reguły NAT.

W Rules and policies > NAT rules także obowiązuje pierwsza pasująca reguła. Ogólna reguła SNAT lub MASQ może zatem zasłonić bardziej szczegółową regułę poniżej. Linked NAT Rules są ponadto uwzględniane tylko dla ruchu, który pasuje do powiązanej z nimi reguły firewalla; wcześniejsza samodzielna reguła NAT może mimo to zadziałać jako pierwsza.

Pełną logikę identyfikatorów wyjaśnia Zrozumienie NAT na Sophos Firewall.

Zrozumienie DNAT z perspektywy przed i po NAT

Dla przychodzącego ruchu DNAT obowiązuje ważna zasada:

Reguła firewalla używa strefy docelowej po NAT, ale jako Destination Network adresu pierwotnie wybranego przed NAT.

Przykład przekierowania portu:

• Klient zewnętrzny łączy się z 198.51.100.10 na porcie TCP 8888.
• Reguła NAT tłumaczy połączenie na serwer 10.10.50.20 w strefie DMZ i port TCP 4444.
• W regule NAT TCP 8888 jest Original service, a TCP 4444 jest Translated service (PAT).
• Reguła firewalla używa WAN jako Source zone, DMZ jako Destination zone i 198.51.100.10 jako Destination network.
• W oficjalnym przykładzie Sophos dotyczącym PAT powiązana reguła firewalla zawiera zarówno oryginalną, jak i przetłumaczoną usługę.

Test zewnętrzny nadal wykonuje się na porcie 8888; serwer wewnętrzny odbiera połączenie na porcie 4444. Jeśli analizowany jest tylko jeden z portów, reguła może szybko wyglądać na poprawną, chociaż dopasowanie usługi i translacja nie są zgodne. Pełną publikację opisuje Publikowanie serwera przez DNAT na Sophos Firewall.

Nawiązywanie nowego połączenia po zmianach NAT

Sophos Firewall ocenia regułę NAT tylko dla pierwszego pakietu połączenia. Istniejące sesje nadal używają poprzedniej translacji, nawet jeśli reguła NAT została już zmieniona.

Po korekcie NAT należy zatem nawiązać nowe połączenie: zakończyć trwający test, zamknąć istniejącą sesję przeglądarki lub aplikacji i ponownie uruchomić przepływ. Odświeżenie w tej samej sesji TCP nie potwierdza wiarygodnie nowej konfiguracji NAT.

Analizowanie routingu dopiero po potwierdzeniu dopasowania

Jeśli Rule ID i NAT Rule ID są prawidłowe, a Packet Capture pokazuje Forwarded, dopasowanie reguły jest zasadniczo potwierdzone. Następnie sprawdza się:

• odpowiednią trasę statyczną lub Default Route
• SD-WAN route i aktywną bramę
• rzeczywisty interfejs wyjściowy
• trasę w systemie docelowym i sieciach zdalnych
• symetryczną trasę zwrotną przez VPN, MPLS lub WAN
• lokalną zaporę serwera docelowego

Policy Tester nie uwzględnia SD-WAN. W rzeczywistej decyzji liczą się Gateway ID, interfejs i ścieżka pakietu. Kolejność tras statycznych, SD-WAN i VPN wyjaśnia Dostosowywanie priorytetu routingu na Sophos Firewall.

Przypadki szczególne po pierwszym ustaleniu

Dopiero po sklasyfikowaniu podstawowego przepływu warto przejść do usług lokalnych, użytkowników, rozwiązywania nazw lub modułów bezpieczeństwa.

Ruch do samej zapory: Device Access zamiast reguły firewalla

WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS i SNMP kończą się na zaporze. Status Packet Capture może zatem wynosić Consumed. Dostępem steruje się w Administration > Device access oraz za pomocą Local Service ACL Exception Rules, a nie zwykłą regułą ruchu tranzytowego.

Należy sprawdzić strefę, zaufaną sieć źródłową, udostępnioną usługę, uprawnienia użytkownika i MFA. Zależności istotne dla bezpieczeństwa opisuje Zabezpieczanie Sophos Firewall Device Access i Local Service ACL; różne interfejsy webowe omówiono w Przegląd portali Sophos Firewall.

Rozdzielenie logowania użytkownika i User Matching

Udane logowanie w VPN Portal, User Portal, Captive Portal lub przez Entra ID SSO potwierdza początkowo tylko uwierzytelnianie. Aby planowana reguła użytkownika zadziałała, zapora musi również przypisać użytkownika do rzeczywistego przepływu danych i jego Source IP.

Typowe ustalenia:

• Pole User w Log Viewer jest puste: Sprawdzić STAS, AD SSO, Captive Portal, Entra ID SSO lub Clientless User. W przypadku stałego adresu IP urządzenia artykuł Konfiguracja i testowanie Clientless Users pokazuje przypisanie wraz ze sprawdzeniem w Live Users i testem negatywnym.
• Użytkownik jest widoczny, ale działa inna reguła: Porównać pozycję reguły, warunek grupy lub bardziej ogólną regułę znajdującą się wyżej.
• Problem dotyczy tylko użytkowników VPN: Sprawdzić strefę VPN, pulę VPN, Source network i dopasowanie grupy.
• Problem dotyczy tylko pojedynczych użytkowników: Porównać UPN, adres e-mail, zaimportowaną grupę katalogową i grupę Sophos Firewall.

W lokalnych środowiskach AD pomagają Konfigurowanie STAS na Sophos Firewall i Dodawanie Active Directory do Sophos Firewall. W zależności od ścieżki logowania Entra odpowiednie są Entra ID SSO dla Sophos Connect i VPN Portal lub Entra ID SSO dla Captive Portal. Przy bardzo dużej liczbie rozpoznanych użytkowników lub Clientless Users istotny może być również limit Sophos Firewall User ID.

Sprawdzanie DNS, FQDN, CDN i IPv6

Przy dopasowaniu reguły liczy się rzeczywiście używany docelowy adres IP, a nie tylko wpisana nazwa hosta. Cache DNS, Split DNS, usługi CDN, inny resolver, dodatkowe cele API lub IPv6 mogą skierować przepływ pod inny adres.

Zwykłe FQDN Hosts są rozwiązywane przez samą zaporę, która aktualizuje przypisanie zgodnie z DNS TTL. Wildcard FQDNs działają inaczej: zapora uczy się adresów IP pasujących subdomen na podstawie obserwowanych odpowiedzi DNS. Jeśli klient używa zewnętrznego resolvera, jego ruch UDP DNS na porcie 53 musi przechodzić przez zaporę. Jeśli dana odpowiedź nie jest dla niej widoczna, adres IP subdomeny może nie znaleźć się w obiekcie Wildcard, a reguła nie zostanie dopasowana mimo pozornie prawidłowej nazwy.

FQDN Hosts nie obsługują ponadto rozwiązywania IPv6. Przed rozszerzeniem obiektu należy więc porównać odpowiedź DNS, docelowy adres IP i wersję IP z Log Viewer lub Packet Capture. Szczegóły dotyczące TTL, Wildcards i mechanizmu uczenia opisuje FQDN Hosts i Wildcard FQDNs na Sophos Firewall. W rozwiązywaniu wewnętrznym pomagają DNS Request Routes; aktywne środowisko IPv6 wymaga własnych pasujących reguł i świadomej koncepcji IPv6.

Rozdzielanie modułów bezpieczeństwa i Traffic Shaping

Jeśli Firewall Rule ID, NAT Rule ID i routing są prawidłowe, na aplikację może wpływać moduł przypisany do reguły:

• Web Policy i Application Control
• SSL/TLS inspection rule i Decryption Profile
• IPS Policy i Malware Scan
• Zero-Day Protection
• Security Heartbeat

Zawsze zawęża się tylko jeden moduł dla konkretnego przepływu i krótkiego okresu testowego. Wyjątek pozostaje ograniczony do Source, celu i Service; następnie przywraca się pierwotną ochronę albo dokumentuje wymagany wyjątek. W problemach z HTTPS pomaga kontrolowane wdrożenie TLS Inspection.

Traffic Shaping jest natomiast funkcją QoS. Gwarantuje, nadaje priorytet lub ogranicza przepustowość i może przez to powodować niski transfer, utratę pakietów przy przeciążeniu lub przekroczenia czasu. Nie jest to to samo co decyzja o dostępie Drop lub Reject. Rzeczywistą blokadę analizuje się za pomocą statusu Packet Capture, Reason i odpowiedzialnego modułu bezpieczeństwa. Przy dużych transferach lub połączeniach VPN należy również uwzględnić MTU i MSS.

Kontrolowane testowanie i dokumentowanie zmian

Przy problemach z regułami w każdym teście należy zmieniać tylko jedną zmienną:

1. Zanotować stan początkowy wraz z Source, Destination, Service, User, czasem, Rule ID i NAT ID.
2. Zmienić dokładnie jedną pozycję reguły, obiekt, Service lub moduł.
3. W przypadku NAT nawiązać nowe połączenie, w innych przypadkach ponownie wywołać ten sam przepływ testowy.
4. Porównać Log Viewer i Packet Capture z tymi samymi filtrami.
5. Udokumentować powodzenie lub niepowodzenie i dopiero potem sprawdzić następną zmianę.

Tymczasowe reguły Allow, Drop lub wyjątki otrzymują zrozumiałą nazwę, ownera i datę wygaśnięcia. W przeciwnym razie krótkotrwała pomoc diagnostyczna szybko pozostaje na stałe w zestawie reguł.

Jeśli połączenie działało jeszcze wczoraj, należy również sprawdzić ostatnie zmiany konfiguracji. Audit Trail Logs pokazują, kto zmienił reguły lub obiekty. Config Studio pomaga porównywać większe konfiguracje. Jeśli zmiana pochodziła z Sophos Central, dodatkowo sprawdza się Central Firewall Task Queue.

Lista kontrolna rozwiązywania problemów z regułami

• Zdefiniowano konkretny przepływ testowy z Source, Destination, Service, User i czasem.
• Sprawdzono, czy chodzi o ruch tranzytowy, czy lokalną usługę zapory.
• Skontrolowano pozycję reguły, reguły automatyczne i ukryte filtry tabeli.
• Porównano wszystkie pola dopasowania z rzeczywistym przepływem.
• Wolumen danych użyto tylko jako wskazówki, a nie jako licznika trafień.
• Log Viewer pokazuje rzeczywistą Firewall Rule ID i w razie potrzeby NAT Rule ID.
• Wynik Policy Tester porównano z wersją firmware i rzeczywistymi danymi pakietowymi.
• Packet Capture działa z odpowiednim Capture Filter i wolnym buforem.
• Prawidłowo zinterpretowano Incoming, Forwarded, Consumed, Generated, Violation, Reason i interfejsy.
• Przy DNAT sprawdzono strefę docelową po NAT, Destination Network przed NAT i obie usługi PAT.
• Po zmianach NAT nawiązano nowe połączenie.
• Skontrolowano odpowiedź DNS, docelowy adres IP, mechanizm uczenia FQDN i wersję IP.
• Osobno sprawdzono User Login i User Matching przepływu danych.
• Routing, SD-WAN, bramę i trasę zwrotną zbadano dopiero po potwierdzeniu dopasowania reguły.
• Moduły bezpieczeństwa sprawdzono osobno, a Traffic Shaping jako QoS.
• Każdą zmianę udokumentowano; reguły testowe mają ownera i datę wygaśnięcia.

FAQ