Diagnosticar Wireless Controller do Sophos Firewall por CLI

No SFOS 22, executar system wireless-controller em 4. Device Console. Consultar separadamente os registos de diagnóstico em 5. Device Management > 3. Advanced Shell. Começar por verificações só de leitura e ativar o Remote Packet Capture apenas depois de restringir o problema a um ponto de acesso e a um cliente de teste.

⚠️ Privacidade e operação: Uma captura Wi-Fi pode conter tráfego de utilizadores, endereços IP, consultas DNS e dados de autenticação ou de sessão. Utilizar um filtro preciso, capturar um teste curto e reproduzível e proteger o ficheiro exportado. Registar o valor inicial exato antes de cada alteração.

Este guia aplica-se ao SFOS 22. Confirmar a sintaxe e o resultado dos comandos na versão instalada.

Abrir a consola correta

A CLI está acessível localmente com um cabo de consola, remotamente por SSH ou através de admin > Console no WebAdmin. Para SSH, permitir o serviço SSH na zona necessária em Administration > Device access > Local service ACL. admin > Console requer acesso HTTPS nessa zona. Sempre que possível, limitar o acesso administrativo aos hosts autorizados com uma regra de exceção Local service ACL.

Após iniciar sessão, selecionar 4. Device Console. Nesse contexto, ? mostra os argumentos disponíveis e as respetivas descrições para um comando parcialmente introduzido. system wireless-controller é um comando de Device Console. A Advanced Shell é um ambiente distinto, utilizado abaixo apenas para a consulta documentada e só de leitura dos registos; não é intercambiável com a Device Console.

Registar a linha de base e o sintoma

Verificar primeiro os ramos disponíveis na versão instalada e ler os valores atuais:

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

Substituir <AP_serial_number> pelo número de série do AP afetado; não introduzir os parênteses angulares. Registar também a versão do SFOS, o modelo e firmware do AP, o SSID, a banda, o canal, a largura do canal, os endereços MAC e IP do cliente de teste, a hora e um sintoma exatamente reproduzível. Num par HA, registar o nó em que a sessão foi iniciada. Não repetir indiscriminadamente o diagnóstico nos dois nós após um failover.

Um estado normal do controlador só confirma o estado de controlo. Não prova associação de clientes, DHCP, DNS, autenticação ou o caminho dos dados.

Verificar primeiro o WebAdmin e os registos relevantes

Em Wireless > Access points, verificar se o AP está ativo e se o modelo e o número de série correspondem. O Sophos Firewall gere os pontos de acesso através da porta 2712. Se um AP não aparecer ou estiver inativo, verificar primeiro a zona, VLAN, porta do switch, endereçamento e percurso até essa porta. Aceitar um AP desconhecido não é uma etapa de diagnóstico: confirmar o respetivo modelo, número de série, localização e rede de gestão antes de clicar em Accept.

A documentação do SFOS 22 associa estes ficheiros de log a problemas de rede sem fios:

• awed.log: comunicação entre AP ou APX e o firewall
• wc_remote.log: comunicação de cliente sem fio com AP ou APX
• hostapd.log: eventos SSID para LocalWifi
• hotspotd.log: eventos hotspot

O SFOS 22 documenta oficialmente tail -f, grep e less para ler registos de diagnóstico em 5. Device Management > 3. Advanced Shell. A sintaxe genérica documentada permite estes exemplos deliberadamente restritos:

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

Substituir cada marcador por um único identificador exato e omitir os parênteses angulares. Executar tail -f apenas durante a breve reprodução e terminá-lo com Ctrl+C; sair de less com q. Cada comando lê um único ficheiro relevante e não substitui os comandos de Device Console apresentados acima. As ações de serviço start, stop e restart, bem como as ações de depuração, alteram o estado do sistema. Não as utilizar como diagnóstico genérico: exigem uma necessidade específica do caso, um estado inicial registado e um plano explícito de rollback. Se estas verificações não forem suficientes, ativar o acesso temporário em Diagnostics > Support access e enviar o ID de acesso através do canal de suporte acordado.

Executar a captura remota de pacotes num único AP

remote_pktcap encaminha os pacotes do AP para uma captura executada em simultâneo no firewall. A Sophos exige um valor global de ap_debuglevel de, pelo menos, 4. O nível de depuração é global, enquanto o comando de captura se destina a um número de série de AP específico.

