Configurar e testar Wi-Fi diretamente na Sophos Firewall

Uma rede Wi-Fi gerida diretamente na Sophos Firewall é criada em Wireless > Wireless networks. No entanto, o SSID, por si só, não é suficiente: o modo de tráfego escolhido determina se os clientes recebem uma rede própria, ficam na LAN do AP ou são ligados em bridge a uma VLAN. Em seguida, o DHCP, as regras de firewall, o NAT e a atribuição a um ponto de acesso têm de estar em sintonia.

⚠️ Importante: Este guia aplica-se apenas a hardware Wi-Fi gerido diretamente pela Sophos Firewall. Os pontos de acesso AP6 não podem ser geridos através do SFOS. Para vários AP6, o Sophos Fusion (anteriormente Sophos Central) é a forma de gestão prevista e recomendada; em alternativa, um único AP6 pode ser configurado através da respetiva interface local. Por conseguinte, atualmente o Firewall-managed Wireless é relevante sobretudo para instalações APX existentes, o LocalWiFi integrado nos modelos W de secretária e os módulos Wi-Fi compatíveis na Sophos Firewall ou no SD-RED. O firmware dos APX geridos pelo SFOS é disponibilizado através das atualizações de padrões do firewall e instalado de forma consciente.

Este guia utiliza uma rede Wi-Fi para convidados com Separate zone. É um exemplo fácil de compreender, porque permite separar claramente da LAN interna a rede de clientes, as regras e os destinos permitidos.

Se uma rede Wi-Fi 802.1X usar RADIUS e a firewall tiver de reconhecer utilizadores sem um captive portal adicional, RADIUS SSO com accounting explica o caminho separado de accounting, o Framed-IP-Address necessário e o teste em Live users.

Procedimento resumido:

Preparar a Wireless Protection e a zona do AP em Wireless > Wireless settings.
Aceitar o ponto de acesso em Wireless > Access points.
Criar o SSID, a segurança e a rede de clientes em Wireless > Wireless networks.
Adicionar o DHCP, a regra de firewall e o NAT em Network > DHCP e Rules and policies.
Atribuir a Wireless Network ao AP e verificar, com um cliente de teste, o endereço IP, o DNS, a Rule ID e os acessos internos indesejados.

Este guia é adequado para o ponto de acesso?

O SFOS 22 pode gerir pontos de acesso interiores da série APX, o Wi-Fi integrado de um XGS Appliance compatível e módulos de expansão Wi-Fi compatíveis na Sophos Firewall ou no SD-RED. Para dispositivos APX externos, isto inclui APX 120, APX 320, APX 530 e APX 740. O modelo exterior APX 320X e a antiga série AP não são geridos diretamente por uma Sophos Firewall atual.

O AP6 não faz parte deste procedimento. O AP6 é configurado através do Sophos Fusion ou, no caso de um único dispositivo, através da respetiva interface local. Para a variante Fusion, consulte os requisitos do Sophos Central Wireless.

A função Wireless local faz parte da Sophos Firewall Base License. É necessário adquirir separadamente um ponto de acesso compatível. No entanto, o APX já se encontra em End-of-Sale e atinge o seu End-of-Life em 31 de dezembro de 2027. Por conseguinte, este guia destina-se sobretudo a ajudar a operar em segurança instalações APX existentes. Para uma nova plataforma Wi-Fi, deve considerar-se o End-of-Life do APX e o AP6 como sucessor ou outros sistemas Wi-Fi atuais.

Limite de versão: A ajuda Wireless contém os procedimentos correspondentes tanto para SFOS 22 como para SFOS 23. No entanto, a existência de uma página de ajuda de SFOS 23 não comprova o suporte de um determinado modelo APX em SFOS 23. O suporte do hardware tem de ser confirmado de forma independente com base no Retirement Calendar e na matriz de suporte. Antes de uma atualização, verifique, por isso, o modelo, a revisão de hardware e a build de destino na matriz de suporte; não migre os APX existentes para SFOS 23 apenas com base nestas instruções. O WLAN integrado e os módulos SD-RED também têm de corresponder ao modelo e à build específicos. Para novos pontos de acesso externos, aplica-se o procedimento de gestão AP6 indicado no link acima, e não este procedimento SFOS-APX.

Para ligar um APX existente sem Ethernet através de um APX cablado, configurar e testar Wireless Mesh no Sophos Firewall explica AP raiz, canal, backhaul oculto e validação controlada.

SD-RED com módulo Wi-Fi: A ajuda Wireless documenta DHCP option 234 para a comunicação de um módulo SD-RED utilizado como ponto de acesso com a Sophos Firewall. Não se trata do DHCP dos clientes do Wi-Fi de convidados nem de um requisito geral para APX ou AP6. A ajuda também menciona Sophos UTM neste contexto; daqui não resultam novas instruções de instalação de UTM. Antes de efetuar alterações, esclarecer a compatibilidade do módulo, o DHCP de gestão e o controlador efetivamente utilizado; não adotar um valor de opção de outro tipo de dispositivo. A configuração SD-RED é o procedimento separado para a ligação do local.

Escolher o modo Client traffic correto

A decisão em Client traffic é mais importante do que o nome do SSID. Determina se os clientes se encontram no mesmo segmento de rede local de camada 2, quem distribui os endereços IP e que tráfego passa efetivamente pela firewall.

Separate zone

Separate zone cria uma interface Wireless própria com endereço IP próprio e um túnel VXLAN entre o ponto de acesso e a firewall. Os clientes recebem uma sub-rede própria. Desta forma, é possível controlar os acessos de cada rede Wi-Fi através de regras específicas de WiFi para WAN ou de WiFi para LAN. Zonas e interfaces da Sophos Firewall explica como a zona, a interface e o objeto de rede funcionam em conjunto.

Este modo é adequado para convidados, IoT ou outras redes que devam estar separadas da LAN interna. Um hotspot com Captive Portal, palavra-passe diária ou voucher também requer Separate zone. O procedimento completo com a definição de voucher, o portal e a regra automática encontra-se em Configurar um hotspot Sophos Firewall.

O VXLAN reduz a MTU utilizável. Os pacotes grandes podem, por isso, causar fragmentação ou perdas de desempenho. A MTU não deve ser alterada preventivamente para um valor genérico. Primeiro, deve verificar-se se apenas as transferências grandes falham ou se os pacotes TCP são transmitidos novamente de forma repetida, os chamados Retransmits; Verificar MTU e MSS na Sophos Firewall explica o procedimento controlado.

Bridge to AP LAN

Bridge to AP LAN coloca os clientes Wi-Fi na mesma rede que o ponto de acesso. Um servidor DHCP existente nessa LAN distribui os endereços dos clientes. É prático, mas não oferece um limite de rede separado para convidados ou dispositivos não seguros.

O percurso dos dados é decisivo: a comunicação dentro da mesma sub-rede pode passar diretamente entre o cliente, o AP e o switch, contornando completamente a Sophos Firewall. Uma regra de firewall no SFOS só pode controlar o tráfego que é efetivamente encaminhado através da firewall.

