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 herdadas de uma configuração antiga.
• Os próprios serviços da firewall têm de alcançar uma VLAN com tráfego etiquetado.
• Após uma atualização, AD, DNS, autenticação, monitoramento ou acesso de gerenciamento funcionam apenas parcialmente.
• Uma atualização para SFOS 22.0 MR2 ou posterior está planejada ou está bloqueada por legacy CLI VLAN tagging.
• O tráfego normal do cliente através da ponte parece ainda estar em execução.

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 autorizações de Device Access. Primeiro, deve ficar claro se o próprio design da interface é afetado.

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

Antes de mover o endereço IP de uma bridge ou criar novas interfaces VLAN na bridge, é necessário identificar 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 o caso especial de VLAN em bridges. 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 o caso especial de VLAN em bridges. Utilizar os testes diretamente na configuração da firewall e os logs de serviço correspondentes.
• 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 na bridge.
• Não há entradas de log correspondentes: Verificar o registo de logs, o filtro, o serviço local ou um descarte não registado específico de bridge/NAT. 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.

Documentar o desenho 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.
• Endereço IP da bridge, se existir.
• 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, era necessário utilizar system vlan-tag para ativar a comunicação com marcação VLAN através de interfaces bridge. Desde o SFOS 18.0, a funcionalidade VLAN-over-bridge está integralmente disponível no WebAdmin. No entanto, há um limite importante a respeitar no levantamento e na limpeza da configuração: a documentação de tags VLAN para o SFOS 22 e 23 descreve um reset com argumentos de interface simultaneamente como uma forma de apresentar a configuração. Daí não se pode concluir que system vlan-tag show, utilizado isoladamente, seja uma consulta que não altera a configuração, nem que system vlan-tag reset sem argumentos seja um comando de limpeza com âmbito conhecido. A disponibilidade de um comando num contexto CLI também não confirma estas propriedades.

Antes de qualquer ação CLI de levantamento ou limpeza da configuração, é necessário confirmar, através de documentação inequívoca para a build instalada ou do Sophos Support, qual é o método exato para levantar a configuração existente sem a alterar e qual é a sintaxe de limpeza aplicável. Esta confirmação deve abranger o contexto CLI exato, os privilégios e argumentos necessários, as interfaces ou os nós afetados, bem como os efeitos e o âmbito da limpeza. Se estes pontos não estiverem esclarecidos, documente apenas a configuração visível no WebAdmin em Network > Interfaces e pare antes da limpeza ou da atualização. A ausência de entradas no WebAdmin não prova que não existam tags legadas configuradas por CLI; esclareça a questão pendente do levantamento com o Sophos Support, em vez de experimentar um suposto comando de consulta ou de reset.

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. Definir o endereço IP na interface VLAN se a firewall tiver de funcionar como gateway ou disponibilizar um serviço local nessa VLAN.
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 bridge já tiver o endereço IP de produção

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 alteração pode causar indisponibilidade. Deve ser esclarecido de antemão:

• Qual endereço é usado para acessar WebAdmin?
• Quais clientes utilizam o firewall como Default 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 no endereço IP da bridge afetada, um erro poderá interromper o acesso administrativo.

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

A ordem é fundamental: após os esclarecimentos descritos acima, comece por criar todas as interfaces VLAN necessárias em Network > Interfaces, com a bridge como Parent Interface, transfira o endereço IP atual da bridge para a interface VLAN adequada, se necessário, e verifique os novos caminhos de dados e de gestão. Num ambiente HA, confirme previamente, através da visualização de estado suportada, que o peer e a sincronização não apresentam erros, e faça um backup de cada nó na medida prevista pela plataforma e pelos procedimentos de suporte. Se o estado do peer ou da sincronização apresentar erros ou não estiver claro, pare antes da limpeza ou da atualização e escale o caso. Não invente comandos de HA ou de sincronização.

Só depois de o mapeamento estar documentado, de existir um acesso alternativo ativo e de todos os pré-requisitos de HA estarem cumpridos é que a definição legada pode ser removida através do procedimento confirmado por documentação ou pelo Sophos Support para a build instalada. A confirmação da sintaxe exata, do contexto CLI, dos efeitos e do âmbito por interface e por nó tem de estar disponível antes da execução; este artigo não autoriza a execução de um comando de reset sem as devidas condições. Na ausência dessa confirmação, limite-se ao inventário do WebAdmin e pare antes da limpeza ou da atualização.

