Packet Capture Sophos Firewall w WebAdmin
Packet Capture to jedno z najważniejszych narzędzi troubleshooting w Sophos Firewall WebAdmin. Pokazuje, czy pakiety docierają na interfejs, czy są przekazywane dalej, która reguła lub NAT ID bierze udział w przetwarzaniu i czy pakiet został odrzucony.
Log Viewer pokazuje decyzję firewalla. Packet Capture pokazuje przepływ pakietów. Razem często są najszybszą drogą do znalezienia przyczyny.
Ważne: ten artykuł opisuje wersję WebAdmin narzędzia Packet Capture. Jest idealna do pierwszej kontroli, ponieważ bezpośrednio w przeglądarce widać, czy pakiety docierają, są przekazywane albo odrzucane. Do dłuższych przechwyceń, bardzo precyzyjnych filtrów, eksportu PCAP lub zgłoszeń supportowych często lepszy jest tcpdump przez SSH.
Kiedy Packet Capture ma sens
Packet Capture pomaga szczególnie przy pytaniach takich jak:
- Czy ruch w ogóle dociera do firewalla?
- Czy ruch wychodzi oczekiwanym interfejsem?
- Czy pasuje Firewall Rule?
- Czy pasuje NAT Rule?
- Czy pakiet jest odrzucany przez policy, IPS albo routing?
- Czy odpowiedź wraca z systemu docelowego?
- Czy używany jest inny port lub protokół niż oczekiwano?
Jeżeli w Log Viewer nic nie widać, Packet Capture jest często następnym krokiem. Widać wtedy, czy problem leży przed firewallem, czy firewall przetwarza ruch.
Ścieżka menu
Narzędzie znajduje się tutaj:
Diagnostics > Packet capture
Packet Capture otwiera się bezpośrednio w WebAdmin. W zależności od wersji SFOS i widoku przeglądarki wygląda jak osobne okno diagnostyczne w WebAdmin.
Log Viewer czy Packet Capture?
Log Viewer i Packet Capture odpowiadają na różne pytania.
| Narzędzie | Pokazuje głównie |
|---|---|
| Log Viewer | Która Firewall Rule, Web Policy, Application Control, IPS albo SSL/TLS inspection podjęła decyzję |
| Packet Capture | Czy pojedyncze pakiety docierają, są przekazywane, konsumowane, generowane albo odrzucane |
Dobrym przykładem jest ping. W Log Viewer często widać tylko jeden wpis albo podsumowaną decyzję dla połączenia. W Packet Capture widać natomiast pojedyncze pakiety ICMP: Echo Request do celu i Echo Reply z powrotem. Windows domyślnie wysyła cztery ICMP Echo Requests poleceniem ping. W Packet Capture należy więc oczekiwać kilku pakietów w obie strony. Jeśli widać tylko requests, ale nie wracają replies, to inny problem niż sytuacja, w której żaden request nie dociera do firewalla.
W praktyce oznacza to:
- Log Viewer odpowiada: Która reguła lub moduł podjął decyzję?
- Packet Capture odpowiada: Czy pakiety naprawdę dotarły i jaką drogę wybierają?
- Przy problemach z routingiem, NAT, VLAN, gateway albo drogą powrotną Packet Capture jest często bardziej wymowny.
- Przy decyzjach Web filter, Application Control, IPS albo SSL/TLS inspection dodatkowo potrzebny jest Log Viewer.
Dobrze zawęzić zakres przed startem
Packet Capture nie powinien być uruchamiany bez filtra. W sieciach produkcyjnych powstaje wtedy bardzo dużo danych, a wynik staje się nieczytelny.
Wcześniej warto zanotować:
- Source IP
- Destination IP albo FQDN
- Protokół
- Source port, jeśli ma znaczenie
- Destination port
- Interfejs albo strefę
- Godzinę testu
- Dotkniętą aplikację
Dla testu web zakres może wyglądać tak:
| Pole | Przykład |
|---|---|
| Source IP | 172.16.10.25 |
| Destination | 93.184.216.34 |
| Protocol | TCP |
| Destination Port | 443 |
| Oczekiwany kierunek | LAN do WAN |
Skonfigurować capture filter
Przez Configure ustawia się możliwie wąski filtr.
Typowe filtry:
- Source IP klienta
- Destination IP serwera
- Destination port
- Protokół TCP, UDP albo ICMP
- Interfejs
Jeśli serwer docelowy nie jest znany, można najpierw filtrować tylko po Source IP. Jeśli pakietów jest zbyt dużo, filtr należy zawęzić.
Sophos Firewall używa składni Berkeley Packet Filter, czyli BPF. Capture filter decyduje, które pakiety w ogóle trafiają do capture buffer. Dlatego powinien być ustawiony dokładnie przed testem.
Typowe przykłady BPF:
| Cel | Przykład BPF |
|---|---|
| konkretny host | host 10.10.10.1 |
| konkretne Source IP | src host 10.10.10.1 |
| konkretne Destination IP | dst host 10.10.10.1 |
| konkretna sieć | net 10.10.10.0 |
| konkretny port | port 443 |
| konkretny port docelowy | dst port 443 |
| konkretny host i port | host 10.10.10.1 and port 443 |
| ICMP/ping | proto ICMP |
| TCP | proto TCP |
| UDP | proto UDP |
Dla bardzo precyzyjnego testu web filtr może wyglądać tak:
host 172.16.10.25 and host 93.184.216.34 and port 443
Dla testu ping często wystarczy:
host 172.16.10.25 and proto ICMP
W WebAdmin po zapisaniu aktywny BPF string jest widoczny nad listą pakietów. Pierwszy zrzut ekranu pokazuje konfigurację filtra, drugi listę wyników z aktywnym filtrem.


