Planear corretamente zonas e interfaces no Sophos Firewall
Uma zona agrupa interfaces com um nível de confiança semelhante. A interface é a ligação física ou virtual, por exemplo Port1, uma VLAN, um LAG ou uma interface RED ou XFRM. Cada interface associada pertence exatamente a uma zona; as portas físicas também podem ficar sem associação.
Importante: uma zona não permite tráfego automaticamente. Mesmo entre duas interfaces na zona LAN, é necessária uma regra de firewall LAN-to-LAN adequada. O acesso à própria firewall, por exemplo ao WebAdmin, SSH ou DNS, é adicionalmente controlado através de Device Access.
Configurar diretamente zonas e interfaces
Criar uma zona
Uma zona personalizada é criada em quatro passos em Network > Zones > Add:
- Atribuir um nome inequívoco, por exemplo
Server,Management,GuestouIoT. - Selecionar
LANouDMZcomo Type. - Em Device Access, permitir apenas os serviços locais da firewall que são realmente necessários a partir desta zona.
- Guardar.

Em seguida, a zona deve aparecer em Network > Zones e estar disponível numa regra de firewall como Source zone ou Destination zone. O tráfego de produção só pode utilizar a zona depois de lhe ser atribuída pelo menos uma interface.
As zonas personalizadas só podem ser do tipo LAN ou DMZ. Não é possível criar zonas WAN ou VPN adicionais. O SFOS atribui automaticamente as interfaces VPN à zona VPN. O número máximo de zonas depende da versão: o SFOS 22.0 permite até 100 zonas e o SFOS 23.0 até 248 zonas.
Configurar uma interface física
O número de portas físicas disponíveis depende do modelo do appliance. Por isso, ao planear, deve verificar-se primeiro que ligações disponibiliza o equipamento concreto; as interfaces virtuais não substituem portas físicas adicionais necessárias.
Uma porta existente é editada através de Edit interface em Network > Interfaces:
- Atribuir um Name descritivo com um máximo de 58 caracteres, por exemplo
Core Switch TrunkouMPLS Provider. - Selecionar a Network zone adequada.
- Configurar IPv4 e, se necessário, IPv6.
- Nas interfaces WAN, verificar Gateway e, se necessário, MTU e MSS.
- Guardar e verificar depois o estado da ligação, o estado do gateway e o Log Viewer.

