Konfiguracja i testowanie WLAN bezpośrednio w Sophos Firewall

Sieć WLAN zarządzaną bezpośrednio w Sophos Firewall tworzy się w Wireless > Wireless networks. Samo utworzenie SSID jednak nie wystarcza: wybrany tryb ruchu określa, czy klienci otrzymają własną sieć, znajdą się w sieci LAN punktu dostępowego, czy zostaną dołączeni mostem do sieci VLAN. Następnie konfiguracje DHCP, reguł zapory, NAT oraz przypisania do punktu dostępowego muszą być ze sobą zgodne.

⚠️ Ważne: Ta instrukcja dotyczy wyłącznie sprzętu WLAN zarządzanego bezpośrednio przez Sophos Firewall. Punktami dostępowymi AP6 nie można zarządzać przez SFOS. W przypadku wielu urządzeń AP6 przewidzianym i zalecanym sposobem zarządzania jest Sophos Fusion (dawniej Sophos Central); pojedynczy AP6 można alternatywnie skonfigurować za pomocą jego lokalnego interfejsu. Dlatego funkcja Wireless zarządzana przez zaporę ma obecnie zastosowanie przede wszystkim w istniejących instalacjach APX, w zintegrowanym LocalWiFi modeli desktopowych W oraz z obsługiwanymi modułami Wi-Fi w urządzeniach Sophos Firewall lub SD-RED. Firmware urządzeń APX zarządzanych przez SFOS jest udostępniany poprzez aktualizacje wzorców zapory i instalowany świadomie.

W tej instrukcji wykorzystano sieć WLAN dla gości z trybem Separate zone. Jest to zrozumiały przykład, ponieważ sieć klientów, reguły i dozwolone cele można jednoznacznie oddzielić od wewnętrznej sieci LAN.

Jeśli sieć Wi-Fi 802.1X korzysta z RADIUS, a firewall ma rozpoznawać użytkowników bez dodatkowego captive portalu, RADIUS SSO z accountingiem opisuje oddzielną ścieżkę accountingu, wymagany Framed-IP-Address i test w Live users.

Skrócona procedura:

1. Przygotować Wireless Protection i strefę punktu dostępowego w Wireless > Wireless settings.
2. Zaakceptować punkt dostępowy w Wireless > Access points.
3. Utworzyć SSID, zabezpieczenia i sieć klientów w Wireless > Wireless networks.
4. Uzupełnić DHCP, regułę zapory i NAT w Network > DHCP oraz Rules and policies.
5. Przypisać Wireless Network do punktu dostępowego i za pomocą klienta testowego sprawdzić IP, DNS, Rule ID oraz niepożądany dostęp do sieci wewnętrznych.

Czy ta instrukcja pasuje do punktu dostępowego?

SFOS 22 może zarządzać punktami dostępowymi serii APX do zastosowań wewnętrznych, zintegrowaną siecią WLAN zgodnego XGS Appliance oraz zgodnymi modułami rozszerzeń Wi-Fi w urządzeniach Sophos Firewall lub SD-RED. W przypadku zewnętrznych urządzeń APX dotyczy to modeli APX 120, APX 320, APX 530 i APX 740. Model zewnętrzny APX 320X i starsza seria AP nie są zarządzane bezpośrednio przez aktualną zaporę Sophos Firewall.

AP6 nie należy do tej procedury. AP6 konfiguruje się przez Sophos Fusion, a pojedyncze urządzenie również za pomocą jego lokalnego interfejsu. Dla wariantu Fusion odpowiednie są wymagania Sophos Central Wireless.

Lokalna funkcja Wireless jest częścią Sophos Firewall Base License. Dodatkowo potrzebny jest zgodny punkt dostępowy. Seria APX jest już jednak End-of-Sale i osiągnie End-of-Life 31 grudnia 2027 r. Ta instrukcja pomaga więc przede wszystkim bezpiecznie eksploatować istniejące instalacje APX. W przypadku nowej platformy WLAN należy uwzględnić End-of-Life serii APX i AP6 jako jej następcę albo zaplanować inne aktualne systemy WLAN.

Granica wersji: Pomoc Wireless zawiera odpowiednie procedury zarówno dla SFOS 22, jak i dla SFOS 23. Istnienie strony pomocy SFOS 23 nie dowodzi jednak obsługi konkretnego modelu APX w SFOS 23. Obsługę sprzętu należy potwierdzić niezależnie na podstawie Retirement Calendar i macierzy obsługi. Przed aktualizacją należy zatem sprawdzić model, rewizję sprzętową i docelowy build w macierzy obsługi; nie migrować istniejących APX do SFOS 23 wyłącznie na podstawie tej instrukcji. Zintegrowany WLAN i moduły SD-RED również muszą odpowiadać konkretnemu modelowi i buildowi. W przypadku nowych zewnętrznych punktów dostępowych obowiązuje procedura zarządzania AP6, do której odsyła powyższy link, a nie ta procedura SFOS-APX.

Aby połączyć istniejący APX bez Ethernetu przez przewodowy APX, konfiguracja i test Wireless Mesh na Sophos Firewall opisują root AP, kanał, ukryty backhaul i kontrolowaną walidację.

SD-RED z modułem Wi-Fi: Pomoc Wireless dokumentuje DHCP option 234 na potrzeby komunikacji modułu SD-RED używanego jako punkt dostępowy z Sophos Firewall. Nie jest to ani DHCP klientów gościnnej sieci Wi-Fi, ani ogólny wymóg dla APX lub AP6. Pomoc wspomina przy tym także o Sophos UTM; nie stanowi to tutaj nowej instrukcji instalacji UTM. Przed zmianami należy ustalić zgodność modułu, DHCP do zarządzania i faktycznie używany kontroler; nie przejmować wartości opcji z innego typu urządzenia. Konfiguracja SD-RED to osobna procedura podłączania lokalizacji.

Wybór właściwego trybu Client traffic

Wybór w sekcji Client traffic jest ważniejszy niż nazwa SSID. Określa on, czy klienci znajdują się w tym samym lokalnym segmencie sieci na warstwie 2, kto przydziela adresy IP i jaki ruch w ogóle przechodzi przez zaporę.

Separate zone

Separate zone tworzy własny interfejs Wireless z osobnym adresem IP oraz tunel VXLAN między punktem dostępowym a zaporą. Klienci otrzymują własną podsieć. Dzięki temu dostęp dla poszczególnych sieci WLAN można kontrolować za pomocą precyzyjnych reguł WiFi-to-WAN lub WiFi-to-LAN. Współdziałanie strefy, interfejsu i obiektu sieciowego wyjaśnia artykuł Strefy i interfejsy Sophos Firewall.

Ten tryb dobrze nadaje się dla gości, IoT lub innych sieci, które należy oddzielić od wewnętrznej sieci LAN. Hotspot z Captive Portal, hasłem dziennym lub kuponem również wymaga Separate zone. Pełny proces z definicją vouchera, portalem i automatyczną regułą opisano w artykule Konfiguracja hotspotu Sophos Firewall.

VXLAN zmniejsza użyteczną wartość MTU. Duże pakiety mogą przez to powodować fragmentację lub spadek wydajności. Nie należy więc profilaktycznie zmieniać MTU na arbitralną wartość. Najpierw sprawdza się, czy zawodzą tylko duże transfery albo czy pakiety TCP są przesyłane ponownie, czyli występują retransmisje. Kontrolowaną procedurę opisuje artykuł Sprawdzanie MTU i MSS w Sophos Firewall.

Bridge to AP LAN

Bridge to AP LAN umieszcza klientów WLAN w tej samej sieci co punkt dostępowy. Adresy klientów przydziela istniejący serwer DHCP tej sieci LAN. Jest to wygodne, ale nie zapewnia osobnej granicy sieciowej dla gości ani niezaufanych urządzeń.

Decydująca jest ścieżka danych: komunikacja w tej samej podsieci może odbywać się bezpośrednio między klientem, punktem dostępowym i przełącznikiem, całkowicie omijając Sophos Firewall. Reguła zapory w SFOS może kontrolować wyłącznie ruch rzeczywiście routowany przez zaporę.

Aby w zintegrowanej sieci WLAN dopuścić tylko znaną listę urządzeń, należy utworzyć listę adresów MAC w Hosts and services > MAC host. Następnie w sieci Wireless wybrać Allow list w Advanced settings > MAC filtering i przypisać tę listę. Hasło musi mieć od 8 do 63 znaków. Podczas weryfikacji należy połączyć jedno urządzenie znajdujące się na liście i jedno spoza niej.

