Altere Sophos Firewall Route Precedence com segurança

O Route Precedence do Sophos Firewall determina a ordem na qual os diferentes tipos de roteamento são levados em consideração ao selecionar a rota. Parece um pequeno ajuste, mas pode impactar imediatamente o tráfego produtivo. É particularmente relevante quando Rotas estáticas, Rotas de política SD-WAN e Rotas VPN se sobrepõem.

O artigo explica quando uma alteração faz sentido, quando você deve verificar outras causas primeiro e como documentar adequadamente a alteração usando Device Console, testá-la e revertê-la, se necessário. Se você deseja planejar ou testar uma rota SD-WAN normal primeiro, Configuração e teste da rota Sophos Firewall SD-WAN é adequado.

Quando Route Precedence é importante

Route Precedence torna-se importante quando vários mecanismos de roteamento teoricamente se ajustam ao mesmo destino. O firewall deve então decidir qual tipo de roteamento será avaliado primeiro.

Situações típicas:

• Uma rede de destino interna pode ser alcançada através de uma rota estática e adicionalmente através de uma rota de política SD-WAN.
• Um IPsec VPN baseado em rota usa interfaces XFRM e é simultaneamente influenciado pelas regras SD-WAN.
• Um caso especial IPsec baseado em política funciona com rotas IPsec manuais.
• Uma migração antiga manteve rotas SD-WAN ou uma Route Precedence anterior.
• O tráfego gerado pelo sistema ou os pacotes de resposta seguem uma rota inesperada após uma alteração no SD-WAN.
• Após uma atualização ou migração de firmware, as rotas existentes se comportam de maneira diferente do esperado.

Para casos especiais de IPsec, Route Precedence não é automaticamente a melhor solução. Freqüentemente, primeiro você precisa entender se um problema de roteamento clássico, uma Rota IPsec, uma regra SD-WAN, NAT ou uma regra de firewall está envolvido.

Requisitos

• Sophos Firewall no modo Gateway.
• Acesso ao Device Console, por exemplo via SSH.
• Documentação atual de rotas estáticas afetadas, rotas de política SD-WAN e conexões VPN.
• Janela de manutenção ou pelo menos um caminho alternativo quando o tráfego produtivo puder ser afetado.
• Acesso ao Log Viewer e, se necessário, ao Packet Capture.

Se o acesso ao console ainda não estiver configurado, Conectar Sophos Firewall via SSH explica como acessar o Device Console. SSH só deve ser permitido em redes confiáveis.

⚠️ Importante: Uma alteração no Route Precedence tem um efeito global. Não é apenas um único túnel ou rota que é afetado, mas a ordem dos tipos de roteamento no firewall. Portanto, você nunca deve fazer várias alterações de roteamento, NAT e SD-WAN ao mesmo tempo.

Ordem padrão

A documentação atual descreve a seguinte ordem padrão:

1. Estático
2. SD-WAN
3. VPN

Os valores no Device Console são:

• static
• sdwan_policyroute
• vpn

Importante: a categoria static é mais ampla do que o nome sugere. A Sophos inclui nela redes diretamente conectadas, rotas de ipsec_route, rotas unicast, rotas dinâmicas e conexões SSL VPN. Isso é especialmente relevante quando tráfego de acesso remoto, rotas estáticas, roteamento dinâmico e regras SD-WAN são analisados em conjunto.

Também importante: redes diretamente conectadas são tratadas como rotas estáticas nesse contexto. Se sdwan_policyroute estiver antes de static e uma rota SD-WAN com um destino muito amplo como Any estiver ativa, o tráfego interno poderá ir repentinamente para o gateway WAN. É exatamente por isso que static antes de sdwan_policyroute é o ponto de partida seguro em muitos ambientes.

Em firewalls migradas, é importante verificar a saída atual com atenção especial. A Sophos pode manter a Route Precedence de uma versão anterior, e rotas SD-WAN migradas podem continuar associadas a regras de firewall antigas. Nesse caso, o valor decisivo não é o padrão da documentação atual, mas o que system route_precedence show mostra na firewall concreta.

Qual ordem está correta?

Não existe uma ordem certa para cada design. O Route Precedence deve se adequar ao modelo de roteamento.

