Rozwiązywanie problemów z CLI Sophos Firewall: ważne polecenia

Podczas rozwiązywania problemów z Sophos Firewall Log Viewer często wystarcza do wstępnego zawężenia przyczyny. Gdy usługa nie uruchamia się prawidłowo, połączenia VPN są niestabilne, pojedyncze pakiety nie docierają lub dział wsparcia potrzebuje szczegółowych danych, istotne staje się użycie CLI.

Ten przegląd przedstawia najważniejsze polecenia do codziennej pracy: gdzie je wykonywać, co pokazują i kiedy lepiej skorzystać z wyspecjalizowanego artykułu. Przed uzyskaniem bezpiecznego dostępu przez SSH warto najpierw sprawdzić artykuł Łączenie z Sophos Firewall przez SSH. Klucz publiczny, weryfikacja klucza hosta i precyzyjnie ograniczony dostęp w Device Access są ważniejsze niż możliwość szybkiego logowania z dowolnego miejsca.

⚠️ Ważne: Polecenia CLI i Advanced Shell należy wykonywać wyłącznie z zaufanych sieci administracyjnych i w jasno określonym celu. Szczególnie debugowanie, tcpdump, operacje na plikach i polecenia dotyczące usług mogą wpływać na wolne miejsce, wydajność lub aktywne połączenia.

Najpierw WebAdmin, potem CLI

CLI nie zawsze jest najszybszym punktem wyjścia. W przypadku dopasowania reguł, NAT lub pojedynczych połączeń Log Viewer, Policy Test i Packet Capture w WebAdmin często szybciej dostarczają jednoznacznych informacji.

Dobre punkty wyjścia:

• Która reguła firewalla jest stosowana? Najpierw skorzystać z Log Viewer, Policy Test i Packet Capture. CLI jest potrzebne dopiero wtedy, gdy Log Viewer pokazuje zbyt mało szczegółów lub wymagane są logi na żywo.
• Czy pakiety docierają do firewalla? Najpierw użyć Packet Capture w WebAdmin. CLI jest przydatne, gdy potrzebne jest precyzyjne przechwytywanie albo plik PCAP dla działu wsparcia.
• Czy występuje problem z usługą? Najpierw sprawdzić dashboard, Log Viewer i logi usług. CLI staje się istotne, gdy trzeba bezpośrednio sprawdzić stan usługi, debugowanie lub pliki logów.
• Czy coś zostało zmienione? Najpierw sprawdzić Audit Trail Logs. Następnie CLI pomaga porównać różnicę konfiguracji z logami lub kopiami zapasowymi.

Celem nie jest jak najszybsze przejście do Advanced Shell. Lepszy jest powtarzalny proces: najpierw sprawdzenie widocznych zdarzeń, a następnie otwarcie odpowiedniego pliku logu lub przechwytywania.

Użyteczne dokumentowanie wyników z CLI

Wyniki z CLI są przydatne tylko wtedy, gdy później nadal wiadomo, którego testu dotyczą. Pojedyncze skopiowane komunikaty o błędach bez przedziału czasu, adresów IP lub funkcji, której dotyczy problem, często prowadzą do dodatkowych pytań i powtarzania analizy.

Zwykle wystarczy krótka notatka dla każdego testu:

• Przedział czasu: początek, koniec i strefa czasowa testu.
• Przepływ testowy: Source IP, Destination IP lub FQDN, port, użytkownik lub peer VPN.
• Narzędzie: Device Console, Advanced Shell, Log Viewer lub Packet Capture.
• Polecenie lub filtr: wykonane polecenie, używana fraza wyszukiwania grep lub filtr przechwytywania.
• Wynik: trafienie, komunikat o błędzie, brak wpisu w logu, pakiet widoczny lub niewidoczny.
• Następny wniosek: na przykład problem z regułą, DNS, trasą zwrotną, usługą lub zgłoszenie do wsparcia.

