Tornar o IPsec route-based redundante com duas ligações à Internet

Uma segunda ligação à Internet não torna automaticamente um túnel IPsec redundante. Um failover fiável requer uma ligação route-based separada para cada linha, uma interface XFRM com endereço próprio e um caminho de routing monitorizado. Só então a Sophos Firewall pode mudar deliberadamente o tráfego de ISP1 para ISP2 e regressar ao caminho preferido após a recuperação.

Este procedimento aborda IPsec route-based Any-to-Any entre duas Sophos Firewalls. Os túneis policy-based e os túneis route-based com Traffic Selectors concretos utilizam, em alternativa, um IPsec Failover Group.

Procedimento rápido

1. Validar separadamente, nas duas firewalls, um túnel Any-to-Any através de ISP1 e outro através de ISP2.
2. Atribuir um endereço de transferência único a cada uma das quatro interfaces XFRM.
3. Criar em cada firewall um gateway monitorizado para ambos os endereços XFRM do peer.
4. Adicionar duas rotas estáticas para a mesma LAN remota: Primary com uma Administrative Distance inferior e Backup com uma superior.
5. Registar a Route Precedence global e defini-la como static vpn sdwan_policyroute apenas se for adequada a todo o design.
6. Verificar as regras de firewall e os caminhos de retorno para ambos os caminhos XFRM.
7. Interromper ISP1 de forma controlada, testar tráfego real da aplicação através de ISP2 e, em seguida, validar o Failback para ISP1.

⚠️ Route Precedence aplica-se a toda a firewall. Uma alteração também pode afetar caminhos Static, VPN e SD-WAN existentes. Primeiro, registar o valor atual e todas as rotas sobrepostas, criar um backup da configuração e verificar um acesso de gestão independente.

Desenho e requisitos

Compreender o modelo de failover

As duas ligações IPsec permanecem túneis independentes. A rota com a Administrative Distance inferior é o caminho de dados preferido. Se o respetivo gateway XFRM monitorizado for considerado inacessível, a rota através do segundo túnel pode assumir o tráfego.

São dois estados separados:

• O túnel está ativo: IKE e Child SA foram estabelecidos.
• O caminho é utilizável: gateway, rota, regra de firewall, comportamento NAT esperado, peer e caminho de retorno funcionam para o tráfego real.

Por isso, um túnel verde, por si só, não prova o failover. Um failover WAN normal também não basta: o WAN link manager não cria uma segunda ligação IPsec nem uma rota correspondente no peer.

Any-to-Any não utiliza um VPN Failover Group adicional. As interfaces XFRM endereçadas, os gateways e as rotas selecionam o caminho. Configurar uma VPN IPsec Site-to-Site explica a configuração de base completa deste tipo de túnel.

Planear a topologia de exemplo

O exemplo liga uma sede a uma filial:

• Sede: 172.16.16.0/24
• Filial: 192.168.10.0/24
• Primary: ISP1
• Backup: ISP2
• Rede XFRM de ISP1: 10.255.1.0/30
• Rede XFRM de ISP2: 10.255.2.0/30

Head office 172.16.16.0/24                 Branch office 192.168.10.0/24

       xfrm-ISP1 10.255.1.1  ⇄  10.255.1.2 xfrm-ISP1     AD 1
Firewall HQ                                                   Firewall BO
       xfrm-ISP2 10.255.2.1  ⇄  10.255.2.2 xfrm-ISP2     AD 2

Os endereços são valores de documentação e são substituídos por redes de transferência próprias e não sobrepostas. Cada par XFRM precisa de uma rede separada. Em cada túnel, os endereços públicos dos ISP, Local e Remote IDs, Profiles e Listening Interfaces têm de corresponder à configuração do peer.

Configurar túneis, gateways e rotas

Preparar dois túneis

Em cada firewall são criadas duas ligações em Site-to-site VPN > IPsec. Ambas utilizam Route-based (Tunnel interface) e Any em Local subnet e Remote subnet. Num design típico de sede e filial, a sede utiliza Respond only e a filial Initiate the connection.

O primeiro túnel utiliza a interface WAN de ISP1 e o segundo a interface WAN de ISP2. As duas ligações são testadas individualmente antes de configurar o failover. Em cada teste, fica ativo apenas o túnel previsto e verifica-se um fluxo de dados definido nas duas direções.

Em Network > Interfaces, atribuem-se estes endereços de exemplo às interfaces XFRM criadas automaticamente:

• Sede: 10.255.1.1/30 para ISP1 e 10.255.2.1/30 para ISP2
• Filial: 10.255.1.2/30 para ISP1 e 10.255.2.2/30 para ISP2

Não alterar o endereço de uma interface XFRM enquanto outras rotas ou serviços dependerem dela. Verificar Object usage, o estado do túnel e os objetos de routing existentes antes de cada alteração.

Monitorizar os gateways XFRM

Em Routing > Gateways, cria-se em cada lado um gateway por túnel para o endereço XFRM do peer. Na sede são 10.255.1.2 e 10.255.2.2; na filial, 10.255.1.1 e 10.255.2.1.

Como Interface, seleciona-se a XFRM correspondente. Se for necessário avaliar todo o caminho subsequente, o Monitoring Target deve ser um endpoint estável e permitido atrás do peer. Um ping apenas ao endereço XFRM do peer prova somente o segmento imediato do túnel.

A escolha do destino é uma decisão operacional: tem de responder de forma estável, não pode desaparecer durante a manutenção normal e requer a autorização adequada. Criar e validar um Custom Gateway explica em detalhe o Health Check, o estado e as condições de paragem.

Adicionar rotas estáticas Primary e Backup