Para permitir apenas uma lista conhecida de dispositivos na rede sem fios integrada, cria-se uma lista MAC em Hosts and services > MAC host. Em seguida, na rede Wireless, seleciona-se Allow list em Advanced settings > MAC filtering e atribui-se essa lista. A palavra-passe deve ter entre 8 e 63 caracteres. Durante a validação, liga-se um dispositivo incluído na lista e outro que não esteja incluído.

Um endereço MAC pode, no entanto, ser falsificado. A Allow list é, por isso, apenas um filtro de acesso adicional e não substitui WPA2 Personal com AES, um método WPA3 suportado, uma palavra-passe forte nem uma segmentação de rede adequada.

Quando Bridge to AP LAN é utilizado com o LocalWiFi integrado, a rede Wi-Fi também tem de ser ligada à LAN com fios. O procedimento correto depende do modelo de XGS Appliance:

Gen.1 – XGS 87w, 107w, 116w, 126w e 136w: Em Network > Interfaces > Add interface > Add bridge, cria-se uma bridge. Name é o nome apresentado, que pode ser alterado posteriormente e admite até 58 caracteres; Hardware name admite até 10 caracteres de A-Za-z0-9_ e não pode ser alterado depois de guardar. Em Member interfaces, atribuir a zona WiFi à interface Wireless e a zona LAN à porta Ethernet pretendida. Se necessário, podem ser adicionadas outras portas Ethernet a esta bridge.
Em seguida, selecionar IPv4 configuration, introduzir o IPv4 address previsto para a bridge na LAN existente e escolher a máscara de sub-rede correspondente. O endereço e a máscara devem provir do plano de endereçamento da própria LAN, não da rede de convidados Separate zone utilizada mais adiante. Antes de Save, verificar se o endereço não está atribuído a outro dispositivo nem simultaneamente a uma interface membro, e se não se encontra no intervalo DHCP dinâmico sem reserva. Não alterar incidentalmente o gateway existente dos clientes nem o plano de endereçamento DHCP. Antes da alteração, verificar o backup, as dependências das portas e um acesso administrativo independente; o procedimento para interfaces bridge explica estas verificações comuns e os nomes de hardware reservados. O seu exemplo transparente inline sem endereço IP tem outra finalidade: este procedimento documentado de LocalWiFi Gen.1 utiliza um endereço IPv4 na bridge, mas nem todas as bridges precisam de um endereço IP. Guardar com Save apenas após estas verificações.
Gen.2 – XGS 88w, 108w, 118w e 128w: A interface Wireless não pode pertencer a uma bridge física. Em alternativa, ative Bridge to Ethernet em Wireless > Access points > LocalWiFi > Advanced settings, selecione exatamente uma porta Ethernet e defina a zone como LAN.
Para Bridge to Ethernet, a porta física selecionada tem de ter um endereço IP e não pode ser uma porta WAN nem membro de outra bridge. Não é possível ligar por bridge uma interface VLAN a LocalWiFi desta forma; a zona da bridge também não pode ser WAN. A função aplica-se apenas a IPv4 e a SSID do tipo Bridge to AP LAN. O SFOS utiliza o servidor DHCP existente da porta da bridge; se não existir, a ajuda documenta a criação automática de um novo servidor. Antes de guardar, verificar, por isso, se já existe um servidor DHCP na LAN e, depois, verificar o servidor, o pool e a concessão para evitar respostas DHCP concorrentes. Ao desativar, a bridge é eliminada e a configuração é reposta na interface física. Guardar, por isso, previamente o estado inicial e verificar a reversão, incluindo o acesso de administrador, o DHCP da LAN e a ligação dos clientes, durante uma janela de manutenção.

Um APX externo não necessita desta bridge LocalWiFi adicional. Ao substituir o hardware, uma bridge Wireless física de Gen.1 também não pode ser transferida sem alterações para Gen.2. A preparação necessária é explicada em Backup e restauro da Sophos Firewall.

Bridge to AP LAN só deve ser selecionado quando a rede Wi-Fi e a LAN com fios formarem intencionalmente a mesma zona de segurança.

Para este procedimento LAN, guardar a Wireless Network com Save depois de selecionar Bridge to AP LAN, as definições de segurança e a lista MAC. Em Wireless > Access points > LocalWiFi, verificar o Country correto, atribuir precisamente esta rede em Wireless networks > Add new item e guardar; o Guest WiFi apresentado mais adiante é um exemplo separado. Após configurar a bridge, o dispositivo de teste incluído na lista tem de conseguir ligar-se e o dispositivo não incluído tem de ser rejeitado. No cliente autorizado, verificar uma concessão do intervalo LAN previsto, a máscara correspondente, o gateway existente e os servidores DNS previstos; confirmar a concessão no servidor DHCP que efetivamente serve essa LAN. Testar a resolução de nomes e um serviço pretendido num dispositivo da LAN com fios. Se não houver concessão, verificar primeiro a admissão MAC, a atribuição da rede, os membros da bridge e o DHCP da LAN. A comunicação local na LAN é intencional neste caso e não demonstra isolamento de convidados nem um percurso de dados controlado pelo SFOS.

Bridge to VLAN

Bridge to VLAN separa a rede de gestão do ponto de acesso da VLAN dos clientes. A porta do switch ligada ao AP tem de transportar ambas as redes como trunk. No perfil Wi-Fi, Bridge to VLAN ID identifica a VLAN dos clientes; com autenticação Enterprise, esta ID de VLAN dos clientes pode ser definida de forma estática ou através de RADIUS com fallback estático.

O AP deve ser inicialmente ligado à firewall durante pelo menos um minuto através da LAN padrão sem tagging, para receber a respetiva configuração. Em seguida, ativa-se VLAN tagging em Wireless > Access points > AP > Advanced settings e introduz-se a AP VLAN ID para a rede de gestão. Só então se altera a porta do switch para trunk. A VLAN de gestão do AP e a VLAN dos clientes podem utilizar IDs diferentes. A Sophos recomenda que não se misturem Separate zone e redes Wi-Fi VLAN no mesmo AP. O tagging de VLAN no próprio AP não está disponível para o LocalWiFi0 integrado.

Após a ativação, o AP tenta durante 60 segundos obter por DHCP um endereço na VLAN de gestão configurada. Se não receber resposta, volta a tentar DHCP na LAN sem tagging. Este é um caminho de recuperação útil, mas não um critério de sucesso: a VLAN, o trunk e o DHCP devem ser corrigidos até o AP ficar realmente online através da VLAN de gestão planeada. Com Bridge to VLAN, o SFOS cria automaticamente a interface VLAN e as regras de firewall correspondentes. Estes objetos devem ser verificados, porque cada AP cria uma interface backend separada para cada zona e um desenho com muitos AP e zonas pode crescer consideravelmente.

A zona da interface da firewall para a VLAN de gestão dos AP tem de estar autorizada em Wireless > Wireless settings > Allowed zone. O modo de tráfego dos clientes e o VLAN tagging do lado do AP têm de ser compatíveis: Bridge to VLAN requer etiquetagem no AP; para Separate zone, esta pode estar ativada ou desativada. A ajuda VLAN mais antiga designa outro caso como bridge to an access point VLAN e exige aí que a etiquetagem no AP esteja desativada. Desta formulação não se deve deduzir uma opção adicional da interface de utilizador atual. Para o procedimento Bridge to AP LAN sem etiquetas aqui descrito, deixar a etiquetagem no AP desativada; no caso de um desenho diferente, confirmar a compatibilidade no modelo e na compilação efetivos antes da alteração.

