Przejdz do tresci
Avanet

Diagnostyka Wireless Controller Sophos Firewall przez CLI

W SFOS 22 polecenia system wireless-controller uruchamia się w 4. Device Console. Dzienniki diagnostyczne należy przeglądać osobno w 5. Device Management > 3. Advanced Shell. Zacznij od kontroli tylko do odczytu. Funkcję Remote Packet Capture włącz dopiero po zawężeniu problemu do jednego punktu dostępowego i jednego klienta testowego.

⚠️ Prywatność i eksploatacja: Capture Wi-Fi może zawierać ruch użytkowników, adresy IP, zapytania DNS oraz dane uwierzytelniania lub sesji. Użyj precyzyjnego filtra, zarejestruj jeden krótki i powtarzalny test oraz zabezpiecz wyeksportowany plik. Przed każdą zmianą zapisz dokładną wartość początkową.

Ten przewodnik opiera się na publicznej dokumentacji SFOS 22. Polecenia nie zostały na potrzeby artykułu uruchomione na Sophos Firewall, dlatego sprawdź składnię i rzeczywisty wynik w zainstalowanej wersji.

Otwórz prawidłową konsolę

Do CLI można uzyskać dostęp lokalnie za pomocą kabla konsolowego, zdalnie przez SSH albo przez admin > Console w WebAdmin. W przypadku SSH zezwól na usługę SSH dla wymaganej strefy w Administration > Device access > Local service ACL. admin > Console wymaga dostępu HTTPS dla tej strefy. W miarę możliwości ogranicz dostęp administracyjny do wybranych hostów za pomocą reguły wyjątku Local service ACL.

Po zalogowaniu wybierz 4. Device Console. W tym miejscu ? wyświetla dostępne argumenty i ich opisy dla częściowo wpisanego polecenia. system wireless-controller jest poleceniem Device Console. Advanced Shell to odrębne środowisko, używane poniżej wyłącznie do udokumentowanego odczytu dzienników; nie jest zamienne z Device Console.

Zapisz stan początkowy i objaw

Najpierw sprawdź, które gałęzie polecenia są dostępne w zainstalowanej wersji, i odczytaj bieżące wartości:

system wireless-controller ?
system wireless-controller ap_localdebuglevel get
system wireless-controller global show
system wireless-controller remote_pktcap show <AP_serial_number>

Zastąp <AP_serial_number> numerem seryjnym odpowiedniego AP; nie wpisuj nawiasów ostrych. Zapisz także wersję SFOS, model i firmware AP, SSID, pasmo, kanał, szerokość kanału, adresy MAC i IP klienta testowego, godzinę oraz dokładnie powtarzalny objaw. W parze HA zanotuj również węzeł, do którego się zalogowano. Po przełączeniu awaryjnym nie powtarzaj diagnostyki bez uzasadnienia na obu węzłach.

Prawidłowy status kontrolera potwierdza jedynie stan płaszczyzny sterowania. Nie dowodzi poprawnego działania asocjacji klienta, DHCP, DNS, uwierzytelniania ani ścieżki danych.

Sprawdź najpierw WebAdmin i odpowiednie dzienniki

W Wireless > Access points sprawdź, czy AP jest aktywny oraz czy model i numer seryjny się zgadzają. Sophos Firewall zarządza punktami dostępowymi przez port 2712. Jeżeli AP nie jest widoczny lub pozostaje nieaktywny, sprawdź najpierw strefę, VLAN, switchport, adresację i ścieżkę do tego portu. Akceptacja nieznanego AP nie jest krokiem diagnostycznym: przed kliknięciem Accept potwierdź jego model, numer seryjny, lokalizację i sieć zarządzającą.

Dokumentacja SFOS 22 przypisuje do problemów z siecią bezprzewodową następujące pliki dziennika:

  • awed.log: komunikacja między AP lub APX a firewallem
  • wc_remote.log: komunikacja klienta bezprzewodowego z AP lub APX
  • hostapd.log: zdarzenia SSID dla LocalWifi
  • hotspotd.log: zdarzenia hotspotu

SFOS 22 oficjalnie dokumentuje polecenia tail -f, grep i less do odczytu dzienników diagnostycznych w 5. Device Management > 3. Advanced Shell. Ogólna udokumentowana składnia pozwala zastosować następujące, celowo zawężone przykłady:

tail -f /log/awed.log
grep '<AP_serial_number>' /log/awed.log
grep '<client_MAC_address>' /log/wc_remote.log
less /log/hostapd.log

