Configurare e testare una WLAN direttamente su Sophos Firewall

Una WLAN gestita direttamente da Sophos Firewall viene creata in Wireless > Wireless networks. Configurare soltanto l’SSID, tuttavia, non basta: la modalità di traffico scelta determina se i client ricevono una rete dedicata, entrano nella LAN dell’AP oppure vengono collegati in bridge a una VLAN. DHCP, regole firewall, NAT e assegnazione a un Access Point devono poi essere coerenti tra loro.

⚠️ Importante: Questa guida si applica soltanto all’hardware WLAN gestito direttamente da Sophos Firewall. Gli Access Point AP6 non possono essere gestiti tramite SFOS. Per più AP6, Sophos Fusion (in precedenza Sophos Central) è la modalità di gestione prevista e consigliata; in alternativa, un singolo AP6 può essere configurato tramite la sua interfaccia locale. Oggi il Wireless gestito dal firewall è quindi rilevante soprattutto per le installazioni APX esistenti, il LocalWiFi integrato nei modelli desktop W e i moduli Wi-Fi supportati in Sophos Firewall o SD-RED. Il firmware degli APX gestiti da SFOS viene fornito tramite i pattern update del firewall e installato consapevolmente.

Questa guida utilizza una WLAN per ospiti con Separate zone. È un esempio facile da comprendere perché consente di separare chiaramente dalla LAN interna la rete dei client, le regole e le destinazioni consentite.

Se una rete Wi-Fi 802.1X usa RADIUS e il firewall deve riconoscere gli utenti senza un captive portal aggiuntivo, RADIUS SSO con accounting spiega il percorso accounting separato, la Framed-IP-Address necessaria e il test in Live users.

Procedura rapida:

Preparare Wireless Protection e la zona dell’AP in Wireless > Wireless settings.
Accettare l’Access Point in Wireless > Access points.
Creare SSID, sicurezza e rete dei client in Wireless > Wireless networks.
Aggiungere DHCP, regola firewall e NAT in Network > DHCP e Rules and policies.
Assegnare la Wireless Network all’AP e verificare con un client di test IP, DNS, Rule ID e gli accessi interni non consentiti.

Questa guida è adatta all’Access Point?

SFOS 22 può gestire gli Access Point indoor della serie APX, la WLAN integrata di un XGS Appliance compatibile e i moduli di espansione Wi-Fi compatibili in Sophos Firewall o SD-RED. Per gli APX esterni, sono supportati APX 120, APX 320, APX 530 e APX 740. Il modello outdoor APX 320X e la vecchia serie AP non vengono gestiti direttamente da un Sophos Firewall aggiornato.

AP6 non rientra in questa procedura. AP6 viene configurato tramite Sophos Fusion oppure, per un singolo dispositivo, mediante la sua interfaccia locale. Per la variante Fusion sono utili i requisiti di Sophos Central Wireless.

La funzione Wireless locale è inclusa nella Sophos Firewall Base License. Serve inoltre un Access Point compatibile. APX, tuttavia, è già End-of-Sale e raggiungerà l’End-of-Life il 31 dicembre 2027. Questa guida serve quindi soprattutto per gestire in sicurezza le installazioni APX esistenti; per una nuova piattaforma WLAN è opportuno considerare l’End-of-Life degli APX e AP6 come modello successivo oppure valutare altri sistemi WLAN attuali.

Limite di versione: La guida Wireless contiene le procedure corrispondenti sia per SFOS 22 sia per SFOS 23. Tuttavia, l’esistenza di una pagina della guida di SFOS 23 non dimostra il supporto di un determinato modello APX su SFOS 23. Il supporto hardware deve essere confermato indipendentemente tramite il Retirement Calendar e la matrice di supporto. Prima di un aggiornamento, verificare quindi il modello, la revisione hardware e la build di destinazione nella matrice di supporto; non migrare gli APX esistenti a SFOS 23 basandosi esclusivamente su queste istruzioni. Anche il WLAN integrato e i moduli SD-RED devono corrispondere al modello e alla build specifici. Per i nuovi access point esterni si applica la procedura di gestione AP6 collegata sopra, non questa procedura SFOS-APX.

Per collegare un APX esistente senza Ethernet tramite un APX cablato, configurare e testare Wireless Mesh su Sophos Firewall spiega AP root, canale, backhaul nascosto e validazione controllata.

SD-RED con modulo Wi-Fi: La guida Wireless documenta DHCP option 234 per la comunicazione di un modulo SD-RED utilizzato come access point con Sophos Firewall. Non si tratta né del DHCP dei client del Wi-Fi guest né di un requisito generale per APX o AP6. La guida menziona anche Sophos UTM in questo contesto; ciò non costituisce qui nuove istruzioni di installazione UTM. Prima di apportare modifiche, chiarire la compatibilità del modulo, il DHCP di gestione e il controller effettivamente utilizzato; non adottare un valore di opzione da un altro tipo di dispositivo. La configurazione SD-RED è la procedura separata per il collegamento della sede.

Scegliere la modalità Client traffic corretta

La scelta in Client traffic è più importante del nome dell’SSID. Determina se i client si trovano nello stesso segmento di rete locale a livello 2, chi assegna gli indirizzi IP e quale traffico attraversa effettivamente il firewall.

Separate zone

Separate zone crea un’interfaccia Wireless dedicata con un proprio indirizzo IP e un tunnel VXLAN tra Access Point e firewall. I client ricevono una sottorete dedicata. Gli accessi di ogni WLAN possono così essere gestiti con regole WiFi-to-WAN o WiFi-to-LAN mirate. L’articolo su zone e interfacce di Sophos Firewall spiega come interagiscono zona, interfaccia e oggetto di rete.

Questa modalità è adatta a ospiti, IoT e altre reti che devono essere separate dalla LAN interna. Anche un Hotspot con Captive Portal, password giornaliera o voucher richiede Separate zone. Configurare un hotspot Sophos Firewall descrive la procedura completa con la definizione del voucher, il portale e la regola creata automaticamente.

VXLAN riduce la MTU utilizzabile. I pacchetti di grandi dimensioni possono quindi causare frammentazione o cali di prestazioni. Non si dovrebbe perciò modificare preventivamente la MTU impostando un valore generico. Occorre prima verificare se falliscono soltanto i trasferimenti di grandi dimensioni o se i pacchetti TCP vengono trasmessi ripetutamente, le cosiddette ritrasmissioni (Retransmits); la procedura controllata è descritta nell’articolo su come verificare MTU e MSS su Sophos Firewall.

Bridge to AP LAN

Bridge to AP LAN colloca i client WLAN nella stessa rete dell’Access Point. Un server DHCP già presente in questa LAN distribuisce gli indirizzi ai client. È una soluzione pratica, ma non crea un confine di rete dedicato per ospiti o dispositivi non sicuri.

Il percorso dei dati è determinante: la comunicazione nella stessa sottorete può avvenire direttamente tra client, AP e switch, escludendo completamente Sophos Firewall. Una regola firewall su SFOS può controllare soltanto il traffico effettivamente instradato attraverso il firewall.

Per consentire l’accesso alla rete wireless integrata solo a un elenco noto di dispositivi, si crea una lista MAC in Hosts and services > MAC host. Nella rete Wireless si seleziona quindi Allow list in Advanced settings > MAC filtering e si assegna la lista. La passphrase deve contenere da 8 a 63 caratteri. Durante la convalida si collega un dispositivo presente nella lista e uno non incluso.

