Przejdz do tresci
Avanet
Moje konto
Moje konto

Ładowanie …
Portal klienta Ustawienia konta

Konfiguracja i test Wireless Mesh w istniejącej instalacji APX zarządzanej przez Sophos Firewall

Sophos Firewall

Wireless Mesh na Sophos Firewall łączy bezprzewodowo jeden lub kilka Access Pointów APX z przewodowym root AP. Wypełnia lukę zasięgu tam, gdzie brakuje Ethernetu. Backhaul mesh nie jest widocznym SSID WLAN: SFOS tworzy ukrytą sieć WPA2-Personal z losową passphrase. Klienci nadal używają osobno skonfigurowanego Wireless Network.

⚠️ Ważne: Instrukcja dotyczy istniejących instalacji APX zarządzanych bezpośrednio przez SFOS. APX tworzy mesh tylko z APX. AP6, zintegrowane LocalWiFi, moduły Wi-Fi SD-RED i mieszane serie AP Sophos nie należą do tego procesu. Mesh nie zastępuje też redundancji przewodowej: co najmniej jeden AP pozostaje w LAN, a SFOS nie zmienia automatycznie root po awarii root AP.

Zakres: eksploatacja istniejącej instalacji, nie nowa platforma WLAN

Poniższe kroki opisują mesh w istniejącej, starszej instalacji APX zarządzanej przez Firewall, a nie budowę nowej platformy APX lub UTM. Przed wprowadzeniem zmian należy potwierdzić obsługę konkretnego modelu AP, jego rewizji sprzętowej oraz faktycznie używanego buildu SFOS. Pomoc dotycząca Wireless w SFOS 22 i SFOS 23 zawiera starsze procedury mesh; samo istnienie strony pomocy nie potwierdza obsługi sprzętu. W szczególności nie można na tej podstawie uznać, że instalację APX można zaktualizować do SFOS 23. Jeśli obsługa nie została potwierdzona, należy pozostawić obecną konfigurację i najpierw wyjaśnić zgodność modelu z buildem oraz kwestię migracji.

Mesh AP6 jest zarządzany w inny sposób: konfigurację centralnie zarządzanej grupy AP6 przeprowadza się w Sophos Fusion, dawniej Sophos Central, a nie w Wireless > Mesh networks na firewallu. Sophos Firewall może nadal pełnić rolę routera i granicy bezpieczeństwa na ścieżce transmisji danych, ale nie staje się kontrolerem AP6. APX i AP6 nie mogą tworzyć wspólnej sieci mesh. Rejestrację i wymagania sieciowe dla tego odrębnego sposobu zarządzania opisuje Wymagania Sophos Central Wireless; szczegółowe planowanie, konfigurację mesh i testy odbiorcze przedstawia Planowanie i konfiguracja mesh AP6. Opisanych tutaj ról APX, przypisań SSID i kroków wycofania konfiguracji nie należy przenosić na AP6.

Model zewnętrzny APX 320X nie jest objęty tą procedurą zarządzania przez Firewall. Wzmianki o starej serii Sophos AP i ręcznym przypisywaniu ról w starszych instrukcjach wyjaśniają działanie historycznych instalacji, a nie nową instalację wspieraną obecnie. Również zintegrowane LocalWiFi i moduły Wi-Fi SD-RED nie są zamiennikami dwóch zewnętrznych APX z przykładu; ich wymagania dotyczące WLAN i modeli należy sprawdzić osobno. Ten artykuł nie rozwija instrukcji UTM ani nie zaleca ich jako sposobu wdrożenia nowej instalacji.

Skrócona procedura:

  1. Najpierw podłączyć oba APX do LAN, zaakceptować w Wireless > Access points i sprawdzić firmware, Country oraz plan radiowy.
  2. Ustawić ten sam stały kanał pasma mesh na wszystkich AP i wyłączyć Dyn chan.
  3. W Wireless > Mesh networks > Add skonfigurować Mesh-ID, Frequency band i APX.
  4. Osobno przypisać widoczne SSID klientów do obu APX.
  5. Zapisać, odłączyć kabel LAN od mesh AP, zrestartować APX i odczekać do pięciu minut.
  6. Kontrolowanie sprawdzić status AP, klienta, DHCP, Rule ID, Internet i awarię ścieżki root.

Kiedy mesh APX ma sens