• Caminhos normais de Internet LAN, DMZ, VLAN, acesso remoto e SD-WAN: static sdwan_policyroute vpn Redes diretamente conectadas e rotas estáticas não devem ser substituídas por rotas SD-WAN amplas.
• IPsec policy-based se sobrepõe a rotas estáticas ou SD-WAN: vpn static sdwan_policyroute pode ajudar em casos adequados de roteamento VPN. Se uma rota estática ou local enviar tráfego para uma zona diferente de WAN, uma ipsec_route direcionada geralmente é mais limpa do que uma alteração global de precedence. Em seguida, verifique NAT, regras do firewall e caminho de retorno.
• L2TP Remote Access ou outros casos especiais VPN documentados: A Sophos exige vpn em primeiro lugar em alguns cenários. Isso não é um padrão geral, mas um desvio direcionado para um caso de uso verificado.
• IPsec baseado em rota ou failover WAN é controlado deliberadamente via SD-WAN: A ordem depende do design, muitas vezes com SD-WAN antes de outro tipo de roteamento. Teste juntos a interface XFRM, critérios SD-WAN, status do gateway, NAT e Route Precedence.
• MTA, roteamento especial ou cenários how-to individuais da Sophos: A ordem deve corresponder ao cenário testado. Não copie cegamente um exemplo; verifique sempre redes locais e rotas de retorno.

Se um exemplo do Sophos mostrar uma ordem diferente, isso não será automaticamente um novo padrão. Muitos exemplos resolvem um problema concreto e especial. O que conta para um firewall produtivo é quais redes de origem e de destino estão realmente competindo.

Limite antes da mudança

Route Precedence não deve ser a primeira reação quando uma rede alvo não pode ser alcançada. Primeiro você deve restringir o fluxo de pacotes afetados.

Verifique:

1. Qual origem e destino são afetados?
2. Qual zona e qual interface estão envolvidas?
3. Existe uma rota estática adequada?
4. Existe uma rota de política SD-WAN que corresponda mais amplamente do que o planejado?
5. Existem rotas SD-WAN migradas de uma versão SFOS antiga?
6. Há uma rota VPN ou uma interface XFRM envolvida?
7. NAT ou MASQ se aplicam?
8. A regra de firewall esperada foi atendida no Log Viewer?
9. Packet Capture mostra o caminho de entrada e saída esperado?

Regra de teste Sophos Firewall com Log Viewer e Packet Capture e Sophos Firewall use Packet Capture em WebAdmin ajuda para o exame prático. Para questões de NAT, Entenda NAT em Sophos Firewall é adequado.

Ver Route Precedence atual

Os comandos são executados no Device Console, não no Advanced Shell.

Mostrar pedido atual:

system route_precedence show

A saída deve ser documentada antes de qualquer alteração. É melhor anotar também a data, o motivo, as redes afetadas e o comportamento esperado. Se for necessária uma reversão, esta ordem exata deverá ser definida novamente.

No WebAdmin você também pode ver o Route Precedence atual em:

Routing > SD-WAN routes

Lá ele será exibido na área de aconselhamento de roteamento. A ordem é alterada através do Device Console.

Alteração Route Precedence

A sintaxe é:

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

A ordem dos três valores determina a prioridade. Um exemplo típico coloca rotas estáticas na frente das rotas de política SD-WAN e das rotas VPN:

system route_precedence set static sdwan_policyroute vpn

Se este pedido já estiver ativo, o problema provavelmente não está no Route Precedence. Então você deve verificar especificamente a pesquisa de rota, rotas de política SD-WAN, configuração IPsec, NAT, regras de firewall e rotas de retorno.

Outro exemplo coloca as rotas de política SD-WAN antes das rotas estáticas:

system route_precedence set sdwan_policyroute static vpn

Isso pode ser intencional em determinados designs SD-WAN, mas é arriscado quando regras SD-WAN amplas usam Any ou grandes faixas de rede. Nesses casos, o acesso de gerenciamento, redes internas ou pacotes de retorno podem ser roteados inesperadamente via SD-WAN. O artigo Sophos Firewall SD-WAN routing para reply packets e system traffic explica essas interações com mais detalhes.

Para casos especiais IPsec baseados em políticas, vpn também pode ser necessário em primeiro lugar:

system route_precedence set vpn static sdwan_policyroute

Isso só deve ser feito se as rotas VPN realmente precisarem ter prioridade no fluxo de pacotes concreto. A Sophos indica que route_precedence não faz as rotas VPN vencerem as rotas estáticas para qualquer caminho de destino. Se uma rota estática ou local apontar para uma zona diferente de WAN, em VPNs policy-based com traffic selectors, verifique antes ipsec_route. Com IPsec route-based e interfaces XFRM, uma rota SD-WAN ou estática limpa geralmente é melhor do que colocar vpn globalmente em primeiro lugar.