Apenas as interfaces na zona WAN recebem uma configuração de gateway. As interfaces internas são normalmente endereçadas de forma estática; as ligações WAN podem ser configuradas de forma estática, por DHCP ou PPPoE.
Se a interface física já tiver uma VLAN, o SFOS não permite alterar a atribuição IPv4 de Static para DHCP ou PPPoE. Em IPv6, a alteração de Static para DHCP ou Delegated também fica bloqueada. Antes desta alteração, devem registar-se as dependências das VLAN em Object usage. Em seguida, as interfaces VLAN afetadas devem ser movidas para outra Parent Interface ou removidas durante uma janela de manutenção. Só depois se altera o método de atribuição, se repõe a configuração das VLAN e se testa a conectividade.
Em Advanced settings, deve alinhar-se Link mode, Auto-negotiation for media type, Forward Error Correction (FEC) dependente do modelo, MTU e MSS com o dispositivo remoto. Para portas de 25, 50 e 100 Gbps, guarda-se primeiro o Link mode, volta-se a abrir a interface e carrega-se depois a configuração recomendada. Nos XGS 2100, 2300, 3100 e 3300, todas as portas SFP+ dos módulos FleXi Port têm de usar a mesma velocidade. O SFOS não suporta marcação DSCP para tráfego DHCP e ARP gerado pelo sistema; uma política não pode depender de tratamento prioritário para estes pacotes.
As velocidades das portas na firewall e no equipamento remoto têm de ser compatíveis. Por exemplo, uma porta de 25 Gbit/s não pode ser ligada a uma porta de 40 Gbit/s através de cabos breakout sem uma conversão adequada. As portas de 40 e 100 Gbit/s da firewall que suportam breakout podem ser divididas em duas ou quatro portas com cabos breakout adequados. Isto não constitui uma garantia para todos os appliances ou todas as combinações de cabos; antes de planear, deve verificar-se o suporte das portas, dos transceivers e do equipamento remoto concretos.
Definir um endereço IPv4 no menu de recovery interativo
Em 1. Network Configuration > Interface Configuration, a CLI apresenta endereço IPv4 e netmask, endereço IPv6 e prefixo, zona, gateways e aliases configurados das portas físicas. Interfaces VLAN e WLAN não aparecem nesta vista.
y inicia uma alteração IPv4. O SFOS mostra sequencialmente endereço, netmask e zona atuais de cada porta; Enter sem novo valor mantém o campo. Este caminho aplica-se apenas ao Gateway mode e a valores IPv4 estáticos. Não permite configurar VLAN, DHCP, PPPoE, WLAN ou WWAN, e o diálogo IPv6 é diferente.
Antes da alteração, guardar todos os valores, ID da porta, zona, gateway, aliases e um caminho de gestão independente. Depois, verificar link, novo IP e netmask, gateway, Device Access, routing, DNS e o caminho de gestão real. Se o acesso for interrompido ou o caminho de dados estiver incorreto, restaurar os valores originais pela consola ou acesso independente.
Corrigir valores de link e MAC na Device Console
O WebAdmin continua a ser o caminho normal de configuração. A Device Console destina-se a uma correção ou recovery documentada, porque um valor de link incorreto pode interromper imediatamente o único caminho de gestão. Primeiro registam-se Port ID, peer, Link mode atual, autonegotiation, FEC, acesso administrativo independente e rollback.
A sintaxe oficial do SFOS 22 aceita 1000fd, 100fd, 100hd, 10fd, 10hd ou auto para os valores copper indicados:
set network interface-link Port2 linkmode auto autoneg on
set network interface-link Port2 linkmode 1000fd autoneg off
autoneg controla parâmetros de link adicionais à velocidade e duplex. Os modos FEC dependem do modelo e a Sophos não fornece uma lista universal neste comando CLI. Para portas de 25, 50 ou 100 Gbit/s, utiliza-se a configuração recomendada para o appliance e transceiver exatos, não um valor copiado de outro modelo.
Um endereço MAC só é substituído por uma dependência de design comprovada. O endereço de exemplo é administrado localmente, mas deve continuar a ser único na rede real:
set network macaddr Port2 override 02:00:5e:10:00:02
set network macaddr Port2 default
Antes do override verificam-se Port Security, bindings DHCP, allowlists do operador, HA e LAG. default restaura o endereço MAC predefinido existente da porta. A Sophos documenta MTU 1500 e MSS 1460 como valores predefinidos; só devem ser alterados com o processo controlado de Verificar MTU e MSS em problemas VPN.
Para IPv6, DAD attempts determina quantas mensagens Neighbor Solicitation a firewall envia durante Duplicate Address Detection. Em Allowed RA servers, introduzem-se os endereços MAC ou IPv6 dos servidores Router Advertisement dos quais esta interface pode aceitar uma configuração stateless. IPv6 Prefix Delegation na Sophos Firewall explica o prefixo do operador e a distribuição interna; Configurar IPv6 Router Advertisement descreve os flags dos clientes e os prefixos anunciados.
Para tarefas concretas, estão disponíveis instruções mais específicas:
- Configurar e testar uma interface VLAN
- Configurar e testar Wi-Fi gerido pelo SFOS
- Ligar APX existentes com Wireless Mesh
- Configurar uma interface LAG
- Configurar e testar um túnel GRE
- Transportar IPv6 sobre IPv4 ou IPv4 sobre IPv6 com um túnel IP
- Configurar e verificar uma WAN PPPoE
- Configurar o failover WAN com uma segunda ligação à Internet
- Configurar o Sophos SD-RED
- Proteger o Device Access
- Encaminhar Multicast entre interfaces com uma rota Multicast estática
- Planear e verificar Multicast Routing dinâmico com PIM-SM
- Configurar uma Site-to-Site IPsec VPN
Planear o modelo de zonas
Distinguir zona, interface e objeto de rede
Estes três elementos têm funções diferentes:
- Zona: descreve a área de segurança de onde vem o tráfego ou para onde se dirige.
- Interface: liga a firewall física ou virtualmente a uma rede.
- Objeto de rede: descreve o endereço IP ou a sub-rede concreta numa regra.
Uma regra só é precisa quando a zona e o objeto de rede estão corretos. Source zone: LAN em conjunto com Source networks: Any é muitas vezes desnecessariamente abrangente. Por outro lado, um objeto de rede correto não ajuda se o pacote entrar por uma zona diferente da indicada na regra.
As zonas predefinidas têm funções fixas:
LANpara redes internasWANpara ligações ao fornecedor e à internetDMZpara sistemas expostos ou especialmente isoladosWiFipara ambientes WLANVPNpara túneis Remote Access e Site-to-Site
A zona WiFi aplica-se a redes sem fios que utilizam uma zona própria. No entanto, com Bridge to AP LAN e Bridge to VLAN não é criada uma interface WiFi dedicada; o percurso do tráfego segue a associação de bridge selecionada.
Uma Wireless Network define as configurações comuns para os clientes WLAN: SSID, modo de segurança e tratamento do tráfego dos clientes. Com o Traffic Mode Separate zone, a firewall cria um túnel VXLAN associado. A seleção do Traffic Mode determina, assim, também a forma como a WLAN é ligada à firewall; não é apenas uma designação para a rede.
As zonas LAN personalizadas são adequadas, por exemplo, para Client, Server, Management, Guest, IoT, VoIP, Backup ou OT. Uma zona DMZ personalizada é adequada para servidores publicados, Reverse Proxy ou outros sistemas cujo acesso à rede interna deve ser estritamente limitado.
Nem todas as VLAN precisam de uma zona própria. É possível agrupar várias VLAN se tiverem o mesmo nível de confiança, as mesmas regras de firewall e o mesmo Device Access. Se os destinos permitidos, os acessos de gestão ou as funções de proteção forem diferentes, uma zona própria é geralmente mais clara.
Não se criam tipos de zona VPN próprios para utilizadores VPN ou túneis entre localizações. A separação é feita na zona VPN através de objetos de rede, utilizadores e regras de firewall precisos.
Definir as direções de acesso antes das regras
Antes da configuração, basta uma lista curta das direções permitidas. Por exemplo:
ClientparaWAN: serviços web, DNS, NTP e aplicações necessáriosClientparaServer: apenas portas de aplicações definidasGuestparaWAN: acesso à internet, mas sem acesso às redes internasIoTparaServer: apenas destinos necessários, como DNS, NTP ou uma plataforma de gestãoManagementpara zonas internas: serviços administrativos estritamente limitados e registadosDMZparaLAN: bloqueado por predefinição, apenas ligações explicitamente necessáriasVPNparaServer: apenas destinos e serviços autorizados
Para cada direção permitida devem ser conhecidos o destino, os serviços, a necessidade de NAT, o logging e a pessoa responsável. A partir daí são criadas as regras propriamente ditas. A estrutura, a ordem e o matching são explicados em Configurar corretamente regras no Sophos Firewall.
Verificar antes de uma alteração
Antes de criar ou mover uma interface, devem ser esclarecidos pelo menos os seguintes pontos:
- zona e nível de confiança da rede
- endereço IP, sub-rede e Default Gateway
- origem do DHCP e servidores DNS
- serviços locais da firewall necessários
- regras de firewall e NAT
- routing e SD-WAN
- cliente de teste, acesso esperado e entrada de log esperada
As alterações em produção exigem uma cópia de segurança atual, um plano de reversão e uma verificação em Object usage.
Criar e validar uma VLAN
Uma VLAN constitui um domínio de broadcast isolado: os broadcasts permanecem dentro dessa VLAN. A atribuição de várias VLAN à mesma zona de segurança não elimina esta separação de Layer 2; a zona determina o contexto das regras de firewall e do Device Access.
Uma VLAN é criada em Network > Interfaces > Add interface > Add VLAN. Os seguintes campos são decisivos:
- Interface: interface física, RED, Bridge ou LAG onde chega a VLAN tagged
- Network zone: área de segurança da VLAN
- VLAN ID: tem de corresponder à configuração do switch e, se aplicável, do Access Point
- IPv4/IPv6 configuration: em VLAN internas, normalmente um endereço de gateway estático