Un indirizzo MAC può tuttavia essere falsificato. L’Allow list è quindi solo un filtro di accesso aggiuntivo e non sostituisce WPA2 Personal con AES, un metodo WPA3 supportato, una passphrase robusta o un’adeguata separazione della rete.

Quando si utilizza Bridge to AP LAN con LocalWiFi integrato, la WLAN deve essere collegata anche alla LAN cablata. Il metodo corretto dipende dal modello di XGS Appliance:

Gen.1 – XGS 87w, 107w, 116w, 126w e 136w: in Network > Interfaces > Add interface > Add bridge si crea un bridge. Name è il nome visualizzato, modificabile in seguito, con un massimo di 58 caratteri; Hardware name ammette al massimo 10 caratteri tra A-Za-z0-9_ e non può essere modificato dopo il salvataggio. In Member interfaces, assegnare la zona WiFi all’interfaccia Wireless e la zona LAN alla porta Ethernet desiderata. Se necessario, è possibile aggiungere al bridge altre porte Ethernet.
Selezionare quindi IPv4 configuration, inserire l’IPv4 address prevista per il bridge nella LAN esistente e scegliere la maschera di sottorete corrispondente. Indirizzo e maschera devono provenire dal piano di indirizzamento della propria LAN, non dalla rete ospiti Separate zone utilizzata più avanti. Prima di Save, verificare che l’indirizzo non sia assegnato a un altro dispositivo o contemporaneamente a un’interfaccia membro e che non rientri senza prenotazione nell’intervallo DHCP dinamico. Non modificare incidentalmente il gateway esistente dei client o il piano di indirizzamento DHCP. Prima della modifica, verificare backup, dipendenze delle porte e un accesso amministrativo indipendente; la procedura per l’interfaccia bridge spiega questi controlli comuni e i nomi hardware riservati. Il suo esempio di bridge trasparente inline senza indirizzo IP ha uno scopo diverso: questa procedura documentata per LocalWiFi Gen.1 usa un indirizzo IPv4 sul bridge, ma non tutti i bridge richiedono un indirizzo IP. Salvare con Save solo dopo questi controlli.
Gen.2 – XGS 88w, 108w, 118w e 128w: l’interfaccia Wireless non può essere membro di un bridge fisico. In alternativa, in Wireless > Access points > LocalWiFi > Advanced settings si attiva Bridge to Ethernet, si seleziona esattamente una porta Ethernet e si imposta la zona su LAN.
Per Bridge to Ethernet, la porta fisica selezionata deve avere un indirizzo IP e non deve essere né una porta WAN né membro di un altro bridge. Non è possibile collegare tramite bridge un’interfaccia VLAN a LocalWiFi in questo modo; anche la zona del bridge non deve essere WAN. La funzione si applica solo a IPv4 e agli SSID di tipo Bridge to AP LAN. SFOS utilizza il server DHCP esistente della porta del bridge; se non esiste, la guida documenta la creazione automatica di un nuovo server. Prima di salvare, verificare quindi se nella LAN è già presente un server DHCP e successivamente controllare server, pool e lease per evitare risposte DHCP concorrenti. Alla disattivazione, il bridge viene eliminato e la configurazione viene riportata all’interfaccia fisica. Salvare quindi preventivamente lo stato iniziale e verificare il ripristino, inclusi l’accesso amministrativo, il DHCP della LAN e la connessione dei client, durante una finestra di manutenzione.

Un APX esterno non richiede questo bridge LocalWiFi aggiuntivo. In caso di sostituzione dell’hardware, inoltre, un bridge Wireless fisico di Gen.1 non può essere trasferito senza modifiche a Gen.2. Backup e restore di Sophos Firewall spiega la preparazione necessaria.

Bridge to AP LAN dovrebbe essere scelto solo se la WLAN e la LAN cablata devono appartenere consapevolmente allo stesso ambito di sicurezza.

Per questa procedura LAN, salvare la Wireless Network con Save dopo aver selezionato Bridge to AP LAN, le impostazioni di sicurezza e la lista MAC. In Wireless > Access points > LocalWiFi, verificare il Country corretto, assegnare proprio questa rete in Wireless networks > Add new item e salvare; il Guest WiFi presentato più avanti è un esempio distinto. Dopo la configurazione del bridge, il dispositivo di test incluso nella lista deve potersi connettere, mentre quello non incluso deve essere rifiutato. Sul client autorizzato, verificare un lease dell’intervallo LAN previsto, la maschera corrispondente, il gateway esistente e i server DNS previsti; controllare il lease sul server DHCP effettivamente responsabile della LAN. Testare la risoluzione dei nomi e un servizio previsto su un dispositivo della LAN cablata. Se non arriva un lease, controllare prima l’ammissione MAC, l’assegnazione della rete, i membri del bridge e il DHCP della LAN. La comunicazione locale nella LAN è intenzionale e non dimostra né l’isolamento degli ospiti né un percorso dati controllato da SFOS.

Bridge to VLAN

Bridge to VLAN separa la rete di gestione dell’Access Point dalla VLAN dei client. La porta dello switch verso l’AP deve trasportare entrambe le reti come trunk. Nel profilo WLAN, Bridge to VLAN ID indica la VLAN dei client; con l’autenticazione Enterprise, l’ID della VLAN client può essere definito in modo statico oppure tramite RADIUS con un fallback statico.

Inizialmente l’AP dovrebbe rimanere collegato al firewall per almeno un minuto tramite la LAN predefinita senza tag, in modo da ricevere la configurazione. Successivamente si attiva VLAN tagging in Wireless > Access points > AP > Advanced settings e si inserisce la AP VLAN ID per la rete di gestione. Solo a questo punto si configura la porta dello switch come trunk. La VLAN di gestione dell’AP e la VLAN dei client possono utilizzare ID differenti. Sophos consiglia di non combinare Separate zone e WLAN basate su VLAN sullo stesso AP. Il tagging VLAN sul lato AP non è disponibile per LocalWiFi0 integrato.

Dopo l’attivazione, per 60 secondi l’AP tenta di ottenere tramite DHCP un indirizzo nella VLAN di gestione configurata. Se non riceve risposta, prova DHCP sulla LAN senza tag come fallback. È un utile percorso di recupero, ma non un criterio di successo: VLAN, trunk e DHCP devono essere corretti finché l’AP non risulta realmente online tramite la VLAN di gestione prevista. Con Bridge to VLAN, SFOS crea automaticamente l’interfaccia VLAN e le relative regole firewall. Questi oggetti devono essere controllati, perché ogni AP crea un’interfaccia backend separata per ogni zona e un design con molti AP e zone può crescere notevolmente.

La zona dell’interfaccia del firewall per la VLAN di gestione degli AP deve essere consentita in Wireless > Wireless settings > Allowed zone. La modalità del traffico client e il VLAN tagging lato AP devono essere coerenti: Bridge to VLAN richiede il tagging sull’AP; per Separate zone, può essere attivato o disattivato. La guida VLAN precedente definisce un ulteriore caso come bridge to an access point VLAN e richiede che il tagging sull’AP sia disattivato. Da questa formulazione non si deve dedurre un’ulteriore opzione dell’interfaccia utente attuale. Per la procedura Bridge to AP LAN senza tag descritta qui, lasciare disattivato il tagging sull’AP; per un progetto diverso, confermare la compatibilità sul modello e sulla build effettivi prima del cambiamento.