Mesh pasuje do istniejącej instalacji APX, gdy pojedynczy zdalny AP nie ma Ethernetu, a połączenie radiowe z root AP jest stabilne. Przykładem jest mały magazyn, sala spotkań lub strefa tymczasowa, która później zostanie okablowana.

Ethernet pozostaje lepszy dla stałej wysokiej przepustowości, stabilnych opóźnień i przewidywalnego failover. Backhaul mesh dzieli czas radiowy z innymi transmisjami. Rzeczywistą wydajność należy zmierzyć z docelowymi klientami i aplikacjami, a nie wnioskować z samego statusu linku.

Istotna jest też granica produktu: APX jest End-of-Sale i osiągnie End-of-Life 31 grudnia 2027 r. Dlatego cykl życia APX i AP6 jako następca powinny znaleźć się w planie. AP6 nie jest zarządzany przez SFOS.

Backhaul mesh, SSID klientów i role

Elementy mają różne zadania:

  • Mesh network: ukryty backhaul radiowy między APX. Mesh-ID identyfikuje grupę, a SFOS zarządza losową passphrase WPA2.
  • Root AP: APX z Ethernetem do firewalla. W APX rola wynika automatycznie z okablowania.
  • Mesh AP: APX bez uplinku Ethernet, który dociera radiowo do root AP.
  • Wireless Network: widoczne SSID z Security mode, Client traffic, DHCP i regułami. Podstawy opisuje Konfiguracja WLAN bezpośrednio na Sophos Firewall.

W starszych seriach Sophos AP role root i mesh wybiera się jawnie. Artykuł używa tylko APX i nie przenosi starego ekranu ról do przykładu.

Repeater lub wireless bridge

W trybie repeater mesh AP nadaje przypisane SSID klientów w zdalnej lokalizacji. Endpointy łączą się przez Wi-Fi, a AP przesyła ruch backhaulem do root AP.

W wireless bridge do portu mesh AP podłącza się dodatkowo segment Ethernet. Rozszerza to Layer 2 i przy drugim łączu może tworzyć pętle. Zmiana wymaga okna serwisowego i drogi powrotnej. STP musi pasować do całego projektu switchy i bridge; nie wyłącza się go tylko dlatego, że blokuje ścieżkę.

Dla małych rozszerzeń repeater jest prostszy. Bridge stosuje się tylko, gdy zdalny Ethernet jest potrzebny i znane są konsekwencje broadcast, VLAN i pętli.

Granice przed konfiguracją

  • Wszystkie AP należą do serii APX.
  • Na AP działa tylko jedna sieć mesh.
  • Co najmniej jeden APX pozostaje połączony z firewallem przez LAN.
  • Wszystkie mesh AP używają tego samego kanału pasma mesh.
  • Dynamic Channel Selection lub Dyn chan musi być wyłączony, inaczej po restarcie kanały mogą się różnić.
  • Przy mesh oba radia APX nie mogą jednocześnie używać 5 GHz.
  • AP z VLAN mogą tworzyć mesh tylko, gdy VLAN nie używa Client traffic Bridge to VLAN.
  • Drugi mesh na tym samym AP nie działa.
  • Inny mesh AP nie przejmuje awarii root AP automatycznie i bez przerwy.

Pomoc Sophos podaje 2.4 GHz dla backhaulu i 5 GHz dla SSID klientów jako punkt startowy, nie uniwersalną best practice. Projekt zależy od odległości, ścian, zakłóceń, kanałów, Country i wymaganej przepustowości.

Jak interpretować rozbieżności w dokumentacji: starsza instrukcja wdrożenia wskazuje 5 GHz na root AP i 2.4 GHz na mesh AP; z kolei instrukcja dodawania rozróżnia 5 GHz dla SSID klientów i 2.4 GHz dla backhaulu mesh. Te sformułowania nie mogą prowadzić do ustawienia różnych pasm backhaulu na root AP i mesh AP. W opisanej tutaj procedurze dla istniejącej instalacji oba AP muszą używać tego samego wybranego pasma mesh i tego samego stałego kanału. Przykładowe 2.4 GHz nie jest ustawieniem obowiązkowym; przed wyborem innego pasma należy sprawdzić obsługę przez dany model i build oraz warunki połączenia radiowego. Nadal obowiązuje ograniczenie APX: oba radia nie mogą być jednocześnie skonfigurowane do pracy w paśmie 5 GHz.