Bridge to VLAN evita o percurso VXLAN e é frequentemente mais adequado para ambientes Wi-Fi de maiores dimensões que já estejam devidamente segmentados. Também neste caso se aplica o seguinte: o tráfego dentro da VLAN dos clientes não é inspecionado automaticamente pelo SFOS.

Preparar a rede de exemplo

O exemplo utiliza estes valores:

Nome no SFOS: Guest WiFi
Hardware name imutável: GuestWiFi
SSID visível: Company Guest
Security mode: WPA2 Personal
Client traffic: Separate zone
Zone: WiFi
Rede de clientes: 10.30.40.0/24
Interface e gateway: 10.30.40.1
Intervalo DHCP: 10.30.40.100 a 10.30.40.220
Regra de firewall: WiFi_Guest_to_WAN

10.30.40.0/24 é um exemplo do espaço de endereços privados. Antes de o utilizar, deve escolher-se uma sub-rede livre que não se sobreponha a uma LAN, VPN, RED, VLAN ou localização remota. No exemplo, o primeiro endereço utilizável, 10.30.40.1, pertence à interface Wireless da firewall e é distribuído como gateway.

Para dispositivos APX existentes, WPA2 Personal com AES é a base segura e compatível. Uma palavra-passe longa e única deve ser guardada no gestor de palavras-passe, não em tickets nem em capturas de ecrã. No SFOS 22, a Sophos documenta os modos WPA3 apenas para o Wi-Fi integrado dos modelos XGS 88w, 108w, 118w e 128w; por isso, não se deve planear a utilização de WPA3 com APX.

A lista de segurança também contém No Encryption, WEP Open, modos WPA mais antigos e modos mistos WPA/WPA2. Estas entradas não são uma recomendação para um Wi-Fi novo ou renovado: não utilizar um perfil de convidados sem encriptação nem um mecanismo de recurso WEP/TKIP; substituir os clientes incompatíveis ou migrá-los separadamente. Em XGS 88w, 108w, 118w e 128w, é possível guardar perfis com TKIP ou AES/TKIP, mas não atribuí-los a LocalWiFi0. Nestes modelos, selecionar o modo WPA3 mais forte suportado por todos os clientes previstos, ou WPA2 Personal com AES, e testar efetivamente a ligação.

Configurar uma rede Wi-Fi gerida pelo SFOS

1. Permitir a ligação do ponto de acesso

Num APX externo, a rede de gestão e a rede de clientes Wi-Fi são duas coisas distintas. O AP obtém o seu próprio endereço de gestão por DHCP a partir da rede ligada. Os clientes Wi-Fi posteriores, por outro lado, recebem endereços da rede planeada acima, 10.30.40.0/24.

Abrir Wireless > Wireless settings.
Ativar Enable wireless protection.
Em Allowed zone, selecionar a zona através da qual o AP alcança a firewall. O SFOS disponibiliza DMZ, LAN e WiFi para este fim. Confirmar a seleção e guardar as definições Wireless com Apply antes de aceitar o AP.
Certificar-se de que o AP recebe um endereço, gateway e DNS por DHCP. Não é possível configurar um endereço de gestão estático no AP.
Verificar se a porta 2712 entre o AP e a firewall não está bloqueada por um switch, uma ACL ou um dispositivo intermédio.
Abrir Wireless > Access points e aceitar um AP pending com Accept.
Definir o Country correto no AP ativo. É esta definição que determina os canais legalmente permitidos. Se o Country de um APX for alterado, deve guardar-se a definição e reiniciar depois o ponto de acesso de forma controlada, para aplicar a nova lista de canais.

Numa firewall com duas placas Wi-Fi, uma alteração de Country afeta ambas as placas e define ambos os canais como Auto. Documentar previamente ambas as configurações de rádio e verificar ambas depois. Segundo a ajuda, no APX 320, ambos os rádios têm de estar definidos para 5 GHz para listar todos os canais de 5 GHz disponíveis; em Israel, porém, Radio 0 suporta apenas 2.4 GHz. A autorização local do país tem prioridade: não utilizar uma seleção de Country diferente para forçar canais.

Em Wireless > Wireless settings > Advanced settings, Timeout indica o número de minutos entre o momento em que um ponto de acesso fica offline e a notificação de tempo esgotado; após esse período, o SFOS considera o AP inactive. Para uma verificação controlada, deve anotar-se primeiro o valor existente e desligar, durante uma janela de manutenção, apenas um AP de teste sem clientes de produção. Após um período temporariamente reduzido, mas seguro para a operação, devem surgir a notificação e o estado inactive. Em seguida, deve voltar a ligar-se o AP, confirmar que regressa ao estado active e repor o valor anterior de Timeout.

A seleção em Allowed zone refere-se ao percurso de gestão do ponto de acesso, não à zona posterior dos clientes Wi-Fi. Se o AP ainda estiver registado noutra Sophos Firewall ou no Sophos Fusion, terá de ser primeiro eliminado nesse local. Se tal não for possível, terá de ser reposto para as definições de fábrica. Para a desativação definitiva planeada, retire primeiro da rede o AP identificado de forma inequívoca e, em seguida, selecione esse AP em Wireless > Access points e utilize Delete. Verifique previamente a sua identidade; depois, verifique se a respetiva entrada foi removida e se os AP e SSID restantes continuam a funcionar. Delete não equivale à remoção de uma atribuição Wi-Fi nem à desativação de um grupo; não elimine um AP em produção a título de experiência para resolver problemas.

A ligação de controlo pela porta 2712 é encriptada com AES entre a firewall e o ponto de acesso. Permitir a porta não substitui, no entanto, a limitação da rede de gestão do AP à zona que realmente necessita dessa ligação.

2. Criar a Wireless Network

Em Wireless > Wireless networks > Add, introduzem-se os valores do exemplo:

Name: Guest WiFi
Hardware name: GuestWiFi
SSID: Company Guest
Security mode: WPA2 Personal
Passphrase: uma palavra-passe longa e única
Client traffic: Separate zone
Zone: WiFi
IP address: 10.30.40.1
Netmask: /24

O Hardware name pode ter, no máximo, dez caracteres compostos por letras, números e sublinhados e não pode ser alterado posteriormente. O Name suporta até 58 caracteres e o SSID entre 1 e 32 caracteres ASCII imprimíveis. Ambos podem ser adaptados à convenção de nomes da organização. O Name da rede sem fios pode ser alterado posteriormente e é apresentado noutras definições em vez do Hardware name. Neste campo são permitidos todos os caracteres exceto '"<>#%\/,; não aplique esta restrição a SSID, Hardware name ou Passphrase.

Em Advanced settings, estas opções são adequadas para o exemplo de convidados:

