Alterar Route Precedence no Sophos Firewall com segurança

Route Precedence define se o Sophos Firewall avalia primeiro Static Routes, SD-WAN Policy Routes ou rotas VPN. A definição tem efeito global e pode afetar imediatamente o tráfego de produção e o acesso administrativo.

Resposta curta

A ordem predefinida é:

1. static
2. sdwan_policyroute
3. vpn

Esta ordem é adequada para muitos ambientes, pois impede que redes diretamente ligadas e rotas estáticas sejam substituídas por uma rota SD-WAN abrangente. A ordem só deve ser alterada quando vários tipos de routing concorrem para o mesmo destino num fluxo de pacotes concreto.

Antes de qualquer alteração: documentar a ordem atual, assegurar um acesso de gestão independente, verificar as rotas afetadas e preparar o rollback exato. Uma rota SD-WAN normal é explicada em Configurar e testar uma rota SD-WAN no Sophos Firewall.

Qual é a ordem adequada?

Ordem predefinida e diferenças entre versões

A ordem predefinida é idêntica no SFOS 21.5 e 22.0. No entanto, a atribuição de ipsec_route mudou:

• SFOS 21.5: static inclui redes diretamente ligadas, ipsec_route, Unicast Routes, Dynamic Routes e SSL VPN. As rotas policy-based IPsec criadas automaticamente pertencem a vpn.
• SFOS 22.0: static inclui redes diretamente ligadas, Unicast Routes, Dynamic Routes e SSL VPN. vpn inclui as rotas policy-based IPsec criadas automaticamente e ipsec_route.

Isto é importante durante atualizações: uma recomendação para ipsec_route no SFOS 21.5 não deve ser transferida sem alterações para o SFOS 22.0. No SFOS 22.0, o firewall processa internamente as rotas policy-based IPsec. As rotas policy-based VPN criadas automaticamente e as rotas definidas com ipsec_route não são visíveis na tabela de routing. ipsec_route não é necessário para tráfego gerado pelo sistema. Uma rota IPsec manual só faz sentido no caso especial adequado e dependente da versão.

Em firewalls migrados, o que conta não é a predefinição documentada, mas o resultado real do comando. Uma migração pode, por exemplo, manter sdwan_policyroute vpn static. Além disso, SD-WAN Routes migradas podem continuar associadas ao ID da respetiva regra de firewall original e desaparecer quando essa regra é eliminada.

Static primeiro

static sdwan_policyroute vpn é geralmente o ponto de partida adequado para LAN, DMZ, VLAN, SSL VPN e percursos de Internet SD-WAN normais. As redes diretamente ligadas são tratadas como rotas estáticas.

Isto protege os destinos internos contra SD-WAN Routes demasiado abrangentes. Se sdwan_policyroute estiver antes de static e uma rota SD-WAN utilizar, por exemplo, o destino Any, o tráfego interno ou administrativo pode ser encaminhado inesperadamente para o gateway WAN.

SD-WAN primeiro

sdwan_policyroute static vpn faz sentido quando o Policy Routing deve ter deliberadamente prioridade sobre as rotas estáticas. Isto deve ser planeado com base em origens, destinos e serviços concretos. As SD-WAN Routes só se aplicam a Reply Packets e a tráfego gerado pelo sistema se as opções CLI correspondentes estiverem ativadas.

Verificar o routing SD-WAN para Reply Packets e System Traffic no Sophos Firewall explica detalhadamente estas duas opções.

VPN primeiro

vpn static sdwan_policyroute é uma exceção específica, por exemplo para cenários L2TP documentados. A prioridade de vpn sobre static só se aplica ao tráfego cuja rota concorrente conduz à zona WAN. Não é uma correção universal para todos os túneis IPsec.

As ligações SSL VPN pertencem à categoria static, não a vpn. O route-based IPsec através de interfaces XFRM é controlado pela rota estática, dinâmica ou SD-WAN configurada para esse fim. Por isso, são decisivos a interface XFRM, a rota, os critérios SD-WAN, o NAT, a regra de firewall e o percurso de retorno.

Uma alteração global não é adequada quando apenas uma rede de destino é encaminhada incorretamente. Nesse caso, uma rota estática ou SD-WAN mais específica, a configuração VPN ou uma ipsec_route utilizada de acordo com a versão são normalmente opções mais precisas.

Preparar a alteração com segurança

Os comandos são executados na Device Console, não na Advanced Shell. Se o acesso ainda não estiver configurado, consulte Ligar ao Sophos Firewall através de SSH. O SSH só deve ser permitido a partir de redes fidedignas.

Preparação:

1. Assegurar uma via de retorno independente para o firewall e testá-la ativamente antes da alteração, por exemplo, uma consola local, uma interface de gestão dedicada ou um percurso administrativo confirmado e não afetado.
2. Anotar a origem, o destino, o serviço, a zona e as interfaces envolvidas.
3. Verificar rotas estáticas, SD-WAN Policy Routes, rotas VPN e interfaces XFRM.
4. Identificar SD-WAN Routes abrangentes com Any e regras migradas.
5. Verificar o NAT, a regra de firewall e o percurso de retorno do ponto remoto.
6. Definir a janela de manutenção, o teste de aceitação e o rollback.

⚠️ Importante: Route Precedence tem efeito global. Não alterar simultaneamente regras de routing, NAT, firewall e SD-WAN, caso contrário não será possível atribuir o efeito de forma fiável.

Mostrar e documentar exatamente a ordem atual:

system route_precedence show