Każdy symbol zastępczy zastąp jednym dokładnym identyfikatorem i pomiń nawiasy ostre. Polecenie tail -f uruchamiaj tylko na czas krótkiej próby odtworzenia problemu i zakończ je skrótem Ctrl+C; z programu less wyjdź klawiszem q. Każde z tych poleceń odczytuje jeden właściwy plik i nie zastępuje powyższych poleceń Device Console. Operacje serwisowe start, stop i restart oraz operacje debugowania zmieniają stan systemu. Nie stosuj ich jako ogólnej metody diagnostycznej: wymagają potrzeby wynikającej z konkretnego przypadku, zapisanego stanu początkowego i jednoznacznego planu wycofania zmian. Jeżeli te kontrole nie wystarczą, włącz ograniczony czasowo dostęp w Diagnostics > Support access i przekaż identyfikator dostępu uzgodnionym kanałem pomocy technicznej.

Uruchom zdalne przechwytywanie pakietów na jednym AP

remote_pktcap przekazuje pakiety z AP do funkcji Packet Capture uruchomionej w tym samym czasie na firewallu. Sophos wymaga globalnego ap_debuglevel co najmniej 4. Poziom debugowania jest globalny, podczas gdy polecenie przechwytywania jest ukierunkowane na określony numer seryjny AP.

  1. Uruchom system wireless-controller global show i zapisz dokładną wartość ap_debuglevel. Jeżeli wynosi już 4 lub więcej, nie zmieniaj jej.

  2. Jeżeli wynosi mniej niż 4, ustaw ją tymczasowo na 4 i ponownie odczytaj stan:

    system wireless-controller global ap_debuglevel 4
    system wireless-controller global show
    
  3. Otwórz Diagnostics > Packet capture, skonfiguruj wąski filtr dla klienta testowego, celu, portu lub protokołu i uruchom przechwytywanie pakietów.

  4. Włącz przechwytywanie AP i sprawdź jego status:

    system wireless-controller remote_pktcap enable <AP_serial_number>
    system wireless-controller remote_pktcap show <AP_serial_number>
    
  5. Wygeneruj wyłącznie zdefiniowany ruch testowy. Packet Capture pokazuje między innymi interfejs wejściowy i wyjściowy, Status, Reason oraz Firewall Rule ID. Dane te pomagają ustalić, czy ramka dociera do AP, czy firewall ją przetwarza i czy reguła ją odrzuca.

  6. Zatrzymaj najpierw przechwytywanie AP, a następnie zatrzymaj przechwytywanie pakietów w WebAdmin:

    system wireless-controller remote_pktcap disable <AP_serial_number>
    system wireless-controller remote_pktcap show <AP_serial_number>
    
  7. Jeżeli zmieniono ap_debuglevel, przywróć wartość zapisaną przed testem i ją zweryfikuj:

    system wireless-controller global ap_debuglevel <saved_ap_debuglevel>
    system wireless-controller global show
    

Zastąp <saved_ap_debuglevel> dokładną poprzednią wartością. Udokumentowana składnia Wireless Controller nie zawiera dla tego parametru gałęzi reset, więc przyjęcie domyślnej wartości nie zapewnia bezpiecznego wycofania zmiany.

Nie traktuj pozostałych parametrów jako uniwersalnej naprawy

Konsola urządzenia zawiera listę dodatkowych globalnych parametrów. Ich zakresy liczbowe są udokumentowane, ale efekt operacyjny nie jest wystarczająco wyjaśniony w każdym przypadku:

  • ap_localdebuglevel: 0 do 15; odczyt z get, zmiana z set
  • log_level: 0 do 7; wiadomości na lub powyżej skonfigurowanego poziomu są zapisywane, więc wyższa liczba nie oznacza po prostu “więcej logowania”
  • ap_autoaccept, stay_online i store_bss_stats: 0 off, 1 on
  • tunnel_id_offset: 0 do 65535

Nie zmieniaj tych wartości profilaktycznie ani nie uruchamiaj bloku zawierającego kilka zmian. W szczególności ap_autoaccept usuwa świadomy punkt kontroli przy akceptowaniu AP. Strona poleceń nie podaje wystarczającego kontekstu, aby ogólnie zalecać stay_online, store_bss_stats lub tunnel_id_offset podczas rozwiązywania problemów. Używaj ich wyłącznie zgodnie z instrukcjami Sophos Support dotyczącymi konkretnego przypadku, zapisz poprzednią wartość za pomocą global show, a następnie przywróć dokładnie tę wartość.

