Configurar e testar um grupo de failover IPsec no Sophos Firewall

Um grupo de failover IPsec organiza várias ligações Site-to-Site IPsec por prioridade. Se o túnel principal falhar, o Sophos Firewall ativa a ligação seguinte que estiver disponível. No entanto, a comutação só é útil se os dois túneis já funcionarem separadamente e abrangerem as mesmas redes de produção, regras, expectativas de NAT e rotas de retorno.

Procedimento resumido: Testar duas ligações IPsec separadamente, verificar Remote IDs e ordem, reuni-las num grupo em Site-to-site VPN > IPsec > Failover group, escolher uma Failover condition adequada e validar depois o failover e o failback com um fluxo de teste fixo.

Este guia pressupõe uma configuração Site-to-Site IPsec existente. Explica o controlo da redundância, não novamente toda a configuração do túnel.

Quando utilizar um grupo de failover IPsec

O grupo é especialmente adequado para policy-based IPsec e route-based IPsec com Traffic Selectors concretos. Várias ligações com Local e Remote subnets idênticas têm de pertencer ao mesmo grupo de failover ou utilizar seletores claramente diferentes. Caso contrário, os túneis podem interferir entre si.

Num design route-based Any-to-Any totalmente controlado pelo routing, a decisão é diferente: as interfaces XFRM recebem endereços de transferência e o caminho dos dados é determinado por rotas estáticas, dinâmicas ou SD-WAN Routes. Para este design, a Sophos documenta vários gateways XFRM com um SD-WAN Profile e verificações SLA sem um grupo de failover VPN adicional. Fora deste design, a Sophos alerta que várias ligações Any-to-Any com seletores idênticos devem pertencer ao mesmo grupo de failover.

Tornar o IPsec route-based redundante com duas ligações à Internet explica o design completo com dois operadores, gateways XFRM separados, rotas estáticas Primary e Backup e um teste controlado de failover.

Um failover WAN normal também não substitui o grupo. O WAN link manager pode mudar a ligação à Internet, mas não cria uma segunda ligação IPsec com Gateway Address, Listening Interface e configuração do peer próprias.

`system link_failover` é um mecanismo CLI separado

O SFOS 22 também publica um comando da Device Console que adiciona um túnel VPN ou GRE como backup de um Primary Link. A gramática publicada é:

system link_failover add [primarylink] [portname] [backuplink] [vpn] [gre] [tunnel] [tunnelname] [monitor PING host] [monitor TCP host] [ipaddress] [portnumber]

Com monitor TCP host, deve indicar-se a porta TCP a verificar; monitor PING host não utiliza porta. O destino não deve apenas responder, mas representar de forma útil o caminho relevante. Um monitor bem-sucedido não prova que a aplicação, a regra, a rota ou o caminho de retorno funcionem.

Este comando não corresponde ao grupo de failover IPsec configurado no WebAdmin nem ao design XFRM e SD-WAN. A página pública do SFOS 22 documenta apenas add: não fornece comandos de estado, eliminação ou reversão e não explica a interação com rotas ou SD-WAN Policies existentes. Sem um método de reversão confirmado para a build instalada, não se trata de um procedimento para copiar e colar. Para novas configurações, os métodos WebAdmin ou XFRM documentados são um ponto de partida mais claro.

Um FQDN com vários endereços WAN não é failover

Se o mesmo registo DNS A apontar simultaneamente para o endereço WAN principal e para um endereço que só fica ativo durante uma falha, o peer remoto pode selecionar o endereço inativo. O DNS round robin não conhece o estado da WAN nem o estado do túnel. Um grupo de failover IPsec local não corrige automaticamente esta seleção DNS remota.

Para túneis iniciados pelo peer remoto, são necessárias duas ligações configuradas explicitamente. Em alternativa, pode usar-se um FQDN cujo DNS tenha em conta o estado de saúde ou que uma atualização DDNS faça apontar apenas para o endereço atualmente alcançável. Se não for possível controlar nem o peer nem a atualização DNS, este design não oferece failover de entrada fiável. Dois endereços publicados simultaneamente não constituem failover testado.

Um grupo de failover VPN também não é o mesmo que um cluster HA. O grupo alterna entre túneis; o HA alterna entre dois nós da firewall. Num ambiente crítico, as falhas de WAN, VPN e possíveis falhas de HA devem, por isso, ser planeadas e testadas separadamente.