Encryption: AES
Frequency band: apenas as bandas suportadas pelo modelo utilizado e pelos respetivos módulos de rádio
Client isolation: ativar se não forem pretendidas ligações diretas entre convidados
Hide SSID: deixar desativado
Fast transition: utiliza IEEE 802.11r e requer WPA2 como Security mode. O APX não suporta esta função. Utilize-a apenas em hardware compatível que não seja APX, depois de verificar o modelo, a compilação do SFOS e os clientes; isto não implica suporte para AP6 nem aprovação para todos os modelos W ou para WPA3.
Time-based access: controla os horários de acesso permitidos para este SSID. Utilize Add new item para selecionar um horário adequado ou criar o seu próprio horário. Efetue a ativação e as alterações de configuração durante uma janela de interrupção planeada, porque a ativação reinicia hostapd e desliga todos os clientes do AP afetado, conforme descrito abaixo. Com um cliente de teste, verifique tanto o período previsto de acesso permitido como o de acesso bloqueado; este horário de acesso não é o horário das análises de rádio ou de AP não autorizados.

Client isolation bloqueia apenas a comunicação direta entre clientes do mesmo SSID e no mesmo rádio. Não substitui a separação através de zonas, VLAN e regras de firewall entre vários AP ou módulos de rádio. Um SSID oculto também não é um controlo de segurança; apenas impede a apresentação visível do nome da rede.

Com Wi-Fi integrado, a operação simultânea em banda dupla depende do hardware. XGS 87w e 107w transmitem apenas em 2.4 GHz ou 5 GHz. XGS 116w, 126w e 136w necessitam de um segundo módulo de rádio para utilizar ambas as bandas. XGS 88w, 108w, 118w e 128w podem utilizar ambas as bandas em simultâneo sem um módulo adicional.

Ao ativar uma programação Wireless, o SFOS reinicia o hostapd. Isto desliga brevemente todos os clientes Wi-Fi do ponto de acesso afetado, não apenas os clientes desse SSID. Os dispositivos deverão voltar a ligar-se automaticamente.

Se também se pretender bloquear um dispositivo conhecido, criar, por exemplo, Bad hosts com Type: MAC list em Hosts and services > MAC host > Add, introduzir os endereços MAC efetivamente a bloquear e guardar. No perfil de convidados, em Advanced settings > MAC filtering, selecionar a opção de lista de bloqueio, atribuir esta MAC list e guardar o Wireless Network com Save. A ajuda Separate zone chama a esta opção Blacklist; verificar a designação da lista de bloqueio na compilação utilizada. Com um dispositivo de teste bloqueado e outro autorizado, verificar que apenas o dispositivo bloqueado é rejeitado. Um endereço MAC falsificado ou aleatório pode contornar este bloqueio: este não comprova a deteção de malware nem que um dispositivo esteja limpo, e não substitui políticas de proteção ou a separação de redes. Allowed zone permite o caminho de gestão do AP; ativar Wireless Protection, por si só, não comprova uma verificação de malware em todos os pacotes Wi-Fi ou LAN.

Validar separadamente Wi-Fi Enterprise e RADIUS

Numa rede Wireless com 802.1X, o servidor RADIUS é selecionado em Wireless > Wireless settings. O ponto de acesso não comunica diretamente com o servidor RADIUS: utiliza a porta 414 para comunicar com a firewall durante a Authentication e a porta 417 para Accounting. Em seguida, a firewall encaminha o Accounting para a porta RADIUS configurada, normalmente a 1813.

Para autenticação Enterprise, utilizar Wireless network Name como NAS ID, não automaticamente o SSID visível ou o Hardware name. Estes valores podem ser diferentes. Ajustar a política RADIUS a este nome e verificar no registo de autenticação de um cliente de teste que são utilizadas a NAS ID e a política esperadas; verificar a autenticação e a contabilização separadamente.

O Accounting tem de estar ativo no servidor RADIUS; este percurso Wireless não suporta Interim Accounting Updates. O Secondary RADIUS server não deve ser planeado como failover geral: os dispositivos APX e os dispositivos com Wi-Fi só podem utilizar o servidor RADIUS primário, e os XGS Appliances não suportam um servidor RADIUS secundário para este processo.

Para este percurso sem fios gerido pelo SFOS, as definições Wireless do SFOS 22 e 23 exigem um mapeamento NAT para as redes dos pontos de acesso quando o servidor RADIUS está ligado à firewall através de um túnel IPsec. O IP de origem deve ser traduzido precisamente para o endereço IP da firewall através do qual esta alcança o servidor RADIUS. Trata-se das redes dos AP, não da rede dos clientes sem fios em geral. A ajuda remete para a configuração na shell com sys-traffic-nat, mas não fornece aqui um comando completo e executável. Isto não estabelece uma necessidade geral de NAT para outros caminhos RADIUS.

Antes de uma alteração, documentar a versão e o build exatos do SFOS, as redes dos AP, o endereço de origem efetivamente utilizado, o IP previsto da firewall para a tradução, o túnel e os Traffic Selectors, o caminho de retorno e os logs RADIUS. Sem sintaxe confirmada para este build e percurso de dados, não efetuar alterações na shell: pedir à Sophos Support que confirme a shell suportada, os parâmetros e os endereços a utilizar, bem como as verificações prévias, os critérios de sucesso e a reversão exata. Efetuar a alteração apenas numa janela de manutenção seguindo esse procedimento confirmado; depois, verificar a autenticação 802.1X e o Accounting com um cliente de teste e comparar o IP de origem observado no servidor RADIUS e o caminho de resposta com os valores previstos. Em caso de divergências, não alargar as regras de acesso: analisar as provas com Support e utilizar a reversão confirmada se necessário.

O tráfego de autenticação gerado pela firewall deve ser distinguido do tráfego dos clientes encaminhado. O artigo sobre rotas IPsec para tráfego encaminhado explica system ipsec_route e NAT para esse percurso de encaminhamento; não contém um procedimento de sys-traffic-nat. Nem o seu DNAT/SNAT reflexivo nem uma regra LAN-to-VPN substituem a configuração NAT do tráfego de sistema exigida aqui.

Depois de configurar as definições gerais e avançadas e, se aplicável, as definições Enterprise e do filtro MAC, guardar o Wireless Network com Save – mesmo que não seja utilizada nenhuma lista de bloqueio de MAC. Em Wireless > Wireless networks, verificar se Guest WiFi aparece com as definições previstas. Só depois criar o servidor DHCP nesta interface e atribuir a rede a um AP conforme descrito abaixo. Unplugged antes da atribuição a um AP não é motivo para voltar a criar o perfil nem para o criar com um modo de tráfego diferente.

3. Adicionar DHCP para a rede de clientes

Para Separate zone, não é fornecido automaticamente um servidor DHCP completo para os clientes. Por isso, em Network > DHCP > Server > Add, cria-se, por exemplo, esta configuração:

Name: dhcp-wifi-guest
Interface: Guest WiFi
Dynamic IP lease: 10.30.40.100 a 10.30.40.220
Subnet mask: /24
Gateway: Use interface IP as gateway
DNS server: adequado à arquitetura DNS da organização
Conflict detection: ativado

