Przejdz do tresci
Avanet
Zaloguj sie

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. Zacząć od kontroli tylko do odczytu. Funkcję Remote Packet Capture włączyć 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żyć precyzyjnego filtra, zarejestrować jeden krótki i powtarzalny test oraz zabezpieczyć wyeksportowany plik. Przed każdą zmianą zapisać dokładną wartość początkową.

Ten przewodnik dotyczy SFOS 22. Przed użyciem poleceń 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 zezwolić 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 ograniczyć dostęp administracyjny do wybranych hostów za pomocą reguły wyjątku Local service ACL.

Po zalogowaniu wybrać 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 sprawdzić, które gałęzie polecenia są dostępne w zainstalowanej wersji, i odczytać 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ąpić <AP_serial_number> numerem seryjnym odpowiedniego AP; nie wpisywać nawiasów ostrych. Zapisać 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 zanotować również węzeł, do którego się zalogowano. Po przełączeniu awaryjnym nie powtarzać 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 sprawdzić, 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, sprawdzić najpierw strefę, VLAN, switchport, adresację i ścieżkę do tego portu. Akceptacja nieznanego AP nie jest krokiem diagnostycznym: przed kliknięciem Accept potwierdzić 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ąpić jednym dokładnym identyfikatorem i pominąć nawiasy ostre. Polecenie tail -f uruchamiać tylko na czas krótkiej próby odtworzenia problemu i zakończyć je skrótem Ctrl+C; z programu less wyjść 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 stosować 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łączyć ograniczony czasowo dostęp w Diagnostics > Support access i przekazać 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.

Warunek przed krokiem 1: Sprawdź i zapisz stan przechwytywania tego AP za pomocą system wireless-controller remote_pktcap show <AP_serial_number> oraz istniejący stan przechwytywania firewalla w Diagnostics > Packet capture. Jeżeli którekolwiek przechwytywanie jest już aktywne lub jego stan jest niejasny, nie zmieniaj filtra, stanu przechwytywania ani globalnego poziomu debugowania. Ustal osobę odpowiedzialną i cel, a następnie wstrzymaj tę procedurę do uzyskania wyraźnie zatwierdzonego stanu początkowego, w którym oba przechwytywania są nieaktywne. Nie przejmuj ani nie zatrzymuj cudzej diagnostyki.

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

  2. Jeżeli wynosi mniej niż 4, ustawić ją tymczasowo na 4 i ponownie odczytać stan:

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

  4. Włączyć przechwytywanie AP i sprawdzić jego status:

    system wireless-controller remote_pktcap enable <AP_serial_number>
    system wireless-controller remote_pktcap show <AP_serial_number>
    
  5. Wygenerować 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 wyłącznie przechwytywania uruchomione przez tę procedurę z potwierdzonego nieaktywnego stanu początkowego: najpierw własne przechwytywanie AP poniższymi poleceniami, a potem własne Packet capture w WebAdmin. Pozostaw bez zmian przechwytywania, których nie uruchomiono w tej procedurze, oraz przechwytywania innych osób:

    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ócić wartość zapisaną przed testem i ją zweryfikować:

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

Zastąpić <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 wpisów w dzienniku”
  • ap_autoaccept, stay_online i store_bss_stats: 0 off, 1 on
  • tunnel_id_offset: 0 do 65535

Nie zmieniać tych wartości profilaktycznie ani nie uruchamiać 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żywać ich wyłącznie zgodnie z instrukcjami Sophos Support dotyczącymi konkretnego przypadku, zapisać poprzednią wartość za pomocą global show, a następnie przywrócić 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.

Procedura udokumentowana przez Sophos dotyczy modeli APX zarządzanych przez SFOS i sieci SSID WPA/WPA2 Enterprise. KBA nie potwierdza tej ścieżki SSO dla AP6 ani dowolnych kontrolerów innych producentów.

Przed zmianą wartości potwierdzić kolejność na podstawie dzienników RADIUS i przechwyconego ruchu oraz zapisać 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 kopiować 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 zaplanować 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ń konfigurację AP i odpowiedzi XML API

Jeżeli automatyzacja zmieniła AP, sprawdź także zapisany obiekt WirelessAccessPoint. Referencje XML SFOS 22 i 23 zawierają takie same opisy pól; nie dowodzi to obsługi sprzętu w każdej wersji. ID to obowiązkowy identyfikator AP typu string, nie Label, SSID ani dowolna nazwa grupy. Update Access Point wymienia także Label, Country i Band jako obowiązkowe; Delete Access Point wymienia ID. Usunięcie nie jest diagnostyką ani usunięciem przypisania SSID: wymaga świadomie zatwierdzonego wycofania urządzenia.

