Vai al contenuto
Avanet
Accedi

Configurare e testare Wireless Mesh su Sophos Firewall in un'installazione APX esistente

Wireless Mesh su Sophos Firewall collega in modalità wireless uno o più Sophos Access Point APX a un AP root cablato. Può coprire una zona senza segnale quando nella posizione remota non è disponibile un cablaggio Ethernet. Il backhaul mesh non è l’SSID WLAN visibile: SFOS crea una rete WPA2-Personal nascosta con una passphrase casuale. I client continuano a utilizzare un Wireless Network configurato separatamente.

⚠️ Importante: Questa guida vale per installazioni APX esistenti gestite direttamente da SFOS. APX può formare una mesh solo con APX. AP6, LocalWiFi integrato, moduli Wi-Fi SD-RED e serie di AP Sophos miste non rientrano in questa procedura. Una mesh non sostituisce inoltre la ridondanza cablata: almeno un AP rimane collegato alla LAN e SFOS non esegue un cambio automatico del root se l’AP root si guasta.

Ambito: gestione di un’installazione esistente, non di una nuova piattaforma WLAN

I passaggi seguenti descrivono una mesh legacy gestita dal firewall per un gruppo APX esistente, non la realizzazione di una nuova piattaforma APX o UTM. Prima di qualsiasi modifica, occorre confermare il supporto per lo specifico modello di AP, la sua revisione hardware e la build SFOS effettivamente in uso. La guida Wireless di SFOS 22 e SFOS 23 contiene procedure mesh precedenti; la presenza di una pagina della guida non dimostra il supporto hardware. In particolare, non se ne può dedurre la possibilità di aggiornare a SFOS 23 un’installazione APX. Se il supporto non è confermato, mantenere la configurazione esistente e chiarire prima la compatibilità tra modello e build e il percorso di migrazione.

La mesh AP6 segue un percorso di gestione diverso: per un gruppo AP6 gestito centralmente, la configurazione avviene in Sophos Fusion, precedentemente Sophos Central, non in Wireless > Mesh networks sul firewall. Un Sophos Firewall può comunque fungere da router e da confine di sicurezza nel percorso dati, ma non diventa il controller degli AP6. APX e AP6 non possono far parte dello stesso gruppo mesh. La registrazione e i requisiti di rete per questo percorso separato sono descritti in Requisiti di Sophos Central Wireless; la pianificazione specifica, la configurazione mesh e la validazione sono illustrate in Pianificare e configurare una mesh AP6. I ruoli APX, le assegnazioni degli SSID e i passaggi di ripristino qui descritti non si applicano agli AP6.

Il modello outdoor APX 320X non rientra in questa procedura gestita dal firewall. I riferimenti alla vecchia serie di AP Sophos e ai ruoli manuali nelle guide precedenti spiegano le installazioni storiche, non una nuova installazione supportata oggi. Anche LocalWiFi integrato e i moduli Wi-Fi SD-RED non possono sostituire i due APX esterni dell’esempio; i relativi requisiti WLAN e di modello devono essere verificati separatamente. Le guide UTM non vengono aggiornate in questo articolo né consigliate come percorso per una nuova configurazione.

Procedura rapida:

  1. Collegare inizialmente entrambi gli APX alla LAN, accettarli in Wireless > Access points e controllare firmware, Country e pianificazione radio.
  2. Impostare lo stesso canale fisso su tutti gli AP coinvolti per la banda mesh e disattivare Dyn chan.
  3. Configurare Mesh-ID, Frequency band e APX in Wireless > Mesh networks > Add.
  4. Assegnare separatamente l’SSID client visibile a entrambi gli APX.
  5. Salvare, scollegare il cavo LAN dall’AP mesh, riavviare gli APX e attendere fino a cinque minuti.
  6. Verificare in modo controllato stato AP, connessione client, DHCP, Rule ID, accesso Internet e guasto del percorso root.

Quando è adatta una mesh APX

Una mesh è adatta a un’installazione APX esistente quando un access point remoto non dispone di Ethernet e il collegamento radio verso l’AP root è sufficientemente stabile. Esempi tipici sono una piccola area di magazzino, una sala riunioni o una zona temporanea che verrà cablata in seguito.