O intervalo começa intencionalmente acima do endereço IP da interface e deixa espaço para endereços reservados. Numa rede Wi-Fi para convidados com muita rotatividade, uma concessão mais curta do que numa rede de escritório estável pode ser útil. Concessões extremamente curtas, por outro lado, geram renovações desnecessárias.

A escolha dos servidores DNS distribuídos é uma decisão de segurança e operação. Os servidores DNS internos do AD não devem ser disponibilizados aos convidados apenas por conveniência. Configurar a Sophos Firewall como servidor DHCP explica o planeamento completo e a verificação das concessões.

4. Verificar a regra de firewall, o NAT e os serviços locais

Em Rules and policies > Firewall rules > Add firewall rule > New firewall rule, cria-se uma regra para o acesso pretendido à Internet. O formulário completo, a ordem das regras e as Security Features são explicados no artigo sobre regras da Sophos Firewall.

Rule name: WiFi_Guest_to_WAN
Action: Accept
Log firewall traffic: ativado
Source zones: WiFi
Source networks and devices: objeto de rede para 10.30.40.0/24
Destination zones: WAN
Destination networks: Any
Services: apenas os serviços necessários para a rede Wi-Fi de convidados
Security features: políticas Web, Application e IPS adequadas de acordo com a licença e a finalidade

Um objeto de rede descritivo como net_WiFi_Guest torna a regra mais restrita e compreensível do que Source networks: Any. A seleção dos serviços depende de o DNS e o NTP serem utilizados localmente na firewall ou diretamente no exterior. Uma autorização genérica com Any é prática, mas dificulta a verificação posterior.

Além disso, uma regra NAT tem de traduzir o tráfego de saída para o endereço WAN. A regra SNAT predefinida existente com MASQ já abrange frequentemente novas redes internas, mas isto deve ser verificado no conjunto de regras específico, em vez de se criar uma segunda regra NAT por precaução. Compreender o NAT na Sophos Firewall explica esta relação.

Uma regra de WiFi para WAN não impede automaticamente os acessos através de regras amplas de WiFi para LAN ou Any que já existam. Por isso, deve verificar-se toda a ordem das regras quanto a autorizações internas. Se os clientes da mesma rede do tipo Separate zone tiverem de comunicar entre si através de vários AP, é também necessária uma regra de WiFi para WiFi. Numa rede Wi-Fi para convidados, esta comunicação só deve ser permitida intencionalmente.

O acesso à própria firewall não é controlado pela regra de firewall normal. Em Administration > Device access, verifique as permissões WiFi efetivamente configuradas para HTTPS e SSH, em vez de presumir uma determinada predefinição. Por conseguinte, em Administration > Device access, devem remover-se, para uma rede Wi-Fi de convidados, as caixas de seleção WiFi de HTTPS, SSH e de todos os outros serviços locais desnecessários. O DNS só deve permanecer permitido se os clientes utilizarem efetivamente a firewall como resolver. Device Access e Local Service ACL explica os motivos.

5. Atribuir a rede Wi-Fi a um ponto de acesso

Uma Wireless Network guardada ainda não é transmitida por nenhum ponto de acesso:

Abrir Wireless > Access points.
Abrir o ponto de acesso ativo através do respetivo nome ou de Edit.
Verificar o Country correto.
Em Wireless networks, clicar em Add new item.
Selecionar Guest WiFi, confirmar com Apply e clicar em Save.

Com vários pontos de acesso, é mais claro utilizar um grupo em Wireless > Access point groups. Desta forma, os SSID são atribuídos de modo consistente e não são geridos de forma diferente em cada AP. É possível atribuir até oito Wireless Networks a um AP.

O grupo é criado em Wireless > Access point groups > Add com nome, Wireless networks, VLAN tagging opcional e os Access points incluídos. Antes de guardar, deve confirmar-se que a atribuição de VLAN é realmente adequada para todos os AP selecionados.

⚠️ Impacto operacional: Ao desativar um grupo de pontos de acesso, todos os AP incluídos deixam de transmitir as redes Wi-Fi atribuídas. Uma alteração de grupo deve, por isso, ser planeada numa janela de manutenção com uma lista documentada de AP e SSID.

Alterar conscientemente os parâmetros de rádio e os grupos de AP

Em Wireless > Access points > AP > Advanced settings, o canal, Dyn chan, TX power e Channel width afetam mais do que um único cliente de teste. Uma alteração dinâmica de canal pode obrigar os clientes ligados a voltar a ligar-se. Canais mais largos podem aumentar o débito num ambiente de baixa densidade, mas a sobreposição adicional pode reduzi-lo num ambiente de alta densidade. O SFOS utiliza por predefinição 20 MHz em 2,4 GHz e 40 MHz em 5 GHz. A potência de transmissão e a largura do canal devem, por isso, ser medidas em cada local, em vez de simplesmente maximizadas.

Turn on Spanning Tree Protocol (STP) protege redes em bridge contra loops de camada 2 e as tempestades de broadcast resultantes. STP não deve ser tratado como um ajuste de desempenho. Após uma alteração, testam-se pelo menos dois clientes reais, roaming, DHCP, DNS e uma transferência prolongada; com seleção automática de canal, regista-se também o momento da alteração e a nova ligação correta dos clientes.

Se a seleção dinâmica de canal tiver de ser executada apenas em horários definidos, ative primeiro Dyn chan e depois Time-based scan para cada banda e atribua o Schedule previsto em Select scan time > Add new item ou crie-o através de Add. Após Save, observe a hora da análise e uma eventual nova ligação dos clientes. Antes de efetuar alterações de grupo, identifique inequivocamente o AP através de ID (número de série), Label e Group. Um WLAN individual pode ser novamente desmarcado nos respetivos detalhes do AP através de remove; depois, guarde e verifique os restantes SSIDs. Isto não equivale a desativar todo o grupo de AP. Para um reinício planeado do AP, o AP selecionado pode ser reiniciado em Wireless > Access points através de Restart; antes, guarde a lista de clientes e os registos e, depois, repita os testes de ligação descritos abaixo.

Testar a rede Wi-Fi de forma controlada

A validação não deve terminar em «o SSID está visível». Com um cliente de teste, deve verificar-se se a rede e as regras planeadas estão efetivamente a ser utilizadas:

Em Wireless > Access points, o AP tem de estar ativo. A interface Wireless permanece em Unplugged em Network > Interfaces enquanto não estiver ligado nenhum AP com esta Wireless Network.
Ligar a Company Guest e verificar o AP, o SSID, a frequência e o sinal em Wireless > Wireless client list.
Em Network > DHCP > IPv4 lease, verificar se o cliente recebeu um endereço entre 10.30.40.100 e 10.30.40.220.
Verificar o endereço IP, o gateway e o DNS no cliente. No Windows, estes comandos são úteis:

ipconfig /all
nslookup example.com

Testar uma ligação permitida à Internet e, intencionalmente, um destino interno não permitido.
No Log Viewer, filtrar pelo endereço IP do cliente e verificar os valores esperados de Firewall Rule ID e NAT Rule ID.

O sucesso não consiste apenas no acesso à Internet. O cliente tem de utilizar o gateway correto e os servidores DNS previstos, permanecer separado de destinos internos não autorizados e passar exatamente pelas regras de firewall e NAT esperadas. Testar corretamente as regras de firewall mostra o procedimento geral de verificação.