Bridge to VLAN evita il percorso VXLAN ed è spesso più indicato per ambienti WLAN di maggiori dimensioni già segmentati correttamente. Anche in questo caso, il traffico all’interno della VLAN dei client non viene controllato automaticamente da SFOS.

Preparare la rete di esempio

L’esempio utilizza questi valori:

Nome in SFOS: Guest WiFi
Hardware name non modificabile: GuestWiFi
SSID visibile: Company Guest
Security mode: WPA2 Personal
Client traffic: Separate zone
Zona: WiFi
Rete dei client: 10.30.40.0/24
Interfaccia e gateway: 10.30.40.1
Intervallo DHCP: da 10.30.40.100 a 10.30.40.220
Regola firewall: WiFi_Guest_to_WAN

10.30.40.0/24 è un esempio tratto dallo spazio di indirizzamento privato. Prima di adottarlo, occorre scegliere una sottorete libera che non si sovrapponga a LAN, VPN, RED, VLAN o a una sede remota. Nell’esempio, il primo indirizzo utilizzabile 10.30.40.1 appartiene all’interfaccia Wireless del firewall e viene distribuito come gateway.

Per i dispositivi APX esistenti, WPA2 Personal con AES costituisce una base compatibile e sicura. Una passphrase lunga e univoca deve essere conservata nel password manager e non in ticket o screenshot. In SFOS 22 Sophos documenta le modalità WPA3 soltanto per la WLAN integrata dei modelli XGS 88w, 108w, 118w e 128w; WPA3 non dovrebbe quindi essere previsto per APX.

L’elenco delle opzioni di sicurezza contiene anche No Encryption, WEP Open, modalità WPA precedenti e modalità miste WPA/WPA2. Queste voci non sono una raccomandazione per un Wi-Fi nuovo o rinnovato: non utilizzare un profilo guest non crittografato né un fallback WEP/TKIP, ma sostituire i client incompatibili o migrarli separatamente. Su XGS 88w, 108w, 118w e 128w è possibile salvare profili con TKIP o AES/TKIP, ma non assegnarli a LocalWiFi0. Su questi modelli, scegliere la modalità WPA3 più robusta supportata da tutti i client previsti, oppure WPA2 Personal con AES, e verificare effettivamente la connessione.

Configurare una WLAN gestita da SFOS

1. Consentire la connessione dell’Access Point

Con un APX esterno, la rete di gestione e la rete dei client WLAN sono due elementi distinti. L’AP riceve il proprio indirizzo di gestione tramite DHCP dalla rete a cui è collegato. I successivi client WLAN ricevono invece indirizzi dalla rete 10.30.40.0/24 pianificata in precedenza.

Aprire Wireless > Wireless settings.
Attivare Enable wireless protection.
In Allowed zone, selezionare la zona attraverso la quale l’AP raggiunge il firewall. SFOS offre DMZ, LAN e WiFi a questo scopo. Confermare la selezione e salvare le impostazioni Wireless con Apply prima di accettare l’AP.
Verificare che l’AP riceva tramite DHCP un indirizzo, un gateway e i DNS. Sull’AP non è possibile configurare un indirizzo di gestione statico.
Verificare che la porta 2712 tra AP e firewall non venga bloccata da uno switch, un’ACL o un dispositivo intermedio.
Aprire Wireless > Access points e accettare un AP pending con Accept.
Impostare il Country corretto sull’AP attivo. Da questa impostazione dipendono i canali consentiti dalla legge. Quando si modifica il Country di un APX, salvare l’impostazione e riavviare quindi l’Access Point in modo controllato, affinché venga applicato il nuovo elenco dei canali.

Su un firewall con due schede Wi-Fi, una modifica di Country interessa entrambe le schede e imposta entrambi i canali su Auto. Documentare preventivamente entrambe le configurazioni radio e controllarle entrambe dopo la modifica. Secondo la guida, su APX 320 entrambe le radio devono essere impostate su 5 GHz per elencare tutti i canali a 5 GHz disponibili; in Israele, tuttavia, Radio 0 supporta solo 2.4 GHz. L’autorizzazione locale del paese ha la precedenza: non utilizzare una selezione Country diversa per forzare i canali.

In Wireless > Wireless settings > Advanced settings, Timeout indica il numero di minuti tra il momento in cui un access point passa offline e la notifica di timeout; trascorso questo periodo, SFOS considera l’AP inactive. Per una verifica controllata, annotare prima il valore esistente e scollegare, durante una finestra di manutenzione, solo un AP di test senza client di produzione. Dopo un intervallo temporaneamente ridotto ma sicuro per l’operatività, devono comparire la notifica e lo stato inactive. Ricollegare quindi l’AP, verificare il ritorno allo stato active e ripristinare il precedente valore di Timeout.

La selezione in Allowed zone riguarda il percorso di gestione dell’Access Point, non la futura zona dei client WLAN. Se l’AP è ancora registrato su un altro Sophos Firewall o in Sophos Fusion, deve prima essere eliminato da quella piattaforma. Se ciò non è possibile, deve essere ripristinato alle impostazioni di fabbrica. Per la dismissione pianificata, rimuovere prima dalla rete l’AP identificato in modo univoco, quindi selezionare tale AP in Wireless > Access points e utilizzare Delete. Verificarne prima l’identità; successivamente, verificare che la relativa voce sia stata rimossa e che gli AP e gli SSID rimanenti continuino a funzionare. Delete non equivale alla rimozione di un’assegnazione WLAN o alla disattivazione di un gruppo; non eliminare un AP in produzione a titolo di prova per risolvere problemi.

La connessione di controllo sulla porta 2712 tra firewall e Access Point è cifrata con AES. L’apertura della porta non sostituisce comunque la limitazione della rete di gestione degli AP alla zona che ne ha realmente bisogno.

2. Creare una Wireless Network

In Wireless > Wireless networks > Add si inseriscono i valori dell’esempio:

Name: Guest WiFi
Hardware name: GuestWiFi
SSID: Company Guest
Security mode: WPA2 Personal
Passphrase: una passphrase lunga e univoca
Client traffic: Separate zone
Zone: WiFi
IP address: 10.30.40.1
Netmask: /24

Il Hardware name può contenere al massimo dieci caratteri tra lettere, numeri e caratteri di sottolineatura e non può essere modificato in seguito. Name supporta fino a 58 caratteri e l’SSID da 1 a 32 caratteri ASCII stampabili. Entrambi possono essere adattati alla convenzione di denominazione locale. Il Name della rete wireless può essere modificato in seguito e viene visualizzato nelle altre impostazioni al posto del Hardware name. In questo campo sono consentiti tutti i caratteri tranne '"<>#%\/,; non applicare questa restrizione a SSID, Hardware name o Passphrase.

In Advanced settings, per l’esempio della rete ospiti sono appropriate queste scelte:

Encryption: AES
Frequency band: soltanto le bande supportate dal modello e dai moduli radio utilizzati
Client isolation: attivare se non sono desiderate connessioni dirette tra gli ospiti
Hide SSID: lasciare disattivato
Fast transition: utilizza IEEE 802.11r e richiede WPA2 come Security mode. APX non supporta questa funzione. Utilizzarla solo su hardware compatibile non APX, dopo aver verificato il modello, la build SFOS e i client; ciò non implica né il supporto di AP6 né l’approvazione per tutti i modelli W o per WPA3.
Time-based access: controlla gli orari di accesso consentiti per questo SSID. Utilizzare Add new item per selezionare una pianificazione adatta o crearne una propria. Eseguire l’attivazione e le modifiche alla configurazione durante una finestra di interruzione pianificata, perché l’attivazione riavvia hostapd e disconnette tutti i client dell’AP interessato, come descritto di seguito. Utilizzare un client di prova per verificare sia il periodo previsto di accesso consentito sia quello di accesso bloccato; questa pianificazione dell’accesso non è la pianificazione delle scansioni radio o degli AP non autorizzati.

Client isolation blocca soltanto la comunicazione diretta tra i client dello stesso SSID sulla stessa radio. Non sostituisce la separazione tramite zone, VLAN e regole firewall tra più AP o moduli radio. Nascondere l’SSID non è neppure una misura di sicurezza: impedisce soltanto la visualizzazione del nome della rete.

Per la WLAN integrata, il Dual-Band simultaneo dipende dall’hardware. XGS 87w e 107w trasmettono soltanto su 2.4 GHz oppure 5 GHz. XGS 116w, 126w e 136w richiedono un secondo modulo radio per utilizzare entrambe le bande. XGS 88w, 108w, 118w e 128w possono utilizzare contemporaneamente entrambe le bande senza un modulo aggiuntivo.

Quando si attiva una pianificazione Wireless, SFOS riavvia hostapd. Tutti i client WLAN dell’Access Point interessato vengono quindi disconnessi brevemente, non soltanto i client di questo SSID. I dispositivi dovrebbero riconnettersi automaticamente.

Se si desidera bloccare anche un dispositivo noto, in Hosts and services > MAC host > Add creare, ad esempio, Bad hosts con Type: MAC list, inserire gli indirizzi MAC effettivamente da bloccare e salvare. Nel profilo guest, in Advanced settings > MAC filtering, selezionare l’opzione della lista di blocco, assegnare questa MAC list e salvare il Wireless Network con Save. La guida Separate zone chiama questa opzione Blacklist; verificare il nome della lista di blocco nella build utilizzata. Con un dispositivo di prova bloccato e uno consentito, verificare che venga rifiutato solo quello bloccato. Un indirizzo MAC contraffatto o randomizzato può aggirare questo blocco: il blocco non dimostra né il rilevamento di malware né che un dispositivo sia pulito e non sostituisce le policy di protezione o la separazione delle reti. Allowed zone consente il percorso di gestione dell’AP; la sola attivazione di Wireless Protection non dimostra che tutti i pacchetti Wi-Fi o LAN vengano controllati per rilevare malware.

Collaudare separatamente Wi-Fi Enterprise e RADIUS

Per una rete Wireless che usa 802.1X, il server RADIUS viene selezionato in Wireless > Wireless settings. L’Access Point non comunica direttamente con il server RADIUS: usa la porta 414 per comunicare con il firewall durante l’autenticazione e la porta 417 per l’Accounting. Il firewall inoltra quindi l’Accounting alla porta RADIUS configurata, normalmente la 1813.

Per l’autenticazione Enterprise, utilizzare Wireless network Name come NAS ID, non automaticamente l’SSID visibile o Hardware name. Questi valori possono essere diversi. Adeguare la policy RADIUS a questo nome e verificare nel log di autenticazione di un client di prova che vengano utilizzate la NAS ID e la policy previste; verificare separatamente autenticazione e accounting.

L’Accounting deve essere attivo sul server RADIUS; questo percorso Wireless non supporta gli Interim Accounting Updates. Il Secondary RADIUS server non deve essere pianificato come failover generale: APX e i dispositivi compatibili con Wi-Fi possono usare solo il server RADIUS primario, mentre gli XGS Appliances non supportano un server RADIUS secondario per questo flusso.

Per questo percorso wireless gestito da SFOS, le impostazioni Wireless di SFOS 22 e 23 richiedono un’associazione NAT per le reti degli access point quando il server RADIUS è collegato al firewall tramite un tunnel IPsec. L’IP sorgente deve essere tradotto esattamente nell’indirizzo IP del firewall attraverso il quale il firewall raggiunge il server RADIUS. Si tratta delle reti degli AP, non della rete dei client wireless in generale. La guida rimanda alla configurazione tramite shell con sys-traffic-nat, ma non fornisce qui un comando completo ed eseguibile. Ciò non stabilisce un requisito generale di NAT per altri percorsi RADIUS.

Prima di apportare una modifica, documentare la versione e il build esatti di SFOS, le reti degli AP, l’indirizzo sorgente effettivamente utilizzato, l’IP previsto del firewall per la traduzione, il tunnel e i Traffic Selectors, il percorso di ritorno e i log RADIUS. Senza una sintassi confermata per questo build e percorso dati, non apportare modifiche nella shell: chiedere a Sophos Support di confermare la shell supportata, i parametri e gli indirizzi da utilizzare, insieme ai controlli preliminari, alla verifica del risultato e alla procedura esatta di ripristino. Eseguire la modifica soltanto in una finestra di manutenzione seguendo tale procedura confermata; poi verificare l’autenticazione 802.1X e l’Accounting con un client di prova e confrontare l’IP sorgente osservato sul server RADIUS e il percorso di risposta con i valori previsti. In caso di differenze, non ampliare le regole di accesso: esaminare le evidenze con Support e utilizzare la procedura di ripristino confermata se necessario.

Il traffico di autenticazione generato dal firewall va distinto dal traffico dei client inoltrato. L’articolo sulle route IPsec per il traffico inoltrato spiega system ipsec_route e NAT per quel percorso di inoltro; non contiene una procedura sys-traffic-nat. Né il suo DNAT/SNAT riflessivo né una regola da LAN a VPN sostituiscono la configurazione NAT del traffico di sistema richiesta qui.

Dopo aver configurato le impostazioni generali e avanzate e, se applicabile, le impostazioni Enterprise e del filtro MAC, salvare il Wireless Network con Save – anche se non viene utilizzata alcuna lista di blocco MAC. In Wireless > Wireless networks, verificare che Guest WiFi compaia con le impostazioni previste. Solo successivamente creare il server DHCP su questa interfaccia e assegnare la rete a un AP come descritto di seguito. Unplugged prima dell’assegnazione a un AP non è un motivo per ricreare il profilo o crearlo con una modalità di traffico diversa.

3. Aggiungere DHCP per la rete dei client

Per Separate zone non viene predisposto automaticamente un server DHCP completo per i client. In Network > DHCP > Server > Add si crea quindi, ad esempio, questa configurazione:

Name: dhcp-wifi-guest
Interface: Guest WiFi
Dynamic IP lease: da 10.30.40.100 a 10.30.40.220
Subnet mask: /24
Gateway: Use interface IP as gateway
DNS server: adatto alla propria architettura DNS
Conflict detection: attivato