Topologia przykładowa

  • Firewall: fw01
  • przewodowy APX: ap-office-root
  • bezprzewodowy APX: ap-warehouse-mesh
  • Mesh-ID: OfficeMesh
  • widoczny Wireless Network: Company WiFi
  • Pasmo mesh: 2.4 GHz
  • Kanał mesh: stały kanał sprawdzony lokalnie

OfficeMesh jest przykładem i wymaga krótkiej, unikalnej nazwy lokalnej. Mesh-ID nie jest widocznym SSID. Company WiFi ma już właściwe Client traffic, DHCP, reguły i NAT.

Przed zmianą przygotować backup, przewodowe zarządzanie i rollback. Oba APX otrzymują PoE i są testowane w zasięgu docelowych miejsc. Root AP musi pozostać osiągalny przez Ethernet.

Przygotowanie AP i kanału

Najpierw provisioning obu APX przez LAN

  1. Podłączyć ap-office-root i ap-warehouse-mesh do sieci zarządzającej.
  2. W Wireless > Wireless settings sprawdzić Wireless Protection i Allowed zone.
  3. W Wireless > Access points zaakceptować oba pending APX przez Accept.
  4. Ustawić prawidłowy Country; po zmianie zapisać i kontrolowanie zrestartować, aby odświeżyć kanały.
  5. Potwierdzić aktywny status i odebranie konfiguracji.

Pierwsze okablowanie jest obowiązkowe. APX bez konfiguracji mesh nie dołączy później wyłącznie radiowo.

Zaplanować również firmware przez Pattern Updates Sophos Firewall. Nie łączyć bez kontroli aktualizacji z przełączeniem mesh.

Wspólny stały kanał

  1. Otworzyć pierwszy APX w Wireless > Access points.
  2. W Advanced settings ustawić lokalnie sprawdzony stały kanał w odpowiednim polu Channel 2.4 GHz lub Channel 5 GHz.
  3. Wyłączyć Dyn chan.
  4. Powtórzyć na drugim APX.
  5. Sąsiednie AP spoza mesh umieścić, jeśli możliwe, na innym mało zakłóconym kanale.

Kanał wybiera się na podstawie skanu, Country i otoczenia. Po każdej zmianie oba mesh AP muszą pokazywać tę samą wartość.

Tworzenie Wireless Mesh w SFOS

Utworzenie sieci mesh

Dla backhaulu mesh należy utworzyć nową, osobną sieć mesh lub nowe SSID mesh; istniejącego widocznego SSID klientów Company WiFi nie należy przekształcać w sieć mesh. Pomoc używa w tym kontekście zarówno określenia Mesh-ID, jak i mesh-enabled SSID. Jeśli dostępny interfejs oferuje Enable mesh mode tylko podczas tworzenia nowego SSID, tę udokumentowaną starszą procedurę należy stosować wyłącznie po potwierdzeniu obsługi przez dany model i build, pozostawiając SSID klientów oddzielnie. Na każdy AP przewidziana jest tylko jedna sieć mesh. Wszystkie uczestniczące AP muszą otrzymać ten sam Mesh-ID; współdzielą losowo wygenerowaną przez SFOS frazę hasła WPA2-Personal. Nie jest to hasło sieci WLAN klientów.

  1. Otworzyć Wireless > Mesh networks.
  2. Wybrać Add.
  3. Wpisać OfficeMesh jako Mesh-ID.
  4. W Frequency band wybrać wspólne pasmo, w przykładzie 2.4 GHz.
  5. Dodać ap-office-root i ap-warehouse-mesh.
  6. Zapisać.

W APX nie przypisuje się roli ręcznie. Gdy oba są przewodowe, odbierają konfigurację. Po odłączeniu ap-warehouse-mesh, ap-office-root pozostaje root dzięki Ethernetowi.

Przypisanie widocznego SSID klientów

Mesh nie jest widoczny dla endpointów. W Wireless > Access points lub Access Point Group przypisać Company WiFi do obu APX.

SSID zachowuje własne Security mode i Client traffic. Dla Separate zone muszą działać Wireless interface, DHCP, reguła, NAT i Device Access. Mesh nie naprawia brakującej reguły ani DHCP.

Przeniesienie mesh AP

  1. Potwierdzić konfigurację i SSID na obu APX.
  2. Odłączyć Ethernet tylko od ap-warehouse-mesh.
  3. Pozostawić ap-office-root przewodowo.
  4. Umieścić mesh AP w miejscu docelowym i włączyć go; uruchomi się już bez Ethernetu.
  5. W kontrolowany sposób uruchomić ponownie root AP. Jeśli podczas przenoszenia mesh AP nie został odłączony od zasilania, teraz uruchomić ponownie również ten AP.
  6. Czekać do pięciu minut.

