Verificar Bridge-VLANs no Sophos Firewall após SFOS 22

As interfaces de bridge no Sophos Firewall são práticas quando se deseja continuar uma rede de camada 2 existente de forma transparente ou realizar uma migração sem alteração imediata de IP. No entanto, com VLANs numa bridge, o design pode rapidamente tornar-se propenso a erros: há então encaminhamento entre redes, tráfego para a própria firewall, Device Access, DNS, AD, autenticação e frequentemente configurações antigas de CLI.

É precisamente neste ponto que há um caso operacional importante no SFOS 22. A Sophos lista na atual lista de problemas conhecidos um problema em que Bridge-Interfaces com configurações de CLI VLAN tag no SFOS 22.0 GA e SFOS 22.0 MR1 não processam corretamente o tráfego VLAN etiquetado quando este tráfego se origina na própria Sophos Firewall ou termina na firewall. Isso pode afetar, por exemplo, Active Directory, DNS, Device Access, STAS, LDAP, RADIUS ou acesso de gestão, embora o tráfego normal seja encaminhado pela bridge.

Este artigo não é um capítulo geral sobre fundamentos de VLAN. Para o planeamento de zonas, interfaces, VLANs, bridges e LAGs, consulte primeiro Configurar Zonas e Interfaces no Sophos Firewall. Aqui, o foco é o caso especial de Bridge-VLAN após SFOS 22.

Quando este tema é relevante

A verificação é útil quando vários pontos se juntam:

• A firewall está a funcionar no SFOS 22.0 GA ou SFOS 22.0 MR1.
• Existe uma interface de bridge, por exemplo, br0.
• As VLANs foram historicamente configuradas por CLI VLAN tag configuration como system vlan-tag ou foram herdadas de uma configuração antiga.
• Serviços da própria firewall precisam alcançar uma VLAN etiquetada.
• Após uma atualização, AD, DNS, autenticação, monitorização ou acesso de gestão funcionam apenas parcialmente.
• O tráfego normal de clientes através da bridge parece continuar a funcionar.

O último ponto é importante: se a bridge continuar a encaminhar tráfego entre redes, o problema inicialmente não parece ser um erro da bridge. Na prática, procura-se rapidamente no lugar errado, como nas regras da firewall, DNS, STAS ou no controlador de domínio.

Compreender a direção do tráfego afetado

É necessário separar claramente três tipos de tráfego.

Se apenas uma aplicação entre dois hosts for testada, o erro não é identificado com segurança. O teste deve incluir conscientemente um serviço que termine na Sophos Firewall ou seja gerado pela firewall.

Sintomas típicos

Possíveis sinais são:

• Regras baseadas em utilizadores não funcionam mais de forma confiável, pois AD, STAS ou LDAP não são acessíveis de forma estável.
• Consultas DNS para a firewall falham a partir de algumas VLANs.
• Ping ou HTTPS para serviços locais da firewall não funcionam a partir de uma VLAN, embora as regras da firewall pareçam plausíveis.
• Monitorização ou Syslog parecem incompletos quando a firewall precisa alcançar um destino numa VLAN etiquetada.
• Packet Capture mostra que o tráfego entre sistemas finais é visível, mas os serviços da própria firewall não respondem como esperado.
• Após uma atualização para SFOS 22, os sintomas aparecem sem que algo tenha sido alterado conscientemente no switch ou nas regras da firewall.

Esses sintomas não devem ser imediatamente respondidos com regras de permissão amplas ou liberações de Device Access. Primeiro, deve-se esclarecer se o design da interface em si está afetado.

Delimitação rápida antes da reestruturação

Antes de mover um IP de bridge ou criar novas interfaces VLAN na bridge, deve-se delimitar a causa. Nem todo problema após uma atualização é automaticamente o caso de Bridge-VLAN do SFOS 22.

Para problemas de DNS, é adicionalmente importante saber se os clientes usam a firewall como resolver ou se a própria firewall utiliza DNS Request Routes para servidores internos. O segundo caso afeta o tráfego da firewall e pode parecer diferente de tráfego normal de clientes em problemas de Bridge-VLAN. Os fundamentos estão em Configurar DNS Request Routes no Sophos Firewall.

Se a delimitação rápida indicar claramente serviços locais da firewall ou tráfego gerado pela firewall, a reestruturação ainda deve ser planeada. Uma correção de bridge sem backup, janela de manutenção e caminho de acesso alternativo é muito arriscada em redes produtivas.

Documentar o design existente

Antes de fazer alterações, deve-se documentar o estado atual. Particularmente importantes são:

• Nome da interface de bridge, por exemplo, br0.
• Membros da bridge, ou seja, interfaces físicas envolvidas, VLANs, interfaces RED ou LAGs.
• Endereço IP da bridge, se houver.
• IDs de VLAN que passam pela bridge.
• Perfil de porta do switch: VLANs etiquetadas, VLAN nativa, Trunk ou Porta de Acesso.
• Serviços que terminam na firewall: DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
• Serviços que a firewall precisa alcançar: AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, Monitorização.

Se a configuração for de uma migração antiga, deve-se verificar adicionalmente se as VLANs foram configuradas por CLI. Este legado muitas vezes não é mais lembrado quando a firewall foi apenas atualizada ao longo dos anos.