Przed przekazaniem danych do Sophos Support, Avanet lub zewnętrznego partnera należy sprawdzić, czy wyniki zawierają informacje wrażliwe: publiczne adresy IP, wewnętrzne nazwy hostów, nazwy użytkowników, parametry VPN, numery seryjne, tokeny, adresy e-mail lub nazwy klientów. Analiza techniczna nie wymaga nieograniczonego rozpowszechniania danych; istotny jest najmniejszy fragment potwierdzający wynik.

Przed pierwszym poleceniem

Rozwiązywanie problemów za pomocą CLI jest znacznie bardziej niezawodne, gdy kontekst zostanie ustalony przed pierwszym poleceniem. W przeciwnym razie szybko powstają fragmenty logów bez odniesienia do czasu, zbyt szerokie przechwytywania lub logi debugowania, których później nie można jednoznacznie przypisać.

Przed wykonaniem testów CLI w środowisku produkcyjnym należy zapisać:

• Czas wystąpienia problemu: pozwala przeszukiwać logi dokładnie w przedziale testowym.
• Source IP, Destination IP i port: grep, tcpdump i Packet Capture pozostają precyzyjne i czytelne.
• Użytkownik lub peer, którego dotyczy problem: ułatwia przypisanie uwierzytelniania, VPN i User Matching.
• Oczekiwany moduł: najpierw przeszukiwany jest właściwy plik logu, a nie wszystkie logi.
• Planowane działanie: debugowanie, sprawdzanie usługi lub przechwytywanie nie pozostaje przypadkowo aktywne.
• Kryterium wycofania lub przerwania: test zostaje zakończony w przypadku dużego obciążenia, zapełnienia pamięci lub efektów ubocznych.
• Aktualna kopia zapasowa przy planowanych zmianach: ułatwia zabezpieczenie restartów usług lub zmian konfiguracji.

Pierwszy krok powinien mieć w miarę możliwości charakter tylko do odczytu: sprawdzenie Log Viewer, wyświetlenie właściwego pliku logu, odczytanie service -S lub uruchomienie precyzyjnego przechwytywania. Restarty, tryb debugowania i szerokie przechwytywania należy wykonywać dopiero później, w świadomie zaplanowanym oknie testowym.

W klastrach HA trzeba dodatkowo ustalić, które urządzenie jest obecnie aktywne. Logi, debugowanie i przechwytywania należy sprawdzać na tym węźle, przez który rzeczywiście przechodzi analizowany ruch.

Pełny restart wykonywać wyłącznie jako zaplanowaną czynność

Pełny restart nie jest poleceniem diagnostycznym. Najpierw należy zachować istotne logi, czas systemowy, uptime, role HA i bieżący stan awarii. Jeśli problem dotyczy tylko WebAdmin lub jednej usługi, trzeba sprawdzić, czy wystarczy ukierunkowany restart WebAdmin lub restart usługi.

SFOS 22 dokumentuje w Device Console następującą składnię:

system restart [all]

Nawiasy kwadratowe nie są częścią polecenia, lecz oznaczają opcjonalny argument all. Najpierw należy sprawdzić formę oferowaną przez zainstalowany build za pomocą system restart ?. Polecenie restartuje firewall i przerywa sesje, tunele VPN oraz dostęp administracyjny. Po wykonaniu nie ma rollbacku w CLI, dlatego przed potwierdzeniem trzeba zapewnić okno serwisowe, dostęp konsolowy i przetestowaną drogę powrotu do zarządzania.

Według Sophos polecenie system restart w klastrze HA wywołuje failover. Nie gwarantuje to ciągłości połączeń. Peer, synchronizacja, role i łącze HA muszą być wcześniej stabilne. Po restarcie sprawdza się oba węzły, role, synchronizację, uptime, WAN, routing, DNS, VPN, opublikowane usługi i rzeczywisty przepływ aplikacji. Udany start nie dowodzi usunięcia pierwotnej przyczyny.

Wyłączać tylko z przygotowaną drogą ponownego uruchomienia

Do kontrolowanego wyłączenia służy dokładnie to polecenie Device Console:

system shutdown