Na sede, em Routing > Static routes, adicionam-se duas rotas IPv4 Unicast para a rede da filial 192.168.10.0/24:

• através de 10.255.1.2 e da XFRM de ISP1 com Administrative distance 1
• através de 10.255.2.2 e da XFRM de ISP2 com Administrative distance 2

Na filial, criam-se de forma simétrica duas rotas para a rede da sede 172.16.16.0/24:

• através de 10.255.1.1 e da XFRM de ISP1 com Administrative distance 1
• através de 10.255.2.1 e da XFRM de ISP2 com Administrative distance 2

A Administrative Distance inferior ganha enquanto o respetivo gateway estiver disponível. Redes de destino idênticas e distâncias diferentes formam assim os caminhos Primary e Backup. É diferente de ECMP com prioridades iguais. Configurar e testar uma rota estática explica a lógica geral de rota e caminho de retorno.

Definir Route Precedence de forma controlada

A Sophos documenta este design com Static antes de VPN e SD-WAN. Primeiro, regista-se o estado existente na Device Console:

system route_precedence show

Apenas se esta ordem for adequada a todo o design de routing, é definida nas duas firewalls:

system route_precedence set static vpn sdwan_policyroute

Em seguida, o valor é novamente verificado com system route_precedence show. Esta alteração não é uma solução geral para IPsec. Também afeta outras rotas Static, VPN e SD-WAN sobrepostas. Alterar Route Precedence com segurança explica o efeito global e o rollback.

Alinhar regras, NAT e caminho de retorno

As duas firewalls precisam de regras adequadas entre LAN e VPN. Origens, destinos e serviços são limitados às redes e aplicações reais dos locais; Log firewall traffic permanece ativo durante a implementação.

O tráfego normalmente encaminhado entre locais não costuma precisar de SNAT. Se já existirem exceções NAT ou traduções específicas, têm de funcionar da mesma forma nos dois caminhos. Não adicionar uma regra MASQ abrangente como atalho para failover.

A rota no peer é tão importante como o caminho de ida. Um túnel pode estar ativo embora a resposta regresse pelo ISP errado ou por uma rota mais geral. Por isso, Route Lookup, rota ativa, Firewall Rule ID, NAT Rule ID e Packet Capture são avaliados em conjunto.

Validar e operar o failover

Validar Failover e Failback

Antes do teste de falha, os dois túneis são validados individualmente com o mesmo fluxo da aplicação. Mantém-se visível uma ligação de teste contínua e também são criadas novas sessões durante o teste.

Na janela de manutenção, interrompe-se de forma controlada apenas o caminho ISP1. Não desativar simultaneamente as duas portas WAN ou os dois túneis. A validação responde a quatro perguntas:

1. O gateway ISP1 é detetado como indisponível?
2. A rota com Administrative Distance 2 através da XFRM de ISP2 fica ativa?
3. As novas ligações chegam ao peer e as respostas regressam através de ISP2?
4. Após a recuperação de ISP1, volta a ser utilizada a rota com Administrative Distance 1?

No Log Viewer e num Packet Capture restrito, a Firewall Rule ID esperada, a interface XFRM ativa e o fluxo bidirecional têm de coincidir. Um ping, por si só, não basta. HTTPS, RDP, VoIP ou outra aplicação real também mostram se o estabelecimento da sessão, MTU e o caminho de retorno funcionam. Testar uma regra de firewall com Log Viewer e Packet Capture explica o procedimento combinado.

Num cluster HA, após um Failover planeado, testa-se uma nova ligação através dos dois caminhos ISP. Um túnel ativo não garante que as sessões TCP existentes ou os estados de routing continuem sem interrupção.

Delimitar erros sistematicamente

Ambos os túneis estão verdes, mas ISP2 não assume o tráfego

Verificar o estado dos gateways, o Monitoring Target e as duas rotas estáticas. A rede de destino e o prefix têm de ser idênticos, enquanto os Next Hops e as interfaces XFRM têm de ser diferentes. Depois, comparar a Administrative Distance e a Route Precedence atual.

ISP2 assume o tráfego, mas as aplicações não respondem

Verificar as regras de firewall, as exceções NAT e a rota de retorno nos dois lados. O Packet Capture tem de mostrar o request e o reply na XFRM de ISP2. Se faltar apenas a resposta, a falha está normalmente atrás do peer ou num caminho de retorno assimétrico.

O Failback ocorre demasiado cedo ou não ocorre

Observar o Health Check e o Monitoring Target. O destino não pode indicar de forma intermitente que o túnel está saudável enquanto o caminho da aplicação continua afetado. Verificar em conjunto a Administrative Distance, a rota ativa e uma sessão realmente nova; as ligações existentes podem continuar associadas ao estado anterior.

Só funciona uma direção

Comparar a configuração simétrica: endereço XFRM, gateway, rota estática, regra e caminho de retorno têm de existir nas duas firewalls. strongswan.log e xfrmi.log ajudam nas camadas IKE e XFRM; Troubleshooting de VPN IPsec explica o diagnóstico seguro.

Repor com segurança

Antes da alteração, documentar o backup, a Route Precedence original, o estado dos túneis, os endereços XFRM, os gateways, as regras e as rotas. Se o caminho redundante não for fiável:

1. Desativar as novas rotas Backup.
2. Desativar os gateways ISP2 e o segundo túnel, em vez de os eliminar imediatamente.
3. Repor a Route Precedence original nas duas firewalls.
4. Repor as regras e o NAT no estado anterior documentado.
5. Voltar a testar o caminho ISP1 original com uma nova sessão da aplicação.

Os endereços XFRM, gateways ou túneis só são removidos quando Object usage já não apresentar dependências. Backup e restauro da Sophos Firewall explica o processo de backup e recuperação.

FAQ