L’intervallo si trova volutamente al di sopra dell’indirizzo dell’interfaccia e lascia spazio per gli indirizzi riservati. In una WLAN per ospiti con un ricambio elevato può essere utile una durata del lease più breve rispetto a una rete aziendale stabile. Lease estremamente brevi generano invece rinnovi inutilmente frequenti.

La scelta dei server DNS distribuiti è una decisione di sicurezza e operativa. I server DNS AD interni non dovrebbero essere resi accessibili agli ospiti soltanto per comodità. L’articolo su come configurare Sophos Firewall come server DHCP descrive la pianificazione completa e il controllo dei lease.

4. Verificare regola firewall, NAT e servizi locali

In Rules and policies > Firewall rules > Add firewall rule > New firewall rule si crea una regola per l’accesso a Internet desiderato. L’articolo sulle regole di Sophos Firewall spiega l’intera maschera, l’ordine delle regole e le Security Features.

Rule name: WiFi_Guest_to_WAN
Action: Accept
Log firewall traffic: attivato
Source zones: WiFi
Source networks and devices: oggetto di rete per 10.30.40.0/24
Destination zones: WAN
Destination networks: Any
Services: soltanto i servizi necessari per la WLAN degli ospiti
Security features: policy Web, Application e IPS adatte alla licenza e allo scopo d’uso

Un oggetto di rete descrittivo come net_WiFi_Guest rende la regola più restrittiva e comprensibile rispetto a Source networks: Any. La scelta dei Services dipende dall’utilizzo di DNS e NTP localmente sul firewall oppure direttamente all’esterno. Un’autorizzazione generica Any è comoda, ma rende più difficile il controllo successivo.

Una regola NAT deve inoltre tradurre il traffico in uscita sull’indirizzo WAN. La regola Default-SNAT esistente con MASQ copre spesso anche le nuove reti interne. È però necessario verificarlo nel set di regole specifico, invece di creare per precauzione una seconda regola NAT. L’articolo Comprendere il NAT su Sophos Firewall ne spiega il funzionamento.

Una regola WiFi-to-WAN non impedisce automaticamente gli accessi consentiti da regole WiFi-to-LAN o Any già esistenti e troppo ampie. Occorre quindi controllare l’intero ordine delle regole alla ricerca di autorizzazioni verso reti interne. Se i client della stessa rete Separate-Zone devono comunicare tra loro attraverso più AP, è necessaria anche una regola WiFi-to-WiFi. In una WLAN per ospiti, questa comunicazione dovrebbe essere consentita soltanto in modo intenzionale.

Gli accessi al firewall stesso non vengono gestiti dalla normale regola firewall. In Administration > Device access, verificare le autorizzazioni WiFi effettivamente configurate per HTTPS e SSH, anziché presumere una determinata impostazione predefinita. Per una WLAN per ospiti si devono quindi rimuovere in Administration > Device access le spunte WiFi per HTTPS, SSH e tutti gli altri servizi locali non necessari. DNS rimane consentito soltanto se i client utilizzano effettivamente il firewall come resolver. L’articolo su Device Access e Local Service ACL ne spiega i principi.

5. Assegnare la WLAN a un Access Point

Una Wireless Network salvata non viene ancora trasmessa da alcun Access Point:

Aprire Wireless > Access points.
Aprire l’Access Point attivo tramite il suo nome oppure Edit.
Verificare il Country corretto.
In Wireless networks, fare clic su Add new item.
Selezionare Guest WiFi, confermare con Apply e fare clic su Save.

Con più Access Point, un gruppo in Wireless > Access point groups è più chiaro. In questo modo gli SSID vengono assegnati in modo coerente e non gestiti diversamente per ogni AP. A un AP possono essere assegnate fino a otto Wireless Network.

Il gruppo si crea in Wireless > Access point groups > Add con nome, Wireless networks, VLAN tagging opzionale e gli Access points inclusi. Prima di salvare va verificato che l’assegnazione VLAN sia davvero adatta a tutti gli AP selezionati.

⚠️ Impatto operativo: Disattivando un gruppo di Access Point, tutti gli AP inclusi interrompono la trasmissione delle reti Wi-Fi assegnate. Una modifica al gruppo va quindi pianificata in una finestra di manutenzione con un elenco documentato di AP e SSID.

Modificare consapevolmente i parametri radio e i gruppi di AP

In Wireless > Access points > AP > Advanced settings, canale, Dyn chan, TX power e Channel width interessano più di un singolo client di prova. Un cambio dinamico del canale può obbligare i client connessi a riconnettersi. Canali più ampi possono aumentare il throughput in ambienti a bassa densità, ma la maggiore sovrapposizione può ridurlo in ambienti ad alta densità. SFOS utilizza per impostazione predefinita 20 MHz a 2,4 GHz e 40 MHz a 5 GHz. Potenza di trasmissione e larghezza del canale devono quindi essere misurate per ogni sede, non semplicemente massimizzate.

Turn on Spanning Tree Protocol (STP) protegge le reti in bridge dai loop di livello 2 e dalle conseguenti broadcast storm. STP non deve essere considerato un interruttore per le prestazioni. Dopo una modifica si testano almeno due client reali, roaming, DHCP, DNS e un trasferimento prolungato; con la selezione automatica del canale si registrano anche l’orario del cambio e la corretta riconnessione dei client.

Se la selezione dinamica del canale deve essere eseguita solo in orari prestabiliti, attivare prima Dyn chan, poi Time-based scan per ciascuna banda e assegnare il Schedule previsto in Select scan time > Add new item oppure crearlo tramite Add. Dopo Save, osservare l’orario della scansione e un’eventuale riconnessione dei client. Prima di modificare i gruppi, identificare univocamente l’AP tramite ID (numero di serie), Label e Group. Una singola WLAN può essere nuovamente deselezionata nei relativi dettagli AP tramite remove; quindi salvare e verificare gli altri SSID. Questo non equivale a disattivare l’intero gruppo di AP. Per un riavvio pianificato dell’AP, è possibile riavviare l’AP selezionato in Wireless > Access points tramite Restart; prima salvare l’elenco dei client e i log, quindi ripetere i test di connessione descritti di seguito.

Testare la WLAN in modo controllato

Il collaudo non dovrebbe terminare quando «l’SSID è visibile». Con un client di test si verifica che vengano effettivamente utilizzate la rete e le regole pianificate:

In Wireless > Access points, l’AP deve essere attivo. In Network > Interfaces, l’interfaccia Wireless rimane su Unplugged finché nessun AP è collegato a questa Wireless Network.
Collegarsi a Company Guest e controllare AP, SSID, frequenza e segnale in Wireless > Wireless client list.
In Network > DHCP > IPv4 lease, verificare che il client abbia ricevuto un indirizzo compreso tra 10.30.40.100 e 10.30.40.220.
Controllare sul client indirizzo IP, gateway e DNS. In Windows sono utili:

ipconfig /all
nslookup example.com

Verificare una connessione Internet consentita e, intenzionalmente, una destinazione interna non consentita.
Nel Log Viewer, filtrare per l’indirizzo IP del client e controllare la Firewall Rule ID e la NAT Rule ID previste.

Il successo non consiste soltanto nell’accesso a Internet. Il client deve utilizzare il gateway e i server DNS previsti, rimanere separato dalle destinazioni interne non consentite e passare esattamente attraverso le regole firewall e NAT attese. La procedura generale è descritta nell’articolo su come testare correttamente le regole firewall.