Analisar pontos de acesso rogue de forma controlada

Rogue AP scan só está disponível em appliances Sophos Firewall com Wi-Fi integrado; os pontos de acesso APX externos não podem executar esta análise. Em Wireless > Rogue AP scan, Scan now procura pontos de acesso dentro do alcance de rádio. Durante a análise, os clientes Wi-Fi ligados são brevemente desligados. Uma análise manual ou programada deve, por isso, decorrer numa janela de tempo conhecida e não sem aviso durante a operação em produção.

Os dispositivos encontrados aparecem em Unrecognized access points e são deliberadamente marcados como autorizados ou como Rogue AP. Esta classificação não substitui a investigação do incidente: SSID, BSSID, canal, sinal, localização e uma possível porta do switch devem ser correlacionados antes de uma rede Wi-Fi desconhecida ser tratada como um dispositivo na própria LAN.

Para análises recorrentes, seleciona-se uma programação em General settings > Schedule system-triggered scan at. Com LocalWiFi0, Bridge to Ethernet ativo e uma rede Wireless no modo Bridge to AP LAN, a análise mostra apenas as redes próximas na mesma banda de frequência da rede Wireless atribuída. Esta limitação do produto deve ser documentada durante a avaliação do resultado.

Aplicar a programação da análise com Apply. Nos resultados, utilizar as ações Mark as “authorized access point” ou Mark as “rogue access point” e verificar a atribuição resultante. Uma entrada marcada como rogue é uma classificação, não um mecanismo comprovado para desligar ou bloquear um ponto de acesso de terceiros.

Identificar erros comuns

O SSID não é apresentado

Primeiro, deve verificar-se se a Wireless Protection está ativa, se a zona de gestão do AP consta de Allowed zone e se o ponto de acesso está active, em vez de pending ou inactive, em Wireless > Access points. Em seguida, verificam-se o Country, a Wireless Network atribuída, a Frequency band e uma possível programação.

Uma rede guardada sem atribuição a um AP não é transmitida. No Wi-Fi integrado, as limitações do modelo relativas às bandas de rádio ou um modo de encriptação antigo não suportado também podem impedir que o perfil seja associado a LocalWiFi0.

A interface Separate zone permanece `Unplugged`

O estado Unplugged é normal enquanto nenhum ponto de acesso estiver ligado ou a Wireless Network não estiver atribuída a um AP. Se o estado persistir apesar de um APX ativo e de uma atribuição correta, deve verificar-se o caminho de gestão do ponto de acesso.

No SFOS 21.5 MR1 Build 261, isto pode ocorrer quando o endereço IP da firewall utilizado pela rede de gestão do APX está configurado como alias em vez de diretamente na interface principal (NC-175920). O SFOS não consegue então criar o túnel VXLAN para Separate zone. A solução consiste em mover o APX para uma rede de gestão cujo endereço IP da firewall esteja configurado diretamente na interface principal. O endereço IP alias não deve ser eliminado sem confirmar primeiro a causa.

A alteração interrompe as redes Wi-Fi transmitidas pelo AP. Por isso, devem verificar-se previamente o DHCP, o gateway, Allowed zone e a porta 2712 na rede de destino, e efetuar a alteração durante uma janela de manutenção. Depois, devem confirmar-se o estado do AP, a atribuição da rede Wi-Fi, o estado da interface e a ligação de um cliente de teste. A Sophos não indica uma versão corrigida; noutras versões do SFOS, o estado Unplugged por si só não comprova este problema.

O cliente não recebe um endereço IP

Com Separate zone, o servidor DHCP tem de estar na interface Wireless criada e o intervalo tem de corresponder à rede da interface. Com Bridge to AP LAN, responde o servidor DHCP da LAN do AP. Com Bridge to VLAN, devem verificar-se em conjunto o trunk do switch, a ID de VLAN e o servidor DHCP acessível na VLAN dos clientes.

O DHCP de gestão do AP e o DHCP dos clientes não devem ser confundidos: o AP pode estar online mesmo que ainda não exista um servidor DHCP funcional para os clientes Wi-Fi.

O cliente tem um endereço IP, mas não tem Internet

Nesse caso, o DHCP e a ligação Wi-Fi já funcionam e a verificação seguinte incide sobre a política propriamente dita. Em seguida, verificam-se o gateway e o DNS, a regra de WiFi para WAN, a ordem das regras, o logging e a regra MASQ/SNAT adequada. O Log Viewer mostra se foi utilizada a Firewall Rule ID prevista ou se a regra implícita #0 descartou o tráfego.

Se o cliente aceder à Internet, mas também a sistemas internos, isso não representa um resultado bem-sucedido para uma rede Wi-Fi de convidados. Neste caso, estão provavelmente a ser aplicadas regras de WiFi para LAN, Any ou regras de rede demasiado abrangentes.

A ligação do AP ou a comunicação dos clientes continua por esclarecer

O tráfego da firewall só aparece de forma fiável no Log Viewer se Log firewall traffic estiver ativado na regra e o tipo de log Firewall estiver ativo em System services > Log settings > Local reporting. Os próprios eventos Wireless não estão disponíveis nesse local como um tipo de log Wireless local normal; em System services > Log settings, podem ser enviados para o Sophos Fusion ou para um servidor syslog.

Para um diagnóstico mais aprofundado, a Sophos documenta o awed.log para a comunicação entre a firewall e o APX, o wc_remote.log para os clientes Wireless e o hostapd.log para o LocalWiFi. Verificar serviços e logs da Sophos Firewall através da CLI explica como ler estes logs sem reiniciar serviços de forma descontrolada.

Se necessário, o registo de um APX acessível pode ser lido através de awetool. Iniciar sessão como admin na CLI da firewall, selecionar 5 – Device Management, depois 3 – Advanced Shell, e iniciar awetool. Selecionar Connect to an AP, escolher o AP de destino com base na sua identidade, confirmar com OK e concluir a ligação com y. Só neste AP é que logread e logread -f são as verificações de leitura documentadas. O comando reboot, também disponibilizado, desliga os clientes e altera o estado; só deve ser executado após guardar os registos, durante uma janela de manutenção e com uma verificação posterior do estado do AP, do SSID, da lista de clientes e do tráfego real. Não aplicar estes passos da shell APX a AP6, a LocalWiFi integrado ou a UTM.

As transferências grandes são lentas ou falham

Se apenas os pacotes maiores ou as transferências mais longas forem afetados, a encapsulação VXLAN de Separate zone pode desempenhar um papel. Não existe um valor de MTU universalmente válido. Primeiro, devem documentar-se a Rule ID, o percurso dos dados, os Retransmits e um teste de aplicação reproduzível. Só depois de comprovado um problema de MTU/MSS se deve efetuar uma alteração controlada e repetir o mesmo teste.

Enquadrar os objetos Wireless de forma segura através da XML API