Testar alteração

Após o ajuste, primeiro verifique o novo pedido:

system route_precedence show

Em seguida, teste especificamente o tráfego afetado. Um status VPN verde ou uma rota existente não é evidência suficiente.

Verifique:

• Conexão à rede alvo com ping, teste TCP ou teste de aplicação.
• Filtre Log Viewer na origem, destino e regra de firewall.
• Execute Packet Capture na interface de entrada e saída.
• Verifique a pesquisa de rota ou a regra SD-WAN afetada.
• Verifique a regra NAT e o IP de origem traduzido.
• Verifique o caminho de retorno da estação remota.
• Teste o acesso de gerenciamento a WebAdmin e SSH de redes administrativas relevantes.

Se vários locais forem afetados, você não deverá verificar apenas um cliente de teste. É melhor ter pelo menos um cliente por rede relevante, um destino de servidor e um acesso remoto ou teste VPN se esses caminhos forem afetados pela mudança.

Reversão

Uma reversão não consiste em um valor padrão recomendado, mas na ordem previamente documentada.

Exemplo:

system route_precedence set static sdwan_policyroute vpn

ou:

system route_precedence set sdwan_policyroute static vpn

Verifique novamente após a reversão:

system route_precedence show

Em seguida, repita os mesmos testes após a alteração. Se isso fizer com que o erro original retorne, é uma forte indicação de que o Route Precedence está realmente envolvido. Se nada mudar, a causa provavelmente está em outro lugar.

Erros comuns

A regra SD-WAN é muito ampla

Se uma rota de política SD-WAN corresponder a origens ou destinos muito amplos, ela poderá capturar mais tráfego do que o planejado. Isto é particularmente perigoso se SD-WAN for priorizado em vez de static. O acesso de gerenciamento ou redes de destino internas podem então ser executados inesperadamente por meio de uma rota WAN.

Padrão típico:

• Route Precedence está em sdwan_policyroute static vpn.
• Uma rota SD-WAN usa Any como destino.
• O tráfego gerado pelo sistema ou os pacotes de resposta também são avaliados por meio de SD-WAN.

O acesso a WebAdmin ou SSH de uma sub-rede interna pode então ser perdido, embora o firewall ainda possa ser acessado de outras redes.

O status VPN é confundido com roteamento

Um túnel IPsec ativo apenas prova que o túnel foi negociado. Isso não prova que o firewall roteia o tráfego para o túnel, que o NAT está correto ou que a estação remota conhece o caminho de volta.

Com IPsec policy-based, é particularmente importante verificar se rotas estáticas, locais ou SD-WAN também correspondem às sub-redes remotas. vpn static sdwan_policyroute pode ajudar em alguns casos, mas não substitui a verificação da zona, dos traffic selectors e de uma possível ipsec_route. Para IPsec route-based, primeiro devem ser verificadas a interface XFRM, a rota, a rota SD-WAN e as regras de firewall.

NAT é esquecido

O roteamento decide para onde um pacote é enviado. O NAT decide se o endereço de origem ou de destino será alterado. Se uma rota estiver correta, mas a rota de retorno não funcionar, o NAT ou a rota de retorno geralmente estará envolvido.

Várias alterações de uma só vez

Se as regras Route Precedence, SD-WAN, NAT, regras de firewall e parâmetros VPN forem alterados ao mesmo tempo, o efeito dificilmente poderá ser atribuído com clareza. É melhor fazer uma alteração, depois testar e depois fazer a próxima alteração.

Lista de verificação

• Route Precedence atual documentado com system route_precedence show.
• Fontes, destinos, redes e serviços afetados anotados.
• Rotas estáticas, rotas de política SD-WAN e rotas VPN verificadas.
• Redes diretamente conectadas e caminhos de gerenciamento internos considerados.
• Rotas largas SD-WAN identificadas com Any.
• Regras de NAT e firewall verificadas.
• Janela de manutenção ou caminho alternativo definido.
• Conjunto de alterações com ordem exata.
• Após modificação Log Viewer, Packet Capture e teste de aplicação realizado.
• Acesso de gerenciamento de redes administrativas verificado.
• Ordem de reversão documentada.

Perguntas frequentes