Opóźniaj RADIUS Accounting Start tylko przy potwierdzonej przyczynie

radius_accounting_start_delay służy wyłącznie do rozwiązania potwierdzonego problemu z kolejnością: komunikat 802.1X Accounting Start dociera przed przydzieleniem klientowi adresu przez DHCP. Wi-Fi SSO nie może wtedy pobrać użytecznego atrybutu Framed-IP-Address z komunikatu Accounting Start. Udokumentowany zakres wynosi od 0 do 60 sekund; w KBA-000006795 Sophos podaje przykład z wartością 30 sekund.

Przed zmianą wartości potwierdź kolejność na podstawie dzienników RADIUS i przechwyconego ruchu oraz zapisz bieżącą wartość za pomocą global show. Pełna procedura znajduje się w artykule Sprawdzanie RADIUS SSO i Accounting. Po wykonaniu testu należy uruchomić system wireless-controller global radius_accounting_start_delay <saved_delay> z dokładną poprzednią wartością i zweryfikować ją za pomocą global show.

Szerokość kanału to konfiguracja, nie diagnostyka

Sophos dokumentuje szerokości 20 i 40 MHz dla pasma 2,4 GHz oraz 20, 40 i 80 MHz dla pasma 5 GHz. Strona CLI nieprawidłowo podaje 2.5GHz w jednym miejscu. Nie kopiuj go na ślepo. Udokumentowana gałąź CLI nie zawiera również oddzielnego polecenia odczytu lub resetowania dla szerokości kanału. Bez zapisanego stanu początkowego i potwierdzonej składni nie jest to bezpieczny krok diagnostyczny.

Szerokość kanału zaplanuj w standardowej konfiguracji Wireless Network w WebAdmin. Korzystanie z kanałów, sąsiadujące sieci, sygnał, retransmisje, możliwości klientów i zagęszczenie urządzeń w lokalizacji decydują, czy szersze ustawienie w ogóle pomaga.

Oceń wynik i prawidłowo zakończ sesję

Po diagnostyce sprawdź stan AP, skojarzenie klienta, dzierżawę DHCP, rozwiązywanie nazw DNS, uwierzytelnianie, oczekiwany Firewall Rule ID, utratę pakietów, opóźnienia i działanie aplikacji, której dotyczył problem. W przypadku RADIUS zweryfikuj również Accounting Start, Framed-IP-Address i mapowanie użytkownika.

Procedura jest zakończona dopiero wtedy, gdy remote_pktcap show zgłasza brak aktywnego przechwytywania dla AP, funkcja Packet capture jest wyłączona w WebAdmin, a global show pokazuje zapisane wartości debugowania i parametrów. Jeżeli przyczyna pozostaje niejasna, zachowaj godzinę, numer seryjny AP, dane klienta testowego, przechwycony ruch i nazwy odpowiednich plików dziennika dla Sophos Support, zamiast zmieniać kolejne ustawienia globalne.

Oficjalne źródła

FAQ

Dlaczego zdalne przechwytywanie pakietów nie pokazuje żadnych pakietów?

Sprawdź, czy Packet capture działa w WebAdmin, czy globalny ap_debuglevel wynosi co najmniej 4, czy numer seryjny AP jest poprawny i czy filtr obejmuje ruch testowy. Następnie sprawdź oba polecenia statusu, zamiast bez uzasadnienia zwiększać poziom debugowania.

Czy mogę uruchomić polecenia Bezprzewodowego Kontrolera w Advanced Shell?

Nie. Pokazane tu polecenia system wireless-controller należy uruchamiać w 4. Device Console. Advanced Shell służy osobno do wykonania udokumentowanych powyżej poleceń tylko do odczytu. Operacje serwisowe i debugowania zmieniają stan, dlatego wymagają potrzeby dotyczącej konkretnego przypadku oraz planu wycofania zmian.

Czy ap_autoaccept powinien przyspieszać wdrażanie AP?

Nie jako środek rozwiązywania problemów. Automatyczne przyjęcie usuwa punkt kontrolny. Sprawdź model, numer seryjny, switchport, lokalizację i sieć zarządzającą, a następnie świadomie zaakceptuj oczekiwany AP w WebAdmin.

Jaki poziom debugowania powinien pozostać po zakończeniu przechwytywania?

Nie należy automatycznie ustawiać 0 ani pozostawiać 4: przywróć dokładną wartość zapisaną przed testem za pomocą global show. Ponowne wykonanie global show potwierdzi wycofanie zmiany.