Adres MAC można jednak podszyć. Allow list jest więc tylko dodatkowym filtrem dostępu i nie zastępuje WPA2 Personal z AES, obsługiwanej metody WPA3, silnego hasła ani właściwej segmentacji sieci.

Jeśli Bridge to AP LAN jest używany ze zintegrowanym LocalWiFi, sieć WLAN trzeba dodatkowo połączyć z przewodową siecią LAN. Właściwy sposób zależy od modelu XGS Appliance:

• Gen.1 – XGS 87w, 107w, 116w, 126w i 136w: W Network > Interfaces > Add interface > Add bridge tworzy się interfejs bridge. Name to nazwa wyświetlana, którą można później zmienić i która może mieć maksymalnie 58 znaków; Hardware name może mieć maksymalnie 10 znaków z zestawu A-Za-z0-9_ i po zapisaniu nie można jej zmienić. W Member interfaces przypisać interfejsowi Wireless strefę WiFi, a wybranemu portowi Ethernet strefę LAN. W razie potrzeby do tego interfejsu bridge można dodać kolejne porty Ethernet.

  Następnie wybrać IPv4 configuration, wprowadzić planowany IPv4 address interfejsu bridge w istniejącej sieci LAN i wybrać odpowiednią maskę podsieci. Adres i maska muszą pochodzić z własnego planu adresacji LAN, a nie z sieci gościnnej Separate zone opisanej dalej. Przed Save sprawdzić, czy adres nie jest przypisany innemu urządzeniu ani jednocześnie interfejsowi członkowskiemu oraz czy nie znajduje się bez rezerwacji w dynamicznym zakresie DHCP. Nie zmieniać przy okazji istniejącej bramy klientów ani planu adresacji DHCP. Przed zmianą sprawdzić kopię zapasową, zależności portów i niezależny dostęp administracyjny; procedura konfiguracji interfejsu bridge wyjaśnia te wspólne kontrole i zarezerwowane nazwy sprzętowe. Przykład przezroczystego mostu inline bez adresu IP służy tam innemu celowi: ta udokumentowana procedura LocalWiFi Gen.1 używa adresu IPv4 na interfejsie bridge, ale nie każdy most potrzebuje adresu IP. Zapisać przyciskiem Save dopiero po tych kontrolach.

• Gen.2 – XGS 88w, 108w, 118w i 128w: Interfejs Wireless nie może być członkiem fizycznego interfejsu bridge. Zamiast tego w Wireless > Access points > LocalWiFi > Advanced settings należy włączyć opcję Bridge to Ethernet, wybrać dokładnie jeden port Ethernet i ustawić strefę LAN.

  W przypadku Bridge to Ethernet wybrany port fizyczny musi mieć adres IP i nie może być portem WAN ani członkiem innego mostu. Nie można w ten sposób połączyć interfejsu VLAN mostem z LocalWiFi; strefa mostu również nie może być WAN. Funkcja dotyczy wyłącznie IPv4 i SSID typu Bridge to AP LAN. SFOS korzysta z istniejącego serwera DHCP portu mostu; jeśli go nie ma, pomoc dokumentuje automatyczne utworzenie nowego. Przed zapisaniem należy więc sprawdzić, czy w sieci LAN jest już serwer DHCP, a następnie sprawdzić serwer, pulę i dzierżawę, aby uniknąć konkurencyjnych odpowiedzi DHCP. Po wyłączeniu most zostaje usunięty, a konfiguracja zostaje przywrócona na interfejs fizyczny. Należy zatem wcześniej zapisać stan początkowy i podczas okna serwisowego sprawdzić wycofanie zmian wraz z dostępem administratora, DHCP w sieci LAN i połączeniem klientów.

Zewnętrzny APX nie wymaga tego dodatkowego interfejsu bridge LocalWiFi. Podczas wymiany sprzętu fizycznego interfejsu bridge Wireless z Gen.1 nie można też przenieść bez zmian na Gen.2. Wymagane przygotowanie opisuje artykuł Backup i przywracanie Sophos Firewall.

Bridge to AP LAN należy wybierać tylko wtedy, gdy WLAN i przewodowa sieć LAN mają świadomie należeć do tego samego obszaru bezpieczeństwa.

W tej procedurze LAN zapisać Wireless Network przyciskiem Save po wybraniu Bridge to AP LAN, ustawień zabezpieczeń i listy MAC. W Wireless > Access points > LocalWiFi sprawdzić prawidłowy Country, przypisać dokładnie tę sieć w Wireless networks > Add new item i zapisać; opisane dalej Guest WiFi to osobny przykład. Po konfiguracji interfejsu bridge urządzenie testowe z listy musi móc się połączyć, a urządzenie spoza listy musi zostać odrzucone. Na dopuszczonym kliencie sprawdzić dzierżawę z planowanego zakresu LAN, odpowiednią maskę podsieci, dotychczasową bramę i przewidziane serwery DNS; potwierdzić dzierżawę na serwerze DHCP faktycznie obsługującym tę sieć LAN. Przetestować rozwiązywanie nazw i zamierzoną usługę na urządzeniu przewodowej sieci LAN. Jeśli klient nie otrzyma dzierżawy, najpierw sprawdzić dopuszczenie adresu MAC, przypisanie sieci, interfejsy członkowskie mostu i DHCP sieci LAN. Lokalna komunikacja w LAN jest tutaj zamierzona i nie dowodzi izolacji gości ani ścieżki danych kontrolowanej przez SFOS.

Bridge to VLAN

Bridge to VLAN oddziela sieć zarządzającą punktu dostępowego od sieci VLAN klientów. Port przełącznika prowadzący do punktu dostępowego musi przenosić obie sieci jako trunk. W profilu WLAN pole Bridge to VLAN ID oznacza sieć VLAN klientów. Przy uwierzytelnianiu Enterprise identyfikator VLAN klienta może być określany statycznie albo przez RADIUS ze statyczną wartością rezerwową.

Punkt dostępowy powinien być początkowo połączony z zaporą przez co najmniej minutę za pośrednictwem domyślnej, nietagowanej sieci LAN, aby otrzymać konfigurację. Następnie w Wireless > Access points > AP > Advanced settings włącza się VLAN tagging i wprowadza AP VLAN ID dla sieci zarządzającej. Dopiero wtedy port przełącznika konfiguruje się jako trunk. Sieć VLAN zarządzania AP i sieć VLAN klientów mogą używać różnych identyfikatorów. Sophos zaleca, aby nie łączyć Separate zone i sieci WLAN opartych na VLAN na tym samym punkcie dostępowym. Tagowanie VLAN po stronie AP nie jest dostępne dla zintegrowanego LocalWiFi0.

Po włączeniu tej opcji punkt dostępowy przez 60 sekund próbuje uzyskać adres z DHCP w skonfigurowanej sieci VLAN zarządzania. Jeśli nie otrzyma odpowiedzi, wraca do DHCP w nietagowanej sieci LAN. Jest to przydatna ścieżka odzyskiwania, ale nie kryterium sukcesu: VLAN, trunk i DHCP należy poprawić tak, aby punkt dostępowy rzeczywiście działał przez zaplanowaną sieć VLAN zarządzania. W trybie Bridge to VLAN SFOS automatycznie tworzy interfejs VLAN i odpowiadające mu reguły firewalla. Obiekty te trzeba sprawdzić, ponieważ każdy punkt dostępowy tworzy osobny interfejs backendowy dla każdej strefy, a projekt z wieloma punktami dostępowymi i strefami może szybko się rozrosnąć.

Strefa interfejsu zapory dla sieci VLAN zarządzania AP musi być dozwolona w Wireless > Wireless settings > Allowed zone. Tryb ruchu klientów i VLAN tagging po stronie AP muszą być zgodne: Bridge to VLAN wymaga tagowania na AP; w przypadku Separate zone może ono być włączone lub wyłączone. Starsza pomoc dotycząca VLAN określa inny przypadek jako bridge to an access point VLAN i wymaga w nim wyłączonego tagowania na AP. Z tego sformułowania nie należy wywodzić dodatkowej opcji w aktualnym interfejsie użytkownika. W opisanej tutaj nietagowanej procedurze Bridge to AP LAN należy pozostawić tagowanie na AP wyłączone; w przypadku innego projektu przed przełączeniem potwierdzić zgodność na rzeczywistym modelu i kompilacji.