Cercare gli access point rogue in modo controllato

Rogue AP scan è disponibile solo sulle appliance Sophos Firewall con Wi-Fi integrato; gli access point APX esterni non possono eseguire questa scansione. In Wireless > Rogue AP scan, Scan now cerca gli access point entro la portata radio. Durante la scansione, i client Wi-Fi connessi vengono disconnessi brevemente. Una scansione manuale o pianificata va quindi eseguita in una finestra temporale nota e non senza preavviso durante l’esercizio produttivo.

I dispositivi rilevati compaiono in Unrecognized access points e vengono contrassegnati consapevolmente come autorizzati o come Rogue AP. Questa classificazione non sostituisce l’analisi di un incidente: SSID, BSSID, canale, segnale, posizione ed eventuale porta dello switch devono essere correlati prima di trattare una rete Wi-Fi sconosciuta come un dispositivo della propria LAN.

Per le scansioni ricorrenti si seleziona una pianificazione in General settings > Schedule system-triggered scan at. Con LocalWiFi0, Bridge to Ethernet attivo e una rete Wireless in modalità Bridge to AP LAN, la scansione mostra solo le reti vicine nella stessa banda di frequenza della rete Wireless assegnata. Questo limite del prodotto deve essere documentato durante la valutazione del risultato.

Applicare la pianificazione della scansione con Apply. Nei risultati, utilizzare le azioni Mark as “authorized access point” o Mark as “rogue access point” e verificare l’assegnazione risultante. Una voce contrassegnata come rogue è una classificazione, non un meccanismo comprovato per spegnere o bloccare un access point di terzi.

Individuare gli errori tipici

L’SSID non viene visualizzato

Verificare innanzitutto che Wireless Protection sia attiva, che la zona di gestione dell’AP sia presente in Allowed zone e che l’Access Point risulti active, e non pending o inactive, in Wireless > Access points. Controllare quindi Country, Wireless Network assegnata, Frequency band ed eventuale pianificazione.

Una rete salvata senza assegnazione a un AP non viene trasmessa. Con una WLAN integrata, anche i limiti del modello relativi alle bande radio oppure una vecchia modalità di cifratura non supportata possono impedire l’associazione del profilo a LocalWiFi0.

L’interfaccia Separate zone rimane `Unplugged`

Lo stato Unplugged è normale finché non è connesso alcun Access Point o la Wireless Network non è assegnata a un AP. Se lo stato rimane nonostante un APX attivo e l’assegnazione corretta, occorre controllare il percorso di gestione dell’Access Point.

Su SFOS 21.5 MR1 Build 261, il problema può verificarsi quando l’indirizzo IP del firewall utilizzato dalla rete di gestione dell’APX è configurato come alias anziché direttamente sull’interfaccia parent (NC-175920). SFOS non riesce quindi a creare il tunnel VXLAN per Separate zone. La soluzione consiste nello spostare l’APX in una rete di gestione il cui indirizzo IP del firewall sia configurato direttamente sull’interfaccia parent. Non si deve eliminare l’indirizzo alias senza aver prima confermato la causa.

La modifica interrompe le reti Wi-Fi trasmesse dall’AP. Prima occorre quindi verificare DHCP, gateway, Allowed zone e la porta 2712 nella rete di destinazione, quindi eseguire la modifica durante una finestra di manutenzione. In seguito si controllano stato dell’AP, assegnazione della rete Wi-Fi, stato dell’interfaccia e connessione di un client di test. Sophos non indica una versione corretta; sulle altre versioni SFOS il solo stato Unplugged non dimostra quindi questo problema.

Il client non riceve un indirizzo IP

Con Separate zone, il server DHCP deve risiedere sull’interfaccia Wireless creata e l’intervallo deve corrispondere alla rete dell’interfaccia. Con Bridge to AP LAN risponde invece il server DHCP della LAN dell’AP. Con Bridge to VLAN si controllano insieme il trunk dello switch, l’ID VLAN e il server DHCP raggiungibile nella VLAN dei client.

Il DHCP di gestione dell’AP e il DHCP dei client non devono essere confusi: l’AP può essere online anche se non esiste ancora un server DHCP funzionante per i client WLAN.

Il client ha un indirizzo IP ma non accede a Internet

In questo caso, DHCP e connessione radio hanno già superato una parte della verifica, ma resta da controllare la policy. Si verificano quindi gateway e DNS, la regola WiFi-to-WAN, l’ordine delle regole, il logging e la regola MASQ/SNAT appropriata. Il Log Viewer mostra se corrisponde la Firewall Rule ID prevista oppure se la regola implicita #0 scarta il traffico.

Se il client raggiunge Internet ma anche i sistemi interni, il risultato non è corretto per una WLAN per ospiti. Probabilmente stanno intervenendo regole WiFi-to-LAN, Any oppure regole di rete troppo ampie.

La connessione dell’AP o la comunicazione dei client non è chiara

Il traffico firewall compare in modo affidabile nel Log Viewer soltanto quando sono attivi sia Log firewall traffic nella regola sia il tipo di log firewall in System services > Log settings > Local reporting. Gli eventi Wireless non sono disponibili in questa posizione come normale tipo di log Wireless locale; in System services > Log settings possono essere inviati a Sophos Fusion o a un server Syslog.

Per una diagnosi più approfondita, Sophos documenta awed.log per la comunicazione tra firewall e APX, wc_remote.log per i client Wireless e hostapd.log per LocalWiFi. L’articolo su come verificare servizi e log di Sophos Firewall tramite CLI spiega come leggere questi log senza riavviare in modo incontrollato un servizio.

Se necessario, il log di un APX raggiungibile può essere letto tramite awetool. Accedere alla CLI del firewall come admin, selezionare 5 – Device Management, poi 3 – Advanced Shell e avviare awetool. Selezionare Connect to an AP, scegliere l’AP di destinazione in base alla sua identità, confermare con OK e completare la connessione con y. Solo su questo AP, logread e logread -f sono le verifiche in lettura documentate. Il comando reboot, anch’esso disponibile, disconnette i client e modifica lo stato; deve essere eseguito solo dopo il salvataggio dei log, durante una finestra di manutenzione e con un successivo controllo dello stato dell’AP, dell’SSID, dell’elenco dei client e del traffico reale. Non applicare questi passaggi della shell APX ad AP6, a LocalWiFi integrato o a UTM.

I trasferimenti di grandi dimensioni sono lenti o si interrompono

Se il problema riguarda soltanto i pacchetti di maggiori dimensioni o i trasferimenti più lunghi, l’incapsulamento VXLAN di Separate zone può essere una causa. Non esiste un valore MTU valido in generale. Si documentano prima Rule ID, percorso dei dati, Retransmits e un test applicativo riproducibile. Solo dopo aver dimostrato un problema MTU/MSS si modifica la configurazione in modo controllato e si ripete lo stesso test.

Inquadrare in sicurezza gli oggetti wireless tramite XML API