Por exemplo, uma VLAN de convidados pode utilizar Port3 com VLAN ID 20, zona Guest e endereço de gateway 192.168.20.1/24. No switch, a VLAN 20 tem de estar tagged no uplink para Port3; uma porta de cliente ou o SSID de convidados atribui os equipamentos finais a esta VLAN.
A firewall pode mostrar corretamente a interface mesmo que o switch envie a VLAN pela porta errada, untagged ou com outro VLAN ID. Por isso, uma VLAN só está concluída depois de todo o caminho ter sido testado:
- Verificar VLAN ID, Parent Interface, zona, endereço IP e máscara na firewall.
- Configurar o uplink para a firewall como Trunk com a VLAN tagged.
- Atribuir a Access Port ou o SSID à VLAN correta.
- Verificar DHCP, Gateway e DNS com um cliente de teste.
- Testar um acesso interno permitido e uma ligação deliberadamente bloqueada.
- Verificar o acesso à internet e confirmar o Firewall Rule ID esperado no Log Viewer.
Normalmente, o NAT não é necessário para tráfego interno. Se o cliente obtiver um endereço, mas não conseguir utilizar a firewall como servidor DNS nem alcançá-la por Ping, deve verificar-se primeiro o Device Access. O processo completo com tagging no switch e DHCP encontra-se em Configurar e testar uma VLAN no Sophos Firewall.
A Sophos não especifica um limite máximo fixo de VLAN por Parent Port físico para XGS Appliances. Ainda assim, com carga elevada, muitas VLAN ou desenhos HA, vários uplinks ou um LAG podem simplificar a operação e a resolução de problemas.
Escolher o tipo de interface adequado
As interfaces virtuais e os aliases são criados em Network > Interfaces através de Add interface. Aí, deve selecionar-se o tipo pretendido e abrir a respetiva configuração. As secções seguintes ajudam a escolher o tipo; um alias complementa uma interface existente, enquanto, por exemplo, VLAN, Bridge e LAG representam diferentes ligações lógicas.
Alias
Um Alias adiciona outro endereço IP a uma interface existente. É especialmente útil quando um fornecedor disponibiliza vários endereços IP públicos na mesma sub-rede.
Configurar e testar um IP alias na Sophos Firewall explica como associar o endereço adicional, utilizá-lo como objeto host em regras e NAT e verificar ARP e o tráfego do sistema.
Várias interfaces WAN separadas na mesma sub-rede podem causar problemas de ARP e gateways inacessíveis. Neste caso, um Alias na interface WAN existente ou um LAG devidamente planeado é normalmente a melhor solução. Um Alias acompanha o estado da respetiva Parent Interface e não pode ser desativado de forma independente.
Bridge
Uma Bridge liga várias interfaces em Layer 2. Pode funcionar com um endereço IP para tráfego encaminhado ou de forma transparente sem endereço IP. Para novas redes segmentadas, as VLAN são geralmente mais claras; uma Bridge é mais adequada para migrações ou desenhos deliberadamente transparentes.
O procedimento completo com Bridge Members, STP, filtros VLAN e EtherType, regras e validação está em Configurar uma interface Bridge no Sophos Firewall.
Aplicam-se restrições importantes:
- Uma Bridge não suporta Dynamic DNS, DHCP Client, PPPoE nem IPsec VPN.
- O tráfego entre Bridge Members pode continuar a exigir regras de firewall, por exemplo LAN-to-LAN.
- O HA não pode ser ativado enquanto o STP estiver ativo numa Bridge.
- Se o VLAN Filter estiver ativado, mas nenhuma VLAN for permitida, a firewall descarta todos os frames tagged; o tráfego untagged não é afetado.
- O tráfego através de uma Bridge sem endereço IP pode ser descartado sem uma entrada de log se corresponder a uma regra Web Proxy ou NAT.
Numa Bridge transparente, deve verificar-se se Web Proxy Filtering ou Source Translation são realmente necessários.
A Sophos documenta o NC-177630 para o SFOS 22.0.0 GA-Respin Build 411. O erro pode ocorrer quando o tráfego encaminhado através de uma Bridge é traduzido com SNAT ou MASQ e o tráfego de entrada e de saída utiliza o mesmo Bridge Member físico. Os pacotes de resposta são então descartados pelo Hairpin Filter sem aparecerem em drppkt. Isto também se aplica quando apenas um Bridge Member está ativo. O tráfego através de Bridge Members físicos diferentes ou sem SNAT/MASQ não é afetado.
A Sophos indica o SFOS 22.0.1 MR1 Build 490 como a versão que contém a correção. No GA-Respin Build 411, o SNAT ou MASQ do fluxo afetado só pode ser removido se a tradução não for necessária e existir um caminho de retorno para o endereço IP original do cliente. Como alternativa, o tráfego é encaminhado através de uma interface física dedicada em vez da Bridge. Se faltar um dos fatores descritos ou se o problema ocorrer no MR1 Build 490 ou numa versão posterior, deve procurar-se outra causa. O caso separado do SFOS 22 relativo a tráfego VLAN para a firewall é descrito em Verificar Bridge VLAN após o SFOS 22.
Uma Bridge através de RED pode prolongar uma rede Layer 2 entre localizações, mas deve continuar a ser uma exceção devidamente justificada.

