Sophos Firewall Verifique VLANs de ponte para SFOS 22

As interfaces de ponte em Sophos Firewall são práticas se uma rede existente de camada 2 deve ser continuada de forma transparente ou se uma migração deve ser implementada sem alterações imediatas em IP. No entanto, com VLANs em uma ponte, o design rapidamente se torna sujeito a erros: há então encaminhamento entre redes, tráfego para o próprio firewall, Device Access, DNS, AD, autenticação e, muitas vezes, configurações CLI antigas.

Exatamente neste ponto, há um caso operacional importante com SFOS 22. O Sophos lista um problema na lista atual de problemas conhecidos, onde interfaces de ponte com configurações de tags CLI VLAN em SFOS 22.0 GA e SFOS 22.0 MR1 não processam corretamente o tráfego marcado com VLAN se esse tráfego se originar do próprio Sophos Firewall ou terminar no firewall. Por exemplo, isso pode afetar o Active Directory, DNS, Device Access, STAS, LDAP, RADIUS ou acesso de gerenciamento, mesmo que o tráfego normal seja roteado pela ponte.

Sophos agora também descreve o legacy CLI VLAN tagging como deprecated. Essas configurações herdadas podem impedir atualizações para SFOS 22.0 MR2 e versões posteriores. Portanto, essa verificação não é apenas troubleshooting após uma atualização, mas também uma preparação útil antes da próxima janela de manutenção.

Este artigo não é um capítulo geral de fundamentos do VLAN. Para planejar zonas, interfaces, VLANs, pontes e LAGs, Sophos Firewall Configurar zonas e interfaces é adequado primeiro. Isto é especificamente sobre o caso especial da ponte VLAN após SFOS 22.

Quando este tópico é relevante

A verificação faz sentido quando vários pontos se juntam:

• O firewall é executado em SFOS 22.0 GA ou SFOS 22.0 MR1.
• Existe uma interface bridge, por exemplo br0.
• As VLANs foram historicamente construídas usando a configuração de tag CLI VLAN como system vlan-tag ou foram substituídas por uma configuração antiga.
• Os próprios serviços de firewall devem atingir uma tag VLAN.
• Após uma atualização, AD, DNS, autenticação, monitoramento ou acesso de gerenciamento funcionam apenas parcialmente.
• O tráfego normal do cliente através da ponte parece ainda estar em execução.
• Uma atualização para SFOS 22.0 MR2 ou posterior está planejada ou está bloqueada por legacy CLI VLAN tagging.

O último ponto é importante: se a ponte continuar a encaminhar o tráfego entre redes, o problema inicialmente não parecerá ser uma falha da ponte. Na prática, é fácil procurar no lugar errado, como regras de firewall, DNS, STAS ou controlador de domínio.

Entenda a direção do tráfego afetada

Você deve separar claramente três tipos de tráfego.

Os tipos de tráfego diferem significativamente:

• Tráfego passado pela ponte: Um cliente em VLAN 100 está se comunicando com um servidor em VLAN 100. Isso ainda pode funcionar, mas não prova que o tráfego para o firewall esteja funcionando.
• Tráfego para Firewall: Um cliente usa o firewall como servidor DNS ou destino WebAdmin. É justamente esse tráfego que pode ser afetado porque termina no firewall.
• Tráfego do firewall: O firewall consulta destinos AD, DNS, LDAP, RADIUS, NTP ou Syslog. Isto também é crítico porque o próprio firewall é o remetente.

Se apenas um aplicativo for testado entre dois hosts, o erro não poderá ser identificado com certeza. O teste deve incluir deliberadamente um serviço que termine em Sophos Firewall ou seja criado pelo firewall.

Sintomas típicos

Os possíveis sinais são:

• As regras baseadas no usuário não funcionam mais de maneira confiável porque AD, STAS ou LDAP não podem ser alcançados de maneira estável.
• As consultas DNS ao firewall falham em VLANs individuais.
• Ping ou HTTPS em serviços de firewall locais não funcionam em um VLAN, mesmo que as regras de firewall pareçam plausíveis.
• O monitoramento ou Syslog parece incompleto se o firewall precisar atingir um alvo em um VLAN marcado.
• Packet Capture mostra que o tráfego entre os sistemas finais é visível, mas os próprios serviços de firewall não estão respondendo conforme o esperado.
• Após uma atualização SFOS-22, os sintomas ocorrem sem alterar conscientemente nada no switch ou nas regras do firewall.

Tais sintomas não devem ser resolvidos imediatamente com regras amplas de permissão ou aprovações de acesso a dispositivos. Primeiro, deve ficar claro se o próprio design da interface é afetado.

Demarcação rápida antes da conversão

Antes de mover uma ponte IP ou criar novas interfaces VLAN na ponte, você deve restringir a causa. Nem todo problema após uma atualização é automaticamente o caso SFOS-22-Bridge-VLAN.

Classificação prática:

• Apenas um único aplicativo entre dois hosts não funciona: O mais provável é regra de firewall, NAT, sistema de destino ou caminho de retorno. Primeiro testar regra de firewall e para quedas analisar pacotes descartados.
• WebAdmin, DNS ou ping para o firewall de um VLAN não funciona: Verifique Device Access, zona, serviço local ou ponte VLAN caso especial. Em seguida, teste o tráfego para o firewall separadamente.
• O firewall não alcança AD, LDAP, RADIUS, DNS ou Syslog em VLAN: Verifique o tráfego do firewall, roteamento, DNS ou ponte VLAN caso especial. Use testes diretamente da configuração do firewall e dos logs de serviço apropriados.
• O tráfego normal do cliente está em execução, mas os serviços do firewall em si não estão: O caso especial Bridge VLAN torna-se mais provável. Verifique o design da ponte, a configuração antiga da tag CLI VLAN e a interface VLAN para a ponte.
• Não há entradas de log correspondentes: Verifique o registro, filtro, serviço local ou caso especial de ponte/NAT não registrada. Combine Log Viewer, Packet Capture e Sophos Firewall logs de serviço relevantes.

Para problemas de DNS, também é importante se os clientes usam o firewall como resolvedor ou se o próprio firewall usa rotas de solicitação de DNS para servidores internos. O segundo caso diz respeito ao tráfego do firewall e pode parecer diferente do tráfego normal do cliente para problemas de Bridge VLAN. Os princípios básicos estão em Configurando rotas de solicitação de DNS em Sophos Firewall.

Se a demarcação rápida apontar claramente para serviços de firewall locais ou tráfego gerado pelo firewall, a conversão ainda deverá ser planejada. Uma correção de ponte sem backup, janela de manutenção e caminho de acesso alternativo é muito arriscada para redes produtivas.

Incluir design existente

Antes de fazer alterações, você deve documentar o status atual. Particularmente importantes são:

• Nome da interface da ponte, por exemplo br0.
• Membros da ponte, ou seja, interfaces físicas participantes, VLANs, interfaces RED ou LAGs.
• IP endereço da ponte, se disponível.
• VLAN IDs que passam pela ponte.
• Perfil de porta do switch: Tagged VLANs, Native VLAN, Trunk ou porta de acesso.
• Serviços que terminam no firewall: DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
• Serviços que o firewall deve atingir: AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, Monitoramento.

Se a estrutura vier de uma migração antiga, você também deverá verificar se as VLANs foram configuradas por meio da configuração CLI. É justamente esse legado que muitas vezes não está mais em mente quando o firewall só foi atualizado ao longo dos anos.

⚠️ Você não deve experimentar espontaneamente interfaces de ponte e VLANs durante as operações diárias. Uma alteração incorreta pode afetar o acesso de gerenciamento, o DNS, a autenticação ou redes inteiras de clientes. Antes da correção é necessário um backup, uma janela de manutenção e um caminho de acesso alternativo.

Armadilhas específicas de bridge antes da correção