Sophos nie dokumentuje dla niego żadnych opcji. Do składni nie należy więc dodawać all, nazwy węzła ani domniemanego przełącznika HA. Przed potwierdzeniem trzeba zachować logi i konfigurację, poinformować zależne zespoły oraz ustalić sposób ponownego włączenia urządzenia przez dostęp fizyczny, zdalne zarządzanie lub platformę wirtualizacyjną. Strona shutdown nie gwarantuje żadnego zachowania HA; węzeł klastra należy zatem wyłączać wyłącznie zgodnie z przewidzianą procedurą konserwacji HA, a następnie jednoznacznie sprawdzić peer.

Device Console czy Advanced Shell?

Sophos Firewall udostępnia dwa różne obszary konsoli. Wiele błędów wynika z wprowadzenia polecenia w niewłaściwym obszarze.

Oba obszary mają różne zadania:

• Device Console: CLI Sophos do poleceń sieciowych, systemowych i diagnostycznych. Typowe polecenia to ping, dnslookup, traceroute, tcpdump, drop-packet-capture i show.
• Advanced Shell: powłoka podobna do systemu Linux z pełnym dostępem do komponentów systemowych. Ten artykuł ogranicza jej użycie do poleceń diagnostycznych udokumentowanych przez Sophos: cd /log, tail, grep, less i service -S.

Po zalogowaniu przez SSH firewall najpierw wyświetla menu konsoli. Dla Device Console zwykle wybiera się 4. Device Console. Dla Advanced Shell używa się 5. Device Management > 3. Advanced Shell.

Device Console grupuje pod advanced-firewall globalne parametry inspekcji pakietów, TCP, UDP, dostępu WAN i ścieżek specjalnych. Ich działanie i bezpieczną procedurę zmiany opisuje Bezpieczne sprawdzanie Advanced Firewall Settings.

Test DNS dobrze pokazuje, dlaczego obszar konsoli ma znaczenie. W Device Console oficjalnie udokumentowano polecenie:

dnslookup host example.com

example.com jest bezpieczną wartością dokumentacyjną; w rzeczywistym teście należy ją zastąpić odpowiednią nazwą FQDN. Odpowiedź potwierdza wyłącznie rozwiązywanie nazw z perspektywy firewalla. Przy błędzie klienta trzeba też sprawdzić jego serwer DNS, odpowiedź i ścieżkę sieciową.

Oficjalna pomoc CLI Sophos obsługuje Tab i ? do sprawdzania składni. Jest to przydatne w Device Console, ponieważ nie każde polecenie ma taką samą strukturę.

Szczególnie w Device Console nie należy wykonywać niekompletnych ani odgadywanych poleceń. Sophos ostrzega, że niekompletne polecenie może zablokować access_server. Dlatego najpierw należy wyświetlić składnię za pomocą Tab lub ?, a następnie świadomie wykonać pełne polecenie.

Bezpośrednie zmiany konfiguracji wprowadzone w Advanced Shell nie są trwałe i nie są uwzględniane w kopiach zapasowych. Dlatego w tej instrukcji Advanced Shell służy wyłącznie do poleceń diagnostycznych.

Specjalnym poleceniem awaryjnym jest system appliance_access enable. Zastępuje ono konfigurację Device Access i zezwala na dostęp do wszystkich lokalnych usług firewalla, w tym starszych usług, takich jak Telnet. Ważne: dopóki ten tryb jest aktywny, firewall nie przekazuje ruchu wychodzącego do internetu. Nie jest to standardowy krok podczas rozwiązywania problemów, lecz rozwiązanie przeznaczone wyłącznie do krótkich sytuacji awaryjnych. Przed aktywacją należy sprawdzić stan:

Udokumentowany default to Disable. Przy enable wszystkie porty przyjmują połączenia przychodzące, a zwykłe ograniczenie osiągalności przez Device Access zostaje tymczasowo usunięte. Uwierzytelnianie poszczególnych usług pozostaje osobnym zabezpieczeniem, ale nie czyni tak szerokiej ekspozycji nieszkodliwą.

system appliance_access show

Po teście należy wyłączyć tryb awaryjny i ponownie sprawdzić stan:

system appliance_access disable
system appliance_access show

Jeśli polecenie nie jest rozpoznawane, należy najpierw sprawdzić obszar konsoli. Użycie niewłaściwego obszaru jest bardziej prawdopodobne niż uszkodzenie polecenia.

Sprawdzanie logów w Advanced Shell

Najważniejsze pliki logów znajdują się w /log. Sophos dokumentuje najpierw przejście do tego katalogu w Advanced Shell:

cd /log

Przydatne polecenia podstawowe:

• Śledzenie logu na żywo: tail -f ips.log. Ciągły wynik powinien być otwarty tylko w zapisanym oknie testowym.
• Odczyt pliku logu: less ips.log. Wiersze logu są wyświetlane partiami.
• Wyszukiwanie terminu: grep error ips.log. Termin i plik należy dostosować do problemu.

Powiązanie plików logów z modułami opisano w artykule Sophos Firewall: usługi i logi podczas rozwiązywania problemów.

Podczas śledzenia logów na żywo okres testowy powinien być krótki, a jego czas należy zanotować. Jest to szczególnie ważne, jeśli archiwum logów ma zostać później przekazane do Sophos Support lub Avanet.

Device Console do szybkiej kontroli sieci

Device Console nadaje się do szybkich testów z perspektywy firewalla. Pozwala sprawdzić, czy DNS, routing lub osiągalność zasadniczo działają.

Szybkie kontrole:

• Sprawdzanie hosta: ping 192.0.2.10 count 4 sprawdza osiągalność ICMP.
• Sprawdzanie DNS w Device Console: dnslookup host example.com sprawdza rozpoznawanie nazw z perspektywy firewalla.
• Sprawdzanie trasy: traceroute 192.0.2.10 pokazuje drogę do celu.
• Wyświetlanie stanu interfejsu: show interfaces pokazuje informacje o interfejsach.
• Uruchamianie Drop Capture: drop-packet-capture 'host 192.0.2.10' pokazuje pakiety odrzucone przez reguły firewalla.
• Uruchamianie przechwytywania pakietów: tcpdump 'host 192.0.2.10 and port 443' sprawdza, czy pakiety są widoczne na firewallu.

Dla protokołu IPv6 dostępne są odpowiednie polecenia ping6, dnslookup6 i traceroute6.

Polecenia tcpdump i drop-packet-capture działają do chwili zatrzymania ich za pomocą Ctrl+C. Przed uruchomieniem należy określić filtr i okno testowe, obserwować dane wyjściowe i niezwłocznie zatrzymać przechwytywanie po teście. Polecenia te nie zmieniają konfiguracji, ale ich obciążenie zależy od natężenia ruchu, szerokości filtra i czasu działania.

drop-packet-capture jest szczególnie przydatne, gdy nie wiadomo, czy firewall aktywnie odrzuca pakiety. Nie zastępuje jednak analizy aplikacji. Jeśli serwer odpowiada, ale aplikacja nadal nie działa, należy dodatkowo sprawdzić Log Viewer, NAT, Packet Capture lub logi aplikacji.

W przypadku dłuższych przechwytywań i plików PCAP lepiej skorzystać z artykułu Sophos Firewall: zbieranie logów za pomocą TCPDump do analizy. Należy również zaplanować maksymalny rozmiar pliku, miejsce zapisu i bezpieczny sposób przesyłania.

Kontrole sieci w WebAdmin bez CLI

W Diagnostics > Tools można sprawdzić te same podstawowe kwestie bez dostępu do konsoli. Ping pozwala wybrać IPv4 lub IPv6, interfejs wyjściowy oraz rozmiar pakietu. Sophos domyślnie używa 32 bajtów i dopuszcza wartości od 1 do 65 507 bajtów. Udany ping potwierdza osiągalność ICMP z wybranego interfejsu zapory, ale nie działanie usługi aplikacyjnej.