Un uplink Ethernet rimane la base tecnica migliore per capacità elevata e continua, latenza stabile e failover prevedibile. Il backhaul mesh condivide il tempo radio con le altre trasmissioni. Occorre quindi misurare le prestazioni reali con i client e le applicazioni previsti, senza dedurre la capacità utile dallo stato del link.

Per le nuove installazioni conta anche il limite di prodotto: APX è End-of-Sale e raggiungerà l’End-of-Life il 31 dicembre 2027. Il ciclo di vita APX e AP6 come successore va quindi incluso nella pianificazione a medio termine. AP6 non è gestito tramite SFOS.

Comprendere backhaul mesh, SSID client e ruoli

Questi componenti hanno funzioni diverse:

  • Mesh network: backhaul radio nascosto tra gli APX. Il Mesh-ID identifica il gruppo; SFOS gestisce la passphrase WPA2 casuale.
  • AP root: APX con collegamento Ethernet esistente al firewall. Con APX questo ruolo deriva automaticamente dal cablaggio.
  • AP mesh: APX senza uplink Ethernet che raggiunge l’AP root via radio.
  • Wireless Network: SSID client visibile con Security mode, Client traffic, DHCP e regole. La base completa è descritta in Configurare la WLAN direttamente su Sophos Firewall.

Nelle vecchie serie di AP Sophos, i ruoli root e mesh devono essere assegnati esplicitamente. Questo articolo usa solo APX e quindi non trasferisce quella vecchia schermata dei ruoli nei passaggi dell’esempio.

Repeater o wireless bridge

In modalità repeater, l’AP mesh trasmette l’SSID client assegnato nella posizione remota. Gli endpoint si collegano via Wi-Fi e l’AP trasporta i dati all’AP root attraverso il backhaul mesh.

Con un wireless bridge si collega inoltre un segmento Ethernet alla porta di rete dell’AP mesh. Questo design estende Layer 2 e può creare loop se esiste contemporaneamente un secondo percorso cablato. Va quindi realizzato in una finestra di manutenzione con un percorso di ripristino documentato. STP deve essere coerente con l’intero design di switch e bridge; non va disattivato solo perché blocca un percorso.

Per la maggior parte delle piccole estensioni la modalità repeater è più chiara. Un bridge va usato solo quando il segmento Ethernet remoto è davvero necessario e ne sono compresi broadcast, VLAN e rischio di loop.

Verificare i limiti prima della configurazione

Una mesh APX ha limiti di prodotto chiari:

  • Tutti gli access point coinvolti devono appartenere alla serie APX.
  • Si può utilizzare una sola rete mesh per AP.
  • Almeno un APX deve rimanere collegato al firewall tramite LAN.
  • Tutti gli AP mesh usano lo stesso canale sulla banda mesh.
  • Dynamic Channel Selection, ossia Dyn chan, non deve essere attivo su questa banda, perché dopo un riavvio gli AP potrebbero usare canali differenti.
  • Con APX non si possono configurare entrambe le radio a 5 GHz quando si usa la mesh.
  • Gli AP con VLAN assegnata possono formare una mesh solo se le VLAN non usano la modalità Client traffic Bridge to VLAN.
  • Una seconda rete mesh sullo stesso AP non funziona.
  • Un altro AP mesh non subentra automaticamente e senza interruzioni in caso di guasto dell’AP root.

La guida Sophos attuale indica 2.4 GHz per il backhaul mesh e 5 GHz per gli SSID client come possibile punto di partenza. Non è una best practice universale. Distanza, pareti, interferenze, canali disponibili, Country normativo e capacità richiesta determinano il design reale.

Interpretare il conflitto tra le guide: la precedente guida al deployment indica 5 GHz sull’AP root e 2.4 GHz sull’AP mesh; la guida all’aggiunta distingue invece 5 GHz per gli SSID client da 2.4 GHz per il backhaul mesh. Queste formulazioni non devono portare a usare bande di backhaul diverse sull’AP root e sull’AP mesh. Per la procedura qui documentata relativa a un’installazione esistente, entrambi gli AP devono usare la stessa banda mesh scelta e lo stesso canale fisso. Il valore di esempio 2.4 GHz non è obbligatorio; prima di usare un’altra banda, verificare il supporto del modello e della build e il percorso radio. Rimane valido il limite APX che impedisce di configurare contemporaneamente entrambe le radio a 5 GHz.

