Alterar Route Precedence no Sophos Firewall com segurança

Route Precedence define globalmente se o Sophos Firewall avalia primeiro Static Routes, SD-WAN Policy Routes ou rotas VPN. A ordem aplica-se quando várias categorias correspondem ao mesmo fluxo. Uma exceção importante: vpn antes de static só se sobrepõe a rotas estáticas ou locais para destinos na zona WAN.

Porque é necessária Route Precedence

O Sophos Firewall não mantém Static, SD-WAN e VPN numa única lista de routing. São categorias separadas e várias categorias podem conter simultaneamente um percurso correspondente para o mesmo destino. Route Precedence determina em que categoria é procurada primeiro uma rota correspondente.

Exemplo típico: um cliente na LAN deve alcançar a rede remota 10.20.0.0/16 através de um túnel policy-based IPsec. Ao mesmo tempo, uma rota SD-WAN com o destino Any também corresponde a este tráfego.

• Com static sdwan_policyroute vpn, o firewall verifica primeiro Static. Se não encontrar um percurso correspondente, a rota SD-WAN abrangente corresponde em seguida e o tráfego pode seguir para o gateway WAN em vez do túnel VPN.
• Com static vpn sdwan_policyroute, o firewall verifica as rotas VPN logo após Static. A rota para a rede remota tem assim prioridade sobre a rota SD-WAN geral.

Substituir a rede de exemplo 10.20.0.0/16 pela rede remota real. A questão importante não é qual ordem parece geralmente «melhor», mas qual tipo de routing deve ter prioridade para o fluxo de pacotes concreto.

Route Precedence ordena apenas as categorias. Não altera a ordem das Static Routes ou SD-WAN Routes individuais dentro da respetiva categoria. Antes de a alterar, responder a três perguntas:

1. Que tráfego concreto está atualmente a seguir o percurso errado?
2. Quais das três categorias contêm uma rota correspondente?
3. Que categoria deve ter prioridade para esse tráfego?

Se apenas uma categoria corresponder, alterar Route Precedence não resolverá o problema. Nesse caso, deve corrigir-se a rota afetada, a Policy SD-WAN, a configuração VPN, a regra NAT ou o percurso de retorno. Route Precedence também não permite tráfego entre zonas; continua a ser necessária uma regra de firewall adequada.

Mostrar e alterar diretamente Route Precedence

Os comandos são executados na Device Console, não na Advanced Shell. Depois de iniciar sessão por SSH, selecionar a opção de menu 4. Se o acesso ainda não estiver configurado, consulte Ligar ao Sophos Firewall através de SSH.

Registar primeiro a ordem atual completa e usá-la para preparar o comando de rollback. A predefinição atual da Sophos não a substitui, pois firewalls migrados ou personalizados podem ter outra ordem inicial.

⚠️ Importante: A alteração é global. Antes do comando set, registar a ordem inicial e garantir um acesso de gestão independente. Uma ordem inadequada pode afetar o tráfego de produção e os acessos WebAdmin e SSH.

O exemplo seguinte define Static primeiro, VPN em segundo e SD-WAN em último:

system route_precedence show
system route_precedence set static vpn sdwan_policyroute
system route_precedence show

O primeiro comando mostra a ordem, o segundo altera-a e o terceiro verifica o resultado. A posição determina a prioridade. O resultado final deve mostrar static, vpn, sdwan_policyroute exatamente nessa ordem; depois, testar o fluxo real.

A ordem predefinida atual da Sophos é:

system route_precedence set static sdwan_policyroute vpn

Este comando só constitui um rollback se system route_precedence show tiver mostrado exatamente esta ordem antes da alteração.

O WebAdmin também mostra a ordem atual em Routing > SD-WAN routes, mas a alteração só é possível através da Device Console.

O que significam Static, SD-WAN e VPN

Os três valores representam categorias de routing, não rotas individuais:

• static inclui redes diretamente ligadas, Unicast Routes, Dynamic Routes e SSL VPN.
• sdwan_policyroute inclui as Policy Routes configuradas em Routing > SD-WAN routes.
• vpn inclui as rotas policy-based IPsec criadas automaticamente. No SFOS 22.0, também inclui rotas definidas com ipsec_route.

As rotas policy-based IPsec e entradas ipsec_route não aparecem na tabela de routing do WebAdmin. Na análise de conflitos, considerar também a configuração VPN e as rotas criadas na Device Console. O guia de rotas IPsec no Sophos Firewall explica a classificação completa.

O SSL VPN pertence a static, não a vpn. O route-based IPsec através de XFRM é controlado pela rota estática, dinâmica ou SD-WAN configurada. A interface XFRM, a rota e a respetiva Administrative Distance são decisivas, não apenas a posição de vpn. Sem uma rota correspondente, o WAN Link Manager fornece a rota predefinida.

Static, SD-WAN, VPN

system route_precedence set static sdwan_policyroute vpn

Esta é a ordem predefinida e o ponto de partida adequado para muitos ambientes. Impede que rotas SD-WAN demasiado abrangentes se sobreponham a redes diretamente ligadas, LAN, DMZ, VLAN e SSL VPN.

Static, VPN, SD-WAN

system route_precedence set static vpn sdwan_policyroute

Esta ordem mantém Static primeiro, avalia depois as rotas VPN e utiliza SD-WAN por último. É útil quando os percursos estáticos e diretamente ligados devem manter a prioridade, enquanto uma rota VPN policy-based concorrente deve ser verificada antes de SD-WAN. A Sophos também a utiliza para failover VPN route-based com duas ligações à Internet e MTA com várias ligações WAN.

SD-WAN, Static, VPN