W przypadku Ping w SFOS 22 i SFOS 23 pole IP address or hostname może zawierać adres IPv4, adres IPv6 lub FQDN. IP family określa rodzinę adresów, Interface interfejs wyjściowy, a Size rozmiar pakietu. W przypadku FQDN dodatkowo wymagane jest rozwiązywanie nazw; aby zawęzić przyczynę problemu z DNS, należy porównać wynik z tym samym testem wykonanym dla oczekiwanego adresu IP.

Wynik Ping pokazuje, czy docierają odpowiedzi, ile pakietów wysłano i odebrano, utratę pakietów oraz czas Round-Trip Time (RTT). RTT to czas obejmujący żądanie i odpowiedź, a nie czas transmisji w jedną stronę. Jeśli nie nadejdzie żadna odpowiedź, wyświetlana jest utrata pakietów wynosząca 100 procent. Samo to nie dowodzi, że host jest wyłączony: należy sprawdzić adres docelowy, wybrany interfejs, routing i to, czy ICMP jest dozwolony, a w razie potrzeby użyć precyzyjnie ograniczonego Packet Capture. Udany test musi nadal odpowiadać rzeczywistemu przepływowi aplikacji.

Traceroute przyjmuje również IPv4, IPv6 lub FQDN oraz świadomie wybrany interfejs wyjściowy. Brak odpowiedzi z pojedynczych hopów nie dowodzi przerwania, jeśli odpowiadają późniejsze hopy lub cel. Przy analizie ścieżki należy więc wspólnie ocenić osiągalność celu, ostatni odpowiadający hop i równolegle zmierzony przepływ pakietów.

W WebAdmin w Diagnostics > Tools > Traceroute należy określić cel w IP address or hostname, rodzinę adresów w IP version i interfejs wyjściowy w Interface; zapytanie uruchamia się przyciskiem Traceroute. Dla SFOS 22 i SFOS 23 Sophos opisuje wynik jako obejmujący routery na przebytej trasie, maksymalną liczbę hopów oraz całkowity czas powrotu pakietu w milisekundach. Maksymalna liczba hopów ogranicza wyszukiwanie ścieżki; nie jest dowodem dotarcia do celu. Wartości czasu opisują odpowiedzi diagnostyczne i nie dowodzą przepustowości aplikacji. W 4. Device Console polecenie traceroute6 2001:db8::10 uzupełnia powyższy przykład IPv4; adres dokumentacyjny należy zastąpić rzeczywistym adresem docelowym IPv6.

Poniższe nazwy Name lookup i Lookup using all configured servers dotyczą SFOS 22. Zmienione nazwy w SFOS 23 — DNS lookup i All configured servers — oraz dodatkowe opcje serwerów i warunki ich użycia opisuje artykuł Porównywanie poszczególnych resolverów w Diagnostics.

Name lookup wysyła zapytanie do wybranego serwera DNS. Lookup using all configured servers pozwala porównać wszystkie serwery DNS skonfigurowane na zaporze oraz ich czasy odpowiedzi. Pojedynczy szybki wynik nie jest jeszcze powodem do zmiany priorytetu DNS; poprawne muszą być również treść odpowiedzi, niezawodność i ścieżka danego klienta.

Route lookup pokazuje, przez który interfejs zapora skierowałaby ruch do celu IPv4 lub IPv6. Nie dowodzi ani reguły zapory, ani NAT, decyzji SD-WAN, ani działającej ścieżki powrotnej. Dlatego weryfikację należy uzupełnić rzeczywistym połączeniem, Connection List lub Packet Capture.

Sprawdzanie połączeń bez zmiany ich stanu

Bieżące połączenia IPv4 i IPv6 można filtrować w Current activities > Live connections i Diagnostics > Connection list. Connection list pokazuje między innymi interfejsy wejściowy i wyjściowy, źródło i cel, Rule ID, NAT ID, przetłumaczone adresy, stan oraz liczniki Rx/Tx. To lepszy pierwszy krok niż nieudokumentowane narzędzie Advanced Shell.

W Device Console udokumentowano także to narzędzie połączeń:

system diagnostics utilities connections