Bridge to VLAN pozwala uniknąć ścieżki VXLAN i często lepiej nadaje się do większych, już prawidłowo segmentowanych środowisk WLAN. Również w tym przypadku ruch wewnątrz sieci VLAN klientów nie jest automatycznie kontrolowany przez SFOS.

Przygotowanie przykładowej sieci

W przykładzie użyto następujących wartości:

• Nazwa w SFOS: Guest WiFi
• niezmienna wartość Hardware name: GuestWiFi
• widoczna SSID: Company Guest
• Security mode: WPA2 Personal
• Client traffic: Separate zone
• Strefa: WiFi
• Sieć klientów: 10.30.40.0/24
• Interfejs i brama: 10.30.40.1
• Zakres DHCP: od 10.30.40.100 do 10.30.40.220
• Reguła zapory: WiFi_Guest_to_WAN

10.30.40.0/24 jest przykładem z prywatnej przestrzeni adresowej. Przed zastosowaniem należy wybrać wolną podsieć, która nie nakłada się na LAN, VPN, RED, VLAN ani sieć zdalnej lokalizacji. Pierwszy użyteczny adres 10.30.40.1 należy w przykładzie do interfejsu Wireless zapory i jest rozsyłany jako brama.

Dla istniejących urządzeń APX bezpieczną i zgodną podstawą jest WPA2 Personal z AES. Długie, unikatowe hasło należy przechowywać w menedżerze haseł, a nie w zgłoszeniach ani na zrzutach ekranu. W SFOS 22 Sophos dokumentuje tryby WPA3 tylko dla zintegrowanej sieci WLAN modeli XGS 88w, 108w, 118w i 128w. Dlatego nie należy planować WPA3 dla APX.

Lista zabezpieczeń zawiera także No Encryption, WEP Open, starsze tryby WPA i tryby mieszane WPA/WPA2. Te pozycje nie stanowią zalecenia dla nowej lub modernizowanej sieci Wi-Fi: nie używać niezaszyfrowanego profilu gościnnego ani mechanizmu awaryjnego WEP/TKIP, lecz wymienić niezgodne urządzenia klienckie lub migrować je osobno. Na XGS 88w, 108w, 118w i 128w można zapisać profile z TKIP lub AES/TKIP, ale nie można przypisać ich do LocalWiFi0. W tych modelach należy wybrać najsilniejszy tryb WPA3 obsługiwany przez wszystkie przewidziane urządzenia klienckie albo WPA2 Personal z AES i faktycznie przetestować połączenie.

Konfiguracja sieci WLAN zarządzanej przez SFOS

1. Zezwolenie na połączenie punktu dostępowego

W przypadku zewnętrznego APX sieć zarządzająca i sieć klientów WLAN to dwie różne rzeczy. Punkt dostępowy pobiera własny adres zarządzający przez DHCP z sieci, do której jest podłączony. Późniejsi klienci WLAN otrzymują natomiast adresy z zaplanowanej wcześniej sieci 10.30.40.0/24.

1. Otworzyć Wireless > Wireless settings.
2. Włączyć Enable wireless protection.
3. W Allowed zone wybrać strefę, przez którą AP dociera do zapory. SFOS oferuje w tym celu DMZ, LAN i WiFi. Zatwierdzić wybór i zapisać ustawienia Wireless za pomocą Apply przed zaakceptowaniem AP.
4. Upewnić się, że punkt dostępowy otrzymuje przez DHCP adres, bramę i DNS. Na punkcie dostępowym nie można skonfigurować statycznego adresu zarządzającego.
5. Sprawdzić, czy port 2712 między punktem dostępowym a zaporą nie jest blokowany przez przełącznik, ACL ani urządzenie pośrednie.
6. Otworzyć Wireless > Access points i zaakceptować punkt dostępowy w stanie pending przyciskiem Accept.
7. Dla aktywnego punktu dostępowego ustawić prawidłową wartość Country. Od niej zależą kanały dopuszczone przepisami. Po zmianie Country urządzenia APX zapisać ustawienie, a następnie w kontrolowany sposób ponownie uruchomić punkt dostępowy, aby zastosować nową listę kanałów.

W zaporze z dwiema kartami Wi-Fi zmiana Country wpływa na obie karty i ustawia oba kanały na Auto. Wcześniej udokumentować obie konfiguracje radiowe, a następnie obie sprawdzić. Zgodnie z pomocą w APX 320 oba moduły radiowe muszą być ustawione na 5 GHz, aby wyświetlić wszystkie dostępne kanały 5 GHz; jednak w Izraelu Radio 0 obsługuje tylko 2.4 GHz. Lokalne dopuszczenie dla danego kraju ma pierwszeństwo: nie wybierać innej wartości Country w celu wymuszenia kanałów.

W Wireless > Wireless settings > Advanced settings wartość Timeout określa liczbę minut od przejścia punktu dostępowego w tryb offline do wysłania powiadomienia o przekroczeniu czasu; po upływie tego okresu SFOS uznaje AP za inactive. Aby przeprowadzić kontrolowany test, należy najpierw zapisać dotychczasową wartość, a następnie w oknie serwisowym odłączyć wyłącznie testowy AP bez klientów produkcyjnych. Po tymczasowo skróconym, lecz bezpiecznym operacyjnie czasie powinny pojawić się powiadomienie i stan inactive. Następnie trzeba ponownie podłączyć AP, potwierdzić powrót do stanu active i przywrócić poprzednią wartość Timeout.

Wybór w Allowed zone dotyczy ścieżki zarządzania punktu dostępowego, a nie późniejszej strefy klientów WLAN. Jeżeli punkt dostępowy jest nadal zarejestrowany na innej zaporze Sophos Firewall lub w Sophos Fusion, należy go najpierw tam usunąć. Jeśli nie jest to możliwe, należy przywrócić go do ustawień fabrycznych. W celu planowanego wycofania z eksploatacji najpierw odłączyć jednoznacznie zidentyfikowany AP od sieci, a następnie wybrać ten AP w Wireless > Access points i użyć Delete. Wcześniej sprawdzić jego tożsamość; potem sprawdzić, czy jego wpis został usunięty i czy pozostałe AP oraz SSID nadal działają. Delete nie oznacza usunięcia przypisania WLAN ani dezaktywacji grupy; nie usuwać AP działającego w środowisku produkcyjnym na próbę w celu rozwiązywania problemów.

Połączenie sterujące na porcie 2712 pomiędzy firewallem i punktem dostępowym jest szyfrowane za pomocą AES. Zezwolenie na ten port nie zastępuje jednak ograniczenia sieci zarządzania AP do strefy, która rzeczywiście go potrzebuje.

2. Tworzenie Wireless Network

W Wireless > Wireless networks > Add wprowadza się wartości z przykładu:

1. Name: Guest WiFi
2. Hardware name: GuestWiFi
3. SSID: Company Guest
4. Security mode: WPA2 Personal
5. Passphrase: długie, unikatowe hasło
6. Client traffic: Separate zone
7. Zone: WiFi
8. IP address: 10.30.40.1
9. Netmask: /24

Wartość Hardware name może mieć maksymalnie dziesięć znaków obejmujących litery, cyfry i znaki podkreślenia, a później nie można jej zmienić. Name obsługuje do 58 znaków, a SSID od 1 do 32 drukowalnych znaków ASCII. Obie wartości można dostosować do własnej konwencji nazewnictwa. Wartość Name sieci bezprzewodowej można później zmienić i jest ona wyświetlana w innych ustawieniach zamiast Hardware name. W tym polu dozwolone są wszystkie znaki oprócz '"<>#%\/,; nie stosować tego ograniczenia do SSID, Hardware name ani Passphrase.

W Advanced settings dla przykładowej sieci gościnnej właściwe są następujące decyzje:

• Encryption: AES
• Frequency band: tylko pasma obsługiwane przez używany model i jego moduły radiowe
• Client isolation: włączyć, jeśli bezpośrednie połączenia między gośćmi są niepożądane
• Hide SSID: pozostawić wyłączone
• Fast transition: używa IEEE 802.11r i wymaga WPA2 jako Security mode. APX nie obsługuje tej funkcji. Używać wyłącznie na zgodnym sprzęcie innym niż APX, po sprawdzeniu modelu, kompilacji SFOS i klientów; nie oznacza to ani obsługi AP6, ani dopuszczenia wszystkich modeli W lub WPA3.
• Time-based access: określa dozwolone godziny dostępu do tego SSID. Za pomocą Add new item wybrać odpowiedni harmonogram lub utworzyć własny. Aktywację i zmiany konfiguracji przeprowadzać w zaplanowanym oknie przerwy w działaniu, ponieważ aktywacja, zgodnie z opisem poniżej, ponownie uruchamia hostapd i rozłącza wszystkich klientów danego AP. Za pomocą klienta testowego sprawdzić zarówno przewidziany okres dozwolonego dostępu, jak i okres blokady; ten harmonogram dostępu nie jest harmonogramem skanowania radiowego ani skanowania w poszukiwaniu nieautoryzowanych AP.

