Sophos AP6 offline: diagnosticare provisioning, prestazioni e roaming

Su un AP6 possono guastarsi due livelli indipendenti: il piano di gestione collega l’access point a Sophos Fusion (in precedenza Sophos Central) e trasporta stato e configurazione. Il percorso dati del client va dal client Wi-Fi attraverso AP6, switch e VLAN fino a DHCP, DNS, gateway e destinazioni consentite. Uno stato Central verde non prova il percorso dati; un problema del client non prova un guasto della connessione cloud.

Percorso rapido: con Offline, verificare prima alimentazione, link, DHCP, DNS, ora e raggiungibilità Internet/Central. Con Pending, non accumulare modifiche: annotare stato e ora, stabilizzare la connessione e osservare l’avanzamento dell’attività. Se l’AP è online e l’SSID visibile, verificare separatamente IP client, VLAN, DHCP, DNS e regole. Per prestazioni o roaming, usare un test riproducibile e una sola modifica alla volta.

Prima di iniziare consultare i requisiti di rete AP6, la procedura di onboarding e la gestione locale o Central di AP6.

Conservare le prove e limitare il rischio

Annotare nome AP, numero di serie, modello, sito, porta switch, sorgente PoE, IP di gestione, Config status, ultima attività, firmware, profilo e SSID assegnati. Registrare inoltre inizio del sintomo, client coinvolti e ultima modifica. Password, archivi completi e dati del cliente non vanno inseriti in ticket non protetti.

Non modificare insieme VLAN, profilo e parametri radio e non iniziare con un ripristino di fabbrica. Usare un AP pilota e un client noto. Il reset elimina il contesto diagnostico.

Sintomo 1: AP6 è Offline in Central

Per AP6, Offline significa che l’access point non riesce a comunicare con Sophos Fusion.

Alimentazione e link: verificare classe PoE, porta e link. Una potenza insufficiente può spegnere le radio e genera un avviso in Central e nell’interfaccia locale. La classe PoE dipende dal modello AP6.
Indirizzamento locale: controllare lease, VLAN di gestione, gateway e DNS. Se anche l’interfaccia locale non è raggiungibile, Sophos indica DHCP mancante, potenza insufficiente e STP attivo sull’uplink come possibili cause.
Percorso Central: rispettare i requisiti di rete e dominio. Sophos indica le porte in uscita 443 (HTTPS), 80 (HTTP) e 123 (NTP).
Ora: aprire localmente Management > Date and time e correggere l’orologio dell’AP.
Osservare di nuovo: quando l’AP torna online, attendere lo stato di configurazione prima di testare i client.

Finché l’AP rimane offline non è possibile avviare da Central packet capture, Syslog o una nuova raccolta dei log di sistema: queste funzioni richiedono un AP online o verde. Raccogliere prove da switch, DHCP, DNS e gateway e inoltrare il caso con ora e numero di serie.

Sintomo 2: registrazione scaduta o provisioning Pending

AP did not connect to cloud within the timeout indica che l’AP non ha raggiunto Central nella finestra mostrata. Verificare lo stesso percorso Central, le porte e l’ora prima di registrarlo di nuovo.

Con Pending, separare stato ed effetto:

Se l’AP è anche offline, ripristinare prima il piano di gestione.
Se è online, annotare attività, ora e ultima modifica. Non inviare una seconda modifica di profilo, SSID o radio.
Osservare l’avanzamento di stato e configurazione prevista. Solo dopo collegare il client di test e validare il percorso dati.
Se lo stato resta bloccato in modo riproducibile, raccogliere i log di sistema mentre l’AP è verde e aprire un caso di supporto invece di ripetere reset e registrazioni.

Per modifiche SSID e VLAN usare il pilota SSID e VLAN AP6, così provisioning e rete client a valle restano distinti.

Sintomo 3: AP online ma client senza connettività

Verificare il percorso dati dall’interno verso l’esterno:

L’SSID previsto è visibile e l’autenticazione Wi-Fi riesce?
Quali indirizzo IP, maschera, gateway e DNS riceve il client?
La VLAN prevista è consentita sulla porta AP e su ogni uplink?
Il client raggiunge DHCP, quindi gateway e DNS, e infine esattamente le destinazioni consentite?
Lo stesso test funziona su un SSID di riferimento invariato o su un secondo AP?

Modificare solo il primo stadio dimostrato guasto. Lo stato online in Central conferma la gestione, non DHCP, DNS, VLAN o regole nel percorso client.

Scegliere lo strumento diagnostico adatto

In My Products > Wireless > Diagnostics, Central offre Events, Audit logs, Packet capture, Syslog, System logs e Support settings.

System logs: Central raccoglie i log completi di AP6 e fornisce un file .GZ. Collect logs è disponibile solo con stato verde.
Packet capture: per AP6, la cattura Central registra i pacchetti ricevuti sulle porte LAN cablate e richiede stato verde. Per una cattura WLAN usare l’interfaccia locale dell’AP. Avviarla subito prima del test, annotare client e ora e poi arrestarla.
Syslog: Central lo configura solo per AP online. Il server deve essere raggiungibile e rispondere a ICMP, altrimenti l’AP non invia pacchetti UDP. La porta predefinita è UDP 514; Sophos raccomanda non più di due AP per server per non mescolare i dati.
Support settings: attivare Remote Login solo per un intervallo adatto: 5 ore, 1, 7, 14 o 30 giorni. Disattivarlo revoca subito l’accesso al supporto Sophos.

Documentare inizio e fine di ogni acquisizione. Per configurazione dettagliata, interpretazione e arresto sicuro, seguire la procedura diagnostica AP6 per log e acquisizioni di pacchetti. Catture e log possono contenere dati sensibili e vanno eliminati dopo il caso secondo la propria politica di conservazione.

Sintomo 4: prestazioni, VoIP o roaming scadenti

Definire un test riproducibile: client, SSID, AP iniziale e finale, percorso, ora, applicazione e risultato. Misurare negli stessi punti e cambiare un solo parametro. Verificare anche se il problema appare nel percorso cablato o solo su un AP, banda o client.

Per chiamate VoIP scadenti o interrotte, Sophos indica tre controlli AP6 in Central:

Impostare Guard interval nel profilo assegnato su Normal GI (0.8 µs) o più.
Impostare Sip station idle timeout su 300 o più.
Disattivare Airtime fairness sugli AP con traffico VoIP perché può causare ritardi, jitter e disconnessioni.

Guard interval e Sip station idle timeout si applicano all’intero profilo. Prima di modificare uno dei due valori, verificare che il profilo assegnato contenga soltanto l’AP pilota; in caso contrario, creare e assegnare un profilo dedicato esclusivamente al pilota. Sono modifiche specifiche per VoIP e non vanno distribuite insieme. Annotare ogni valore precedente, ripetere la stessa chiamata e lo stesso percorso dopo una sola modifica e ripristinare il valore precedente se il risultato peggiora.

Per un problema di roaming, segnare luogo e ora esatti dell’interruzione e confrontare almeno due passaggi. Verificare se la connessione cade solo fra AP o anche da fermi. Gestire Offline o Pending sul piano di gestione; analizzare un’interruzione client riproducibile con dati client, log AP e una cattura limitata nel tempo. Si evita così di cambiare la radio quando il guasto è in DHCP, DNS o nell’uplink cablato.

Validazione e ripristino sicuro

La correzione è confermata solo quando l’AP resta online, nessuna attività rilevante rimane bloccata e un client completa più volte autenticazione, configurazione IP, accesso a gateway, DNS e destinazioni consentite. Per prestazioni e roaming documentare lo stesso percorso prima e dopo una sola modifica.

Se il pilota fallisce, ripristinare solo l’ultimo valore di profilo, SSID o radio sulla base annotata. Attendere lo stato Central e ripetere il test. Fermare cattura e Syslog e disattivare Remote Login appena il supporto non ne ha più bisogno. Reset, nuova registrazione e modifiche di rete simultanee sono passi di escalation, non la prima azione di ripristino.