O que o grupo monitoriza

O Sophos Firewall verifica o peer através da Failover condition do grupo. O intervalo é obtido a partir do valor global Gateway failover time-out em:

Network > WAN link manager

O mesmo valor também influencia a monitorização geral dos gateways WAN. Por isso, não deve ser alterado apenas para um único túnel VPN. Um valor curto reage mais depressa, mas pode provocar uma comutação desnecessária durante uma breve perda de pacotes. Um valor longo tolera perturbações durante mais tempo, mas prolonga a falha antes da mudança.

O Health Check apenas confirma que o peer remoto responde à condição de ping ou TCP selecionada. Não demonstra que DNS, uma aplicação empresarial, NAT, routing e toda a rota de retorno funcionam. Estes elementos são testados separadamente após a comutação.

Preparar dois túneis para o grupo

No exemplo seguinte, dois túneis ligam uma sede a uma filial:

sede: 10.10.0.0/16
filial: 10.20.0.0/16
ligação principal: HQ-Branch-ISP1
ligação secundária: HQ-Branch-ISP2
endereço do peer principal: 198.51.100.20
endereço do peer secundário: 203.0.113.20
Remote ID comum da filial: 10.255.255.2
grupo de failover: HQ-Branch-Zurich

Os endereços 198.51.100.0/24 e 203.0.113.0/24 são redes de documentação e são substituídos pelos endereços públicos reais dos peers. As redes, os nomes e o Remote ID também são valores de exemplo. O princípio é determinante: os Gateway addresses podem ser diferentes, mas o endereço IP do Remote ID tem de ser igual para todos os membros do grupo. No outro extremo, este Remote ID tem de corresponder sempre ao Local ID.

Antes de agrupar, verificar as duas ligações separadamente:

As duas ligações estão ativas em Site-to-site VPN > IPsec.
Cada ligação pode ser estabelecida isoladamente e transporta o mesmo fluxo de teste definido.
Local e Remote subnets ou Traffic Selectors correspondem de forma simétrica ao outro extremo.
As regras de firewall permitem o tráfego necessário através da zona VPN nos dois sentidos.
NAT está configurado de forma igual e deliberada nos dois caminhos.
O peer conhece uma rota de retorno através dos dois túneis.
Os perfis correspondem ao respetivo peer. Perfis IPsec no Sophos Firewall explica o significado de DPD, rekeying e lifetimes.
Estão disponíveis um acesso administrativo alternativo e uma janela de manutenção.

⚠️ Adicionar uma ligação a um grupo de failover interrompe as ligações já estabelecidas. A alteração não deve, por isso, ser realizada durante uma sessão remota sem acompanhamento ou sem uma rota de recuperação testada.

Uma ligação só pode pertencer a um grupo de failover. Enquanto estiver atribuída a um grupo, não pode ser eliminada. As ligações Remote Access IPsec não podem ser membros do grupo.

Escolher uma Failover condition adequada

O Sophos suporta ping ou TCP com uma porta definida. A condição deve ser deliberadamente permitida nas duas firewalls:

Ping: fácil de verificar, mas requer Ping/Ping6 para a zona WAN em Administration > Device access. A Sophos documenta esta autorização de zona como requisito. Com endereços de peer fixos, pode avaliar-se uma Local Service ACL Exception restrita como medida de reforço; esta tem de corresponder ao endereço de origem realmente utilizado pelo peer. Device Access e Local Service ACL explica a configuração.
TCP 22: requer SSH através da zona VPN. Não se deve abrir SSH na WAN para este efeito. Um serviço de administração não é um bom Health Check geral se tiver de ser exposto apenas para monitorização.
Outra porta TCP: requer regras de firewall de entrada e de saída adequadas. O serviço tem de estar permanentemente disponível e não deve depender apenas do estado de uma aplicação arbitrária.

A condição deve representar um serviço de resposta ou caminho do peer remoto que esteja acessível de forma estável. Se o serviço TCP não responder devido a manutenção, falha local ou host firewall, o grupo pode comutar mesmo quando o próprio caminho IPsec ainda está disponível.

Configurar o grupo de failover IPsec

O caminho do menu é:

Site-to-site VPN > IPsec > Failover group > Add