Client isolation blokuje tylko bezpośrednią komunikację między klientami tej samej SSID w tym samym module radiowym. Nie zastępuje separacji za pomocą stref, VLAN i reguł zapory między wieloma punktami dostępowymi lub modułami radiowymi. Ukryta SSID również nie jest zabezpieczeniem, lecz jedynie wyłącza widoczne wyświetlanie nazwy sieci.

W przypadku zintegrowanej sieci WLAN możliwość równoczesnej pracy w dwóch pasmach zależy od sprzętu. XGS 87w i 107w nadają tylko w paśmie 2.4 GHz albo 5 GHz. Modele XGS 116w, 126w i 136w wymagają drugiego modułu radiowego do obsługi obu pasm. Modele XGS 88w, 108w, 118w i 128w mogą równocześnie używać obu pasm bez dodatkowego modułu.

Po włączeniu harmonogramu Wireless SFOS uruchamia ponownie hostapd. Powoduje to krótkie rozłączenie wszystkich klientów WLAN danego punktu dostępowego, a nie tylko klientów tej SSID. Urządzenia powinny połączyć się ponownie automatycznie.

Jeśli dodatkowo ma zostać zablokowane znane urządzenie, w Hosts and services > MAC host > Add utworzyć na przykład Bad hosts z Type: MAC list, wpisać adresy MAC faktycznie przeznaczone do zablokowania i zapisać. W profilu gościnnym w Advanced settings > MAC filtering wybrać opcję listy blokowania, przypisać tę MAC list i zapisać Wireless Network za pomocą Save. Pomoc Separate zone nazywa tę opcję Blacklist; sprawdzić nazwę listy blokowania w używanej kompilacji. Za pomocą jednego zablokowanego i jednego dozwolonego urządzenia testowego sprawdzić, czy odrzucane jest wyłącznie urządzenie zablokowane. Podrobiony lub losowy adres MAC może obejść tę blokadę: nie dowodzi ona ani wykrywania złośliwego oprogramowania, ani tego, że urządzenie jest czyste, i nie zastępuje polityk ochrony ani separacji sieci. Allowed zone zezwala na ścieżkę zarządzania AP; samo włączenie Wireless Protection nie jest dowodem kontroli wszystkich pakietów Wi-Fi lub LAN pod kątem złośliwego oprogramowania.

Oddzielna weryfikacja sieci Enterprise Wi-Fi i RADIUS

Dla sieci Wireless z 802.1X serwer RADIUS wybiera się w Wireless > Wireless settings. Punkt dostępowy nie komunikuje się bezpośrednio z serwerem RADIUS: do komunikacji z zaporą podczas Authentication używa portu 414, a podczas Accounting portu 417. Następnie zapora przekazuje Accounting do skonfigurowanego portu RADIUS, zwykle 1813.

Do uwierzytelniania Enterprise używać Wireless network Name jako NAS ID, a nie automatycznie widocznego SSID lub Hardware name. Te wartości mogą się różnić. Dopasować politykę RADIUS do tej nazwy i w dzienniku uwierzytelniania klienta testowego sprawdzić, czy używane są oczekiwana NAS ID i polityka; uwierzytelnianie i rozliczanie sprawdzić osobno.

Accounting musi być aktywny na serwerze RADIUS; ten proces Wireless nie obsługuje Interim Accounting Updates. Secondary RADIUS server nie powinien być planowany jako ogólny failover: urządzenia APX i urządzenia z Wi-Fi mogą korzystać tylko z podstawowego serwera RADIUS, a urządzenia XGS Appliance nie obsługują dodatkowego serwera RADIUS w tym procesie.

Dla tej ścieżki sieci bezprzewodowej zarządzanej przez SFOS ustawienia Wireless w SFOS 22 i 23 wymagają mapowania NAT dla sieci punktów dostępowych, jeśli serwer RADIUS jest połączony z zaporą przez tunel IPsec. Źródłowy adres IP musi zostać przetłumaczony dokładnie na ten adres IP zapory, przez który zapora dociera do serwera RADIUS. Chodzi o sieci AP, a nie ogólnie o sieć klientów bezprzewodowych. Pomoc wskazuje konfigurację w powłoce za pomocą sys-traffic-nat, ale nie podaje tutaj kompletnego polecenia gotowego do wykonania. Nie ustanawia to ogólnego wymogu NAT dla innych ścieżek RADIUS.

Przed zmianą udokumentować dokładną wersję i build SFOS, sieci AP, faktycznie używany adres źródłowy, planowany adres IP zapory do translacji, tunel i Traffic Selectors, drogę powrotną oraz logi RADIUS. Bez składni potwierdzonej dla tego buildu i ścieżki danych nie wprowadzać zmian w powłoce: uzgodnić z Sophos Support obsługiwaną powłokę, parametry i adresy do użycia, a także kontrole wstępne, kryteria powodzenia i dokładną procedurę wycofania zmiany. Zmianę przeprowadzić wyłącznie w oknie serwisowym zgodnie z potwierdzoną procedurą; następnie na kliencie testowym sprawdzić uwierzytelnianie 802.1X i Accounting oraz porównać adres źródłowy obserwowany na serwerze RADIUS i ścieżkę odpowiedzi z planowanymi wartościami. W razie rozbieżności nie rozszerzać reguł dostępu, lecz przeanalizować dowody z Support i w razie potrzeby zastosować potwierdzoną procedurę wycofania.

Ruch uwierzytelniania generowany przez zaporę należy odróżnić od przekazywanego ruchu klientów. Artykuł o trasach IPsec dla przekazywanego ruchu opisuje system ipsec_route i NAT dla tej ścieżki przekazywania; nie zawiera procedury sys-traffic-nat. Ani opisany tam DNAT/zwrotny SNAT, ani reguła LAN-do-VPN nie zastępują wymaganej tutaj konfiguracji NAT dla ruchu systemowego.

Po skonfigurowaniu ustawień ogólnych i zaawansowanych oraz, w stosownych przypadkach, ustawień Enterprise i filtra MAC zapisać Wireless Network za pomocą Save – nawet jeśli nie jest używana lista blokowanych adresów MAC. W Wireless > Wireless networks sprawdzić, czy Guest WiFi jest wyświetlane z przewidzianymi ustawieniami. Dopiero potem utworzyć serwer DHCP na tym interfejsie i przypisać sieć do AP zgodnie z poniższym opisem. Unplugged przed przypisaniem do AP nie jest powodem do ponownego utworzenia profilu ani do utworzenia go z innym trybem ruchu.

3. Dodanie DHCP dla sieci klientów

Dla Separate zone nie jest automatycznie tworzony kompletny serwer DHCP dla klientów. W Network > DHCP > Server > Add tworzy się więc na przykład następującą konfigurację:

• Name: dhcp-wifi-guest
• Interface: Guest WiFi
• Dynamic IP lease: od 10.30.40.100 do 10.30.40.220
• Subnet mask: /24
• Gateway: Use interface IP as gateway
• DNS server: zgodny z własną architekturą DNS
• Conflict detection: włączone

Zakres celowo rozpoczyna się powyżej adresu interfejsu i pozostawia miejsce na adresy zarezerwowane. W często zmieniającej się sieci WLAN dla gości krótszy czas dzierżawy może być bardziej odpowiedni niż w stabilnej sieci biurowej. Bardzo krótkie dzierżawy powodują jednak niepotrzebnie wiele odnowień.

Wybór rozsyłanych serwerów DNS jest decyzją z zakresu bezpieczeństwa i eksploatacji. Wewnętrzne serwery DNS usługi AD nie powinny być udostępniane gościom tylko dla wygody. Pełne planowanie i kontrolę dzierżaw opisuje artykuł Konfiguracja Sophos Firewall jako serwera DHCP.

4. Sprawdzenie reguły zapory, NAT i usług lokalnych

W Rules and policies > Firewall rules > Add firewall rule > New firewall rule tworzy się regułę dla wymaganego dostępu do Internetu. Pełny formularz, kolejność reguł i Security Features wyjaśnia artykuł Reguły Sophos Firewall.