Pianificare la topologia di esempio

L’esempio utilizza questi nomi:

  • Firewall: fw01
  • APX cablato: ap-office-root
  • APX wireless: ap-warehouse-mesh
  • Mesh-ID: OfficeMesh
  • Wireless Network visibile: Company WiFi
  • Banda mesh: 2.4 GHz
  • Canale mesh: un canale fisso verificato sul posto

OfficeMesh è un esempio di documentazione e va sostituito con un nome breve e univoco dell’installazione. Il Mesh-ID non va confuso con l’SSID visibile. Nell’esempio Company WiFi è già disponibile con Client traffic, DHCP, regole firewall e NAT adeguati.

Prima della modifica si preparano un backup aggiornato della configurazione, un accesso di gestione cablato e un piano di rollback. Entrambi gli APX ricevono PoE e, per la configurazione iniziale, vengono testati entro la portata delle posizioni definitive. L’AP root deve rimanere raggiungibile tramite Ethernet.

Preparare access point e canale radio

Effettuare prima il provisioning di entrambi gli APX via LAN

  1. Collegare ap-office-root e ap-warehouse-mesh via Ethernet alla rete di gestione prevista.
  2. In Wireless > Wireless settings, verificare che Wireless Protection sia attivo e la zona di gestione sia consentita in Allowed zone.
  3. In Wireless > Access points, accettare entrambi gli APX pending con Accept.
  4. Impostare il Country corretto per entrambi gli APX. Dopo una modifica di Country, salvare e riavviare gli APX in modo controllato per aggiornare l’elenco dei canali.
  5. Verificare che entrambi gli APX siano attivi e abbiano ricevuto la configurazione corrente.

Il cablaggio iniziale non è una comodità facoltativa. Un APX che non ha ricevuto la configurazione mesh non può essere aggiunto successivamente al gruppo solo via radio.

Prima del rollout va pianificata anche la versione firmware APX tramite i Pattern Update di Sophos Firewall. Un aggiornamento firmware e il passaggio alla mesh non devono avvenire contemporaneamente senza controllo.

Impostare un canale fisso comune

  1. In Wireless > Access points, aprire il primo APX.
  2. In Advanced settings, impostare un canale fisso verificato localmente nel campo Channel 2.4 GHz o Channel 5 GHz appropriato.
  3. Disattivare Dyn chan per questa banda.
  4. Applicare la stessa impostazione al secondo APX.
  5. Se possibile, collocare gli AP vicini non appartenenti alla mesh su un altro canale con poche interferenze.

Un canale non viene scelto solo perché funziona bene nell’esempio. La scelta dipende da scansione locale, requisiti Country e occupazione dei canali vicini. Dopo ogni modifica, entrambi gli AP mesh devono mostrare di nuovo lo stesso valore.

Creare Wireless Mesh in SFOS

Creare la rete mesh

Per il backhaul mesh si crea una nuova rete mesh dedicata oppure un nuovo SSID mesh dedicato; l’SSID client visibile esistente Company WiFi non viene convertito in una rete mesh. La guida usa sia il termine Mesh-ID sia mesh-enabled SSID. Se l’interfaccia in uso offre Enable mesh mode solo durante la creazione di un nuovo SSID, utilizzare questo percorso legacy documentato solo dopo aver confermato il supporto del modello e della build, mantenendo separato l’SSID client. È prevista una sola rete mesh per AP. Tutti gli AP coinvolti devono ricevere lo stesso Mesh-ID e condividono la passphrase WPA2-Personal generata casualmente da SFOS. Non si tratta della passphrase della WLAN client.

  1. Aprire Wireless > Mesh networks.
  2. Selezionare Add.
  3. Inserire OfficeMesh come Mesh-ID.
  4. In Frequency band, scegliere la banda comune pianificata, nell’esempio 2.4 GHz.
  5. Aggiungere ap-office-root e ap-warehouse-mesh.
  6. Salvare.

