Substituir a marcação VLAN legada antes do SFOS 22 MR2

As interfaces bridge do Sophos Firewall são úteis para manter transparente uma rede de camada 2 existente ou para efetuar uma migração sem alterar imediatamente os endereços IP. Se as tags VLAN tiverem sido configuradas anteriormente numa bridge com system vlan-tag, substitua-as por interfaces VLAN no WebAdmin antes de atualizar para o SFOS 22.0 MR2 ou posterior. Não se trata de uma alteração meramente estética: no GA e MR1, o tráfego destinado ao firewall ou gerado pelo firewall pode falhar; a partir do MR2, a configuração legada bloqueia a atualização.

O problema NC-181672 afeta interfaces bridge com configurações CLI VLAN tag no SFOS 22.0 GA e no SFOS 22.0 MR1: o tráfego marcado com VLAN originado no Sophos Firewall ou destinado ao firewall não é processado corretamente. Isso pode afetar o Active Directory, DNS, Device Access, STAS, LDAP, RADIUS ou o acesso de gestão, mesmo que a bridge continue a encaminhar o tráfego normal.

A marcação VLAN legada por CLI está obsoleta: bloqueia a atualização para o SFOS 22.0 MR2 ou posterior, e um backup que a contenha não pode ser restaurado no SFOS 22.0 GA ou posterior. Execute esta verificação antes da atualização e antes de criar o backup destinado à mesma. A verificação de atualização para o SFOS 22 documenta a release de destino verificada MR2 Build 546, o respetivo caminho de atualização e outros bloqueios específicos da versão. Se estiver prevista outra build de destino, esta verificação interna deve ser atualizada antes da alteração; os dados da MR2 não devem ser transpostos sem verificação.

Este artigo não é um capítulo geral sobre VLAN. Para planear zonas, interfaces, VLAN, Bridges e LAG, deve começar-se por Configurar zonas e interfaces no Sophos Firewall. A configuração, proteção e validação normais são explicadas em Configurar uma interface Bridge no Sophos Firewall. Aqui trata-se especificamente do caso especial de VLAN em Bridges após o 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

Antes da alteração, devem ser verificadas cuidadosamente três restrições de bridge.

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. Esses descartes não são registados nos 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. Existem 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.

Criar interfaces VLAN suportadas

O workaround suportado consiste em criar interfaces VLAN em Network > Interfaces usando a bridge como parent. As interfaces físicas, RED, bridge e LAG são parents válidos.

Antes do SFOS 18.0, system vlan-tag era necessário para ativar tráfego VLAN tagged em bridges. Desde o SFOS 18.0, VLAN-over-bridge está disponível no WebAdmin. Para o seguinte comando CLI não são especificados Device Console, Advanced Shell, número de menu, prompt ou nível de privilégio. Use apenas o contexto CLI suportado do firewall no qual o comando esteja disponível. Se não estiver, pare e consulte o Sophos Support em vez de adivinhar a shell ou o contexto. Primeiro confirme a configuração legada com este comando apenas de leitura:

system vlan-tag show

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. O WebAdmin aceita IDs de VLAN 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. Exporte um backup para fins de documentação, mas não conte com o seu restauro como reversão no SFOS 22.
2. Documente a ponte atual e a configuração VLAN.
3. Em Network > Interfaces, selecione Add interface > Add VLAN.
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 a alteração com um cliente de teste e crie um novo backup apenas depois de concluir os testes com êxito.

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.

Remover a configuração legada e preparar a atualização

Primeiro crie as interfaces VLAN necessárias em Network > Interfaces com a bridge como parent, mova se necessário o IP da bridge para a interface VLAN correta e valide os caminhos de dados e gestão. Em HA, confirme pela interface de estado suportada que o peer e a sincronização estão saudáveis e faça backup de cada nó quando a plataforma e o procedimento de suporte o exigirem. Se o estado estiver degradado ou incerto, pare antes do reset ou da atualização e escale; não invente comandos de HA ou sincronização. Com o mapeamento documentado, acesso alternativo ativo e pré-requisitos de HA cumpridos, remova a definição no mesmo contexto CLI suportado descrito acima:

system vlan-tag reset

Execute novamente system vlan-tag show. Se a configuração permanecer, o reset falhar ou a saída for ambígua, pare: não inicie a atualização nem aprove o novo backup como ponto limpo. Guarde saída, precheck e configuração e escale ao Sophos Support sem comandos não documentados. Não existe uma reversão documentada ao nível de comando para system vlan-tag reset: passar nas verificações confirma a limpeza, não a reversão. Após o reset, não recrie a definição legada com um comando presumido. Se for necessário desfazer a alteração, pare e escale para um restauro aprovado pelo fabricante no firmware original suportado. Após os testes, crie um novo backup, repita o precheck e só então atualize. Para um backup restaurável, limpe da mesma forma o firewall de origem, crie opcionalmente a interface VLAN, valide e só depois faça o backup. Isto não corrige um backup antigo com system vlan-tag.

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.
• Em Diagnostics > Packet capture, verifique a interface VLAN. Generated identifica pacotes criados pelo firewall e Consumed os destinados ao firewall; compare também In interface, Out interface, Rule ID, Status e Reason.

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.

Reversão e conclusão

Antes da alteração, registe o endereço IP e a zona da bridge, os IDs de VLAN, o perfil da porta do switch e as regras e serviços dependentes. Prepare acesso de gestão alternativo ou local e um plano de recuperação aprovado pelo fabricante. Antes de system vlan-tag reset, as alterações WebAdmin planeadas podem ser desfeitas pela ordem documentada: remova primeiro o IP da interface VLAN e depois volte a atribuí-lo à bridge; reponha zona, regras, Device Access e perfil do switch e confirme a conectividade. Isto não reverte o reset. Após o reset não existe reversão documentada ao nível de comando: se a validação falhar, pare e escale para um restauro aprovado no firmware original suportado. Em HA, não faça reset nem atualize qualquer nó se o peer ou a sincronização estiver degradado ou incerto e conserve o backup aplicável de cada nó.

Após uma validação bem-sucedida, crie um novo backup. O backup antigo com legacy CLI VLAN tagging não é uma reversão válida para SFOS 22.0 GA ou posterior. Se o precheck ainda o detetar, guarde a configuração e a mensagem e contacte o Sophos Support sem tentar mais alterações CLI não documentadas.

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.
• Backup de cada nó aplicável e acesso de gestão alternativo disponíveis; peer e sincronização HA saudáveis.
• 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.
• Limite de recuperação documentado: sem reversão documentada para system vlan-tag reset; novo backup criado após a correção.
• Resultado registrado no log de alterações ou na documentação da rede.

PERGUNTAS FREQUENTES