Przed wykonaniem należy sprawdzić dostępne argumenty za pomocą system diagnostics utilities connections ?. Ponieważ Connection list jest migawką, przepływ testowy trzeba odtworzyć przy odświeżanej liście. Jeśli połączenia nadal nie ma, należy użyć precyzyjnego Packet Capture; jeśli jest, analizę kontynuuje się według Rule ID, NAT ID, interfejsów, translacji i liczników odpowiedzi.

Sprawdzanie wolnego miejsca i stanu systemu

Przed włączeniem debugowania, utworzeniem dużych archiwów logów lub rozpoczęciem dłuższych przechwytywań należy sprawdzić wolne miejsce.

Device Console udostępnia w tym celu następujące polecenia systemowe tylko do odczytu, oficjalnie opisane w dokumentacji:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk
system diagnostics show uptime
system diagnostics show version-info

system diagnostics show version-info pokazuje również numer seryjny i Device ID. Przed udostępnieniem wyników lub zrzutów należy zamazać te identyfikatory.

Dodatkowe cele tylko do odczytu to interrupts, syslog, sysmsg, subsystem-info i ctr-log-lines. Odpowiadają na różne pytania i nie należy traktować ich jako zamiennych wskaźników stanu:

system diagnostics show interrupts
system diagnostics show syslog
system diagnostics show sysmsg
system diagnostics show subsystem-info
system diagnostics show ctr-log-lines

Na XGS Appliances dostępne jest również polecenie system diagnostics selftest do podstawowych testów karty sieciowej. Nie dotyczy ono innych platform i nie zastępuje testu kabla, pomiaru przepustowości ani przechwytywania pakietów. Ponieważ Sophos nie określa na stronie polecenia wpływu na ruch produkcyjny, test wykonuje się wyłącznie jako zaplanowane działanie lub na polecenie wsparcia, a wynik porównuje ze stanem łącza, licznikami interfejsu i rzeczywistym ruchem.

W sekcji system diagnostics utilities SFOS grupuje dodatkowe narzędzia dla ARP, przepustowości, połączeń, DNS, przechwytywania odrzuceń, konfiguracji sieci, ping, procesów, tras i traceroute, wraz z wariantami IPv6 tam, gdzie Sophos je udostępnia. Dokładną składnię należy sprawdzić w zainstalowanej kompilacji przy użyciu uzupełniania klawiszem Tab. Niektóre narzędzia tylko odczytują stan, inne generują ruch testowy lub uruchamiają ciągłe wyjście.

Do dodatkowej kontroli tylko do odczytu Sophos dokumentuje w Advanced Shell:

service -S
service -S | grep ips

Pierwsza wersja pokazuje stany wielu usług, a druga wykorzystuje przykład IPS udokumentowany przez Sophos. Brak trafienia nie oznacza, że należy restartować usługę: najpierw trzeba porównać nazwę usługi i plik logu z aktualnym wykazem Sophos.

Jeśli wolnego miejsca jest już mało, nie należy włączać debugowania ani rozpoczynać długiego przechwytywania pakietów. Najpierw trzeba ustalić, które logi lub raporty można bezpiecznie zapisać i usunąć.

Zbieranie logów debug tylko z potwierdzoną drogą wyjścia

SFOS 22 włącza tryb debugowania w Device Console, a nie w WebAdmin. Przed kontrolowanym testem z udokumentowanym przez Sophos przykładem Pktcapd należy zapisać ilość wolnego miejsca i czas testu, a następnie wykonać:

system diagnostics subsystems Pktcapd debug on

Należy jednokrotnie odtworzyć problem, a potem pobrać plik logu lub Consolidated Troubleshooting Report (CTR) w Diagnostics > Tools > Troubleshooting logs. Debugowanie zwiększa pliki logów i pozostaje aktywne do chwili wyłączenia. Bezpośrednio po pobraniu należy więc wykonać udokumentowany rollback:

system diagnostics subsystems Pktcapd debug off

Należy zapisać oba polecenia i ich dane wyjściowe CLI. Jeśli polecenie zostanie odrzucone, nie należy improwizować z innym poleceniem podsystemu lub usługi: trzeba sprawdzić składnię za pomocą ? i skontaktować się z Sophos Support. Debugowanie w Advanced Shell zostało celowo pominięte, ponieważ ogólna składnia usług nie zapewnia uniwersalnego polecenia wyłączenia każdego trybu.