• Rule name: WiFi_Guest_to_WAN
• Action: Accept
• Log firewall traffic: włączone
• Source zones: WiFi
• Source networks and devices: obiekt sieciowy dla 10.30.40.0/24
• Destination zones: WAN
• Destination networks: Any
• Services: tylko usługi wymagane dla sieci WLAN dla gości
• Security features: odpowiednie polityki Web, Application i IPS zależnie od licencji i przeznaczenia

Czytelny obiekt sieciowy, taki jak net_WiFi_Guest, sprawia, że reguła jest bardziej restrykcyjna i zrozumiała niż Source networks: Any. Wybór Services zależy od tego, czy DNS i NTP są używane lokalnie na zaporze, czy bezpośrednio zewnętrznie. Ogólne zezwolenie Any jest wygodne, ale utrudnia późniejszą kontrolę.

Dodatkowo reguła NAT musi tłumaczyć ruch wychodzący na adres WAN. Istniejąca domyślna reguła SNAT z MASQ często obejmuje już nowe sieci wewnętrzne. Należy to jednak sprawdzić w konkretnym zestawie reguł, zamiast profilaktycznie tworzyć drugą regułę NAT. Zależność tę wyjaśnia artykuł Zrozumienie NAT w Sophos Firewall.

Reguła WiFi-to-WAN nie blokuje automatycznie dostępu dozwolonego przez istniejące szerokie reguły WiFi-to-LAN lub Any. Dlatego należy sprawdzić całą kolejność reguł pod kątem dostępu do sieci wewnętrznych. Jeśli klienci tej samej sieci Separate-Zone mają komunikować się ze sobą przez wiele punktów dostępowych, potrzebna jest dodatkowa reguła WiFi-to-WiFi. W sieci WLAN dla gości taką komunikację należy dopuszczać wyłącznie świadomie.

Dostęp do samej zapory nie jest kontrolowany przez zwykłą regułę zapory. W Administration > Device access sprawdzić faktycznie skonfigurowane uprawnienia WiFi dla HTTPS i SSH, zamiast zakładać określone ustawienie domyślne. Dlatego dla sieci WLAN dla gości w Administration > Device access należy usunąć zaznaczenia WiFi przy HTTPS, SSH i wszystkich innych niepotrzebnych usługach lokalnych. DNS pozostaje dozwolony tylko wtedy, gdy klienci rzeczywiście używają zapory jako resolvera. Podstawy opisuje artykuł Device Access i Local Service ACL.

5. Przypisanie WLAN do punktu dostępowego

Zapisana Wireless Network nie jest jeszcze rozgłaszana przez żaden punkt dostępowy:

1. Otworzyć Wireless > Access points.
2. Otworzyć aktywny punkt dostępowy przez jego nazwę albo Edit.
3. Sprawdzić prawidłową wartość Country.
4. W sekcji Wireless networks kliknąć Add new item.
5. Wybrać Guest WiFi, zatwierdzić przyciskiem Apply i kliknąć Save.

Przy wielu punktach dostępowych bardziej przejrzysta jest grupa w Wireless > Access point groups. Pozwala to spójnie przypisywać SSID, zamiast zarządzać nimi inaczej na każdym punkcie dostępowym. Do jednego punktu dostępowego można przypisać maksymalnie osiem Wireless Networks.

Grupę tworzy się w Wireless > Access point groups > Add, podając nazwę, Wireless networks, opcjonalne VLAN tagging oraz należące do niej Access points. Przed zapisaniem trzeba sprawdzić, czy przypisanie VLAN rzeczywiście pasuje do wszystkich wybranych punktów dostępowych.

⚠️ Wpływ operacyjny: Wyłączenie grupy punktów dostępowych powoduje, że wszystkie należące do niej punkty dostępowe przestają rozgłaszać przypisane sieci WLAN. Zmianę grupy należy więc zaplanować w oknie serwisowym z udokumentowaną listą punktów dostępowych i SSID.

Świadoma zmiana parametrów radiowych i grup punktów dostępowych

W Wireless > Access points > AP > Advanced settings kanał, Dyn chan, TX power i Channel width wpływają nie tylko na jednego klienta testowego. Dynamiczna zmiana kanału może wymusić ponowne połączenie aktywnych klientów. Szersze kanały mogą zwiększyć przepustowość w środowisku o małej gęstości, ale dodatkowe nakładanie się kanałów może ją obniżyć przy dużej gęstości. SFOS domyślnie używa 20 MHz w paśmie 2,4 GHz i 40 MHz w paśmie 5 GHz. Moc nadawania i szerokość kanału należy więc mierzyć dla konkretnej lokalizacji, a nie po prostu ustawiać na maksimum.

Turn on Spanning Tree Protocol (STP) chroni sieci mostkowane przed pętlami warstwy 2 i wynikającymi z nich burzami broadcastowymi. STP nie należy traktować jako przełącznika wydajności. Po zmianie trzeba sprawdzić co najmniej dwa rzeczywiste klienty, roaming, DHCP, DNS i dłuższy transfer; przy automatycznym wyborze kanału także czas zmiany i ponowne poprawne połączenie klientów.

Jeśli dynamiczny wybór kanału ma być uruchamiany tylko o ustalonych porach, dla każdego pasma należy najpierw włączyć Dyn chan, a następnie Time-based scan i w Select scan time > Add new item przypisać przewidziany Schedule lub utworzyć go za pomocą Add. Po Save obserwować czas skanowania i ewentualne ponowne połączenie klientów. Przed zmianami grup jednoznacznie zidentyfikować AP na podstawie ID (numeru seryjnego), Label i Group. Pojedynczy WLAN można ponownie odznaczyć w jego szczegółach AP za pomocą remove; następnie zapisać i sprawdzić pozostałe SSIDs. Nie jest to równoznaczne z wyłączeniem całej grupy AP. W celu zaplanowanego restartu AP można ponownie uruchomić wybrany AP w Wireless > Access points za pomocą Restart; wcześniej zapisać listę klientów i logi, a następnie powtórzyć opisane poniżej testy połączenia.

Kontrolowane testowanie WLAN

Odbiór konfiguracji nie powinien kończyć się na stwierdzeniu „SSID jest widoczna”. Za pomocą klienta testowego sprawdza się, czy rzeczywiście używane są zaplanowane sieć i reguły:

1. Punkt dostępowy musi być aktywny w Wireless > Access points. Interfejs Wireless w Network > Interfaces pozostaje w stanie Unplugged, dopóki żaden punkt dostępowy nie jest połączony z tą Wireless Network.
2. Połączyć się z Company Guest i sprawdzić punkt dostępowy, SSID, częstotliwość oraz sygnał w Wireless > Wireless client list.
3. W Network > DHCP > IPv4 lease sprawdzić, czy klient otrzymał adres z zakresu od 10.30.40.100 do 10.30.40.220.
4. Na kliencie sprawdzić adres IP, bramę i DNS. W systemie Windows pomagają:

ipconfig /all
nslookup example.com

5. Przetestować dozwolone połączenie z Internetem oraz celowo niedozwolony cel wewnętrzny.
6. W Log Viewer filtrować według adresu IP klienta i sprawdzić oczekiwane Firewall Rule ID oraz NAT Rule ID.

Sukces nie oznacza tylko dostępu do Internetu. Klient musi używać prawidłowej bramy i przewidzianych serwerów DNS, być odseparowany od niedozwolonych celów wewnętrznych oraz przechodzić dokładnie przez oczekiwane reguły zapory i NAT. Ogólną procedurę opisuje artykuł Prawidłowe testowanie reguł zapory.

Kontrolowane skanowanie rogue access pointów

Rogue AP scan jest dostępny wyłącznie na urządzeniach Sophos Firewall ze zintegrowanym Wi-Fi; zewnętrzne punkty dostępowe APX nie mogą wykonywać tego skanowania. W Wireless > Rogue AP scan polecenie Scan now wyszukuje punkty dostępowe znajdujące się w zasięgu radiowym. Podczas skanowania połączenia aktywnych klientów Wi-Fi zostają na krótko przerwane. Dlatego skanowanie ręczne lub planowane powinno odbywać się w znanym oknie czasowym, a nie bez uprzedzenia podczas pracy produkcyjnej.

Wykryte urządzenia pojawiają się w Unrecognized access points i są świadomie oznaczane jako autoryzowane albo jako Rogue AP. Ta klasyfikacja nie zastępuje analizy incydentu: przed uznaniem obcej sieci Wi-Fi za urządzenie we własnej sieci LAN trzeba skorelować SSID, BSSID, kanał, sygnał, lokalizację i możliwy port przełącznika.