Pré-requisito antes do passo 1: Verifique e registe o estado de captura deste AP com system wireless-controller remote_pktcap show <AP_serial_number> e o estado de captura existente no firewall em Diagnostics > Packet capture. Se alguma das capturas já estiver ativa ou o seu estado não for claro, não altere o filtro, o estado de captura nem o nível global de depuração. Identifique o responsável e a finalidade e suspenda este procedimento até existir um estado inicial explicitamente aprovado com ambas as capturas inativas. Não assuma o controlo nem interrompa diagnósticos de terceiros.

1. Executar system wireless-controller global show e registar o valor exato de ap_debuglevel. Se já for 4 ou superior, não o alterar.

2. Se estiver abaixo do 4, defini-lo temporariamente para 4 e ler o estado novamente:

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

3. Abrir Diagnostics > Packet capture, configurar um filtro restrito para o cliente de teste, destino, porta ou protocolo e iniciar o Packet capture.

4. Ativar a captura no AP e verificar o respetivo estado:

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

5. Gerar apenas o fluxo de teste definido. Packet capture mostra, entre outros dados, as interfaces de entrada e saída, Status, Reason e Firewall Rule ID. Estes campos ajudam a determinar se a trama chega ao AP, se o firewall a processa ou se uma regra a descarta.

6. Pare apenas as capturas iniciadas por este procedimento a partir do estado inicial inativo confirmado: primeiro a sua captura no AP com os comandos abaixo e depois o seu Packet capture no WebAdmin. Deixe inalteradas as capturas que não iniciou e as de outros responsáveis:

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

7. Se ap_debuglevel tiver sido alterado, restaurar o valor registado antes do teste e verificá-lo:

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

Substituir <saved_ap_debuglevel> pelo valor anterior exato. A sintaxe documentada do Wireless Controller não inclui um ramo reset para este parâmetro; presumir um valor predefinido não permite, portanto, um rollback seguro.

Não use os restantes parâmetros como solução genérica

A Device Console apresenta outros parâmetros globais. Os respetivos intervalos numéricos estão documentados, mas os efeitos operacionais nem sempre são explicados de forma suficiente:

• ap_localdebuglevel: 0 a 15; leitura com get, alteração com set
• log_level: 0 a 7; são registadas as mensagens com o nível configurado ou superior, pelo que um número maior não significa simplesmente «mais registos»
• ap_autoaccept, stay_online e store_bss_stats: 0 desativado, 1 ativado
• tunnel_id_offset: 0 a 65535

Não alterar estes valores preventivamente nem executar um bloco com várias alterações. Em particular, ap_autoaccept elimina o controlo deliberado na aceitação do AP. A página dos comandos não fornece contexto suficiente para recomendar genericamente stay_online, store_bss_stats ou tunnel_id_offset na resolução de problemas. Utilizá-los apenas segundo instruções específicas da Sophos Support, guardar o valor anterior com global show e restaurar depois exatamente esse valor.

Atrasar RADIUS Accounting Start apenas com uma causa comprovada

radius_accounting_start_delay destina-se apenas a um problema de sequência confirmado: a mensagem 802.1X Accounting Start chega antes de o DHCP atribuir um endereço ao cliente. O Wi-Fi SSO não consegue então obter um Framed-IP-Address utilizável dessa mensagem. O intervalo documentado é de 0 a 60 segundos; a Sophos utiliza 30 segundos na KBA-000006795.

O procedimento documentado pela Sophos aplica-se a modelos APX geridos pelo SFOS com um SSID WPA/WPA2 Enterprise. A KBA não confirma este caminho de SSO para AP6 nem para controladores genéricos de terceiros.

Antes de alterar o valor, confirmar a sequência com registos RADIUS e uma captura e guardar o valor atual com global show. O procedimento completo está em Verificar RADIUS SSO e Accounting. Após o teste, executar system wireless-controller global radius_accounting_start_delay <saved_delay> com o valor exato anterior e verificá-lo com global show.

A largura do canal é configuração, não diagnóstico

A Sophos documenta larguras de canal de 20 e 40 MHz para 2,4 GHz e de 20, 40 e 80 MHz para 5 GHz. A página da CLI indica incorretamente 2.5GHz num ponto. Não copiar esse valor sem o verificar. O ramo documentado da CLI também não fornece um comando separado para ler ou repor a largura do canal. Sem um estado inicial guardado e uma sintaxe confirmada, não é um passo de diagnóstico seguro para copiar e colar.