Broadcast, ARP e tráfego Unicast desconhecido passam então pela ligação WAN. Um desenho encaminhado com sub-redes próprias por localização e regras de firewall específicas é mais estável, escalável e fácil de diagnosticar.
LAG
Um Link Aggregation Group combina duas a quatro interfaces físicas num uplink lógico. As VLAN podem depois ser configuradas sobre esse uplink.

Os modos de funcionamento habituais são:
- Active-Backup: uma ligação está ativa e outra assume o tráfego em caso de falha.
- LACP (802.3ad): várias ligações podem ser utilizadas em paralelo; a firewall e o switch têm de estar configurados de forma idêntica.
Podem ser utilizadas como membros interfaces físicas não associadas com configuração estática. As interfaces PPPoE, Cellular WAN e WLAN estão excluídas. Com LACP, as portas têm de ser do mesmo tipo e ter a mesma velocidade.
A xmit-hash-policy distribui as ligações pelos links. Uma única ligação TCP normalmente não fica mais rápida, porque permanece num só link. O LAG oferece sobretudo redundância e maior largura de banda total para várias ligações paralelas.
WAN móvel e WWAN1
Ao ativar o Cellular WAN, o SFOS cria a interface WWAN1. Esta faz parte da ligação móvel e não é equivalente a uma VLAN ou a um alias criado livremente. Devem continuar a respeitar-se as restrições de HA descritas abaixo e a exclusão como membro de um LAG.
No SFOS 23.0, Network > Interfaces disponibiliza, no Menu da interface WWAN, as ações Connect e Disconnect para ligar ou desligar o modem Cellular WAN. Reset reinicia o modem. Não se deve pressupor que estas ações descritas para o SFOS 23.0 têm um caminho de cliques idêntico no SFOS 22.0.
Antes de utilizar Disconnect ou Reset, deve garantir-se um acesso administrativo independente e uma janela de manutenção, caso a ligação móvel transporte tráfego de produção ou o acesso de gestão. Depois, deve verificar-se o estado da interface e os caminhos de dados e de gestão necessários. Reiniciar o modem não é uma solução garantida para uma falha de ligação cuja causa não foi esclarecida.
TAP / Discover Mode
Uma porta física em Discover Mode recebe uma cópia de tráfego espelhada pelo switch. Não está inline e não pode bloquear o tráfego observado nem controlá-lo com políticas de segurança. É útil para um inventário ou uma prova de conceito, mas não constitui um caminho de proteção em produção.
Na vista de interfaces, esta porta aparece como Discover, physical (TAP). Isto permite distingui-la de uma interface normal no caminho de dados de produção.
Configurar o Discover Mode com TAP e SPAN explica a configuração completa com porta SPAN, comandos da Device Console, Packet Capture, Security Audit Report e limites de HA.
XFRM para route-based IPsec
No IPsec route-based, distingue-se entre ligações Any-to-any e ligações com Traffic Selectors específicos. Quando ambas as sub-redes estão definidas como Any, o SFOS cria automaticamente uma interface XFRM na zona VPN:
- Any-to-any: é necessário atribuir um endereço IP à interface XFRM criada automaticamente em Network > Interfaces. Em seguida, as rotas estáticas, SD-WAN ou dinâmicas determinam o tráfego enviado pelo túnel.
- Traffic Selectors: o SFOS cria automaticamente uma rota estática quando o túnel é estabelecido. Se for apresentada uma interface XFRM, não lhe atribuir um endereço IP nem rotas manuais.
A documentação oficial do SFOS 22 e do SFOS 23 contradiz-se quanto à criação de XFRM para sub-redes específicas: «Configure an XFRM interface» indica que não é criada nenhuma XFRM, enquanto «Route-based VPN» descreve a criação de uma por configuração. Não se deve, por isso, pressupor que a interface está sempre presente ou sempre ausente. Expandir a Listening interface em Network > Interfaces e verificar a visibilidade real no build instalado. A secção Traffic Selectors de Configurar uma Site-to-Site IPsec VPN explica as verificações existentes de visibilidade e tráfego.
Em ambos os casos, o tráfego VPN precisa de regras de firewall adequadas. Em Administration > Device access, o serviço IPsec na zona WAN permite pedidos de ligação IPsec recebidos. O Ping no túnel é permitido separadamente para VPN.
Uma XFRM não é desativada diretamente em Network > Interfaces, mas através da respetiva ligação em Site-to-site VPN > IPsec. Se a SSL/TLS Decryption for aplicada ao tráfego IPsec, a Sophos exige que a MTU da XFRM seja pelo menos 113 bytes inferior à MTU da Listening Interface. Com uma MTU de 1400 na Listening Interface, a MTU da XFRM não pode exceder 1287. Este limite específico do produto aplica-se ao FastPath Offload e não é um valor geral para todos os túneis. O processo completo é descrito em Verificar MTU e MSS em problemas de VPN.
RED
Uma interface RED liga uma localização remota através de um túnel encriptado. O modo de funcionamento determina quanto tráfego passa pela central:
- Standard/Unified: a firewall central gere e filtra todo o tráfego da localização. Se o túnel falhar, o acesso à internet também pode ficar indisponível.
- Standard/Split: apenas as redes de destino definidas passam pelo túnel; o tráfego de internet sai localmente e não é filtrado de forma central.
- Transparent/Split: o RED funciona de forma transparente numa rede existente. É flexível, mas mais difícil de planear e diagnosticar.
- Manual/Split: a configuração da rede é feita de forma mais manual e pode proporcionar autonomia local.
O serviço RED tem de estar ativo em System services > RED. A ligação requer normalmente TCP 3400, UDP 3410 e NTP através de UDP 123. O DNS, a hora correta do sistema e o acesso de saída à internet também têm de funcionar.
O comportamento das VLAN depende do modelo RED, do modo de funcionamento, do modo das portas LAN e da configuração WLAN. A Sophos recomenda Standard/Unified quando são utilizadas VLAN atrás do RED; numa SD-RED 60, o VLAN tagging só é possível neste modo. A WLAN com Bridge to VLAN segue regras próprias. Escolher o modo de funcionamento correto do Sophos RED explica DHCP, gateway, caminho da internet e comportamento em caso de falha nos quatro modos. O provisioning, o estado dos LED e a resolução de problemas são explicados em Configurar o Sophos SD-RED.
Verificar o estado e o Device Access
Estado da interface
Os estados em Network > Interfaces indicam se deve ser verificada primeiro a ligação ou a política:
Not configured: nenhuma zona atribuídaConnected: configurada e ligadaConnecting: a obter um endereço, por exemplo através de DHCPDisconnected: o endereço foi libertadoDisconnecting: o endereço está a ser libertadoUnplugged: sem ligação física; no caso de WiFi, pode não existir Access Point ou Wireless NetworkNot available: FleXi Port configurada sem um módulo FleXi Port instalado
Com o estado Not configured ou Unplugged, as regras de firewall não são o primeiro ponto de diagnóstico. Devem verificar-se primeiro Zone Binding, cabo, SFP, velocidade da porta, porta do switch e DHCP ou PPPoE.
Serviços locais da firewall
Em Administration > Device access, define-se por zona se serviços locais como HTTPS, SSH, User Portal, VPN Portal, DNS, Ping/Ping6, Captive Portal, RADIUS SSO ou Wireless Protection estão acessíveis.
Estas permissões aplicam-se à própria firewall. O tráfego de passagem entre redes é controlado por regras de firewall. HTTPS e SSH só devem ser permitidos a partir de uma rede de gestão ou através de uma Local service ACL exception rule específica. O serviço DNS é necessário quando os clientes utilizam a firewall como servidor DNS.
⚠️ Se os clientes puderem utilizar o Web Proxy da firewall, o SFOS trata os pedidos HTTP e HTTPS como pedidos Proxy internos. Assim, WebAdmin, Captive Portal, VPN Portal ou User Portal podem ficar acessíveis mesmo que o respetivo serviço esteja desativado para a zona dos clientes. Neste desenho, o acesso ao Proxy e aos portais locais tem de ser verificado separadamente.
Tratar dependências e alterações com segurança
Object Usage antes de editar ou eliminar
Zone Binding, DNS, Gateways, SD-WAN, Interface Hosts, VLAN, Dynamic DNS, DHCP, regras de firewall, NAT e VPN podem depender da mesma interface. Object usage mostra estas referências.
O contador apresentado só é atualizado automaticamente uma vez por dia. Antes de alterar ou eliminar, deve clicar-se em Refresh e documentar as dependências importantes. Nem todas as referências podem ser editadas na janela pop-up. Os gateways WAN e as configurações CLI têm de ser alterados na respetiva página de configuração ou na CLI.
Para as referências editáveis em regras ou políticas, o contador permite aceder à configuração concreta:
- Na coluna Usage, clicar no número de utilizações do objeto em causa. A janela pop-up mostra as configurações que utilizam esse objeto.
- Expandir a categoria correspondente através do ícone de mais para apresentar as respetivas regras ou políticas.
- Clicar na regra ou política em causa para a editar. Remover aí a referência ao objeto ou substituí-la pelo objeto de substituição pretendido.
Após a verificação das dependências, a ativação ou desativação é feita em Network > Interfaces, no Menu da interface em causa, através de on ou off, respetivamente. Antes de utilizar off, deve garantir-se um acesso administrativo independente e um caminho de recuperação; a ação pode interromper o caminho de dados que está a ser utilizado. Alias e XFRM não podem ser desativados aqui de forma independente.
Ao desativar uma interface, a respetiva configuração é mantida. Os túneis IPsec em que a firewall é o iniciador são desligados imediatamente. Os túneis em que a firewall responde e as ligações Remote Access terminam, no máximo, por inatividade ou Dead Peer Detection.
Uma interface virtual é eliminada em Network > Interfaces através de Menu > Delete interface. Esta ação só deve ser executada após Refresh em Object usage, uma verificação documentada das dependências e a preparação de uma cópia de segurança e de um caminho de recuperação; não remove apenas a entrada visível da interface.
Ao eliminar uma interface virtual, o SFOS elimina todas as regras de firewall que a utilizam, mesmo que a regra contenha outras interfaces. Também remove Zone Bindings, servidores ou relays DHCP, entradas ARP, Protected Servers, Interface Hosts e as respetivas referências em grupos, assim como rotas unicast e multicast dependentes. As interfaces Alias acompanham a respetiva Parent Interface; as interfaces XFRM são geridas através da ligação IPsec.
HA e alterações remotas
As interfaces HA Link dedicadas pertencem a uma zona DMZ. Outras interfaces monitorizadas ou utilizadas para administração podem estar noutras zonas.
O Active-Active HA requer interfaces configuradas estaticamente. O Cellular WAN é desativado com HA. O Active-Passive pode utilizar interfaces WAN com endereçamento dinâmico, mas ligações como PPPoE não são necessariamente transferidas com a respetiva sessão durante um Failover.
Antes de uma alteração em produção:
- Documentar a configuração e as dependências.
- Preparar a janela de manutenção, o momento de reversão, a cópia de segurança e um plano de reversão concreto.
- Testar um acesso administrativo independente, por exemplo Sophos Fusion (anteriormente Sophos Central), uma segunda WAN, uma rede de gestão separada ou uma pessoa no local.
- Preparar um cliente de teste ou tráfego de teste inequívoco e, em seguida, adicionar e testar a nova zona ou o novo caminho.
- Verificar ligação, IP, Gateway, DHCP, DNS, regras de firewall, NAT e Device Access.
- Eliminar os objetos antigos apenas quando o novo caminho estiver estável.
Para um VLAN Trunk, o plano de reversão deve incluir o VLAN ID anterior, a Native VLAN e o perfil da porta do switch. Nas alterações WAN são importantes os valores do fornecedor e as rotas SD-WAN; com XFRM, também o túnel, o routing e ambas as direções das regras de firewall.
Diagnosticar sistematicamente
Normalmente, a causa pode ser isolada mais depressa começando pelo sintoma:
- Interface está unbound ou disabled: a própria porta física não pode ser eliminada. Para remover apenas a configuração, abrir a porta em Network > Interfaces, definir Network zone como
Nonee guardar. O SFOS mostra depois a interface comoUnbound, o estado comoDisablede o endereço IP comoN/A. Deve verificar-se primeiro Object Usage e o caminho de recuperação administrativa. - A VLAN não funciona: comparar VLAN ID, Parent Interface, Trunk, Tagged/Untagged e Native VLAN.
- A firewall não está acessível por Ping, HTTPS ou DNS: verificar primeiro Device Access e Local Service ACL, não uma regra de firewall normal.
- O tráfego interno está bloqueado: verificar Source zone, Destination zone, objetos de rede, routing, Services e ordem das regras.
- O WAN Gateway permanece inativo: verificar ligação, IP, Gateway, dados de acesso PPPoE e WAN Link Manager.
- Várias portas WAN estão na mesma sub-rede: evitar problemas de ARP e considerar Alias ou LAG.
- SFP ou Port Speed não correspondem: Diagnosticar SFP e SFP+ de forma sistemática explica como comparar transceiver, cabo, breakout e velocidade nos dois lados.
- VPN ou PPPoE estão instáveis: verificar MTU e MSS.
Para o diagnóstico propriamente dito, recomenda-se esta sequência:
- Network > Interfaces: ligação, IP, Zone e Gateway
- Network > Zones: tipo de zona e Device Access
- Hosts and services: objetos de rede e Service Objects
- Firewall rules: direção, ordem, Services e Logging
- NAT rules: Original e Translation
- Log viewer: Rule ID ou motivo do descarte
- Diagnostics > Tools > Packet capture: entrada e encaminhamento do pacote
Se a regra parecer correta, mas não fizer matching, consulte A regra de firewall não faz matching. O fluxo dos pacotes é explicado em Utilizar Packet Capture no WebAdmin.
Lista de verificação operacional
- zonas planeadas e documentadas por nível de confiança
- zona, interface e objeto de rede não confundidos
- VLAN ID, Parent, Trunk e Gateway verificados
- Device Access limitado, especialmente para HTTPS, SSH, DNS, Ping e portais
- regras de firewall criadas com zonas, redes, serviços e Logging específicos
- Alias verificado para endereços IP adicionais do fornecedor na mesma sub-rede
- DHCP, DNS, NTP, routing e, se necessário, NAT testados
- Object Usage atualizado e verificado antes de alterações
- acesso administrativo independente e plano de reversão preparados
- estado da ligação, Log Viewer e Packet Capture verificados após a alteração