Chi automatizza le impostazioni descritte sopra deve trattare separatamente il profilo di rete, la componente radio locale, il gruppo di AP e le impostazioni wireless globali. I riferimenti XML per SFOS 22 e 23 documentano gli oggetti seguenti, ma non autorizzano l’invio di una richiesta di scrittura copiata senza modifiche. Accesso, operazioni esplicite, valutazione delle risposte e ripetizioni sicure sono spiegati in Proteggere l’accesso alla XML API di Sophos Firewall. Prima di apportare modifiche, salvare lo stato esistente degli oggetti, le dipendenze e un percorso di ripristino confermato. In presenza dei conflitti tra fonti indicati di seguito, chiarire prima i campi di scrittura interessati in API help della build installata oppure con il supporto; fino ad allora non inviarli. Tutti i codici seguenti sono valori di stato XML specifici dell’oggetto, non codici di stato HTTP; tutti i simboli Message.* sono chiavi di riferimento non risolte, non testi confermati restituiti in fase di esecuzione. Registrare insieme l’operazione, il codice e la risposta effettiva opportunamente depurata.

WirelessLocalAP: identità e parametri radio del modello W

WirelessLocalAP appartiene all’access point locale integrato di un’appliance wireless compatibile, non all’interfaccia web locale di un AP6 né alla sua gestione tramite Central/Fusion. Da questo contratto non deriva né un nuovo flusso API per APX né una guida per i vecchi dispositivi AP/UTM. Il campo obbligatorio Id identifica l’AP locale esistente; Label è una denominazione facoltativa, non un’identità sostitutiva. L’esempio di riferimento riporta LocalWifi0/LocalWifi1, mentre la guida dell’interfaccia usa LocalWiFi0. Non correggere tacitamente maiuscole e minuscole e non inviare la stringa con la barra come ID comune: confermare la singola identità effettiva nel risultato di lettura/esportazione appropriato per la build. Country deve corrispondere alla posizione reale, non all’esempio In.

Nell’esempio, le assegnazioni di rete si trovano sotto WirelessNetworks/Network. La tabella descrive Network come array e avverte che i valori duplicati non vengono ignorati. Pertanto, verificare integralmente le assegnazioni esistenti e non inviare un elenco di SSID o nomi di rete ipotizzati. Il limite di otto reti wireless assegnate e i limiti hardware delle bande radio restano rilevanti anche nell’automazione.

Per l’assegnazione delle bande, la tabella descrive Band con 2.4GHz o 5GHz, per 2,4 GHz Channel, ChannelWidth, TXPower, DynChan e TimeBasedScan, e per 5 GHz invece Channel5GHz, ChannelWidth11a, TXPower5GHz, DynChan5GHz e TimeBasedScan5GHz. L’esempio mostra gli orari di scansione sotto ScanTime/Time; la tabella elenca Time due volte come array dipendente dalla banda, senza mostrare in modo univoco la struttura padre per entrambe le bande. Confermare la corretta struttura padre per ciascuna banda prima di una richiesta di scrittura, anziché raggruppare tutte le voci Time o inventare un elemento padre per 5 GHz. Gli orari di scansione radio non sono la pianificazione di accesso all’SSID.

Diverse indicazioni si contraddicono: l’esempio usa Channel2.4GHz, la tabella Channel; per DynChan e TimeBasedScan l’esempio riporta Enable, mentre gli elenchi dei valori riportano solo t. Per TXPower l’esempio mostra 100, mentre la tabella riporta 10%, 25%, 50%, 75%, 100%. Anche il testo sull’assegnazione della banda di DynChan non è univoco. Queste forme non sono confermate come valori intercambiabili. La descrizione dell’esportazione per DynChan5GHz distingue inoltre Disabled (canale statico, scansione dinamica disattivata), 1 (canale automatico senza scansione dinamica) e Enabled (canale automatico con scansione dinamica); non considerare automaticamente i valori esportati come input di scrittura ammessi.

BridgeToEthernet, BridgeToPort e Zone riguardano il bridge Ethernet locale, non l’ID VLAN dei client di un profilo di rete. Restano validi i limiti Gen.1/Gen.2, i prerequisiti IPv4/Bridge-to-AP-LAN e le verifiche DHCP/accesso amministrativo descritti sopra. Dopo una modifica confermata, verificare entrambe le radio interessate, il paese, le assegnazioni di rete, il bridge e un client reale prima di modificare altri AP.

La sezione Status Message Information per l’operazione Update Local AP associa, in entrambe le versioni del riferimento, questi valori di stato 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.

Si tratta di chiavi di riferimento letterali non risolte, non di messaggi di esecuzione verificati. In particolare, non dedurre da Message.TopazToNonTopazImportFail un’associazione a modelli o una migrazione tramite importazione consentita. In caso di risposta poco chiara, rileggere l’identità dell’AP, i parametri radio e le assegnazioni salvati, senza ripetere automaticamente lo stesso aggiornamento né indebolire la cifratura.

WiFi6Interface: interfaccia esistente, non SSID o bridge

Nei riferimenti XML per SFOS 22 e 23, WiFi6Interface gestisce le impostazioni di rete e zona per porta di LocalWiFi6, non un profilo SSID o un bridge fisico. I campi obbligatori sono Name, Hardware e Zone: Name è la denominazione descrittiva con un massimo di 58 caratteri; Hardware indica il nome hardware dell’interfaccia già esistente. Prima di una modifica, confermare questa identità nel risultato di lettura/esportazione appropriato per la build, senza dedurla dal nome visualizzato, da SSID o da WirelessNetworks.HardwareName. Il vincolo di dieci caratteri tra A-Za-z0-9_ previsto per il nome hardware di un bridge fisico non si applica qui; la tabella WiFi6Interface indica per Hardware soltanto una stringa. Nemmeno dal nome dell’oggetto API si può dedurre un’associazione a una generazione hardware. Restano invariate le verifiche del bridge nella GUI, del DHCP e dell’accesso amministrativo descritte sopra, che dipendono dal modello.

IPv4Address e Netmask sono facoltativi in questo contratto. Ciò non implica né l’obbligo di impostare un nuovo indirizzo né un effetto confermato in caso di omissione dei valori esistenti. Prima delle modifiche, documentare la porta effettiva, la zona e l’eventuale indirizzo IP esistente con la relativa maschera; successivamente, rileggere lo stato della stessa interfaccia e confrontarlo con il piano di indirizzamento previsto. Questo confronto dell’interfaccia non sostituisce né la verifica dell’assegnazione agli AP e dell’SSID né il test con un client reale.

Per l’operazione WiFi6Interface, entrambe le fonti riportano 200/Message.InterfaceUpdateSuccess, 500/Message.InterfaceUpdateFail e 502/Message.InterfaceIPAlreadyInUsed. Si tratta di valori di stato XML specifici dell’oggetto con chiavi di riferimento non risolte, non di codici HTTP o testi confermati restituiti in fase di esecuzione. Registrare insieme l’operazione, il codice e la risposta effettiva opportunamente depurata. Se il risultato non è chiaro, rileggere prima l’identità hardware, la porta, la zona ed eventualmente IP/Netmask, anziché ripetere automaticamente lo stesso aggiornamento o creare un altro oggetto wireless. Un codice di successo, da solo, non dimostra né la corretta assegnazione di rete né il funzionamento del traffico WLAN; da quanto descritto qui non deriva alcuna nuova richiesta di scrittura.

WirelessNetworks: distinguere identità hardware, profilo e stato