Con APX non occorre assegnare manualmente un ruolo. Finché entrambi gli APX sono cablati, ricevono prima la configurazione. Dopo la successiva disconnessione di ap-warehouse-mesh, ap-office-root rimane l’AP root grazie al collegamento Ethernet.

Assegnare l’SSID client visibile

La rete mesh non è visibile agli endpoint. In Wireless > Access points, o tramite un Access Point Group adeguato, occorre quindi assegnare anche Company WiFi a entrambi gli APX.

L’SSID client mantiene il proprio Security mode e Client traffic. Con Separate zone devono essere corretti soprattutto Wireless interface, DHCP, regola firewall, NAT e Device Access. Una mesh funzionante non corregge una regola WLAN mancante o un percorso DHCP errato.

Spostare l’AP mesh nella posizione prevista

  1. Verificare che configurazione e SSID client visibile siano arrivati su entrambi gli APX.
  2. Rimuovere il cavo Ethernet solo da ap-warehouse-mesh.
  3. Lasciare cablato ap-office-root.
  4. Posizionare l’AP mesh nel punto previsto e accenderlo; in questo modo si avvia senza Ethernet.
  5. Riavviare l’AP root in modo controllato. Se lo spostamento non ha tolto alimentazione all’AP mesh, riavviare ora anche quest’ultimo.
  6. Attendere fino a cinque minuti prima di considerare fallita la connessione.

Nel normale funzionamento mesh rimane collegato alla LAN un solo APX. Se per errore anche il secondo APX viene collegato alla stessa rete Layer 2, controllare il design per eventuali loop e l’effetto di STP.

Validare Wireless Mesh in modo controllato

La validazione combina stato del controller, percorso radio e traffico reale:

  1. In Wireless > Access points, entrambi gli APX devono essere attivi. ap-office-root rimane cablato; ap-warehouse-mesh è raggiungibile senza Ethernet.
  2. Controllare assegnazione mesh e canale identico su entrambi gli APX.
  3. Collegare a Company WiFi un client di prova vicino a ap-warehouse-mesh.
  4. In Wireless > Wireless client list, visualizzare il client di prova filtrando per AP o SSID e verificare che sia associato all’AP mesh previsto e a Company WiFi. Annotare intensità del segnale e frequenza e ripetere la verifica in condizioni simili durante il confronto con l’AP root; la sola frequenza client visualizzata non dimostra quale banda usi il backhaul.
  5. Confrontare indirizzo IP, gateway e DNS del client con il Wireless Network pianificato.
  6. Provare una destinazione consentita e una deliberatamente bloccata.
  7. In Log Viewer, filtrare per IP client e controllare Firewall Rule ID e NAT Rule ID previste.
  8. Eseguire un test realistico di throughput e latenza e confrontarlo con un client sull’AP root.

Lo stato verde dell’AP non conferma ancora l’intero percorso dati. Il test ha successo quando il client usa AP, indirizzo e regole previsti e le prestazioni sono sufficienti per l’applicazione. La procedura generale è descritta in Testare correttamente le regole firewall.

Testare consapevolmente il limite di guasto

L’AP root è una dipendenza nota. In una finestra di manutenzione si può scollegare brevemente il suo uplink e documentare per quanto tempo si interrompe l’accesso dei client. SFOS non garantisce un cambio automatico del root. Per stabilire un nuovo ruolo può essere necessario riavviare e cablare un AP mesh.

Questo test non giustifica lo spegnimento non pianificato di un AP root produttivo. Per aree critiche occorre usare un uplink AP cablato o pianificare un’altra architettura WLAN.

Inquadrare correttamente l’oggetto mesh nella XML API

I riferimenti XML per SFOS 22 e 23 descrivono Add Mesh Networks e Update Mesh Networks per l’oggetto WirelessMeshNetworks. Si tratta di una struttura di oggetto documentata, non di un’ulteriore approvazione hardware: l’ambito limitato agli APX esistenti, la verifica di modello/build e il percorso separato di gestione degli AP6 indicati sopra restano invariati. La protezione dell’accesso, le operazioni esplicite, le risposte XML e le ripetizioni sicure sono spiegate in Proteggere l’accesso alla XML API di Sophos Firewall.

