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.

Com route-based Any-to-Any, 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. Nesse caso, vários gateways XFRM podem ser priorizados diretamente através de um SD-WAN Profile e verificações SLA. Não é necessário um grupo de failover VPN adicional.

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.

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 ou um FQDN cujo DNS baseado no estado ou atualização DDNS aponte apenas para o endereço atualmente alcançável. Se não for possível controlar nem a configuração do peer nem a atualização DNS, o planeamento deve parar neste ponto. Dois endereços publicados simultaneamente não devem ser considerados um 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. Com endereços de peer fixos, uma Local Service ACL Exception restrita é preferível a uma autorização desnecessariamente ampla. Device Access e Local Service ACL explica a implementação segura.
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 ativas.
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 se uma mudança de túnel tiver de ser comunicada por e-mail. 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 define efetivamente Key negotiation tries como 3. A Failover condition assume a monitorização. Por isso, os valores apresentados no perfil não mostram, por si só, todo o comportamento efetivo.

Depois de ser removida do grupo, a ligação volta a utilizar os valores de DPD e Key negotiation do perfil IPsec atribuído. Isto é importante durante um rollback: depois de dissolver o grupo, um túnel pode comportar-se de forma diferente, mesmo que o perfil não tenha sido editado.

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.

O grupo pode ser desativado e reativado manualmente para iniciar uma nova tentativa de estabelecer a ligação principal. No entanto, isto causa downtime e não é um interruptor de atualização inofensivo. Primeiro, devem ser verificados logs, peer, perfil, IDs e 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, ipsec_monitor.log e o log de ação específico da ligação. Na última linha, substituir HQ-Branch-ISP1 pelo nome real da ligação:

tail -n 200 /log/charon.log
tail -n 200 /log/ipsec_monitor.log
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 e ativar pelo menos duas ligações. Verificar se uma ligação já pertence a outro grupo, foi criada 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.

A ordem fica incorreta após drag-and-drop

A Sophos confirma o erro NC-178121 para o SFOS 22.0 GA: após uma alteração por drag-and-drop, as ligações Site-to-Site IPsec podiam ficar numa posição incorreta dentro do grupo de failover. Este erro específico foi corrigido no SFOS 22.0 MR2 Build 546.

No SFOS 22.0 GA, documentar a ordem antes e depois de cada alteração e não confiar apenas no movimento visual. Para o MR1, a Release Note pública não indica um limite separado e inequívoco de versões afetadas ou corrigidas. Por isso, um erro semelhante no MR2 Build 546 ou posterior não deve continuar a ser atribuído automaticamente a NC-178121.

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. Para um rollback controlado:

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.