⚠️ Não se deve experimentar espontaneamente com interfaces de bridge e VLANs durante o horário de funcionamento. Uma alteração incorreta pode afetar o acesso de gestão, DNS, autenticação ou redes de clientes inteiras. Antes da correção, é necessário um backup, uma janela de manutenção e um caminho de acesso alternativo.

Solução alternativa: Criar interfaces VLAN na bridge

Uma maneira prática é criar interfaces VLAN em Network > Interfaces e usar a interface de bridge como interface pai.

Exemplos:

O procedimento depende de a bridge já ter ou não um endereço IP.

Quando a bridge não precisa de um endereço IP

Se a bridge deve apenas encaminhar de forma transparente, pode ser operada sem um endereço IP próprio. O endereço IP para a VLAN afetada fica então na interface VLAN, por exemplo, br0.100.

Procedimento prático:

1. Criar um backup.
2. Documentar a configuração atual da bridge e VLAN.
3. Em Network > Interfaces, adicionar uma nova interface VLAN.
4. Selecionar a bridge como interface pai, por exemplo, br0.
5. Inserir a ID da VLAN.
6. Escolher a zona conscientemente.
7. Definir o endereço IP na interface VLAN, se a firewall for o gateway ou serviço local nesta VLAN.
8. Verificar Device Access para a zona.
9. Verificar regras da firewall e regras NAT.
10. Validar com um cliente de teste.

A zona não é apenas organização no WebAdmin. Esta decisão influencia regras da firewall, Device Access, logs e muitos passos futuros de resolução de problemas. Se uma VLAN for destinada a redes de gestão, servidor ou cliente, isso deve ser visível na zona.

Quando a bridge atualmente tem o endereço IP produtivo

Se a bridge atualmente usa o endereço IP que precisa ser acessível na VLAN no futuro, deve-se proceder com especial cuidado. Para a reestruturação, há duas variantes limpas: a bridge recebe um endereço IP diferente, ou a bridge permanece sem endereço IP. O endereço produtivo atual é então atribuído à interface VLAN.

Esta é uma alteração com risco de interrupção. Antes, deve-se esclarecer:

• Através de qual endereço o WebAdmin é acessado?
• Quais clientes usam a firewall como gateway padrão?
• Quais configurações de DNS ou DHCP apontam para este endereço?
• Quais regras de Device Access estão ligadas à zona anterior?
• Existe um segundo acesso de gestão a partir de uma rede não afetada?

Em locais remotos, esta alteração não deve ser planeada sem um caminho de retorno local. Se o WebAdmin e o SSH funcionarem exatamente através do IP da bridge afetada, um erro pode interromper o acesso administrativo.

Verificar Device Access e regras da firewall depois

Após criar a interface VLAN, não basta testar apenas o endereço IP. Device Access e regras da firewall devem corresponder ao novo design de interface e zona.

A verificar:

• Administration > Device access: Ping/Ping6, DNS, HTTPS, SSH, User Portal ou VPN Portal estão permitidos apenas nas zonas corretas?
• Rules and policies > Firewall rules: Existem regras para a nova zona?
• Rules and policies > NAT rules: O tráfego é traduzido inesperadamente?
• Network > DNS ou DNS Request Routes: A firewall alcança os servidores DNS ou AD corretos?
• Authentication > Servers: AD, LDAP ou RADIUS estão acessíveis após a alteração?

Para serviços locais da firewall, Configurar Device Access de forma segura no Sophos Firewall é o artigo de aprofundamento adequado. Para análise de regras, Testar regra do Sophos Firewall com Log Viewer e Packet Capture ajuda.

Validação após a correção

Um teste limpo deve incluir mais do que um ping.

Teste a partir da VLAN afetada

De um cliente na VLAN afetada, verificar:

1. Alcançar o gateway padrão.
2. Testar o IP da firewall na nova interface VLAN por ping, se permitido.
3. Testar DNS contra a firewall, se a firewall servir como resolver DNS.
4. Testar WebAdmin ou Portal apenas a partir de redes de gestão permitidas.
5. Verificar uma aplicação típica ou conexão de servidor.
6. Controlar Log Viewer para ID de regra e zona correspondentes.

Teste a partir da firewall

Para tráfego gerado pela própria firewall, são necessários testes separados:

• Testar servidor AD ou LDAP em Authentication > Servers.
• Verificar resolução DNS através da firewall.
• Verificar NTP, Syslog ou destino de monitorização, se esses serviços estiverem na VLAN.
• Usar Packet Capture na interface VLAN se não estiver claro se os pacotes estão a sair da firewall.

Se STAS ou regras baseadas em utilizadores forem afetadas, deve-se adicionalmente verificar Configurar STAS no Sophos Firewall. Em atualizações para SFOS 22, este ponto também faz parte do Check de Atualização para SFOS 22.

Erros comuns

Lista de verificação

• Versão do SFOS e relevância do problema conhecido verificados.
• Interface de bridge, membros da bridge e IDs de VLAN documentados.
• Esclarecido se foi usada configuração antiga de CLI VLAN tag.
• Serviços afetados para a firewall e da firewall identificados.
• Backup e acesso de gestão alternativo disponíveis.
• Interface VLAN com bridge como interface pai planeada.
• Zona, Device Access, regras da firewall e regras NAT verificadas.
• Testes a partir da VLAN e da firewall realizados.
• Resultado registado no log de alterações ou na documentação da rede.

FAQ