Informacje o restartach usług i ich skutkach zawiera artykuł Ponowne uruchamianie usług Sophos Firewall. Restart usług VPN, IPS, web lub uwierzytelniania może przerwać aktywne sesje lub logowania.

Bezpieczne przekazywanie logów

W złożonych przypadkach pojedyncze fragmenty logów często nie wystarczają. Pełne archiwum logów jest zazwyczaj bardziej przydatne dla Sophos Support, Avanet lub zewnętrznego zespołu analizującego problem.

Zamiast wpisywać dane logowania w poleceniach powłoki, pobiera się poszczególne logi lub CTR w Diagnostics > Tools > Troubleshooting logs i przekazuje przez uzgodniony portal wsparcia. Zobacz Zbieranie logów Sophos Firewall dla wsparcia i analizy.

Pliki logów mogą zawierać informacje wrażliwe: wewnętrzne i publiczne adresy IP, nazwy hostów, nazwy użytkowników, parametry VPN oraz komunikaty o błędach. Przed przekazaniem należy ustalić, kto otrzyma dane i jak długo będą przechowywane.

Typowe błędy podczas rozwiązywania problemów za pomocą CLI

• Polecenie w niewłaściwym obszarze konsoli: Device Console i Advanced Shell obsługują inną składnię. Najpierw sprawdzić obszar.
• Pozostawienie debugowania po analizie: Logi niepotrzebnie rosną i mogą zużywać wolne miejsce. Natychmiast wyłączyć debugowanie.
• Szerokie tcpdump bez filtra: Dużo danych, wysokie obciążenie i trudna analiza. Ograniczyć host, port, interfejs lub liczbę pakietów.
• Dane logowania FTP w historii powłoki: Dane mogą znaleźć się w logach, zrzutach ekranu lub historii. Używać bezpiecznego przesyłania i tymczasowych danych logowania.
• Sprawdzenie tylko jednego pliku logu: Wiele problemów dotyczy kilku modułów. Połączyć Log Viewer, odpowiednie logi usług i Packet Capture.
• Brak dokumentacji czasu: Wsparcie musi przeszukiwać niepotrzebnie duże zakresy logów. Zanotować czas, działanie testowe i używane adresy IP.
• Brak porządkowania po teście: Debugowanie, pliki tymczasowe lub szeroki dostęp pozostają aktywne. Wyłączyć debugowanie, sprawdzić pliki i usunąć tymczasowy dostęp SSH.

Lista kontrolna

• Dostęp SSH dozwolony tylko z zaufanych sieci administracyjnych.
• Fingerprint SSH i dostęp admin sprawdzone przed analizą.
• Wybrany właściwy obszar konsoli: Device Console lub Advanced Shell.
• Udokumentowany czas problemu, Source IP, Destination IP, port i użytkownik.
• Wynik CLI udokumentowany wraz z przedziałem czasu, poleceniem, filtrem i rezultatem.
• Najpierw użyte polecenia tylko do odczytu, przed włączeniem debugowania, restartem usług lub dłuższymi przechwytywaniami.
• Najpierw sprawdzony Log Viewer.
• Zidentyfikowany odpowiedni plik logu w /log.
• tail, grep lub less użyte z precyzyjną frazą wyszukiwania.
• Przy problemach sieciowych celowo użyto w Device Console poleceń dnslookup, ping, traceroute, drop-packet-capture lub tcpdump.
• Debugowanie włączono tylko na krótko w Diagnostics > Tools > Troubleshooting logs, następnie wyłączono i sprawdzono stan normalny.
• Wolne miejsce sprawdzone przed debugowaniem lub PCAP.
• Archiwum logów przesłane bezpiecznie, a pliki tymczasowe usunięte.
• Tymczasowe wyjątki Device Access lub SSH usunięte po zakończeniu zgłoszenia.

Często zadawane pytania