Em Name, introduzir um nome claro, neste exemplo HQ-Branch-Zurich.
Em Member connections, selecionar pelo menos duas ligações Site-to-Site IPsec. Apenas as ligações ativas participam no failover; por isso, deve ativar e testar individualmente cada membro previsto antes de colocar o grupo em serviço.
Colocar as ligações pela ordem pretendida: primeiro HQ-Branch-ISP1 e depois HQ-Branch-ISP2. A primeira ligação é o túnel principal.
Ativar Mail notification para receber notificações de falha da ligação. Para isso, as Notification settings e notificações VPN já têm de funcionar.
Ativar Automatic failback se o grupo tiver de regressar ao túnel preferido depois da recuperação.
Definir uma Failover condition adequada com ping ou TCP e porta.
Guardar com Save.
Ativar o interruptor de estado do grupo. Só então o grupo fica ativo e tenta estabelecer a ligação principal.

Com duas Sophos Firewalls, verificar as propriedades das ligações, a ordem dos membros, Remote IDs e permissões do Health Check nos dois lados. Um grupo correto apenas de um lado não substitui uma configuração adequada do peer.

O que acontece com DPD e Key negotiation tries

Assim que uma ligação se torna membro do grupo, o SFOS desativa Dead Peer Detection nessa ligação e utiliza 3 para Key negotiation tries. A Failover condition assume a monitorização.

Depois de ser removida do grupo, a ligação volta a utilizar os valores de DPD e Key negotiation do perfil IPsec atribuído. Este comportamento deve fazer parte do teste de reversão, mesmo que o perfil não tenha sido alterado.

Testar o failover e o failback de forma controlada

Antes do teste de falha, definir um fluxo de dados concreto, por exemplo:

Source: 10.10.10.25
Destination: 10.20.20.15
Service: TCP 443
regra de firewall esperada: HQ-to-Branch-HTTPS

Em seguida, realizar o teste por uma ordem clara:

Documentar o estado do grupo, a ordem dos membros, o build de firmware e o Gateway failover time-out.
Verificar o túnel principal nos dois lados no WebAdmin. Confirmar com tráfego HTTPS real que os caminhos de ida e de retorno funcionam.
Guardar o estado na Advanced Shell com ipsec statusall.
Interromper de forma controlada o caminho WAN ou upstream principal durante a janela de manutenção. Não desativar todo o grupo de failover, porque isso desativa todos os túneis ativos do grupo.
Observar durante mais tempo do que o Gateway failover time-out configurado e anotar o momento da comutação.
Verificar se HQ-Branch-ISP2 é estabelecido e se o mesmo teste HTTPS funciona nos dois sentidos.
Verificar a regra de firewall, NAT, rota de retorno e funcionamento da aplicação. Um túnel verde, por si só, não é um critério de sucesso.
Restaurar o caminho principal e observar o Automatic failback.
Depois do regresso, repetir o mesmo teste e documentar a interrupção efetivamente medida.

As sessões TCP existentes podem ser interrompidas durante a mudança. O novo túnel tem Security Associations diferentes e pode utilizar outro endereço público. Por isso, a aplicação necessita frequentemente de estabelecer uma nova sessão. O failover IPsec melhora a disponibilidade, mas não garante uma sessão sem interrupções.

Automatic failback termina após cinco tentativas sem sucesso

Quando o peer principal volta a estar acessível, o SFOS tenta até cinco vezes restaurar a ligação preferida se Automatic failback estiver ativo. Se não conseguir, o túnel secundário permanece ativo. Depois disso, a firewall não verifica indefinidamente o túnel principal; só volta a tentar o regresso quando o caminho secundário falhar. Se o grupo contiver mais de duas ligações, o SFOS regressa à primeira ligação disponível na ordem Member connections.

O grupo pode ser desativado e reativado manualmente para iniciar uma nova tentativa de estabelecer a ligação principal. Isto causa uma interrupção. Primeiro, devem ser verificados os logs, o peer, o perfil, os identificadores e o caminho.

Verificar logs apenas para leitura

Para a decisão do grupo, dgd.log é importante; para o estabelecimento efetivo de IPsec, é strongswan.log. Os seguintes comandos são executados na Advanced Shell e não alteram a configuração:

tail -n 200 /log/dgd.log
tail -n 200 /log/strongswan.log
ipsec statusall

Se necessário, adicionar charon.log e o log de ação específico da ligação. As páginas oficiais do SFOS 22 indicam nomes diferentes para o log de monitorização: a referência geral indica ipsec_monitor.log, enquanto a página de troubleshooting IPsec indica strongswan-monitor.log. Consultar apenas o ficheiro existente na build instalada. Na última linha, substituir HQ-Branch-ISP1 pelo nome real da ligação:

tail -n 200 /log/charon.log
for log in /log/ipsec_monitor.log /log/strongswan-monitor.log; do [ -f "$log" ] && tail -n 200 "$log"; done
tail -n 200 /log/ipsec_conn/ipsec_HQ-Branch-ISP1.log

Comparar os timestamps de dgd.log, o estado IPsec, o evento WAN e o teste da aplicação. Um Health Check falhado sem um erro correspondente no túnel ou na aplicação ainda não prova uma falha do fornecedor. O procedimento completo encontra-se em Resolução de problemas de VPN IPsec no Sophos Firewall.

Erros típicos e regresso seguro

Não é possível ativar corretamente o grupo

É necessário selecionar pelo menos duas ligações. Apenas as ligações ativas participam no failover. Verificar se um membro previsto está desativado, já pertence a outro grupo, foi criado como Remote Access ou utiliza um Remote ID diferente. Depois, testar novamente os dois túneis em separado antes de reativar o grupo.

O túnel secundário está verde, mas o tráfego falha

É provável que a lógica do grupo tenha funcionado, mas não o caminho dos dados. Verificar regras de firewall, NAT, Local e Remote subnets, rotas automáticas ou manuais e a rota de retorno no peer. O túnel secundário tem de transportar o mesmo fluxo de teste de produção que o túnel principal.

O grupo comuta demasiado cedo ou demasiado tarde

Verificar em conjunto Failover condition e Gateway failover time-out. Um alvo de ping ou TCP instável pode provocar mudanças desnecessárias. Um timeout global longo também atrasa outras verificações de gateway que dependem dele. Não se deve alterar apenas o valor numérico, mas documentar a causa, a perda de pacotes e o tempo real de comutação.

Verificar a ordem após arrastar e largar

A ajuda pública atual do SFOS 22 não fornece um limite fiável de versões afetadas ou corrigidas para uma ordem incorreta após arrastar e largar. Voltar a abrir o grupo guardado após cada alteração e comparar a ordem com a prioridade pretendida.

Desfazer o grupo

Desativar um grupo de failover desativa os túneis ativos dos seus membros. As ligações individuais necessárias têm depois de ser reativadas separadamente. A Sophos não documenta os efeitos da eliminação do próprio grupo. Por isso, deve primeiro desativar o grupo numa janela de manutenção, remover as atribuições de forma controlada e não pressupor uma reativação automática. Para uma reversão controlada:

Guardar o estado inicial, a ordem dos membros e os perfis utilizados.
Confirmar a janela de manutenção e o acesso administrativo alternativo.
Desativar o grupo e documentar a interrupção.
Remover as ligações do grupo ou restaurar a atribuição original.
Ativar a ligação individual necessária.
Voltar a considerar o comportamento de DPD e Key negotiation definido no perfil.
Verificar o mesmo fluxo de teste, os logs e a rota de retorno.

Operação

Voltar a testar failover e failback após alterações de firmware, fornecedor, peer, routing, NAT ou perfil.
Documentar a ordem dos membros, Remote IDs, perfis, condição do Health Check e timeout global.
Utilizar Mail notification apenas como aviso; a validação técnica continua a ser feita com estado, logs e tráfego real.
Incluir os dois túneis na monitorização, no plano de manutenção e na documentação do peer.
Verificar se o fornecedor secundário cumpre as mesmas allowlists, dependências de NAT e requisitos de acessibilidade pública.
Desativar e reativar manualmente o grupo apenas com uma interrupção planeada.

FAQ

Qual é a diferença entre failover WAN e um grupo de failover IPsec?

O failover WAN muda a ligação à Internet da firewall. Um grupo de failover IPsec, pelo contrário, prioriza várias ligações Site-to-Site IPsec totalmente configuradas. Por isso, um túnel redundante exige mais do que apenas uma WAN de Backup.

Porque é que Automatic failback já não regressa ao túnel principal?

O SFOS tenta restaurar o túnel principal até cinco vezes. Se essas tentativas falharem, o túnel secundário permanece ativo e o principal só volta a ser verificado quando o caminho secundário falhar. Desativar e reativar manualmente o grupo inicia uma nova tentativa, mas causa downtime.