Normalnie tylko jeden APX pozostaje w LAN. Jeśli drugi przypadkiem trafi do tego samego Layer 2, sprawdzić pętle i STP.

Kontrolowana walidacja

  1. W Wireless > Access points oba APX są aktywne; root ma kabel, mesh działa bez Ethernetu.
  2. Sprawdzić mesh i identyczny kanał.
  3. Połączyć klienta przy ap-warehouse-mesh z Company WiFi.
  4. W Wireless > Wireless client list wyświetlić klienta testowego według AP lub SSID i sprawdzić, czy jest połączony z oczekiwanym mesh AP oraz z Company WiFi. Zanotować siłę sygnału i częstotliwość, a następnie ponownie sprawdzić je w podobnych warunkach podczas porównania z root AP; sama wyświetlana częstotliwość połączenia klienta nie potwierdza pasma backhaulu.
  5. Porównać adres IP, gateway i DNS klienta z planowaną konfiguracją Wireless Network.
  6. Przetestować cel dozwolony i blokowany.
  7. W Log Viewer filtrować wpisy według adresu IP klienta testowego i sprawdzić, czy Firewall Rule ID i NAT Rule ID odpowiadają oczekiwanym regułom.
  8. Porównać throughput i latency z klientem przy root AP.

Zielony status nie dowodzi całej ścieżki. Klient musi używać właściwego AP, adresacji i reguł z odpowiednią wydajnością. Zobacz Testowanie reguł firewalla.

Świadomy test granicy awarii

Root AP jest zależnością. W oknie serwisowym krótko odłączyć uplink i udokumentować przerwę. SFOS nie gwarantuje automatycznej zmiany root. Mesh AP może wymagać restartu i kabla.

Nie wyłączać nieplanowanie produkcyjnego root. Dla stref krytycznych użyć uplinku przewodowego lub innej architektury.

Bezpieczna interpretacja obiektu mesh w XML API

Referencje XML dla SFOS 22 i 23 opisują Add Mesh Networks i Update Mesh Networks dla obiektu WirelessMeshNetworks. Jest to udokumentowana struktura obiektu, a nie dodatkowe dopuszczenie sprzętu do obsługi: opisany powyżej zakres dotyczący istniejących urządzeń APX, weryfikacja modelu/builda oraz odrębna ścieżka zarządzania AP6 pozostają bez zmian. Ochronę dostępu, jawnie określone operacje, odpowiedzi XML i bezpieczne ponawianie wyjaśnia artykuł Zabezpieczanie dostępu do Sophos Firewall XML API.

Rozróżnianie MeshID, pasma i roli AP

Przy przygotowywaniu automatyzacji należy rozróżniać następujące pola:

  • MeshID jest obowiązkowym skalarnym ciągiem znaków o długości maksymalnie dziesięciu znaków. OfficeMesh nadaje się jako krótka przykładowa nazwa; nadal jest to identyfikator połączenia backhaul, a nie widoczny identyfikator SSID dla klientów. Dodatkowego znacznika referencyjnego APINTERFACENAME nie należy interpretować jako oczywistej reguły dotyczącej znaków ani jako tożsamości AP; dopuszczalny zapis należy potwierdzić w zainstalowanym buildzie.
  • FrequencyBand jest obowiązkowe i dopuszcza wyłącznie 5GHz lub 2.4GHz. Tabela podaje 5 GHz jako udokumentowaną wartość domyślną, a nie jako zalecenie dla każdej ścieżki radiowej. Łączny zapis 5GHz/2.4GHz z przykładu w referencji nie znajduje się na liście dozwolonych wartości i nie jest przyjmowany jako pojedyncza wartość pola. Wszystkie uczestniczące AP nadal wymagają tego samego potwierdzonego pasma backhaul i tego samego stałego kanału; Dyn chan pozostaje wyłączone w tym paśmie.
  • Description jest opcjonalnym skalarnym ciągiem znaków. Pusty element w przykładzie nie dowodzi, jak aktualizacja traktuje istniejący opis.
  • AccessPoints zawiera w przykładzie XML element MeshNetwork; w nim razem występują AccessPoint i Role. Tabela parametrów opisuje oba pola jako opcjonalne tablice z wieloma wartościami i wskazuje, że duplikaty nie są ignorowane. Nie należy na tej podstawie wnioskować ani o dwóch listach, które można dowolnie sortować niezależnie od siebie, ani o automatycznej deduplikacji. Tożsamość AP i przypisaną do niego rolę należy wspólnie zweryfikować względem istniejącej konfiguracji oraz API help danego builda.
  • Dla Role udokumentowano dokładnie MeshAccessPoint i RootAccessPoint; tabela podaje Root Access Point jako wartość domyślną. Te wartości XML pochodzą z referencji API, a nie z terminów Root, Mesh lub Repeater używanych w GUI. W szczególności automatyczne określanie roli APX na podstawie Ethernetu nie stanowi dowodu na to, czy Role w konkretnym payloadzie APX należy ustawić, pominąć czy obsłużyć inaczej. Przy niewyjaśnionym przyporządkowaniu modelu/builda nie należy wysyłać żądania zapisu.

