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 com SFOS 22.0 e segue o design com duas ligações à Internet descrito pela Sophos. Os túneis policy-based e os túneis route-based com Traffic Selectors concretos utilizam, em alternativa, um IPsec Failover Group.

⚠️ A ajuda atual da Sophos contradiz-se quanto a duas ligações Any-to-Any. O guia específico para dois ISP cria dois túneis sem Failover Group. Já as indicações gerais de troubleshooting de IPsec afirmam que várias ligações com Local e Remote Subnets iguais, incluindo Any-Any, só funcionam no mesmo Failover Group. Como o grupo altera DPD e Failback, este procedimento não inventa esse passo: validar o design na Maintenance Release de SFOS 22 instalada e esclarecer qualquer comportamento diferente com a Sophos Support antes da produção.

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 Custom Gateway com um Health Check escolhido conscientemente 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.

O SFOS 22 permite rotas estáticas, SD-WAN ou dinâmicas para interfaces XFRM Any-to-Any. O procedimento específico para dois ISP usa expressamente duas rotas estáticas. Este procedimento segue esse desenho; não adicionar uma rota SD-WAN para o mesmo destino sem planear e testar separadamente a interação e a prioridade.

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 ambas as firewalls, em Network > Interfaces, expande-se a interface WAN utilizada para a respetiva ligação IPsec. As interfaces XFRM criadas automaticamente aparecem por baixo desta como interfaces subordinadas. Desta forma, é possível associar cada interface XFRM ao túnel através de ISP1 ou ISP2 antes de lhe atribuir o endereço de transferência.

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.

Em cada gateway, definir pelo menos Name, Gateway IP e Interface. Gateway IP é o endereço XFRM do peer e Interface a XFRM correspondente. Health check está desativado por predefinição e tem de ser ativado para monitorizar o caminho. O SFOS 22 apresenta então Interval (predefinição 60 segundos), Time-out (2 segundos), Retries (3) e pelo menos uma Monitoring condition com Protocol, Port para TCP e IP address.

O IP de teste tem de ser um host atrás do gateway. Para avaliar todo o caminho subsequente, escolher um endpoint estável e permitido atrás do peer. Um ping apenas ao endereço XFRM prova somente o segmento imediato. É possível combinar condições com AND ou OR: AND exige todas as respostas; OR testa de cima para baixo até um destino responder.

A escolha do protocolo, destino e intervalos é operacional: o destino tem de responder de forma estável, permanecer disponível durante a manutenção normal e ter a autorização adequada. As predefinições são valores iniciais, não um tempo de comutação garantido. Só aceitar a alteração depois de medir os tempos de deteção, Failover e Failback. Criar e validar um Custom Gateway explica 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.

O guia Sophos específico atribui Failover e Failback automáticos a este design. A referência geral das rotas estáticas confirma a prioridade por Administrative Distance, mas não descreve separadamente como uma falha no Health Check retira a rota da seleção. Por isso, a validação tem de observar a rota ativa, não apenas o estado do gateway.

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.

A ajuda do SFOS 22 indica como predefinição geral static, sdwan_policyroute, vpn, enquanto o guia específico exige static vpn sdwan_policyroute. O rollback deve, portanto, repor exatamente a ordem registada antes com show, sem aplicar cegamente a predefinição.

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.

Isto é diferente de NAT Traversal. A Sophos Firewall ativa NAT-T automaticamente e usa UDP 4500 quando deteta NAT; sem NAT, IKE usa UDP 500 e ESP o protocolo IP 50. Se uma firewall estiver atrás de um router a montante, o DNAT e as permissões desse router têm de alcançar a Listening Interface correta nos dois caminhos ISP. Redes locais sobrepostas exigem, por outro lado, regras SNAT e DNAT adequadas ao tráfego útil.

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. O SFOS 22 restaura de forma transparente os túneis IPsec route-based, mas limita o Failover de sessões para tráfego dentro do túnel a protocolos sem estado, como UDP e ICMP; TCP não é suportado. Avaliar separadamente uma ligação TCP existente e uma nova. Os logs e relatórios HA também permanecem apenas no nó que processou o tráfego; verificar ambos os dispositivos.

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. O troubleshooting atual da Sophos indica /log/strongswan.log, /log/charon.log, /log/strongswan-monitor.log e /log/dgd.log; o último contém eventos de Dead Gateway Detection e VPN Failover. Na Advanced Shell, o comando só de leitura ip xfrm state mostra se existem Transform States. Troubleshooting de VPN IPsec explica o diagnóstico seguro.

Os estados do túnel e do gateway não coincidem

DPD e Gateway Health Check medem aspetos diferentes. Dead Peer Detection é configurado em Profiles > IPsec profiles e deteta um peer IKE sem resposta após a inatividade do túnel Phase 2; a Sophos recomenda ativar DPD. O Health Check do Custom Gateway testa o host escolhido atrás do caminho XFRM. Não desativar DPD para ocultar um destino de teste defeituoso. Se a Sophos Support exigir um Failover Group devido ao conflito documental acima, ter em conta que o grupo desativa DPD no perfil associado, define Key negotiation tries como 3 e introduz um Automatic failback próprio com um máximo de cinco tentativas. É um modelo operacional diferente, que não deve ser misturado com este procedimento sem validação separada.

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