Sprawdź zależności: Group wybiera grupę AP, a WirelessNetworks/Network przypisania WLAN. Dla 2,4 GHz są to Channel2.4GHz, DynChan, TimeBasedScan, ScanTime/Time, TXPower i ChannelWidth; dla 5 GHz odpowiednio Channel5GHz, DynChan5GHz, TimeBasedScan5GHz, ScanTime5GHz/Time, TXPower5GHz i ChannelWidth11a. Przypisz harmonogram tylko przy włączonym skanowaniu czasowym, a to włączaj tylko przy dynamicznym wyborze kanału w danym paśmie. VLANTagging i zależny od niego APVLANID dotyczą ścieżki zarządzania; udokumentowany zakres APVLANID wynosi 1–4094. Porównaj grupę, SSID, VLAN zarządzający, interfejs i ścieżkę switcha z konfiguracją Wi-Fi. AP6 pozostaje poza zarządzaniem SFOS.

To nie jest gotowe do wysłania żądanie zapisu: Przykład używa RootAccessPoint dla Role, ale opis pola podaje point/portal. Przełączniki skanowania mają w przykładzie Enable, podczas gdy opis dopuszcza tylko t; niektóre opisy pasm również są niespójne. Nie normalizuj tych wartości samodzielnie. Przed zmianą potwierdź dokładne znaczniki nadrzędne, wartości i operację w API help zainstalowanej wersji; jeżeli przyporządkowanie pozostaje niejasne, nie zapisuj i skonsultuj się z Support.

Poniższe przyporządkowania to statusy XML API i nierozwiązane symbole referencji, nie kody HTTP ani zweryfikowane teksty komunikatów podczas wykonania. Każdy wymieniony kod należy do wskazanej operacji i symbolu:

  • Update Access Point — 200, 216 — Message.WPAPkUpdateSuccessfully
  • Update Access Point — 500, 541, 543, 545, 544 — Message.WPAPUpdateFail
  • Update Access Point — 523 — Message.WPNetworkGroupMax
  • Update Access Point — 524 — Message.WPAccessPointMax
  • Update Access Point — 542 — Message.WPAccessPointMesh
  • Update Access Point — 547 — Message.WPAPUpdateFailVLANGroup
  • Update Access Point — 548 — Message.WPA3IsNotSupported
  • Delete Access Point — 200 — Message.WPAccessPointDeleteSuccess
  • Delete Access Point — 500 — Message.WPAccessPointDeleteFail

Nie wyciągaj z samego symbolu wniosków o limicie, przyczynie ani bezpieczeństwie ponowienia. Przed każdą ponowną próbą zapisu porównaj odpowiedź z rzeczywiście zapisanym stanem AP, grupy, WLAN i VLAN, także dla 216; następnie sprawdź połączenie klienta i ścieżkę danych. Centralny przewodnik bezpieczeństwa XML API wyjaśnia ochronę dostępu, jawne operacje, wyniki częściowe i wycofanie zmian.

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

Po diagnostyce sprawdzić 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 zweryfikować również Accounting Start, Framed-IP-Address i mapowanie użytkownika.

Procedura jest zakończona, gdy jej własne tymczasowe przechwytywania zostały zatrzymane: remote_pktcap show musi potwierdzić nieaktywny stan przechwytywania AP uruchomionego tutaj, a WebAdmin stan uruchomionego tutaj Packet capture. Pozostała diagnostyka pozostaje bez zmian; jeżeli procedurę wstrzymano z powodu już aktywnego przechwytywania, jego zatrzymanie nie jest warunkiem zakończenia. global show musi pokazywać zapisane wartości debugowania i parametrów. Jeżeli przyczyna pozostaje niejasna, zachować godzinę, numer seryjny AP, dane klienta testowego, przechwycony ruch i nazwy odpowiednich plików dziennika dla Sophos Support, zamiast zmieniać kolejne ustawienia globalne.

FAQ

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

Sprawdzić, 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 sprawdzić 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. Sprawdzić model, numer seryjny, switchport, lokalizację i sieć zarządzającą, a następnie świadomie zaakceptować 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.