Diagnosticare Wireless Controller di Sophos Firewall dalla CLI

In SFOS 22, eseguire system wireless-controller in 4. Device Console. Consultare separatamente i log di diagnostica in 5. Device Management > 3. Advanced Shell. Iniziare con verifiche di sola lettura e attivare Remote Packet Capture solo dopo aver circoscritto il problema a un access point e a un client di test.

⚠️ Privacy e operatività: Una cattura wireless può contenere traffico degli utenti, indirizzi IP, query DNS e dati di autenticazione o di sessione. Utilizzare un filtro preciso, acquisire un solo test breve e riproducibile e proteggere il file esportato. Annotare il valore iniziale esatto prima di ogni modifica.

Questa guida si basa sulla documentazione pubblica di SFOS 22. I comandi non sono stati eseguiti su un Sophos Firewall per questo articolo: verificare quindi la sintassi e l’output sulla build installata.

Aprire la console corretta

È possibile accedere alla CLI localmente con un cavo console, da remoto tramite SSH oppure mediante admin > Console in WebAdmin. Per SSH, abilitare SSH per la zona necessaria in Administration > Device access > Local service ACL. admin > Console richiede l’accesso HTTPS per la zona. Se possibile, limitare l’accesso amministrativo agli host autorizzati con una regola di eccezione Local service ACL.

Dopo l’accesso, selezionare 4. Device Console. In questo contesto, ? mostra gli argomenti disponibili e le relative descrizioni per un comando parzialmente digitato. system wireless-controller è un comando di Device Console. Advanced Shell è un ambiente separato, utilizzato di seguito solo per consultare i log in sola lettura con comandi documentati; non è intercambiabile con Device Console.

Registrare lo stato iniziale e il sintomo

Verificare innanzitutto quali rami sono disponibili nella build installata e leggere i valori correnti:

system wireless-controller ?
system wireless-controller ap_localdebuglevel get
system wireless-controller global show
system wireless-controller remote_pktcap show <AP_serial_number>

Sostituire <AP_serial_number> con il numero di serie dell’AP interessato, senza digitare le parentesi angolari. Registrare anche la build SFOS, il modello e il firmware dell’AP, l’SSID, la banda, il canale, la larghezza del canale, gli indirizzi MAC e IP del client di test, l’ora e un sintomo esattamente riproducibile. In una coppia HA, annotare il nodo al quale è stato effettuato l’accesso. Dopo un failover, non ripetere indiscriminatamente la diagnostica su entrambi i nodi.

Uno stato normale del controller conferma soltanto il piano di controllo. Non dimostra che l’associazione del client, DHCP, DNS, l’autenticazione o il percorso dati funzionino correttamente.

Controllare prima WebAdmin e i log pertinenti

In Wireless > Access points, verificare che l’AP sia attivo e che modello e numero di serie corrispondano. Sophos Firewall gestisce gli access point tramite la porta 2712. Se un AP manca o risulta inattivo, controllare prima zona, VLAN, porta dello switch, indirizzamento e percorso verso questa porta. Accettare un AP sconosciuto non è un passaggio diagnostico: verificare modello, numero di serie, posizione e rete di gestione prima di fare clic su Accept.

L’aiuto SFOS 22 mappa questi file di registro a problemi wireless:

awed.log: comunicazione tra AP o APX e il firewall
wc_remote.log: comunicazione client wireless con AP o APX
hostapd.log: eventi SSID per LocalWifi
hotspotd.log: eventi hotspot

SFOS 22 documenta ufficialmente tail -f, grep e less per leggere i log di diagnostica in 5. Device Management > 3. Advanced Shell. La sintassi generica documentata consente questi esempi circoscritti:

tail -f /log/awed.log
grep '<AP_serial_number>' /log/awed.log
grep '<client_MAC_address>' /log/wc_remote.log
less /log/hostapd.log

Sostituire ogni segnaposto con un solo identificativo esatto, omettendo le parentesi angolari. Eseguire tail -f solo durante la breve riproduzione e interromperlo con Ctrl+C; uscire da less con q. Questi comandi leggono un singolo file pertinente e non sostituiscono i comandi di Device Console riportati sopra. Le azioni di servizio start, stop e restart, così come le azioni di debug, modificano lo stato del sistema: non utilizzarle come diagnostica generica. Richiedono un’esigenza specifica del caso, uno stato iniziale registrato e un piano di rollback esplicito. Se queste verifiche non bastano, abilitare un accesso temporaneo in Diagnostics > Support access e comunicare l’Access ID tramite il canale di supporto concordato.

Eseguire Remote Packet Capture su un solo AP

remote_pktcap inoltra i pacchetti dell’AP a un Packet Capture eseguito contemporaneamente sul firewall. Sophos richiede un valore globale di ap_debuglevel pari almeno a 4. Il livello di debug è globale, mentre il comando di cattura utilizza il numero di serie di uno specifico AP.

Eseguire system wireless-controller global show e annotare il valore esatto di ap_debuglevel. Se è già 4 o superiore, non modificarlo.

Se è inferiore a 4, impostarlo temporaneamente su 4 e leggere di nuovo lo stato:

system wireless-controller global ap_debuglevel 4
system wireless-controller global show

Aprire Diagnostics > Packet capture, configurare un filtro preciso per il client di test, la destinazione, la porta o il protocollo e avviare Packet capture.

Abilitare la cattura sull’AP e controllarne lo stato:

system wireless-controller remote_pktcap enable <AP_serial_number>
system wireless-controller remote_pktcap show <AP_serial_number>