Distinguere MeshID, banda e ruolo dell’AP

Per preparare un’automazione occorre distinguere questi campi:

  • MeshID è una stringa scalare obbligatoria di al massimo dieci caratteri. OfficeMesh è adatto come nome di esempio breve; resta l’ID del backhaul, non l’SSID visibile ai client. Non interpretare il marcatore di riferimento aggiuntivo APINTERFACENAME come una regola autoesplicativa sui caratteri o come un’identità AP; confermare la sintassi consentita nel build installato.
  • FrequencyBand è obbligatorio e ammette esclusivamente 5GHz o 2.4GHz. La tabella indica 5 GHz come valore predefinito documentato, non come raccomandazione per ogni collegamento radio. La notazione combinata 5GHz/2.4GHz nell’esempio di riferimento non compare nell’elenco dei valori consentiti e non viene adottata come singolo valore del campo. Tutti gli AP coinvolti continuano a richiedere la stessa banda di backhaul confermata e lo stesso canale fisso; Dyn chan resta disattivato su questa banda.
  • Description è una stringa scalare facoltativa. Un elemento vuoto nell’esempio non dimostra come un aggiornamento gestisca una descrizione esistente.
  • AccessPoints contiene MeshNetwork nell’esempio XML; al suo interno si trovano insieme AccessPoint e Role. La tabella dei parametri descrive entrambi i campi come array facoltativi con più valori e segnala che i duplicati non vengono ignorati. Non dedurne né due elenchi ordinabili arbitrariamente e indipendentemente, né una deduplicazione automatica. Verificare insieme l’identità AP e il ruolo associato rispetto alla configurazione esistente e ad API help del build.
  • Per Role sono documentati esattamente MeshAccessPoint e RootAccessPoint; la tabella indica Root Access Point come valore predefinito. Questi valori XML provengono dal riferimento API, non dai termini Root, Mesh o Repeater della GUI. In particolare, l’assegnazione automatica dei ruoli APX tramite Ethernet non dimostra se Role debba essere impostato, omesso o gestito diversamente nel payload APX specifico. Se la corrispondenza tra modello e build non è stata chiarita, non inviare alcuna richiesta di scrittura.

Il seguente estratto limitato della struttura XML non è una richiesta eseguibile né un’assegnazione di ruolo APX. Mostra soltanto l’annidamento documentato con un valore di riferimento per Role; AP_IDENTITAET_AUS_API_HELP è un segnaposto che non può essere inviato. L’identità AP30 dell’esempio del produttore non viene ripresa come esempio APX:

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

Prima di una modifica, rileggere la rete effettivamente salvata con ID mesh, identità AP, assegnazioni e parametri radio, salvarne una copia e confrontarla con lo stato di destinazione previsto. L’estratto non contiene né un login né un’operazione e non sostituisce un payload completo confermato. Dalla struttura XML non derivano né la sicurezza di un nuovo tentativo né il funzionamento del collegamento radio; resta necessaria la verifica separata dello stato degli AP, dell’SSID client, del DHCP e del percorso dei dati utente.

Distinguere le risposte per operazione, codice e simbolo

I riferimenti associano alle due operazioni i seguenti codici di stato XML e le chiavi letterali Message.*. Le chiavi non sono risolte: non sono messaggi di runtime confermati e non vengono tradotte in presunti testi di errore. L’associazione specifica dell’oggetto deve essere confrontata con API help del build installato; in particolare, non interpretare qui 521 e 522 basandosi soltanto sulla tabella generale degli stati nell’articolo centrale sull’API.

Add Mesh Networks:

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

Update Mesh Networks:

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

Anche la grafia Faild viene mantenuta esattamente. Non dedurre dai nomi dei simboli una causa accertata, l’annullamento completo di una modifica o una dipendenza DHCP/interfaccia già eliminata. Dopo una risposta ambigua o non riuscita, confrontare prima lo stato mesh e AP effettivamente salvato, nonché le configurazioni wireless, delle interfacce e DHCP dipendenti, con lo stato iniziale salvato; conservare la risposta e i log depurati per il chiarimento. Decidere se apportare un’ulteriore modifica soltanto dopo il chiarimento specifico per il build, senza ripetere automaticamente lo stesso Add o Update. Anche 200 non sostituisce né la rilettura dell’oggetto di destinazione né la verifica radio e client indicata sopra.

