Configurar e testar uma interface bridge na Sophos Firewall

Uma interface bridge liga várias interfaces físicas ou virtuais na camada 2. Isto permite inserir uma Sophos Firewall de forma transparente num caminho existente ou criar conscientemente um gateway bridge routed. A decisão central é tomada antes da criação: a bridge deve apenas encaminhar frames ou deve ter um endereço IP e fazer routing?

⚠️ Uma configuração bridge incorreta pode causar um loop de camada 2, uma broadcast storm ou a perda do acesso de gestão. Antes da cablagem são necessários backup, janela de manutenção, acesso administrativo independente e um caminho de recuperação claro. Os caminhos redundantes de camada 2 só são ativados quando STP e o design HA estiverem esclarecidos.

Transparente ou routed

Uma bridge transparente sem endereço IP encaminha frames entre os seus members. Pode ligar redes sem atuar como gateway. É adequada para migrações controladas ou para um caminho inline em que a arquitetura IP existente deve permanecer inalterada.

Uma bridge routed com endereço IP é ativada com Enable routing on this bridge pair. O IP da bridge pode depois atuar como gateway ou endpoint local da firewall. O filtro VLAN na bridge aplica-se apenas a tráfego bridged, não a tráfego routed.

Nos modelos XGS suportados, um par de portas bridge fixo no hardware também pode servir como caminho Fail-to-Wire. Configurar e testar LAN Bypass de forma controlada explica o limite dos modelos, o par FTW, o tráfego sem inspeção durante a falha e o regresso ao funcionamento protegido. Dois members arbitrários não recebem esta função de hardware.

Uma bridge não substitui universalmente uma interface WAN ou VPN dedicada. A Sophos não suporta Dynamic DNS, DHCP client, PPPoE ou IPsec VPN em interfaces bridge. Para novas redes segmentadas, VLANs e routing são frequentemente mais simples de operar. Zonas e interfaces na Sophos Firewall explica a escolha entre alias, bridge, LAG, VLAN, XFRM e RED.

Planear o exemplo e os members

O exemplo liga Port3 e Port4 de forma transparente. Ambas as portas estão no mesmo caminho de camada 2 planeado e a bridge não recebe endereço IP. São valores de exemplo que devem ser substituídos pela cablagem, zonas e estratégia de gestão reais.

O SFOS permite até 64 members. Podem ser interfaces físicas, RED, LAG e interfaces VLAN numa interface física, RED ou LAG. Cada member é previamente verificado quanto a endereços IP existentes, VLANs, DHCP, NAT, regras, routing e acesso administrativo.

As zonas dos members continuam relevantes para regras de firewall. Uma bridge não permite tráfego automaticamente. Se ambos os members estiverem, por exemplo, em LAN, o fluxo pretendido pode continuar a precisar de uma regra LAN-to-LAN adequada.

Controlos avançados da bridge na Device Console

A configuração habitual da bridge permanece no WebAdmin. A Device Console fornece ainda três controlos globais ou de baixo nível. Antes de os utilizar, guardam-se o nome da bridge, o hardware name, os members, IDs de porta, tabela MAC, caminho de administração e estado atual da CLI. Estes comandos não substituem regras de firewall em falta nem um design Layer 2 por esclarecer.

Tratar tráfego desconhecido não encaminhável

bypass-firewall-policy aplica-se a tráfego de bridge não encaminhável ao qual não é aplicada nenhuma Security Policy. O SFOS distingue dynamic de static. Primeiro consulta-se o estado atual das duas categorias:

system bridge bypass-firewall-policy unknown-network-traffic show dynamic
system bridge bypass-firewall-policy unknown-network-traffic show static

As ações disponíveis são allow e drop. allow é relevante para a segurança, porque este tráfego pode ser encaminhado explicitamente sem uma firewall policy. A ajuda do SFOS 22 não indica um valor predefinido nem explica a distinção exata entre dynamic e static. Por isso, nenhuma categoria deve ser alterada por suspeita. Se o Sophos Support indicar uma alteração, substitui-se show por allow ou drop na mesma sintaxe e verificam-se depois o estado, um Packet Capture e um fluxo de teste positivo e outro negativo.