In WirelessNetworks, il Hardware name immutabile, il nome visualizzato modificabile Name e l’SSID trasmesso sono valori diversi. Nell’esempio per gli ospiti, questi sono GuestWiFi, Guest WiFi e Company Guest. La tabella dei parametri di aggiunta/aggiornamento richiede HardwareName con un massimo di dieci caratteri; anche l’operazione di eliminazione identifica la destinazione tramite HardwareName, non tramite SSID o nome visualizzato. Prima di un’eliminazione, controllare le assegnazioni agli AP, l’interfaccia, il DHCP e le regole, e rimuovere solo la destinazione identificata in modo univoco e approvata. Un errore non giustifica la creazione ripetuta del profilo con un nuovo nome.

L’esempio di aggiunta/aggiornamento usa tuttavia Hardware anziché HardwareName e ClientIsolation con Enable anziché il valore della tabella Enabled. Per HideSSID è presente la stessa discrepanza; la tabella indica per TimeBasedAccess, ClientIsolation, HideSSID e FastTransition i valori Enabled/Disabled. Anche MACFiltering con Allowlist/Blocklist compare accanto a una descrizione precedente di MACList con Whitelist/Blacklist. Non risolvere nessuna di queste discrepanze per supposizione. Il contratto XML elenca inoltre modalità di sicurezza precedenti, mentre la guida attuale dell’interfaccia descrive WPA3 solo per i modelli W sopra indicati: da ciò non deriva una sintassi di scrittura WPA3 completa.

I token di traffico documentati SeparateZone, BridgetoAPLAN e BridgetoVLAN appartengono a ClientTraffic. IPAddress e Netmask si riferiscono a Separate zone; BridgetoVLANid alla VLAN dei client, ClientVlanId a Static oppure RadiusAndStatic. Non confondere questi valori con la VLAN di gestione degli AP. La chiave dell’esempio, l’IP pubblico dell’esempio e TKIP(only abg) non devono essere adottati: l’obiettivo resta AES oppure una modalità di sicurezza più forte di cui sia comprovato il supporto, una propria passphrase sicura e una separazione controllata delle reti. ClientIsolation continua a non sostituire un confine firewall o VLAN tra più radio/AP.

Per Add Wireless Network, entrambi i riferimenti indicano le seguenti associazioni:

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.

Per Update Wireless Network, diverse chiavi differiscono nonostante i codici siano gli stessi:

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.

Per Delete Wireless Network sono documentati 200/Message.WPNetworkDeleteSuccess, 500/Message.WPNetworkDeleteFail, 541/Message.BridgeWirelessNetworkExists e 542/Message.WPEnableDeteleFail. Anche apparenti errori di scrittura come Message.SecModeChangedToWAP3Fail e Message.WPEnableDeteleFail restano invariati; non vengono rinominati come presunti messaggi di esecuzione corretti. In presenza di queste risposte, verificare prima l’identità hardware, l’IP, le dipendenze DHCP, il bridge e le assegnazioni agli AP effettivamente salvati. Non affermare, sulla base di una sola chiave, una causa, un ripristino riuscito o la sicurezza di un nuovo tentativo.

WirelessNetworkStatus è un oggetto separato: la sua tabella descrive espressamente Name come nome dell’interfaccia con un massimo di dieci caratteri, non come alias automatico dell’SSID o del nome visualizzato. Qui Status usa Enable/Disable, non i valori Enabled/Disabled di altri campi. Confermare prima il nome effettivo dell’interfaccia. Per Enable-Disable Wireless Network sono indicati 200/Message.WPNetworkUpdateSuccessfully e 500/Message.WPNetworkUpdateFail. Una modifica dello stato non assegna la rete a un AP e non dimostra ancora che venga trasmessa; verificare separatamente lo stato salvato, l’assegnazione agli AP e la connessione del client.

WirelessGrouping: l’appartenenza a un gruppo non è una configurazione radio

WirelessGrouping descrive un gruppo di AP con Name e le voci ripetibili WirelessNetworks/Network e AccessPoints/AccessPoint. Utilizzare le identità degli AP presenti nell’inventario esistente, non il vecchio esempio AP30 del riferimento. La struttura del gruppo configura le assegnazioni di rete e il tagging facoltativo della gestione degli AP, ma non i parametri radio locali dipendenti dalla banda. La presenza di array facoltativi non implica una semantica confermata per elenchi vuoti o un aggiornamento parziale sicuro.

VLANTagging indica Enable/Disable; APVLANID indica da 1 a 4094 e si applica quando il tagging è attivato. Si tratta della VLAN di gestione degli AP, non di BridgetoVLANid per i client. Prima delle modifiche, verificare l’intero elenco dei membri, il trunk, il DHCP di gestione, Allowed zone e il percorso di ripristino. La disattivazione di un gruppo continua a interrompere la trasmissione dei suoi AP; dopo una modifica confermata, controllare ogni AP interessato e gli SSID previsti.

Per Add an Access Point Group sono indicati 200, 216/Message.WPGroupSuccess, 500, 541, 543, 545/Message.WPGroupCreated, 502/Message.WPGroupExists, 523/Message.WPGroupMax, 524/Message.WPGroupMaxAP e 546/Message.WPA3IsNotSupported. Per Update an Access Point Group sono invece indicati 200, 216/Message.WPGroupUpdateSuccessfully, 500, 541, 543, 545/Message.WPGroupUpdateFail, 523/Message.WPGroupMaxForUpdate, 524/Message.WPGroupMaxAPForUpdate e 546/Message.WPA3IsNotSupported. La chiave fuorviante Message.WPGroupCreated associata a codici di errore non garantisce il successo. Prima di un nuovo tentativo, rileggere il gruppo e i membri salvati, anziché creare un secondo gruppo o aggiungere altri AP.

Impostazioni globali: accesso di gestione e conseguenze

WirelessProtectionGlobalSettings non è né un profilo SSID né una zona client. Nell’esempio, AllowedZone/Zone contiene le zone di gestione ripetibili; NotificationTimeout corrisponde al timeout di notifica offline in minuti spiegato sopra. RADIUSServer indica il server selezionato globalmente per il percorso Enterprise descritto. Per il selettore, l’esempio usa WirelessProtection, mentre la tabella usa EnableWirelessProtection: anche questi nomi di campo discordanti devono essere chiariti per la build specifica prima di una richiesta di scrittura.

Per Global Settings, entrambi i riferimenti indicano 200/Message.WLANAPEditSuccessful, 500/Message.WLANAPEditFailed, 501/Message.WLANAPIPAlreadyInUsed e 504/Message.WLANAPIntBaseVHExist. Ulteriori distinzioni sono:

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

Le chiavi non vengono interpretate come cause di errore comprovate, ma mostrano perché una modifica globale non debba essere trattata come un test innocuo: le associazioni delle interfacce e la configurazione DHCP possono essere interessate. Non disattivare e riattivare Wireless Protection per una diagnosi rapida. Prima di una modifica pianificata, acquisire un backup e documentare un accesso amministrativo indipendente, le interfacce, i server/relay DHCP e le assegnazioni agli AP. Successivamente, rileggere lo stato globale effettivamente salvato e i servizi interessati, verificare la raggiungibilità degli AP e i client, e solo sulla base di queste evidenze decidere se ripetere l’operazione o seguire il percorso di ripristino confermato. Un codice XML di successo, da solo, non dimostra né l’effetto sulle radio né il completo successo della configurazione.