Individuare gli errori in base al sintomo

L’AP mesh non appare o rimane offline

Dopo la configurazione attendere fino a cinque minuti. Se l’AP rimane offline, verificare prima che fosse attivo durante il provisioning iniziale via LAN e abbia ricevuto la configurazione mesh. Controllare poi serie APX, assegnazione mesh, banda, canale comune, Dyn chan, Country e alimentazione.

L’AP root deve rimanere cablato. Se entrambi gli AP sono wireless o è stato scollegato da Ethernet l’AP sbagliato, manca il percorso verso il firewall. Dopo la correzione, riavviare gli APX in modo controllato e attendere di nuovo.

Se, in una procedura precedente, l’opzione Enable mesh mode non compare per un SSID esistente, creare un nuovo SSID invece di riutilizzare l’SSID client visibile. Se la causa resta incerta, durante una finestra di manutenzione isolare il percorso trasmettendo solo la rete mesh sull’AP root e solo l’SSID client visibile sul repeater. Se l’SSID client compare sul repeater, questo indica inizialmente che la configurazione client viene trasmessa, ma non dimostra ancora che il backhaul o l’accesso Internet funzionino correttamente. Verificare inoltre che il repeater sia effettivamente raggiungibile senza uplink LAN, che il client di prova compaia nell’elenco client di questo AP e che funzionino il DHCP previsto e il percorso dati consentito. Ripristinare poi le assegnazioni normali. Se la mesh resta inutilizzabile, verificare se STP blocca la configurazione mesh. Non disattivare STP senza criterio: impedisce i loop nelle topologie bridge.

L’SSID client non è visibile

Il Mesh-ID non viene intenzionalmente trasmesso come SSID client. In Wireless > Access points occorre assegnare all’AP mesh anche un Wireless Network visibile. Se è configurato solo OfficeMesh, gli endpoint non hanno una rete visibile.

Controllare inoltre Frequency band, pianificazione, Security mode e assegnazione AP dell’SSID client. Una seconda rete mesh sullo stesso AP non è una soluzione, perché è supportata una sola mesh per AP.

Il client si collega ma non riceve un indirizzo IP

Il percorso radio funziona già almeno in parte. Controllare poi Client traffic, Wireless interface, server DHCP o DHCP relay ed eventuali percorsi VLAN. Con Bridge to VLAN va considerato anche il limite del prodotto mesh: gli AP con VLAN assegnate possono formare una mesh solo se le VLAN non usano questa modalità Client traffic.

Il riavvio del servizio wireless non è un passaggio standard. Occorre prima stabilire a quale AP è collegato il client e se le richieste DHCP raggiungono il percorso previsto.

Il client ha un indirizzo IP ma non accede a Internet

In Log Viewer cercare prima Firewall Rule ID e NAT Rule ID previste. Se mancano entrambe, il problema riguarda più probabilmente zona, oggetto di rete, ordine delle regole o percorso dati che la mesh stessa. Se le regole corrispondono, controllare poi DNS, gateway e percorso WAN.

Una regola Any ampia non è una diagnosi mesh. Eseguire lo stesso test client una volta sull’AP root e una sull’AP mesh. Se funziona solo sul root, approfondire il backhaul; se fallisce su entrambi, l’errore appartiene probabilmente alla configurazione WLAN o firewall comune.

La connessione è instabile o lenta

Controllare lo stesso canale su tutti gli AP mesh, Dyn chan disattivato, qualità del segnale, interferenze, distanza e pareti. Gli AP estranei alla mesh non dovrebbero occupare inutilmente lo stesso canale. Deve inoltre rimanere capacità radio sufficiente per backhaul e client.

Confrontare le prestazioni con la stessa applicazione, lo stesso client e condizioni il più possibile simili sull’AP root e sull’AP mesh. In questo modo si separa il percorso mesh da un problema generale WAN, DNS o client.