Quem automatiza as definições descritas acima deve tratar separadamente o perfil de rede, a componente de rádio local, o grupo de APs e as definições globais de Wireless. As referências XML para SFOS 22 e 23 documentam os objetos seguintes, mas não autorizam o envio de um pedido de escrita copiado sem alterações. O acesso, as operações explícitas, a avaliação das respostas e as repetições seguras são explicados em Proteger o acesso à Sophos Firewall XML API. Antes de efetuar alterações, guardar o estado atual do objeto, as dependências e um procedimento de reversão confirmado. Nos conflitos entre fontes indicados abaixo, esclarecer primeiro os campos de escrita afetados em API help do build instalado ou com o suporte; até lá, não os enviar. Todos os códigos seguintes são valores de estado XML específicos do objeto, não códigos de estado HTTP; todos os símbolos Message.* são chaves de referência não resolvidas, não textos confirmados de respostas em tempo de execução. Registar em conjunto a operação, o código e a resposta efetivamente recebida, devidamente expurgada de dados sensíveis.

WirelessLocalAP: identidade e parâmetros de rádio do modelo W

WirelessLocalAP pertence ao ponto de acesso local integrado de um appliance Wireless compatível, não à interface Web local de um AP6 nem à sua gestão através de Central/Fusion. Este contrato não estabelece um novo fluxo de API para APX nem constitui instruções para dispositivos AP/UTM antigos. O campo obrigatório Id identifica o AP local existente; Label é uma designação opcional, não uma identidade alternativa. O exemplo da referência usa LocalWifi0/LocalWifi1, enquanto a ajuda da interface utiliza LocalWiFi0. Não corrigir silenciosamente as maiúsculas e minúsculas nem enviar a barra como parte de um ID conjunto: confirmar a identidade individual efetiva no resultado de leitura/exportação correspondente ao build. Country deve corresponder à localização real, não ao exemplo In.

No exemplo, as atribuições de rede encontram-se em WirelessNetworks/Network. A tabela descreve Network como um array e avisa que os valores duplicados não são ignorados. Por isso, comparar integralmente as atribuições existentes e não enviar uma lista de SSIDs nem nomes de rede presumidos. O limite de oito Wireless Networks atribuídas e os limites de hardware das bandas de rádio continuam a ser relevantes na automatização.

Quanto à atribuição de bandas, a tabela descreve Band com 2.4GHz ou 5GHz; para 2,4 GHz, indica Channel, ChannelWidth, TXPower, DynChan e TimeBasedScan; para 5 GHz, indica, por sua vez, Channel5GHz, ChannelWidth11a, TXPower5GHz, DynChan5GHz e TimeBasedScan5GHz. O exemplo apresenta os horários de varrimento em ScanTime/Time; a tabela lista Time duas vezes como um array dependente da banda, sem mostrar claramente a estrutura superior para ambas as bandas. Confirmar a estrutura superior correta para cada banda antes de um pedido de escrita, em vez de reunir todas as entradas Time ou inventar um elemento superior para 5 GHz. Os horários de varrimento de rádio não são o horário de acesso ao SSID.

Várias indicações contradizem-se: o exemplo utiliza Channel2.4GHz, a tabela utiliza Channel; em DynChan e TimeBasedScan, o exemplo apresenta Enable, mas as listas de valores apenas indicam t. Para TXPower, o exemplo apresenta 100, enquanto a tabela indica 10%, 25%, 50%, 75%, 100%. O texto relativo à atribuição de banda de DynChan também não é inequívoco. Estas formas não estão confirmadas como valores intercambiáveis. Além disso, a descrição de exportação de DynChan5GHz distingue Disabled (canal estático, varrimento dinâmico desativado), 1 (canal automático sem varrimento dinâmico) e Enabled (canal automático com varrimento dinâmico); não tratar automaticamente os valores exportados como entradas de escrita permitidas.

BridgeToEthernet, BridgeToPort e Zone dizem respeito à bridge Ethernet local, não ao ID de VLAN dos clientes de um perfil de rede. Os limites de Gen.1/Gen.2, os requisitos de IPv4/Bridge-to-AP-LAN e as verificações de DHCP/acesso administrativo descritos acima continuam a aplicar-se. Após uma alteração confirmada, verificar ambos os rádios afetados, o país, as atribuições de rede, a bridge e um cliente real antes de alterar outros APs.

A Status Message Information da operação Update Local AP associa, em ambas as versões da referência, os seguintes valores de estado 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.

Estas são chaves de referência literais, não resolvidas, e não mensagens comprovadas em tempo de execução. Em particular, não deduzir de Message.TopazToNonTopazImportFail uma correspondência entre modelos nem uma migração por importação permitida. Perante uma resposta pouco clara, consultar a identidade do AP, os parâmetros de rádio e as atribuições efetivamente guardados, em vez de repetir automaticamente a mesma atualização ou enfraquecer a encriptação.

WiFi6Interface: interface existente, não um SSID ou uma bridge

WiFi6Interface gere, nas referências XML para SFOS 22 e 23, as definições de rede e de zona por porta de LocalWiFi6, não um perfil de SSID nem uma bridge física. Os campos obrigatórios são Name, Hardware e Zone: Name é a designação descritiva, com um máximo de 58 caracteres; Hardware identifica o nome de hardware da interface já existente. Antes de uma alteração, confirmar esta identidade no resultado de leitura/exportação correspondente ao build, sem a deduzir do nome de apresentação, de SSID ou de WirelessNetworks.HardwareName. O requisito de dez caracteres de A-Za-z0-9_ para o nome de hardware de uma bridge física não se aplica aqui; a tabela de WiFi6Interface indica apenas uma string para Hardware. O nome do objeto da API também não permite deduzir uma correspondência com uma geração de hardware. As verificações de bridge na GUI, de DHCP e de acesso administrativo dependentes do modelo, descritas acima, continuam a aplicar-se sem alterações.

IPv4Address e Netmask são opcionais neste contrato. Isto não implica uma obrigação de definir um novo endereço nem confirma o efeito de omitir valores existentes. Antes de efetuar alterações, documentar a porta efetiva, a zona e, se existir, o endereço IP com a respetiva máscara; depois, consultar novamente o estado dessa mesma interface e compará-lo com o plano de endereçamento previsto. Esta comparação da interface não substitui a verificação da atribuição ao AP e do SSID nem um teste com um cliente real.

Para a operação WiFi6Interface, ambos os corpos das fontes apresentam 200/Message.InterfaceUpdateSuccess, 500/Message.InterfaceUpdateFail e 502/Message.InterfaceIPAlreadyInUsed. Estes são valores de estado XML específicos do objeto, com chaves de referência não resolvidas, não códigos HTTP nem textos confirmados de respostas em tempo de execução. Registar em conjunto a operação, o código e a resposta efetivamente recebida, devidamente expurgada de dados sensíveis. Perante um resultado pouco claro, consultar primeiro a identidade de hardware, a porta, a zona e, se aplicável, o IP/Netmask, em vez de repetir automaticamente a mesma atualização ou criar outro objeto Wireless. Um código de sucesso, por si só, não comprova a atribuição correta à rede nem o funcionamento do tráfego Wi-Fi; daqui não se deduz um novo pedido de escrita.

WirelessNetworks: distinguir identidade de hardware, perfil e estado