A Sophos descreve três restrições de bridge que devem ser verificadas conscientemente antes da alteração.

Primeiro: uma bridge sem endereço IP pode descartar tráfego se o tráfego corresponder a uma regra de firewall com filtragem web proxy ou a uma regra NAT. Segundo a Sophos, esses descartes não são registrados em logs. Se uma regra NAT ainda for necessária, ela deve ser delimitada de forma que a source translation para a bridge sem endereço IP permaneça em Original. Caso contrário, pode-se procurar no Log Viewer um descarte que nunca aparece ali.

Segundo: o VLAN filtering na bridge aplica-se apenas ao tráfego bridged, não ao tráfego roteado. Se Filter VLANs estiver ativado, mas nenhum VLAN ID permitido for inserido, o tráfego marcado de todos os VLANs será descartado; o tráfego sem tag fica excluído. Durante os testes, isso pode parecer um problema VLAN inconsistente.

Terceiro: interfaces bridge não substituem qualquer design. A Sophos lista restrições para Dynamic DNS, DHCP client, PPPoE e IPsec VPN. Se uma dessas funções fizer parte do design de destino, o workaround da bridge não deve ser aplicado isoladamente; o design das interfaces deve ser reavaliado.

Solução alternativa e preparação da atualização

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

Designs novos ou corrigidos não devem mais depender de system vlan-tag. Se essas tags CLI ainda existirem, elas devem ser documentadas, migradas para interfaces VLAN no WebAdmin e só então a atualização de firmware deve continuar. Isso reduz tanto o caso especial de bridge no SFOS 22 quanto bloqueios posteriores de atualização.

Exemplos:

• VLAN 100: br0.100
• VLAN 200: br0.200

Ao criar o VLAN no WebAdmin, três campos são decisivos: Interface deve ser a bridge, Zone deve corresponder ao objetivo de segurança do VLAN e VLAN ID deve ser único. A Sophos permite IDs de VLAN no WebAdmin de 1 a 4094; o mesmo VLAN ID não deve ser planejado mais de uma vez no mesmo parent interface.

O processo depende se a própria ponte já possui um endereço IP.

Se a ponte não precisar de um endereço IP

Se a ponte deve apenas encaminhar de forma transparente, ela pode ser operada sem seu próprio endereço IP. O endereço IP para o VLAN afetado está então na interface VLAN, por exemplo br0.100.

Processo prático:

1. Crie backup.
2. Documente a ponte atual e a configuração VLAN.
3. Adicione uma nova interface VLAN em Network > Interfaces.
4. Selecione a ponte como interface pai, por exemplo br0.
5. Insira o ID VLAN.
6. Escolha sua zona conscientemente.
7. Defina o endereço IP na interface VLAN se o firewall deve estar neste serviço VLAN Gateway ou local.
8. Verifique Device Access para a zona.
9. Verifique as regras de firewall e as regras NAT.
10. Valide com um cliente de teste.

A zona não é apenas ordem no WebAdmin. Esta decisão afeta regras de firewall, Device Access, logs e muitas etapas posteriores de solução de problemas. Se um VLAN for destinado a uma rede de gerenciamento, servidor ou cliente, isso deverá estar visível na zona.

Se a ponte anteriormente tinha o endereço produtivo IP

Se a ponte estiver usando atualmente o endereço IP, que deverá estar acessível em VLAN no futuro, você deverá ter cuidado especial. Existem duas variantes limpas para a conversão: a ponte recebe um endereço IP diferente ou a ponte permanece sem um endereço IP. O endereço produtivo anterior é então atribuído à interface VLAN.

Esta é uma mudança com risco de fracasso. Deve ser esclarecido de antemão:

• Qual endereço é usado para acessar WebAdmin?
• Quais clientes utilizam o firewall como padrão Gateway?
• Quais configurações de DNS ou DHCP apontam para este endereço?
• Quais regras de acesso a dispositivos se aplicam à zona anterior?
• Existe um segundo acesso de gerenciamento de uma rede não afetada?