Lo stato di controller o client rimane poco chiaro

I log dei servizi di Sophos Firewall aiutano nella diagnosi locale del nodo. In Advanced Shell sono utili questi controlli in sola lettura:

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

awed.log mostra la comunicazione tra controller e APX; wc_remote.log aiuta con i client wireless. Una singola voce di log non dimostra il percorso del traffico. Occorre correlare timestamp, stato AP, elenco client, log firewall e un test riproducibile. I LED e codici di lampeggio dei Sophos Access Point aiutano inoltre a classificare gli stati di avvio, aggiornamento e mesh sul dispositivo.

Ripristinare la configurazione in sicurezza

Distinguere l’SSID mesh dall’SSID client durante il ripristino: la guida precedente descrive la disattivazione tramite eliminazione dell’SSID mesh. Si intende il relativo oggetto di configurazione mesh, non genericamente l’SSID client visibile Company WiFi. Prima di eliminare, verificare la corrispondenza tra Mesh-ID, assegnazioni AP e dipendenze, salvare la configurazione corrente e rendere gli AP raggiungibili tramite il percorso cablato previsto. La rimozione del backhaul interrompe la connettività degli AP collegati via radio; eliminare un SSID client ancora necessario disconnetterebbe anche i relativi utenti WLAN. A seconda dell’interfaccia legacy, il ripristino avviene tramite la rete mesh o il suo SSID mesh. Se non è possibile identificare con certezza l’oggetto corrispondente, non eliminare nulla per tentativi: chiarire prima la configurazione specifica del modello e della build.

Il rollback avviene in modo controllato finché funziona l’accesso di gestione cablato:

  1. Documentare quale APX è root e quale è l’AP mesh.
  2. Ricollegare l’AP mesh via LAN alla rete di gestione e attendere che sia attivo.
  3. Se necessario, spostare l’SSID client visibile su un AP cablato rimanente.
  4. Rimuovere la rete mesh dagli APX oppure eliminarla in Wireless > Mesh networks.
  5. Ripristinare le precedenti impostazioni di canale e Dyn chan solo consapevolmente.
  6. Riavviare entrambi gli APX in modo controllato.
  7. Ricontrollare IP client, DNS, regole e accesso Internet.

Un reset di fabbrica è utile solo se l’APX non accetta più una configurazione gestita nonostante cablaggio, alimentazione e percorso controller corretti. Non sostituisce un rollback documentato.

Checklist operativa

  • Tutti i dispositivi coinvolti sono APX compatibili e sono stati prima sottoposti a provisioning via LAN.
  • A ogni AP è assegnata esattamente una rete mesh.
  • Un APX rimane permanentemente cablato come root.
  • Banda mesh e canale fisso coincidono su tutti gli APX coinvolti.
  • Dyn chan è disattivato sulla banda mesh.
  • L’SSID client visibile è assegnato separatamente.
  • Sono stati verificati DHCP, Firewall Rule ID, NAT Rule ID e una destinazione bloccata.
  • Prestazioni e stabilità sono state confrontate su AP root e AP mesh.
  • Guasto del root, assenza di takeover automatico e rollback sono documentati.
  • End-of-Life APX e successivo cambio di piattaforma WLAN sono pianificati.

FAQ

Il Mesh-ID è l'SSID WLAN visibile?

No. Il Mesh-ID appartiene al backhaul nascosto tra gli APX. I client richiedono anche un normale Wireless Network con SSID visibile, sicurezza, Client traffic e regole adeguate.

Un secondo APX può assumere automaticamente il ruolo dell'AP root?

No. Sophos non documenta un takeover automatico del root per questa mesh. Almeno un AP rimane cablato; dopo un guasto del root, il ripristino deve essere controllato e può richiedere un riavvio o un nuovo cablaggio.

Perché tutti gli APX devono essere prima collegati via LAN?

Ogni APX deve essere accettato dal firewall e ricevere la configurazione mesh. Solo dopo l’AP mesh previsto viene scollegato dalla LAN, avviato nella posizione di destinazione e collegato tramite l’AP root.