Dla cyklicznych skanów wybiera się harmonogram w General settings > Schedule system-triggered scan at. W przypadku LocalWiFi0 z aktywną opcją Bridge to Ethernet i siecią Wireless w trybie Bridge to AP LAN skan pokazuje tylko pobliskie sieci w tym samym paśmie częstotliwości co przypisana sieć Wireless. To ograniczenie produktu należy udokumentować podczas oceny wyniku.

Zatwierdzić harmonogram skanowania za pomocą Apply. W wynikach użyć działań Mark as “authorized access point” lub Mark as “rogue access point” i sprawdzić wynikowe przypisanie. Wpis oznaczony jako rogue jest klasyfikacją, a nie potwierdzonym mechanizmem wyłączania lub blokowania obcego punktu dostępowego.

Lokalizowanie typowych błędów

SSID nie jest wyświetlana

Najpierw sprawdzić, czy Wireless Protection jest włączona, strefa zarządzania punktem dostępowym znajduje się w Allowed zone, a punkt dostępowy w Wireless > Access points ma stan active, a nie pending lub inactive. Następnie sprawdzić Country, przypisaną Wireless Network, Frequency band oraz ewentualny harmonogram.

Zapisana sieć bez przypisania do punktu dostępowego nie jest rozgłaszana. W przypadku zintegrowanej sieci WLAN ograniczenia modelu dotyczące pasm radiowych albo nieobsługiwany starszy tryb szyfrowania mogą dodatkowo uniemożliwić powiązanie profilu z LocalWiFi0.

Interfejs Separate zone pozostaje Unplugged

Stan Unplugged jest prawidłowy, dopóki żaden punkt dostępowy nie jest połączony lub Wireless Network nie jest przypisana do AP. Jeśli stan utrzymuje się mimo aktywnego APX i prawidłowego przypisania, trzeba sprawdzić ścieżkę zarządzania punktem dostępowym.

W SFOS 21.5 MR1 Build 261 problem może wystąpić, gdy adres IP zapory używany przez sieć zarządzania APX jest skonfigurowany jako alias zamiast bezpośrednio na interfejsie nadrzędnym (NC-175920). SFOS nie może wtedy utworzyć tunelu VXLAN dla Separate zone. Obejście polega na przeniesieniu APX do sieci zarządzania, której adres IP zapory jest skonfigurowany bezpośrednio na interfejsie nadrzędnym. Nie należy usuwać adresu alias bez wcześniejszego potwierdzenia przyczyny.

Zmiana przerywa sieci Wi-Fi rozgłaszane przez punkt dostępowy. Dlatego najpierw trzeba sprawdzić DHCP, bramę, Allowed zone i port 2712 w sieci docelowej, a zmianę przeprowadzić w oknie serwisowym. Następnie należy sprawdzić stan AP, przypisanie sieci Wi-Fi, stan interfejsu i połączenie klienta testowego. Sophos nie podaje wersji z poprawką, więc w innych wersjach SFOS sam stan Unplugged nie potwierdza tego problemu.

Klient nie otrzymuje adresu IP

W trybie Separate zone serwer DHCP musi działać na utworzonym interfejsie Wireless, a zakres musi pasować do sieci interfejsu. W trybie Bridge to AP LAN odpowiada natomiast serwer DHCP sieci LAN punktu dostępowego. W trybie Bridge to VLAN wspólnie sprawdza się trunk przełącznika, identyfikator VLAN i serwer DHCP osiągalny w sieci VLAN klientów.

Nie wolno mylić DHCP zarządzania punktem dostępowym z DHCP klientów: punkt dostępowy może być online, mimo że dla klientów WLAN nie działa jeszcze żaden serwer DHCP.

Klient ma adres IP, ale nie ma dostępu do Internetu

W takim przypadku DHCP i połączenie radiowe już działają, a problem znajduje się dalej na ścieżce, przy właściwej polityce. Następnie sprawdza się bramę i DNS, regułę WiFi-to-WAN, kolejność reguł, logowanie oraz odpowiednią regułę MASQ/SNAT. Log Viewer pokazuje, czy dopasowano oczekiwane Firewall Rule ID, czy też niejawna reguła #0 odrzuca ruch.

Jeśli klient ma dostęp do Internetu, ale jednocześnie do systemów wewnętrznych, nie jest to sukces w przypadku sieci WLAN dla gości. Prawdopodobnie działają istniejące reguły WiFi-to-LAN, Any albo zbyt szerokie reguły sieciowe.

Połączenie punktu dostępowego lub komunikacja klientów pozostaje niejasna

Ruch zapory pojawia się niezawodnie w Log Viewer tylko wtedy, gdy aktywne są zarówno Log firewall traffic w regule, jak i typ logu zapory w System services > Log settings > Local reporting. Same zdarzenia Wireless nie są tam dostępne jako zwykły lokalny typ logu Wireless. W System services > Log settings można je wysyłać do Sophos Fusion lub serwera Syslog.

W celu głębszej diagnostyki Sophos dokumentuje awed.log dla komunikacji między zaporą i APX, wc_remote.log dla klientów Wireless oraz hostapd.log dla LocalWiFi. Artykuł Sprawdzanie usług i logów Sophos Firewall przez CLI wyjaśnia, jak odczytywać takie logi bez niekontrolowanego ponownego uruchamiania usługi.

W razie potrzeby dziennik osiągalnego APX można odczytać za pomocą awetool. Zalogować się jako admin do CLI zapory, wybrać 5 – Device Management, następnie 3 – Advanced Shell i uruchomić awetool. Wybrać Connect to an AP, wybrać docelowy AP na podstawie jego tożsamości, potwierdzić za pomocą OK i zakończyć zestawianie połączenia za pomocą y. Dopiero na tym AP logread i logread -f są udokumentowanymi kontrolami odczytu. Również dostępne polecenie reboot rozłącza klientów i zmienia stan; należy je wykonać dopiero po zapisaniu dzienników, w oknie serwisowym i z późniejszą kontrolą stanu AP, SSID, listy klientów i rzeczywistego ruchu. Nie stosować tych kroków powłoki APX do AP6, zintegrowanego LocalWiFi ani UTM.

Duże transfery są powolne lub przerywane

Jeżeli problem dotyczy tylko większych pakietów lub dłuższych transferów, przyczyną może być enkapsulacja VXLAN trybu Separate zone. Nie istnieje jeden uniwersalny rozmiar MTU. Najpierw dokumentuje się Rule ID, ścieżkę danych, retransmisje i odtwarzalny test aplikacji. Dopiero po potwierdzeniu problemu MTU/MSS wprowadza się kontrolowaną zmianę i powtarza ten sam test.

Bezpieczna interpretacja obiektów Wireless w XML API

Automatyzując opisane powyżej ustawienia, należy oddzielnie traktować profil sieciowy, lokalny moduł radiowy, grupę AP i globalne ustawienia Wireless. Dokumentacja referencyjna XML dla SFOS 22 i 23 opisuje poniższe obiekty, ale nie stanowi zgody na wysłanie żądania zapisu skopiowanego bez zmian. Dostęp, jawne operacje, analizę odpowiedzi i bezpieczne ponawianie opisuje artykuł Zabezpieczanie dostępu do XML API Sophos Firewall. Przed zmianami należy zabezpieczyć istniejący stan obiektów, zależności i potwierdzoną ścieżkę przywrócenia. W przypadku wymienionych poniżej sprzeczności między źródłami należy najpierw wyjaśnić odpowiednie pola zapisu w API help zainstalowanego buildu lub z pomocą wsparcia technicznego; do tego czasu nie należy ich wysyłać. Wszystkie poniższe kody są wartościami statusu XML specyficznymi dla obiektu, a nie kodami statusu HTTP; wszystkie symbole Message.* są nierozwiązanymi kluczami referencyjnymi, a nie potwierdzonymi tekstami zwracanymi podczas działania. Należy wspólnie zapisać operację, kod i rzeczywistą odpowiedź po usunięciu danych wrażliwych.

WirelessLocalAP: tożsamość i parametry radiowe modelu W