Registar o resultado completo juntamente com a data, o motivo, as redes afetadas e o comportamento esperado. Antes da alteração, preparar o comando de rollback exato a partir dos três valores.

A ordem atual também está visível no WebAdmin em:

Routing > SD-WAN routes

A alteração é feita através da Device Console. Se o SD-WAN estiver envolvido, registar primeiro também o estado do tráfego gerado pelo sistema e dos Reply Packets:

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

Estes valores não devem ser confundidos inadvertidamente com o efeito de Route Precedence. Existe uma combinação particularmente crítica quando sdwan_policyroute está antes de static, uma rota SD-WAN correspondente utiliza o destino Any e o SD-WAN está ativo tanto para o tráfego gerado pelo sistema como para Reply Packets. Nesse caso, o acesso ao WebAdmin e por SSH a partir da sub-rede interna afetada pode ser perdido, embora o firewall ainda possa estar acessível a partir de outras sub-redes.

Alterar Route Precedence

A sintaxe contém sempre os três valores:

system route_precedence set [sdwan_policyroute] [static] [vpn]

Definir a ordem predefinida:

system route_precedence set static sdwan_policyroute vpn

Se esta ordem já estiver ativa, o erro está provavelmente no Route Lookup, nos critérios SD-WAN, na configuração VPN, no NAT, na regra de firewall ou no percurso de retorno.

⚠️ Antes de SD-WAN-First: Verificar se SD-WAN Routes abrangentes incluem redes internas ou o acesso de gestão. Executar o comando apenas com uma via de retorno preparada.

Avaliar primeiro as SD-WAN Policy Routes:

system route_precedence set sdwan_policyroute static vpn

⚠️ Antes de VPN-First: Utilizar esta ordem apenas para um caso especial VPN confirmado. Não resolve a falta de uma rota, Traffic Selectors incorretos, problemas de NAT ou do percurso de retorno.

Avaliar primeiro as rotas VPN:

system route_precedence set vpn static sdwan_policyroute

Testar e reverter a alteração

Após a alteração, confirmar primeiro se a ordem esperada está ativa:

system route_precedence show

Em seguida, testar o fluxo de pacotes afetado:

• Verificar a aplicação, a ligação TCP ou o ping para o destino.
• Filtrar o Log Viewer por origem, destino e regra de firewall.
• Executar o Packet Capture nas interfaces de entrada e saída.
• Verificar o Route Lookup e a rota SD-WAN afetada.
• Verificar o NAT e o endereço IP de origem traduzido.
• Confirmar o percurso de retorno do ponto remoto.
• Testar o WebAdmin e o SSH a partir das redes administrativas relevantes.

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

Se forem afetados vários locais ou percursos de routing, testar pelo menos um cliente por rede relevante, um destino de servidor e os percursos Remote Access ou VPN afetados.

No rollback, é definida exclusivamente a ordem inicial completa que foi documentada anteriormente. Não é possível deduzi-la apenas a partir do primeiro valor, pois existem seis combinações possíveis. Utilizar o comando preparado de acordo com este padrão:

system route_precedence set <primeiro valor> <segundo valor> <terceiro valor>

Substituir os três marcadores pelos três valores do resultado guardado anteriormente. Em seguida, voltar a verificar:

system route_precedence show

Depois, repetir os mesmos testes funcionais, de routing e de gestão. Se o erro original reaparecer após o rollback, Route Precedence esteve provavelmente envolvido. Se nada mudar, a causa encontra-se noutro ponto.

Erros frequentes

A rota SD-WAN é demasiado abrangente

Uma rota SD-WAN com intervalos de rede amplos ou com o destino Any pode abranger mais tráfego do que o planeado. Se SD-WAN estiver antes de Static, os destinos internos e os acessos de gestão podem ser encaminhados inesperadamente para o gateway WAN. Reply Packets e o tráfego gerado pelo sistema são afetados se as opções SD-WAN correspondentes estiverem ativadas.

O estado da VPN é confundido com routing

Um túnel ativo apenas confirma a negociação. Não demonstra que o routing, os Traffic Selectors, as regras de firewall, o NAT e o percurso de retorno estão corretos. No route-based IPsec, verificar primeiro a interface XFRM e a rota; no policy-based IPsec, verificar também o tratamento de ipsec_route dependente da versão. O artigo Resolver problemas de IPsec VPN no Sophos Firewall orienta sistematicamente a análise.

O NAT é ignorado

O routing determina o percurso do pacote, enquanto o NAT altera o endereço de origem ou destino. Se a rota estiver correta, mas o percurso de retorno não funcionar, o NAT ou a rota de retorno são frequentemente a causa. Consulte Compreender o NAT no Sophos Firewall.

Várias alterações são efetuadas simultaneamente

Se Route Precedence, SD-WAN, NAT, regras de firewall e parâmetros VPN forem alterados ao mesmo tempo, deixa de ser possível separar claramente a causa do efeito. É preferível proceder assim: uma alteração, teste completo, alteração seguinte.

Lista de verificação

• Route Precedence atual documentado.
• Versão do SFOS e atribuição de ipsec_route consideradas.
• Origens, destinos, redes e serviços afetados anotados.
• Static, SD-WAN, VPN e XFRM verificados.
• Redes diretamente ligadas e percursos de gestão considerados.
• SD-WAN Routes abrangentes com Any identificadas.
• Estado de System Traffic e Reply Packets registado.
• NAT, regras de firewall e percurso de retorno verificados.
• Acesso de gestão independente e rollback preparados.
• Alteração efetuada isoladamente.
• Aplicação, Log Viewer, Packet Capture e acesso de gestão testados.

FAQ