Poniższy ograniczony fragment struktury XML nie jest wykonywalnym żądaniem ani przypisaniem roli APX. Pokazuje jedynie udokumentowane zagnieżdżenie z wartością referencyjną dla Role; AP_IDENTITAET_AUS_API_HELP jest symbolem zastępczym, którego nie wolno wysyłać. Tożsamość AP30 z przykładu producenta nie jest przejmowana jako przykład APX:

<WirelessMeshNetworks>
  <MeshID>OfficeMesh</MeshID>
  <FrequencyBand>2.4GHz</FrequencyBand>
  <Description />
  <AccessPoints>
    <MeshNetwork>
      <AccessPoint>AP_IDENTITAET_AUS_API_HELP</AccessPoint>
      <Role>RootAccessPoint</Role>
    </MeshNetwork>
  </AccessPoints>
</WirelessMeshNetworks>

Przed zmianą należy odczytać faktycznie zapisaną konfigurację sieci mesh wraz z identyfikatorem mesh, tożsamościami AP, przypisaniami i parametrami radiowymi, wykonać jej kopię i porównać ją z planowanym stanem docelowym. Fragment nie zawiera ani logowania, ani operacji i nie zastępuje potwierdzonego kompletnego payloadu. Ze struktury XML nie wynika ani bezpieczeństwo ponowienia, ani działające połączenie radiowe; nadal konieczna jest odrębna weryfikacja odbiorcza statusu AP, identyfikatora SSID dla klientów, DHCP i ścieżki transmisji danych użytkowych.

Rozróżnianie odpowiedzi według operacji, kodu i symbolu

Referencje przypisują obu operacjom następujące kody statusu XML i dosłowne klucze Message.*. Klucze nie zostały rozwinięte: nie są potwierdzonymi komunikatami z czasu wykonania i nie są tłumaczone na domniemane teksty komunikatów o błędach. Przyporządkowanie właściwe dla tego obiektu należy zweryfikować z API help zainstalowanego builda; w szczególności nie należy interpretować tutaj 521 i 522 wyłącznie na podstawie ogólnej tabeli statusów w głównym artykule o API.

Add Mesh Networks:

  • 200: Message.WLANAPAddSuccessful.
  • 500: Message.WLANAPAddFailed.
  • 501: Message.WLANAPIPAlreadyInUsed.
  • 504: Message.WLANAPIntBaseVHExist.
  • 521: Message.WLANAPAddRunConfigFailed.
  • 522: Message.WLANAccessPointUnbound.

Update Mesh Networks:

  • 200: Message.WLANAPEditSuccessful.
  • 500: Message.WLANAPEditFailed.
  • 501: Message.WLANAPIPAlreadyInUsed.
  • 504: Message.WLANAPIntBaseVHExist.
  • 511: Message.WLANAPFailedWhileUnbinding.
  • 512: Message.WLANAPFailedWhileDeleteDHCPServer.
  • 513: Message.WLANAPFailedWhileDeleteDHCPRelay.
  • 516: Message.WLANAPFailedToUnbindInterface.
  • 520: Message.WLANAPFailedToUnbindIfaceRCg.
  • 521: Message.WLANAPEditRunConfigFailed.
  • 523: Message.WLANAPWLAN1UnboundEditFaild.
  • 524: Message.WLANAPOtherUnboundEditFaild.