⚠️ Dane PCAP mogą zawierać adresy IP, nazwy hostów, szczegóły protokołów oraz, zależnie od protokołu, dane użytkowe. Captures powinny być udostępniane tylko osobom lub partnerom, którzy mogą je zobaczyć.
Uruchomić capture i odtworzyć problem
- Ustawić filtr.
- Włączyć Packet Capture przełącznikiem.
- Celowo odtworzyć problem.
- Ponownie zatrzymać capture.
- Przeanalizować wyniki.
- Wyczyścić capture przed nowym testem.
Sophos Firewall pokazuje status i buffer:
| Wskazanie | Znaczenie |
|---|---|
Trace On | Packet Capture działa |
Trace Off | Packet Capture jest wyłączony |
Buffer size | Rozmiar capture buffer, w dokumentacji Sophos 2048 KB |
Buffer used | aktualnie użyty buffer |
Gdy buffer się zapełni, przechwytywanie zatrzymuje się automatycznie. Następnie trzeba użyć Clear, zanim kolejny capture będzie miał sens. Dlatego wąski filtr jest ważny.
W ustawieniach filtra można dodatkowo określić, ile bajtów na pakiet ma być przechwytywanych. Do wielu pierwszych analiz wystarczają informacje nagłówkowe. Jeśli potrzeba więcej danych payload, trzeba przechwycić więcej bajtów, pamiętając o ochronie danych i rozmiarze bufora.
Zrozumieć ważne kolumny
Packet Capture pokazuje wiele pól. W praktyce szczególnie ważne są:
| Pole | Znaczenie |
|---|---|
| Time | Czas pakietu |
| In interface | Interfejs, na którym pakiet wszedł |
| Out interface | Interfejs, przez który pakiet wychodzi |
| Source IP | Adres źródłowy |
| Destination IP | Adres docelowy |
| Packet type | Protokół albo typ pakietu |
| Ports [src, dst] | Port źródłowy i docelowy |
| NAT ID | Pasująca reguła NAT |
| Rule ID | Pasująca Firewall Rule |
| Status | Status pakietu |
| Reason | Powód drop albo violation |
| Connection status | Stan połączenia |
| Gateway ID | Użyta gateway |
| Username | Rozpoznany użytkownik |
| IPS policy ID | Zastosowana IPS Policy |
| Application filter ID | Zastosowana Application Control Policy |
Te pola są cenne, ponieważ zamykają lukę między „reguła wygląda dobrze” a „ruch naprawdę działa w ten sposób”.
Przez Show additional properties albo widok szczegółowy, zależnie od wersji, widać kolejne informacje, takie jak Connection ID, Web filter ID, Application ID, Web category ID, Gateway ID, Username lub inne policy IDs. Te szczegóły pomagają, gdy pakiet jest przetwarzany nie tylko przez Firewall Rule, ale również przez Web, Application Control, IPS lub inne moduły.
Poprawnie interpretować Status
| Status | Znaczenie |
|---|---|
| Incoming | Pakiet został odebrany na interfejsie |
| Forwarded | Pakiet został przekazany dalej |
| Consumed | Pakiet jest przeznaczony dla samego firewalla |
| Generated | Pakiet został wygenerowany przez firewall |
| Violation | Pakiet został odrzucony z powodu naruszenia policy |
Jeśli widać tylko Incoming, a nie ma Forwarded, pakiet prawdopodobnie zatrzymuje się na firewallu. Wtedy należy sprawdzić Firewall Rule, NAT, routing i security features.
Jeśli widać Forwarded, ale nie wraca odpowiedź, problem często leży po stronie systemu docelowego, drogi powrotnej, NAT albo zdalnego peer.
Przy udanym ping zwykle widać pakiety w obie strony. Jeśli Windows wysyła cztery pingi, widać kilka ICMP Echo Requests od klienta do celu oraz kilka Echo Replies z powrotem. Jeśli brakuje Replies, należy sprawdzić trasę powrotną, system docelowy, lokalny firewall systemu docelowego, NAT albo zdalny peer. Jeśli brakuje już Requests, należy sprawdzić klienta, gateway, VLAN, port switcha albo czy ruch w ogóle dociera do Sophos Firewall.
Użyć Display filter
Capture filter ogranicza, które pakiety są rejestrowane. Display filter filtruje natomiast już zarejestrowany widok. To praktyczne, gdy capture celowo uruchomiono nieco szerzej, a później trzeba wyświetlić tylko określone pakiety.
W Display filter można filtrować między innymi po:
- Interface name
- Ethernet type, na przykład IPv4, IPv6 albo ARP
- Packet type
- Source IP i Source port
- Destination IP i Destination port
- Reason
- Status
- Rule ID
- User
- Connection ID
Przy troubleshooting szczególnie pomocne są Status, Reason, Rule ID, Source IP, Destination IP i Destination port. Jeśli w capture jest wiele pakietów, pozwalają szybko zawęzić widok do istotnej części bez natychmiastowego powtarzania testu.
Czytać NAT w Packet Capture
Przy NAT trzeba pamiętać, że pakiet przed i po NAT wygląda inaczej. Packet Capture może pokazać NAT ID, Rule ID i zmienione adresy.
Przy problemach NAT należy sprawdzić:
- Czy pakiet jest widoczny z oryginalnym adresem?
- Czy pakiet jest widoczny po translacji?
- Czy wyświetla się oczekiwany NAT ID?
- Czy pakiet wychodzi przez oczekiwany Out interface?
- Czy wraca odpowiedź?
Dla DNAT dochodzi dodatkowo: Firewall Rule używa strefy docelowej po NAT, ale Destination IP przed NAT. Na początku wygląda to nietypowo.
Więcej: NAT w Sophos Firewall: SNAT, DNAT, MASQ, PAT.
Łączyć Packet Capture i Log Viewer
Najlepszy przebieg to:
- Otworzyć Log Viewer.
- Uruchomić Packet Capture z wąskim filtrem.
- Odtworzyć test.
- W Packet Capture sprawdzić, czy pakiety docierają i wychodzą.
- W Log Viewer sprawdzić, która reguła lub moduł podjął decyzję.
- W razie potrzeby przejść do odpowiedniego pliku logu.
Log Viewer pokazuje na przykład zdarzenia Firewall, Web, SSL/TLS inspection, IPS albo Application Control. Packet Capture pokazuje natomiast przepływ pakietów na poziomie interfejsów.
Szczególnie przy ping albo prostych połączeniach TCP ta kombinacja jest ważna. Log Viewer może pokazać tylko, że połączenie zostało dozwolone albo zablokowane. Packet Capture dodatkowo pokazuje, czy pakiety odpowiedzi wracają, czy działa NAT, czy używany jest właściwy Out interface i czy ścieżka powrotna jest poprawna.
Typowe przykłady
Klient nie ma dostępu do Internetu: ustawić capture na Source IP i TCP 443. Jeśli żaden pakiet nie dociera, sprawdzić klienta, VLAN, gateway albo switch. Jeśli pakiet dociera, ale nie wychodzi, sprawdzić Firewall Rule, NAT albo routing.
DNAT nie działa: ustawić capture na publiczny Destination IP i zewnętrzny port. Jeśli żaden pakiet nie dociera, sprawdzić router dostawcy, port forwarding, cloud Security Group albo WAN. Jeśli pakiet dociera, ale nie idzie do wewnętrznego serwera, sprawdzić regułę DNAT i Firewall Rule.
Ruch VPN nie działa: ustawić capture na tunnel interface, XFRM interface albo odpowiednie sieci źródłowe/docelowe. Dodatkowo sprawdzić strongswan.log, charon.log albo xfrmi.log.
Web filter blokuje nieoczekiwanie: W Packet Capture zwykle widać tylko przepływ pakietów. Samą decyzję lepiej sprawdzić w Log Viewer pod Web, Application Control albo SSL/TLS inspection.
Kiedy tcpdump jest lepszy
WebAdmin Packet Capture jest idealny do szybkich analiz. Do dłuższych capture, bardzo precyzyjnych filtrów albo przypadków supportowych często lepszy jest tcpdump z CLI.
Więcej: Zbierać logi Sophos Firewall za pomocą TCPDump do analizy.