Planear a largura do canal através da configuração normal de Wireless Network no WebAdmin. A utilização dos canais, as redes vizinhas, o sinal, as retransmissões, as capacidades dos clientes e a densidade do local determinam se uma largura superior será realmente útil.

Interpretar a configuração do AP e as respostas XML API

Se a automação alterou o AP, verifique também o objeto guardado WirelessAccessPoint. As referências XML de SFOS 22 e 23 apresentam as mesmas descrições dos campos; isto não prova compatibilidade de hardware em todas as versões. ID é o identificador obrigatório do AP, do tipo string, não Label, o SSID ou um nome de grupo arbitrário. Update Access Point também indica Label, Country e Band como obrigatórios; Delete Access Point indica ID. Eliminar não é uma etapa de diagnóstico nem remover uma atribuição SSID: exige uma retirada de serviço expressamente aprovada.

Verifique as dependências: Group seleciona o grupo AP e WirelessNetworks/Network as atribuições WLAN. Para 2,4 GHz existem Channel2.4GHz, DynChan, TimeBasedScan, ScanTime/Time, TXPower e ChannelWidth; para 5 GHz, os correspondentes Channel5GHz, DynChan5GHz, TimeBasedScan5GHz, ScanTime5GHz/Time, TXPower5GHz e ChannelWidth11a. Atribua um horário apenas com a pesquisa temporizada ativa e ative-a apenas com seleção dinâmica de canal na banda em questão. VLANTagging e o seu dependente APVLANID dizem respeito ao percurso de gestão; o intervalo documentado de APVLANID é 1–4094. Compare grupo, SSID, VLAN de gestão, interface e percurso do switch com a configuração Wi-Fi. AP6 permanece fora da gestão SFOS.

Não é um pedido de escrita pronto a enviar: O exemplo utiliza RootAccessPoint para Role, mas a descrição indica point/portal. As opções de pesquisa mostram Enable no exemplo, enquanto a descrição permite apenas t; algumas descrições de bandas também são inconsistentes. Não normalize estes valores por iniciativa própria. Antes de alterar, confirme os elementos XML superiores, valores e operação exatos em API help da versão instalada; se a correspondência continuar por esclarecer, não escreva e consulte Support.

Estas correspondências são estados XML API e símbolos de referência não resolvidos, não códigos HTTP nem textos de mensagens de execução verificados. Cada código indicado pertence à operação e ao símbolo apresentados:

• Update Access Point — 200, 216 — Message.WPAPkUpdateSuccessfully
• Update Access Point — 500, 541, 543, 545, 544 — Message.WPAPUpdateFail
• Update Access Point — 523 — Message.WPNetworkGroupMax
• Update Access Point — 524 — Message.WPAccessPointMax
• Update Access Point — 542 — Message.WPAccessPointMesh
• Update Access Point — 547 — Message.WPAPUpdateFailVLANGroup
• Update Access Point — 548 — Message.WPA3IsNotSupported
• Delete Access Point — 200 — Message.WPAccessPointDeleteSuccess
• Delete Access Point — 500 — Message.WPAccessPointDeleteFail

Não deduza um limite, uma causa ou a segurança de uma nova tentativa apenas do símbolo. Antes de repetir uma escrita, compare a resposta com o estado realmente guardado do AP, grupo, WLAN e VLAN, incluindo para 216; depois teste a ligação do cliente e o percurso dos dados. O guia central de segurança XML API explica proteção de acesso, operações explícitas, resultados parciais e rollback.

Avaliar o resultado e fechar a sessão de forma limpa

Após o diagnóstico, verificar o estado do AP, a associação do cliente, a concessão DHCP, a resolução DNS, a autenticação, o Firewall Rule ID esperado, a perda de pacotes, a latência e a aplicação afetada. Para RADIUS, verificar também Accounting Start, Framed-IP-Address e o mapeamento do utilizador.

O procedimento termina quando as suas próprias capturas temporárias tiverem sido encerradas: remote_pktcap show deve confirmar o estado inativo da captura AP iniciada aqui, e o WebAdmin o de Packet capture iniciado aqui. Os restantes diagnósticos ficam inalterados; se o procedimento foi suspenso devido a uma captura já ativa, interrompê-la não é uma condição de conclusão. global show deve apresentar os valores de depuração e dos parâmetros guardados. Se a causa continuar por esclarecer, guardar a hora, o número de série do AP, o cliente de teste, a captura e os nomes dos ficheiros de registo relevantes para a Sophos Support, em vez de experimentar mais definições globais.

FAQ