Również pisownia Faild pozostaje zachowana dokładnie. Z nazw symboli nie należy wnioskować o potwierdzonej przyczynie, całkowitym wycofaniu zmiany ani o już usuniętej zależności DHCP/interfejsu. Po niejasnej odpowiedzi lub odpowiedzi wskazującej niepowodzenie należy najpierw porównać faktycznie zapisany stan mesh i AP oraz zależne konfiguracje sieci bezprzewodowej, interfejsów i DHCP z zachowanym stanem początkowym; na potrzeby wyjaśnienia należy zachować odpowiedź po usunięciu danych wrażliwych oraz logi. Dopiero po wyjaśnieniu kwestii specyficznych dla builda należy zdecydować o kolejnej zmianie, zamiast automatycznie powtarzać tę samą operację Add lub Update. Również 200 nie zastępuje ani ponownego odczytu obiektu docelowego, ani opisanej powyżej weryfikacji odbiorczej łączności radiowej i klientów.

Diagnostyka według objawu

Mesh AP nie pojawia się lub jest offline

Odczekać pięć minut. Sprawdzić, czy podczas provisioning LAN był aktywny i odebrał konfigurację. Potem serię APX, przypisanie, pasmo, kanał, Dyn chan, Country i zasilanie.

Root pozostaje przewodowy. Jeśli oba są bezprzewodowe lub odłączono zły AP, brakuje ścieżki do firewalla. Poprawić, zrestartować i czekać.

Jeśli w starszej procedurze przy istniejącym SSID brakuje opcji Enable mesh mode, utworzyć nowy SSID zamiast zmieniać przeznaczenie widocznego SSID klientów. Gdy przyczyna nadal jest niejasna, w oknie serwisowym odizolować ścieżkę: na root AP nadawać tylko sieć mesh, a na repeaterze tylko widoczne SSID klientów. Jeśli SSID klientów pojawia się na repeaterze, wskazuje to na nadawanie skonfigurowanej sieci klientów, ale nie stanowi jeszcze pełnego potwierdzenia działania backhaulu ani dostępu do Internetu. Należy dodatkowo sprawdzić, czy repeater jest rzeczywiście osiągalny bez uplinku LAN, czy klient testowy widnieje na liście klientów tego AP oraz czy działają oczekiwana obsługa DHCP i dozwolona ścieżka transmisji danych. Następnie przywrócić zwykłe przypisania. Jeśli mesh nadal jest niedostępny, sprawdzić, czy STP nie blokuje konfiguracji mesh. Nie wyłączać STP bez wyraźnej przyczyny, ponieważ zapobiega ono pętlom w topologiach bridge.

SSID klientów nie jest widoczne

Mesh-ID nie jest SSID klientów. W Wireless > Access points przypisać dodatkowy widoczny Wireless Network. Sam OfficeMesh nie jest widoczny.

Sprawdzić Frequency band, harmonogram, Security mode i AP. Drugi mesh nie pomoże, ponieważ dozwolony jest jeden.

Klient łączy się bez adresu IP

W tej sytuacji połączenie radiowe między klientem a AP już częściowo działa. Następnie sprawdzić ustawienie Client traffic, interfejs Wireless interface, serwer DHCP lub DHCP relay oraz możliwe ścieżki przez VLAN. Przy Bridge to VLAN uwzględnić także ograniczenie produktu: AP przypisane do VLAN mogą tworzyć mesh tylko wtedy, gdy te VLAN nie korzystają z tego trybu Client traffic.

Restart usługi bezprzewodowej (wireless service) nie jest standardowym krokiem diagnostycznym. Najpierw ustalić, z którym AP klient jest rzeczywiście połączony, i sprawdzić, czy żądania DHCP docierają oczekiwaną ścieżką.

Klient ma IP bez Internetu

W Log Viewer filtrować wpisy według adresu IP klienta testowego i najpierw poszukać oczekiwanych Firewall Rule ID i NAT Rule ID. Jeśli brakuje obu identyfikatorów, przyczyna jest bardziej prawdopodobna w konfiguracji strefy, obiektu sieciowego, kolejności reguł lub ścieżki danych niż w samym mesh. Jeśli identyfikatory odpowiadają oczekiwanym regułom, następnie sprawdzić DNS, gateway i ścieżkę do WAN.

Nie używać szerokiej reguły Any do diagnozowania mesh. Wykonać ten sam test klienta raz przy root AP, a następnie przy mesh AP. Jeśli test powiedzie się tylko przy root AP, dalej zbadać backhaul. Jeśli nie powiedzie się przy obu AP, problem prawdopodobnie dotyczy wspólnej konfiguracji WLAN lub firewalla.