Em WirelessNetworks, o Hardware name imutável, o nome de apresentação alterável Name e o SSID difundido são valores distintos. No exemplo de convidados, são GuestWiFi, Guest WiFi e Company Guest. A tabela de parâmetros de adição/atualização exige HardwareName com um máximo de dez caracteres; a operação de eliminação também identifica o destino através de HardwareName, não do SSID nem do nome de apresentação. Antes de eliminar, verificar as atribuições de APs, a interface, o DHCP e as regras, e remover apenas o destino inequivocamente identificado e autorizado. Um erro não justifica voltar a criar o perfil com um novo nome.

No entanto, o exemplo de adição/atualização utiliza Hardware em vez de HardwareName e ClientIsolation com Enable em vez do valor da tabela Enabled. Em HideSSID existe a mesma divergência; a tabela indica Enabled/Disabled para cada um dos campos TimeBasedAccess, ClientIsolation, HideSSID e FastTransition. Também MACFiltering com Allowlist/Blocklist aparece a par de uma descrição mais antiga de MACList com Whitelist/Blacklist. Não resolver nenhuma destas divergências por suposição. O contrato XML lista ainda modos de segurança mais antigos, enquanto a ajuda atual da interface descreve WPA3 apenas para os modelos W acima referidos: isto não estabelece uma sintaxe de escrita WPA3 completa.

Os tokens de tráfego documentados SeparateZone, BridgetoAPLAN e BridgetoVLAN pertencem a ClientTraffic. IPAddress e Netmask referem-se a Separate zone; BridgetoVLANid, à VLAN dos clientes; ClientVlanId, a Static ou RadiusAndStatic. Não confundir estes valores com a VLAN de gestão dos APs. Não reutilizar a chave do exemplo, o IP público do exemplo nem TKIP(only abg): o objetivo continua a ser AES ou um modo de segurança mais forte comprovadamente suportado, uma frase-passe própria e segura e uma separação de redes controlada. ClientIsolation continua a não substituir uma fronteira de firewall ou VLAN entre vários rádios/APs.

Para Add Wireless Network, ambas as referências indicam as seguintes associações:

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.

Para Update Wireless Network, várias chaves diferem apesar de os códigos serem os mesmos:

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.

Para Delete Wireless Network, estão documentados 200/Message.WPNetworkDeleteSuccess, 500/Message.WPNetworkDeleteFail, 541/Message.BridgeWirelessNetworkExists e 542/Message.WPEnableDeteleFail. Mesmo aparentes erros de escrita, como Message.SecModeChangedToWAP3Fail e Message.WPEnableDeteleFail, permanecem inalterados; não são renomeados para mensagens de execução supostamente corretas. Perante estas respostas, comparar primeiro a identidade de hardware, o IP, as dependências de DHCP, a bridge e as atribuições de APs efetivamente guardados. Não afirmar, com base apenas numa chave, uma causa, uma reversão bem-sucedida ou a segurança de uma nova tentativa.

WirelessNetworkStatus é um objeto separado: a sua tabela descreve expressamente Name como o nome da interface, com um máximo de dez caracteres, não como um alias automático do SSID ou do nome de apresentação. Aqui, Status utiliza Enable/Disable, não os valores Enabled/Disabled de outros campos. Confirmar previamente o nome efetivo da interface. Para Enable-Disable Wireless Network, são indicados 200/Message.WPNetworkUpdateSuccessfully e 500/Message.WPNetworkUpdateFail. Uma alteração de estado não atribui a rede a nenhum AP nem comprova, por si só, a sua difusão; verificar separadamente o estado guardado, a atribuição ao AP e a ligação do cliente.

WirelessGrouping: a pertença ao grupo não é uma configuração de rádio

WirelessGrouping descreve um grupo de APs com Name e as entradas repetíveis WirelessNetworks/Network e AccessPoints/AccessPoint. Utilizar as identidades dos APs do inventário existente, não o exemplo antigo de AP30 da referência. A estrutura do grupo configura atribuições de rede e a marcação opcional da VLAN de gestão dos APs, mas não os parâmetros de rádio locais dependentes da banda. O facto de os arrays serem opcionais não confirma a semântica de listas vazias nem a segurança de uma atualização parcial.

VLANTagging indica Enable/Disable; APVLANID indica 1 a 4094 e aplica-se quando a marcação está ativada. Esta é a VLAN de gestão dos APs, não BridgetoVLANid para os clientes. Antes de efetuar alterações, verificar a lista completa de membros, o trunk, o DHCP de gestão, a Allowed zone e o procedimento de reversão. A desativação de um grupo continua a interromper a difusão dos seus APs; após uma alteração confirmada, verificar cada AP afetado e os SSIDs previstos.

Para Add an Access Point Group, são indicados 200, 216/Message.WPGroupSuccess, 500, 541, 543, 545/Message.WPGroupCreated, 502/Message.WPGroupExists, 523/Message.WPGroupMax, 524/Message.WPGroupMaxAP e 546/Message.WPA3IsNotSupported. Para Update an Access Point Group, são indicados, por sua vez, 200, 216/Message.WPGroupUpdateSuccessfully, 500, 541, 543, 545/Message.WPGroupUpdateFail, 523/Message.WPGroupMaxForUpdate, 524/Message.WPGroupMaxAPForUpdate e 546/Message.WPA3IsNotSupported. A chave desconcertante Message.WPGroupCreated associada a códigos de erro não é uma garantia de sucesso. Antes de uma nova tentativa, consultar o grupo e os membros guardados, em vez de criar um segundo grupo ou adicionar mais APs.

Definições globais: acesso de gestão e efeitos subsequentes

WirelessProtectionGlobalSettings não é um perfil de SSID nem uma zona de clientes. No exemplo, AllowedZone/Zone contém as zonas de gestão repetíveis; NotificationTimeout corresponde ao tempo limite de notificação de estado offline, em minutos, explicado acima. RADIUSServer designa o servidor selecionado globalmente para o percurso Enterprise descrito. Para a opção de ativação, o exemplo utiliza WirelessProtection, enquanto a tabela utiliza EnableWirelessProtection: esclarecer também estes nomes de campo divergentes para o build específico antes de um pedido de escrita.

Para Global Settings, ambas as referências indicam 200/Message.WLANAPEditSuccessful, 500/Message.WLANAPEditFailed, 501/Message.WLANAPIPAlreadyInUsed e 504/Message.WLANAPIntBaseVHExist. As restantes distinções são:

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

As chaves não são interpretadas como causas de erro comprovadas, mas mostram por que motivo uma alteração global não deve ser tratada como um teste inofensivo: as associações de interfaces e a configuração de DHCP podem ser afetadas. Não desativar e reativar Wireless Protection para um diagnóstico rápido. Antes de uma alteração planeada, guardar uma cópia de segurança e registar o acesso administrativo independente, as interfaces, os servidores/relays DHCP e as atribuições de APs. Depois, consultar o estado global efetivamente guardado e os serviços afetados, verificar a acessibilidade dos APs e os clientes e, só com estas evidências, decidir sobre uma nova tentativa ou o procedimento de reversão confirmado. Um código XML de sucesso, por si só, não comprova nem o efeito sobre o rádio nem o sucesso completo da configuração.