Em seguida, utilize o método de levantamento previamente confirmado como não modificador para verificar especificamente se a definição legada foi removida no âmbito previsto. Os testes de tráfego, por si só, não o provam. Se continuar a ser visível uma configuração legada, se a limpeza falhar ou se o levantamento não for inequívoco, interrompa o procedimento: não inicie ainda a atualização nem aprove o novo backup como ponto de restauro limpo. Guarde os comprovativos do levantamento disponíveis, a saída dos comandos, se aplicável, a verificação prévia da atualização e a configuração atual, e escale o caso para o Sophos Support; não experimente comandos CLI não documentados.

A descrição contraditória do reset também não permite deduzir um método fiável de reversão ao nível dos comandos. O êxito das verificações da configuração e dos testes de tráfego confirma a limpeza, não a possibilidade de reversão. Após a limpeza, não recrie a definição legada com um comando presumido. Se for necessário reverter a alteração, pare e envolva o Sophos Support para efetuar um restauro aprovado pelo fabricante no firmware original suportado; reverta as alterações no WebAdmin apenas no âmbito desse plano aprovado.

Se os testes de aceitação e a nova verificação da configuração forem bem-sucedidos, crie um novo backup, repita a verificação prévia da atualização e só depois atualize para o SFOS 22.0 MR2 ou posterior. Para obter um estado que possa ser restaurado no futuro, aplica-se o mesmo procedimento de limpeza confirmado: remova a definição legada no firewall de origem, crie, se necessário, uma interface VLAN com a bridge como Parent, verifique e só depois gere um novo backup. Isto não corrige um backup antigo que contenha system vlan-tag.

Verificar Device Access e as regras de firewall após a alteração

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 serviços Ping/Ping6, DNS, HTTPS, SSH, User Portal e 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 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, Configurar Device Access na Sophos Firewall em segurança é o artigo detalhado apropriado. Testar uma regra da Sophos Firewall 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.

Testar a partir da VLAN afetada

Verifique de um cliente no VLAN afetado:

1. Testar a acessibilidade do Default Gateway.
2. Testar por ping o endereço IP da firewall na nova interface VLAN, 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 atual da bridge, a zona, os VLAN IDs, a configuração das portas do switch e as regras e serviços dependentes. É também necessário dispor de acesso de gestão alternativo ou local e de um plano de recuperação aprovado pelo fabricante. Enquanto a limpeza CLI confirmada ainda não tiver sido executada, as alterações planeadas no WebAdmin podem ser revertidas pela ordem documentada: remova primeiro o endereço IP transferido da nova interface VLAN e só depois volte a atribuí-lo à bridge; em seguida, reponha a zona, as regras, o Device Access e o perfil da porta do switch, e verifique a acessibilidade da gestão e do gateway. Isto não reverte uma limpeza efetuada por CLI.

A descrição contraditória do reset não comprova a existência de uma reversão ao nível dos comandos. Se os testes de aceitação falharem após a limpeza confirmada, pare e não recrie a definição legada. Escale o caso para obter um restauro aprovado pelo fabricante no firmware original suportado. Em HA, não limpe nem atualize qualquer nó enquanto o estado do peer ou da sincronização apresentar erros ou não estiver claro; conserve o backup necessário de cada nó. Sem a confirmação prévia exigida do método de levantamento, da sintaxe de limpeza, do contexto, dos efeitos e do âmbito, limite-se ao inventário do WebAdmin e pare antes da limpeza ou da atualização.

Após a conclusão bem-sucedida dos testes de aceitação, é criado um novo backup. O backup antigo com marcação VLAN legada por CLI não constitui uma opção de reversão para o SFOS 22.0 GA ou posterior. Se a configuração legada persistir apesar da migração para o WebAdmin, ou se a verificação prévia da atualização continuar a assinalá-la, não experimente outras alterações por CLI; guarde a configuração e a mensagem e envolva o Sophos Support.

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 o endereço IP da bridge sem um plano: WebAdmin, DNS ou Gateway podem falhar. Preparar backup, janelas de manutenção e acessos alternativos.
• Escolher uma zona incorreta para a nova interface VLAN: As regras, o Device Access e os logs não correspondem. 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. Planear Local Service ACL com um âmbito restrito.
• Porta do switch não verificada: 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.
• Método de levantamento que não altera a configuração, bem como sintaxe exata de limpeza, contexto CLI, efeitos e âmbito confirmados antes de qualquer ação CLI, através de documentação para a build instalada ou do Sophos Support; caso contrário, apenas inventário do WebAdmin e paragem antes da limpeza ou da atualização.
• Limite de recuperação documentado: não é possível deduzir um método de reversão ao nível dos comandos a partir da descrição contraditória do reset; novo backup criado após a limpeza confirmada e a conclusão bem-sucedida dos testes de aceitação.
• Resultado registrado no log de alterações ou na documentação da rede.

PERGUNTAS FREQUENTES