Połączenie jest niestabilne lub wolne

Sprawdzić kanał, wyłączony Dyn chan, sygnał, zakłócenia, odległość i ściany. AP spoza mesh nie powinny niepotrzebnie zajmować kanału. Musi zostać pojemność dla backhaulu i klientów.

Porównać tę samą aplikację i klienta w podobnych warunkach przy root i mesh, aby oddzielić problem WAN, DNS lub klienta.

Status kontrolera lub klienta jest niejasny

Logi usług Sophos Firewall pomagają w diagnostyce lokalnej na danym węźle. W Advanced Shell można wykonać poniższe polecenia, które jedynie odczytują logi:

tail -n 200 /log/awed.log
tail -n 200 /log/wc_remote.log

awed.log pokazuje komunikację między kontrolerem a APX; wc_remote.log pomaga w diagnostyce klientów bezprzewodowych. Pojedynczy wpis w logu nie potwierdza działania ścieżki danych użytkownika. Należy zestawić znaczniki czasu, status AP, listę klientów i logi firewalla z powtarzalnym testem ruchu. Diody i kody AP Sophos dodatkowo pomagają rozpoznać na urządzeniu stany uruchamiania, aktualizacji i mesh.

Bezpieczny rollback

Podczas wycofywania konfiguracji należy rozróżniać SSID mesh i SSID klientów: starsza pomoc opisuje wyłączenie mesh przez usunięcie SSID mesh. Chodzi o powiązany obiekt konfiguracji mesh, a nie automatycznie o widoczne SSID klientów Company WiFi. Przed usunięciem należy zweryfikować Mesh-ID, przypisania AP i zależności, wykonać kopię zapasową konfiguracji oraz zapewnić dostęp do AP przez przewidziane połączenie kablowe. Usunięcie backhaulu odłączy AP połączone bezprzewodowo; usunięcie nadal potrzebnego SSID klientów dodatkowo odłączy użytkowników tej sieci WLAN. Zależnie od wersji starszego interfejsu konfigurację wycofuje się przez usunięcie sieci mesh lub jej SSID mesh. Jeśli nie można jednoznacznie ustalić powiązań, nie należy niczego usuwać na próbę — najpierw trzeba wyjaśnić konfigurację konkretnego modelu i buildu.

  1. Udokumentować root i mesh APX.
  2. Podłączyć mesh AP przez LAN i czekać na aktywność.
  3. W razie potrzeby przenieść SSID na przewodowy AP.
  4. Usunąć mesh z APX lub w Wireless > Mesh networks.
  5. Kanał i Dyn chan przywrócić świadomie.
  6. Zrestartować oba APX.
  7. Ponownie sprawdzić IP, DNS, reguły i Internet.

Reset fabryczny ma sens dopiero, gdy APX mimo poprawnego kabla, zasilania i kontrolera nie przyjmuje konfiguracji. Nie zastępuje rollbacku.

Checklista operacyjna

  • Wszystkie urządzenia to kompatybilne APX, najpierw provisionowane przez LAN.
  • Na AP przypisano dokładnie jeden mesh.
  • Jeden APX pozostaje przewodowym root.
  • Pasmo i kanał są identyczne.
  • Dyn chan jest wyłączony.
  • Widoczne SSID przypisano osobno.
  • Sprawdzono DHCP, Firewall Rule ID, NAT Rule ID i blokowany cel.
  • Porównano wydajność i stabilność.
  • Udokumentowano awarię root, brak takeover i rollback.
  • Zaplanowano End-of-Life APX i zmianę platformy.

FAQ

Czy Mesh-ID jest widocznym SSID WLAN?

Nie. Mesh-ID należy do ukrytego backhaulu. Klienci potrzebują też Wireless Network z widocznym SSID, zabezpieczeniami, Client traffic i regułami.

Czy drugi APX automatycznie przejmie root AP?

Nie. Sophos nie dokumentuje automatycznego takeover. Co najmniej jeden AP pozostaje przewodowy; odzyskanie może wymagać restartu lub okablowania.

Dlaczego wszystkie APX muszą być najpierw w LAN?

Każdy APX musi zostać zaakceptowany i odebrać konfigurację mesh. Dopiero potem mesh AP jest odłączany, uruchamiany docelowo i łączy się przez root AP.