Este seletor não é LAN Bypass nem uma stateful firewall bypass rule. Não ativa um caminho fail-to-wire nem remove uma ligação conhecida da Stateful Inspection.

Definir entradas MAC estáticas apenas de forma deliberada

A bridge forwarding table aprende normalmente os endereços MAC de forma dinâmica e decide por que porta encaminhar os frames. static-entry pode associar de forma fixa um endereço MAC a uma bridge, interface e porta. O modelo oficial do comando é:

system bridge static-entry [add | delete | show] [interface] {interface ID} [bridge name] [Port] {PortID} [macaddr] {MAC Address} [priority] [dynamic | static]

Os parênteses retos e chavetas descrevem a sintaxe e não são copiados para o comando. Antes de add, confirmam-se os IDs reais com show, conclusão por Tab e correspondência no WebAdmin. Uma entrada estática incorreta ou desatualizada pode encaminhar frames para a porta errada ou tornar o destino inacessível. Para o rollback, remove-se exatamente a entrada documentada com delete. Depois, a aprendizagem MAC, os caminhos de ida e volta e o acesso de administração devem voltar a funcionar.

Não utilizar o limite de members como objetivo de escala

O limite interno atual é mostrado com:

system bridge max_bridge_members show

A Device Console aceita valores max_bridge_members entre 2 e 256 e também disponibiliza reset:

system bridge max_bridge_members set limit <2-256>
system bridge max_bridge_members reset

Isto não deve ser equiparado ao limite publicado do WebAdmin. A Sophos continua a indicar um máximo de 64 members para uma bridge. Por isso, o intervalo maior da CLI não é um objetivo de design suportado para uma bridge com 256 interfaces. Só deve ser alterado para uma exceção comprovada e após coordenação com o Sophos Support. Como a ajuda não indica o valor predefinido resultante após reset, regista-se antecipadamente se o estado inicial era um valor personalizado ou o default. O rollback repõe exatamente esse estado.

Adicionar a bridge no WebAdmin

1. Abrir Network > Interfaces > Add interface > Add bridge.
2. Introduzir um Name descritivo com até 58 caracteres, por exemplo Bridge_Inline.
3. Definir um Hardware name imutável com até 10 letras, números e _, por exemplo brinline. Nomes de sistema como all, ipsec0, xfrm, Port, eth, WLAN ou Halink são reservados.
4. Ativar Enable routing on this bridge pair apenas quando a bridge deve receber conscientemente um endereço IP e fazer routing.
5. Adicionar as Member interfaces preparadas e as respetivas zonas.
6. Para uma bridge routed, configurar IPv4 ou IPv6 e o gateway planeado para members WAN.
7. Verificar as definições VLAN, ARP, STP, MTU, MSS e EtherType.
8. Selecionar Save e depois testar link, regras e um fluxo real.

O nome apresentado pode ser alterado mais tarde. O Hardware name permanece imutável e deve corresponder à convenção de nomes antes de guardar.

Compreender os filtros VLAN e EtherType

Com Filter VLANs, apenas são encaminhadas as VLANs introduzidas em Permitted VLAN ID or ID range. São possíveis intervalos como 20-35. Se o filtro estiver ativo e a lista vazia, o SFOS descarta todo o tráfego VLAN tagged; o tráfego untagged não é afetado.

Este filtro atua apenas sobre frames bridged. Não é uma regra de firewall para tráfego routed. O caso dependente da versão com configurações antigas system vlan-tag é tratado em Verificar Bridge-VLANs após o SFOS 22.

Filter Ethernet frames permite limitar EtherTypes. Sem valores permitidos, são descartados todos os frames exceto os tipos sempre permitidos ARP, IPv4, IPv6, 8021Q e EXTE. Outros tipos são adicionados como ID hexadecimal de quatro dígitos, por exemplo 809B, 8138, 8863 ou 8864. Estas permissões só são acrescentadas por um requisito de protocolo concreto.