WirelessLocalAP dotyczy zintegrowanego lokalnego punktu dostępowego odpowiedniego urządzenia Wireless, a nie lokalnego interfejsu WWW AP6 ani jego zarządzania przez Central/Fusion. Z tego kontraktu nie wynika ani nowy przebieg obsługi APX przez API, ani instrukcja dla starych urządzeń AP/UTM. Wymagane pole Id identyfikuje istniejący lokalny AP; Label jest opcjonalną etykietą, a nie tożsamością zastępczą. Przykład w dokumentacji referencyjnej zawiera LocalWifi0/LocalWifi1, natomiast pomoc interfejsu użytkownika używa LocalWiFi0. Nie należy po cichu poprawiać wielkości liter ani wysyłać zapisu z ukośnikiem jako wspólnego identyfikatora: rzeczywistą pojedynczą tożsamość należy potwierdzić w wyniku odczytu/eksportu odpowiednim dla danego buildu. Country musi odpowiadać rzeczywistej lokalizacji, a nie przykładowemu In.

Przypisania sieci znajdują się w przykładzie pod WirelessNetworks/Network. Tabela opisuje Network jako tablicę i ostrzega, że zduplikowane wartości nie są ignorowane. Dlatego należy w pełni zweryfikować istniejące przypisania i nie wysyłać listy SSID ani odgadniętych nazw sieci. Limit ośmiu przypisanych sieci Wireless Networks oraz ograniczenia sprzętowe pasm radiowych pozostają istotne również przy automatyzacji.

W odniesieniu do przypisania pasma tabela opisuje Band z wartościami 2.4GHz lub 5GHz, dla 2,4 GHz pola Channel, ChannelWidth, TXPower, DynChan i TimeBasedScan, a dla 5 GHz pola Channel5GHz, ChannelWidth11a, TXPower5GHz, DynChan5GHz i TimeBasedScan5GHz. Przykład pokazuje czasy skanowania pod ScanTime/Time; tabela wymienia Time dwukrotnie jako tablicę zależną od pasma, bez jednoznacznego przedstawienia struktury nadrzędnej dla obu pasm. Przed żądaniem zapisu należy potwierdzić właściwą strukturę nadrzędną dla każdego pasma, zamiast łączyć wszystkie wpisy Time lub wymyślać element nadrzędny dla 5 GHz. Czasy skanowania radiowego nie są harmonogramem dostępu do SSID.

Kilka informacji jest sprzecznych: przykład używa Channel2.4GHz, a tabela Channel; w przypadku DynChan i TimeBasedScan przykład zawiera Enable, podczas gdy listy wartości zawierają tylko t. Dla TXPower przykład pokazuje 100, natomiast tabela 10%, 25%, 50%, 75%, 100%. Również opis przypisania DynChan do pasma nie jest jednoznaczny. Nie potwierdzono, że te zapisy są wartościami zamiennymi. Opis eksportu dla DynChan5GHz rozróżnia ponadto Disabled (kanał statyczny, skanowanie dynamiczne wyłączone), 1 (kanał automatyczny bez skanowania dynamicznego) i Enabled (kanał automatyczny ze skanowaniem dynamicznym); wartości eksportowanych nie należy automatycznie traktować jako dopuszczalnych danych wejściowych do zapisu.

BridgeToEthernet, BridgeToPort i Zone dotyczą lokalnego mostu Ethernet, a nie identyfikatora VLAN klientów w profilu sieciowym. Nadal obowiązują opisane powyżej ograniczenia Gen.1/Gen.2, wymagania dotyczące IPv4/Bridge-to-AP-LAN oraz kontrole DHCP i dostępu administracyjnego. Po potwierdzonej zmianie należy sprawdzić oba objęte nią moduły radiowe, kraj, przypisania sieci, most i rzeczywistego klienta, zanim zostaną zmienione kolejne AP.

Sekcja Status Message Information dla operacji Update Local AP przypisuje w obu wersjach dokumentacji referencyjnej następujące wartości statusu XML:

• 200, 216: Message.WPAPkUpdateSuccessfully; 500, 541, 543, 544, 545: Message.WPAPUpdateFail.
• 523: Message.WPNetworkGroupMax; 524: Message.WPAccessPointMax; 542: Message.WPAccessPointMesh.
• 547: Message.WPAPUpdateFailVLANGroup; 548: Message.WPA3IsNotSupported.
• 561: Message.LegacyModeNotSupported; 564: Message.TKIPModeNotSupported; 565: Message.TopazToNonTopazImportFail.

Są to dosłowne, nierozwiązane klucze referencyjne, a nie potwierdzone komunikaty zwracane podczas działania. W szczególności z Message.TopazToNonTopazImportFail nie należy wywodzić przypisania do modeli ani dopuszczalnej migracji przez import. W przypadku niejasnej odpowiedzi należy odczytać zapisaną tożsamość AP, parametry radiowe i przypisania, a nie automatycznie powtarzać tę samą aktualizację lub osłabiać szyfrowanie.

WiFi6Interface: istniejący interfejs, a nie SSID ani most

WiFi6Interface w dokumentacji referencyjnej XML dla SFOS 22 i 23 zarządza ustawieniami sieci i stref przypisanymi do portów LocalWiFi6, a nie profilem SSID ani fizycznym mostem. Pola wymagane to Name, Hardware i Zone: Name jest nazwą opisową o długości maksymalnie 58 znaków; Hardware oznacza nazwę sprzętową już istniejącego interfejsu. Przed zmianą należy potwierdzić tę tożsamość w wyniku odczytu/eksportu odpowiednim dla danego buildu, a nie wywodzić jej z nazwy wyświetlanej, SSID lub WirelessNetworks.HardwareName. Nie stosuje się tutaj ograniczenia do dziesięciu znaków z zestawu A-Za-z0-9_, dotyczącego nazwy sprzętowej fizycznego mostu; tabela WiFi6Interface określa dla Hardware jedynie typ string. Również z nazwy obiektu API nie wynika przypisanie do generacji sprzętu. Opisane powyżej, zależne od modelu kontrole mostu w GUI, DHCP i dostępu administracyjnego obowiązują bez zmian.

IPv4Address i Netmask są w tym kontrakcie opcjonalne. Nie wynika z tego ani obowiązek ustawienia nowego adresu, ani potwierdzony skutek pominięcia istniejących wartości. Przed zmianami należy udokumentować rzeczywisty port, strefę oraz ewentualny istniejący adres IP wraz z maską; następnie ponownie odczytać stan tego samego interfejsu i porównać go z przewidzianym planem adresacji. Taka weryfikacja interfejsu nie zastępuje ani sprawdzenia przypisania AP i SSID, ani rzeczywistego testu klienta.

Dla operacji WiFi6Interface oba źródła podają 200/Message.InterfaceUpdateSuccess, 500/Message.InterfaceUpdateFail i 502/Message.InterfaceIPAlreadyInUsed. Są to wartości statusu XML specyficzne dla obiektu, z nierozwiązanymi kluczami referencyjnymi, a nie kody HTTP ani potwierdzone teksty zwracane podczas działania. Należy wspólnie zapisać operację, kod i rzeczywistą odpowiedź po usunięciu danych wrażliwych. W przypadku niejasnego wyniku należy najpierw odczytać tożsamość sprzętową, port, strefę oraz, jeśli występują, IP/Netmask, zamiast automatycznie powtarzać tę samą aktualizację lub tworzyć inny obiekt Wireless. Sam kod sukcesu nie dowodzi ani prawidłowego przypisania do sieci, ani działającego ruchu WLAN; nie wywodzi się tutaj nowego żądania zapisu.

WirelessNetworks: rozróżnianie tożsamości sprzętowej, profilu i statusu

W przypadku WirelessNetworks niezmienny Hardware name, zmienna nazwa wyświetlana Name i rozgłaszany SSID są różnymi wartościami. W przykładzie dla gości są to GuestWiFi, Guest WiFi i Company Guest. Tabela parametrów dodawania/aktualizacji wymaga HardwareName o długości maksymalnie dziesięciu znaków; również operacja usuwania identyfikuje cel przez HardwareName, a nie przez SSID lub nazwę wyświetlaną. Przed usunięciem należy sprawdzić przypisania AP, interfejs, DHCP i reguły oraz usunąć wyłącznie jednoznacznie zidentyfikowany i zatwierdzony obiekt docelowy. Błąd nie jest powodem do ponownego utworzenia profilu pod nową nazwą.

Przykład dodawania/aktualizacji używa jednak Hardware zamiast HardwareName oraz ClientIsolation z Enable zamiast wartości tabelarycznej Enabled. W przypadku HideSSID występuje ta sama rozbieżność; tabela podaje dla TimeBasedAccess, ClientIsolation, HideSSID i FastTransition wartości Enabled/Disabled. Również MACFiltering z Allowlist/Blocklist występuje obok starszego opisu MACList z Whitelist/Blacklist. Żadnej z tych rozbieżności nie należy rozstrzygać przez zgadywanie. Kontrakt XML wymienia ponadto starsze tryby zabezpieczeń, podczas gdy aktualna pomoc interfejsu użytkownika opisuje WPA3 tylko dla wymienionych powyżej modeli W: nie wynika z tego pełna składnia zapisu WPA3.