Para locais remotos, esta mudança não deve ser planeada sem um caminho de retorno local. Se WebAdmin e SSH forem executados exatamente na ponte afetada IP, um erro poderá interromper o acesso administrativo.

Device Access e verifique as regras do firewall depois

Depois de criar a interface VLAN, não basta apenas testar o endereço IP. Device Access e as regras de firewall devem corresponder à nova interface e ao design da zona.

Para verificar:

• Administration > Device access: Os portais Ping/Ping6, DNS, HTTPS, SSH, User Portal ou VPN sã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 Rotas de solicitação de DNS: o firewall está alcançando os servidores DNS ou AD corretos?
• Authentication > Servers: AD, LDAP ou RADIUS estão acessíveis após a alteração? Para serviços de firewall locais, Device Access configurar Sophos Firewall com segurança é o artigo detalhado apropriado. Sophos Firewall Testar regra com Log Viewer e Packet Capture ajuda na análise de regras.

Validação após correção

Um teste limpo deve conter mais de um ping.

Teste dos afetados VLAN

Verifique de um cliente no VLAN afetado:

1. Alcance o padrão Gateway.
2. Teste o firewall IP na nova interface VLAN via ping, se permitido.
3. Teste o DNS no firewall se o firewall servir como um resolvedor de DNS.
4. Teste WebAdmin ou portal apenas de redes de gerenciamento permitidas.
5. Verifique uma conexão típica de aplicativo ou servidor.
6. Verifique Log Viewer para identificar o ID da regra e a zona correspondentes.

Teste do firewall

Testes separados são necessários para o tráfego gerado pelo próprio firewall:

• Teste servidores AD ou LDAP em Authentication > Servers.
• Verifique a resolução DNS via firewall.
• Verifique NTP, Syslog ou alvo de monitoramento se esses serviços estão em VLAN.
• Use Packet Capture na interface VLAN quando não estiver claro se os pacotes estão saindo do firewall.

Se o STAS ou as regras baseadas no usuário forem afetados, Configurar STAS em Sophos Firewall também deverá ser verificado. Para atualizações SFOS-22, este ponto também pertence à SFOS 22 Upgrade Check.

Erros comuns

Armadilhas típicas:

• Teste apenas o tráfego de cliente para servidor: A ponte parece íntegra, embora os serviços de firewall locais sejam afetados. Teste também o tráfego de e para o firewall.
• Mover ponte IP sem plano: WebAdmin, DNS ou Gateway podem falhar. Preparar backup, janelas de manutenção e acessos alternativos.
• Selecione a zona incorretamente para a nova interface VLAN: Regras, Device Access e logs não cabem. Escolha uma zona com base em questões de segurança, não com base no hábito.
• Device Access aberto demais: O problema parece resolvido, mas os serviços de gerenciamento estão desnecessariamente acessíveis. Local Service ACL planeje especificamente.
• Não verifique a porta do switch: VLAN chega incorreto ou sem etiqueta. Valide o perfil Tagged/Untagged, Native VLAN e Trunk.
• Ignorar configuração CLI antiga: O erro permanece inexplicável após a atualização. Documente o design antigo e migre para interfaces WebAdmin-VLAN.

Lista de verificação

• Versão SFOS e relevância do problema conhecido verificadas.
• Interface da ponte, membros da ponte e IDs VLAN documentados.
• Esclarecido se a configuração antiga da tag CLI VLAN foi usada.
• Drops específicos de bridge por NAT/web proxy e VLAN filtering verificados.
• Atualização planejada para SFOS 22.0 MR2 ou posterior verificada em relação a legacy CLI VLAN tags.
• Serviços afetados de e para o firewall identificados.
• Acesso de backup e gerenciamento alternativo disponível.
• Interface VLAN planejada com ponte como interface pai.
• Zona, Device Access, regras de firewall e regras NAT verificadas.
• Testes realizados desde o VLAN e desde o firewall.
• Resultado registrado no log de alterações ou na documentação da rede.

PERGUNTAS FREQUENTES