ARP, STP, MTU e MAC aging

Permit ARP broadcast está ativo por predefinição. Sem broadcasts ARP, a bridge não consegue criar uma tabela MAC normal através de ARP. Desativar não é uma proteção geral contra broadcast, mas uma medida restrita para uma storm confirmada e exige entradas estáticas adequadas em Neighbors (ARP–NDP).

Spanning Tree Protocol (STP) protege contra loops de camada 2 e pode ativar um caminho redundante. Contudo, STP não pode ser ativado em interfaces bridge quando HA está ativo. Um design não deve depender simultaneamente de um mecanismo de prevenção de loops desconhecido e de HA. STP max age é 20 segundos por predefinição e só é alterado de acordo com todo o domínio STP.

MAC aging remove por predefinição endereços MAC inativos após 300 segundos. Valores mais curtos podem adequar-se a redes dinâmicas e valores mais longos a redes estáveis. As alterações baseiam-se no comportamento do switch e das aplicações, não numa recomendação genérica de performance.

Se as MTU da bridge e dos members forem diferentes, a bridge herda o valor inferior. Um member com MTU 1500 limita assim também uma bridge configurada com 9000. Override MSS só é usado perante um problema TCP ou MTU comprovado. Verificar MTU e MSS na Sophos Firewall oferece um procedimento controlado.

Regras, NAT e web proxy

O tráfego entre members precisa de uma regra de firewall adequada entre as zonas envolvidas. Source, destination e service ficam tão restritos quanto possível e o logging permanece ativo durante a verificação. Regras de firewall na Sophos Firewall explica o comportamento geral.

Uma bridge sem endereço IP tem uma condição de STOP importante: se o tráfego corresponder a uma regra com web proxy filtering ou a uma regra NAT, o SFOS pode descartar os pacotes sem log. Este comportamento não deve ser interpretado como um drop normal no Log Viewer.

Se uma regra NAT for inevitável, usa-se Override source translation for specific outbound interfaces para esta bridge concreta, define-se Outbound interface como a bridge e Translated source (SNAT) como Original. Uma alteração NAT ampla não é um teste seguro. Web proxy filtering só é usado numa bridge transparente quando o design o suporta explicitamente.

Testar a bridge de forma controlada

Depois de guardar, testam-se separadamente o control plane e o tráfego de utilizador:

1. Em Network > Interfaces, comparar bridge, members, zonas, modo IP e estado do link com o plano.
2. Confirmar a Firewall Rule ID esperada com um fluxo de teste controlado.
3. Comparar entrada e saída no Packet Capture; endereços MAC, tag VLAN e EtherType têm de corresponder ao design.
4. Testar um serviço permitido nas duas direções e fazer um teste negativo a um serviço deliberadamente proibido.
5. Com STP, ativar caminhos redundantes individualmente apenas numa janela de manutenção e medir topologia e failover.
6. Com HA, voltar a testar bridge, members, aprendizagem MAC e aplicações após uma mudança de função controlada.

Para drops Bridge ACL, ativar Bridge ACLs em System services > Log settings > Firewall. No Log Viewer, filtrar depois por Log component > Bridge ACLs e pelos subtipos ARP broadcasts, EtherType filtering ou VLAN filtering.

Se o datapath continuar pouco claro, Packet Capture na Sophos Firewall explica como interpretar em conjunto interfaces de entrada e saída, Rule ID, status e reason.

Reverter em segurança

Antes de eliminar, documentam-se Object Usage, regras, NAT, VLANs, DHCP, routes, hosts e acesso de gestão da bridge e de todos os members. Primeiro cria-se um caminho alternativo e testa-se com tráfego real. Só depois se removem as dependências produtivas, se elimina a bridge e se associam os members às novas funções de forma controlada.

Um único ping bem-sucedido não é prova suficiente de rollback. Depois, voltam a verificar-se gateway, DNS, gestão, aplicações produtivas, Firewall Rule ID e caminho de retorno.

Perguntas frequentes