Udokumentowane tokeny ruchu SeparateZone, BridgetoAPLAN i BridgetoVLAN należą do ClientTraffic. IPAddress i Netmask odnoszą się do Separate zone; BridgetoVLANid do VLAN klientów, a ClientVlanId do Static lub RadiusAndStatic. Tych wartości nie należy mylić z VLAN zarządzania AP. Nie należy przejmować przykładowego klucza, publicznego przykładowego adresu IP ani TKIP(only abg): celem pozostają AES lub potwierdzony jako obsługiwany silniejszy tryb zabezpieczeń, własne bezpieczne hasło oraz kontrolowana izolacja sieci. ClientIsolation nadal nie zastępuje granicy firewalla ani VLAN obejmującej wiele modułów radiowych/AP.

Dla Add Wireless Network obie dokumentacje referencyjne podają następujące przypisania:

• 200: Message.WPNetworkSuccess; 500, 541, 545: Message.WPNetworkFail.
• 502: Message.WPNetworkExists; 503: Message.WPNetworkInterfaceExists; 542: Message.WPNetworkInterfaceIPExists.
• 544: Message.InterfaceIPAssignedToPeerAdminIP; 548: Message.InterfaceReservedName; 560: Message.DHCPIPRangeConfig.

Dla Update Wireless Network kilka kluczy różni się mimo takich samych kodów:

• 200: Message.WPNetworkUpdateSuccessfully; 500, 541, 543, 545, 549: Message.WPNetworkUpdateFail.
• 503: Message.WPNetworkInterfaceExistsForUpdate; 542: Message.WPNetworkInterfaceIPExistsForUpdate.
• 544: Message.InterfaceIPAssignedToPeerAdminIP; 548: Message.InterfaceReservedName; 560: Message.DHCPIPRangeConfig.
• 546: Message.WPBindWithLA; 547: Message.APNotSupport5GHzWP.
• 561: Message.SecModeChangedToLegacyFail; 562: Message.SecModeChangedToWAP3Fail; 563: Message.EncModeChangedToTKIPFail.

Dla Delete Wireless Network udokumentowano 200/Message.WPNetworkDeleteSuccess, 500/Message.WPNetworkDeleteFail, 541/Message.BridgeWirelessNetworkExists i 542/Message.WPEnableDeteleFail. Również pozorne literówki, takie jak Message.SecModeChangedToWAP3Fail i Message.WPEnableDeteleFail, pozostają niezmienione; nie zastępuje się ich rzekomo poprawnymi komunikatami zwracanymi podczas działania. Przy takich odpowiedziach należy najpierw zweryfikować rzeczywiście zapisaną tożsamość sprzętową, IP, zależności DHCP, most i przypisania AP. Na podstawie samego klucza nie należy stwierdzać przyczyny, pomyślnego wycofania zmian ani bezpieczeństwa ponowienia.

WirelessNetworkStatus jest odrębnym obiektem: jego tabela wyraźnie opisuje Name jako nazwę interfejsu o długości maksymalnie dziesięciu znaków, a nie jako automatyczny alias SSID lub nazwy wyświetlanej. Status używa tutaj Enable/Disable, a nie wartości Enabled/Disabled innych pól. Rzeczywistą nazwę interfejsu należy wcześniej potwierdzić. Dla Enable-Disable Wireless Network podano 200/Message.WPNetworkUpdateSuccessfully i 500/Message.WPNetworkUpdateFail. Zmiana statusu nie przypisuje sieci do żadnego AP i nie dowodzi jeszcze jej rozgłaszania; zapisany status, przypisanie AP i połączenie klienta należy sprawdzić oddzielnie.

WirelessGrouping: członkostwo w grupie nie jest konfiguracją radiową

WirelessGrouping opisuje grupę AP z Name oraz wpisami WirelessNetworks/Network i AccessPoints/AccessPoint, które mogą występować wielokrotnie. Tożsamości AP należy pobrać z istniejącego zbioru urządzeń, a nie ze starego przykładu AP30 w dokumentacji referencyjnej. Struktura grupy konfiguruje przypisania sieci i opcjonalne tagowanie zarządzania AP, ale nie lokalne parametry radiowe zależne od pasma. Z opcjonalności tablic nie wynika potwierdzona semantyka pustych list ani bezpieczeństwo częściowej aktualizacji.

VLANTagging podaje Enable/Disable; APVLANID podaje zakres od 1 do 4094 i ma zastosowanie przy włączonym tagowaniu. Jest to VLAN zarządzania AP, a nie BridgetoVLANid dla klientów. Przed zmianami należy sprawdzić pełną listę członków, trunk, DHCP dla zarządzania, Allowed zone i ścieżkę przywrócenia. Wyłączenie grupy nadal zatrzymuje rozgłaszanie przez jej AP; po potwierdzonej zmianie należy sprawdzić każdy objęty nią AP i przewidziane SSID.

Dla Add an Access Point Group podano 200, 216/Message.WPGroupSuccess, 500, 541, 543, 545/Message.WPGroupCreated, 502/Message.WPGroupExists, 523/Message.WPGroupMax, 524/Message.WPGroupMaxAP i 546/Message.WPA3IsNotSupported. Dla Update an Access Point Group podano natomiast 200, 216/Message.WPGroupUpdateSuccessfully, 500, 541, 543, 545/Message.WPGroupUpdateFail, 523/Message.WPGroupMaxForUpdate, 524/Message.WPGroupMaxAPForUpdate i 546/Message.WPA3IsNotSupported. Mylący klucz Message.WPGroupCreated przy kodach błędów nie jest gwarancją sukcesu. Przed ponowieniem należy odczytać zapisaną grupę i jej członków, zamiast tworzyć drugą grupę lub dodawać kolejne AP.

Ustawienia globalne: dostęp do zarządzania i dalsze skutki

WirelessProtectionGlobalSettings nie jest ani profilem SSID, ani strefą klientów. W przykładzie AllowedZone/Zone zawiera strefy zarządzania, które mogą występować wielokrotnie; NotificationTimeout odpowiada objaśnionemu powyżej limitowi czasu powiadomienia o stanie offline w minutach. RADIUSServer oznacza globalnie wybrany serwer dla opisanej ścieżki Enterprise. W przypadku przełącznika przykład używa WirelessProtection, natomiast tabela EnableWirelessProtection: również te rozbieżne nazwy pól należy wyjaśnić dla konkretnego buildu przed żądaniem zapisu.

Dla Global Settings obie dokumentacje referencyjne podają 200/Message.WLANAPEditSuccessful, 500/Message.WLANAPEditFailed, 501/Message.WLANAPIPAlreadyInUsed i 504/Message.WLANAPIntBaseVHExist. Dalsze rozróżnienia to:

• 511: Message.WLANAPFailedWhileUnbinding; 512: Message.WLANAPFailedWhileDeleteDHCPServer; 513: Message.WLANAPFailedWhileDeleteDHCPRelay.
• 516: Message.WLANAPFailedToUnbindInterface; 520: Message.WLANAPFailedToUnbindIfaceRCg; 521: Message.WLANAPEditRunConfigFailed.
• 523: Message.WLANAPWLAN1UnboundEditFaild; 524: Message.WLANAPOtherUnboundEditFaild.

Kluczy nie interpretuje się jako dowiedzionych przyczyn błędów, pokazują one jednak, dlaczego globalnej zmiany nie wolno traktować jako nieszkodliwego testu: może ona wpływać na powiązania interfejsów i konfigurację DHCP. Nie należy wyłączać i ponownie włączać Wireless Protection w celu szybkiej diagnostyki. Przed planowaną zmianą należy przygotować kopię zapasową i niezależny dostęp administracyjny oraz udokumentować interfejsy, serwery/przekaźniki DHCP i przypisania AP. Następnie należy odczytać rzeczywiście zapisany stan globalny i stan usług objętych zmianą, sprawdzić osiągalność AP i klientów, a dopiero na podstawie tych dowodów zdecydować o ponowieniu lub skorzystaniu z potwierdzonej ścieżki przywrócenia. Sam kod sukcesu XML nie dowodzi ani skutku w warstwie radiowej, ani pełnego powodzenia konfiguracji.