system route_precedence set sdwan_policyroute static vpn

Esta variante só deve ser utilizada quando o Policy Routing deve deliberadamente ter prioridade sobre as rotas estáticas. É necessário cuidado especial com uma rota SD-WAN cujo destino seja Any: Também pode abranger redes internas ou o acesso de gestão e encaminhar esse tráfego para o gateway WAN. Por isso, uma rota SD-WAN deve utilizar destinos tão específicos quanto possível e ser testada.

VPN, Static, SD-WAN

system route_precedence set vpn static sdwan_policyroute

Colocar VPN em primeiro lugar é uma exceção específica, não uma solução geral para problemas de IPsec. Para L2TP Remote Access, vpn deve surgir primeiro; static e sdwan_policyroute podem seguir em qualquer ordem. No entanto, vpn antes de static só dá prioridade a VPN sobre Static quando a rota estática concorrente conduz à zona WAN. Para destinos noutras zonas, o firewall continua a utilizar a rota estática ou local.

O design policy-based que encaminha o tráfego Internet de uma filial pela sede também requer exatamente esta ordem. Combina seletores Any, uma regra VPN-to-WAN, MASQ e uma decisão separada para o tráfego gerado pelo sistema.

Alterar Route Precedence com segurança

Antes de uma alteração em produção, preparar o comando e o fluxo de pacotes afetado:

1. Guardar a ordem atual completa com system route_precedence show e utilizá-la para preparar o comando de rollback.
2. Identificar origem, destino, serviço, zona e interfaces envolvidas. Verificar Static Routes, SD-WAN Routes, rotas VPN e interfaces XFRM relativamente a destinos concorrentes.
3. Testar um percurso independente para o firewall, por exemplo uma consola local, uma interface de gestão separada ou um percurso administrativo não afetado.
4. Alterar apenas Route Precedence. Não modificar simultaneamente regras de NAT, firewall, VPN e SD-WAN, para que a causa e o efeito continuem identificáveis.

Se o SD-WAN estiver envolvido, verificar também se está ativado para tráfego gerado pelo sistema ou Reply Packets:

show routing sd-wan-policy-route system-generate-traffic
show routing sd-wan-policy-route reply-packet

Estas opções não alteram a ordem. Expandem o tráfego ao qual se aplicam as SD-WAN Routes: Reply-Packet-Routing não se aplica se o percurso de ida usou apenas a rota predefinida do WAN Link Manager. Para tráfego do sistema, usar apenas redes de destino e serviços, pois Incoming Interface e Source Network são desconhecidos. Pelo menos um gateway do WAN Link Manager deve estar Active; gateways que estejam apenas em Backup não bastam. O tráfego RED do sistema por UDP 3410 permanece fora do routing SD-WAN por ser Layer 2. Verificar o routing SD-WAN para Reply Packets e System Traffic no Sophos Firewall explica os detalhes.

Depois do comando set, confirmar primeiro a ordem com system route_precedence show. Em seguida, testar o caso concreto:

• Testar a aplicação, uma ligação TCP ou o ping para o destino.
• Verificar Route Lookup, Log Viewer e Packet Capture quando necessário.
• Verificar o NAT e o percurso de retorno do ponto remoto.
• Testar WebAdmin e SSH a partir das redes de gestão relevantes.

Um estado VPN verde ou a existência de uma rota não demonstram que o fluxo de pacotes funciona. Os controlos práticos são explicados em Testar regras do Sophos Firewall com Log Viewer e Packet Capture e Utilizar o Packet Capture no WebAdmin do Sophos Firewall.

Rollback

Para o rollback, repor exatamente a ordem inicial registada antes da alteração:

system route_precedence set <erster Wert> <zweiter Wert> <dritter Wert>

Substituir os três placeholders. O estado anterior não pode ser deduzido apenas a partir do primeiro valor, porque existem seis ordens possíveis. Depois, repetir system route_precedence show e os mesmos testes funcionais e de gestão.

Se a alteração não resolver o problema

• Apenas uma rede de destino é afetada: Uma rota estática mais específica, uma rota SD-WAN mais restrita ou uma configuração VPN corrigida são normalmente mais precisas do que uma alteração global.
• O túnel VPN está verde, mas o tráfego segue o percurso errado: No route-based IPsec, verificar primeiro a interface XFRM e a rota. No policy-based IPsec, verificar também os Traffic Selectors e o tratamento de ipsec_route dependente da versão. Seguir o guia de resolução de problemas de IPsec VPN.
• O percurso de ida está correto, mas o de retorno não: O routing determina o percurso, enquanto o NAT altera o endereço de origem ou destino. Verificar a rota de retorno e a configuração NAT.
• Um firewall migrado mostra uma ordem inesperada: O resultado de system route_precedence show é a referência, não a predefinição atual. As rotas SD-WAN migradas também podem continuar associadas à regra de firewall original e desaparecer quando essa regra é eliminada.
• O WebAdmin ou o SSH estão inacessíveis após uma alteração SD-WAN: Muitas vezes coincidem três condições: SD-WAN está antes de Static, uma rota SD-WAN correspondente utiliza Any e System Traffic ou Reply Packets estão ativados para SD-WAN. Repor a ordem inicial através do percurso de gestão preparado e restringir a rota SD-WAN.
• Um pedido SSL VPN chega ao destino interno, mas a resposta não chega ao cliente: SSL VPN pertence a static. Se SD-WAN surgir antes, uma rota SD-WAN abrangente pode desviar do túnel a resposta destinada ao intervalo de endereços. Restringir a rota de forma específica; o procedimento completo está em Configurar e testar o acesso remoto SSL VPN.

FAQ