Generare soltanto il flusso di test definito. Packet Capture mostra, tra gli altri dati, le interfacce di ingresso e uscita, Status, Reason e Firewall Rule ID. Questi campi aiutano a capire se il frame raggiunge l’AP, se il firewall lo elabora o se una regola lo scarta.

Arrestare prima la cattura sull’AP e poi Packet Capture in WebAdmin:

system wireless-controller remote_pktcap disable <AP_serial_number>
system wireless-controller remote_pktcap show <AP_serial_number>

Se ap_debuglevel è stato modificato, ripristinare il valore registrato prima del test e verificarlo:

system wireless-controller global ap_debuglevel <saved_ap_debuglevel>
system wireless-controller global show

Sostituire <saved_ap_debuglevel> con l’esatto valore precedente. La sintassi documentata del Wireless Controller non prevede un ramo reset per questo parametro; presumere un valore predefinito non consente quindi un rollback sicuro.

Non usare gli altri parametri come soluzione generica

Device Console elenca altri parametri globali. Gli intervalli numerici sono documentati, ma in alcuni casi gli effetti operativi non sono spiegati a sufficienza:

ap_localdebuglevel: 0 a 15; leggere con get, cambiare con set
log_level: 0 a 7; i messaggi al livello configurato o al di sopra sono scritti, quindi un numero più alto non significa semplicemente “più registrazione”
ap_autoaccept, stay_online e store_bss_stats: 0 off, 1 on
tunnel_id_offset: 0 a 65535

Non modificare questi valori in via preventiva e non eseguire un blocco contenente più modifiche. In particolare, ap_autoaccept elimina il controllo intenzionale previsto per l’accettazione degli AP. La pagina dei comandi non fornisce contesto sufficiente per raccomandare in generale stay_online, store_bss_stats o tunnel_id_offset durante la risoluzione dei problemi. Utilizzarli solo su indicazione specifica di Sophos Support, salvare il valore precedente con global show e ripristinare in seguito esattamente tale valore.

Ritardare RADIUS Accounting Start solo per una causa comprovata

radius_accounting_start_delay serve soltanto in presenza di un problema di sequenza confermato: il messaggio 802.1X Accounting Start arriva prima che DHCP assegni un indirizzo al client. Wi-Fi SSO non può quindi ricavare un Framed-IP-Address utilizzabile dal messaggio. L’intervallo documentato va da 0 a 60 secondi; nella KBA-000006795 Sophos utilizza 30 secondi.

Prima di modificare il valore, dimostrare la sequenza con i log RADIUS e una cattura, quindi salvare il valore corrente con global show. La procedura completa è descritta in Controllare RADIUS SSO e Accounting. Dopo il test, eseguire system wireless-controller global radius_accounting_start_delay <saved_delay> con il valore precedente esatto e verificarlo con global show.

La larghezza del canale è configurazione, non diagnostica

Sophos documenta larghezze di canale di 20 e 40 MHz per 2,4 GHz e di 20, 40 e 80 MHz per 5 GHz. In un punto, la pagina della CLI riporta erroneamente 2.5GHz. Non copiare questo valore senza verificarlo. Il ramo CLI documentato non fornisce inoltre un comando separato per leggere o reimpostare la larghezza del canale. Senza uno stato iniziale salvato e una sintassi confermata, non è un passaggio diagnostico sicuro da copiare e incollare.

Pianificare la larghezza del canale attraverso il normale Configurazione di rete wireless in WebAdmin. L’uso dei canali, le reti vicine, il segnale, le ritrasmissioni, le capacità dei client e la densità del sito determinano se una larghezza maggiore sia davvero utile.

Valutare il risultato e chiudere la sessione in modo pulito

Dopo la diagnostica, verificare lo stato AP, l’associazione client, il lease DHCP, la risoluzione DNS, l’autenticazione, l’ID di regola firewall previsto, la perdita di pacchetti, la latenza e l’applicazione interessata. Per RADIUS, verificare anche Accounting Start, Framed-IP-Address e mappatura utente.

La procedura è completa solo quando remote_pktcap show non segnala catture attive per l’AP, Packet capture è disattivato in WebAdmin e global show riporta i valori di debug e dei parametri salvati. Se la causa rimane poco chiara, conservare l’ora, il numero di serie dell’AP, il client di test, la cattura e i nomi dei log pertinenti per Sophos Support, invece di provare altre impostazioni globali.

Fonti ufficiali

FAQ

Perché Remote Packet Capture non mostra pacchetti?

Verificare che Packet Capture sia attivo in WebAdmin, che il valore globale di ap_debuglevel sia almeno 4, che il numero di serie dell’AP sia esatto e che il filtro corrisponda al flusso di test. Controllare quindi entrambe le interrogazioni di stato invece di aumentare il livello di debug senza criterio.

Posso eseguire i comandi Wireless Controller in Advanced Shell?

No. I comandi system wireless-controller riportati qui appartengono a 4. Device Console. Utilizzare Advanced Shell separatamente per i comandi documentati di sola lettura indicati sopra. Le azioni di servizio e di debug modificano lo stato e richiedono un’esigenza specifica del caso e un piano di rollback.

È opportuno usare ap_autoaccept per accelerare l'onboarding degli AP?

Non come misura di risoluzione dei problemi. L’accettazione automatica elimina un punto di controllo. Verificare il modello, il numero di serie, la porta dello switch, la posizione e la rete di gestione, quindi accettare deliberatamente l’AP previsto in WebAdmin.

Quale livello di debug è corretto dopo la cattura?

Non automaticamente 0, e non necessariamente 4: ripristinare il valore esatto registrato con global show prima del test. Un secondo global show conferma il rollback.