Configurar e testar o failover WAN no Sophos Firewall

Uma segunda ligação à Internet não se torna automaticamente uma ligação de reserva no Sophos Firewall. Um gateway WAN recém-criado é, por predefinição, Active e participa assim no Load Balancing. Num desenho Primary/Backup clássico, o segundo gateway deve, por isso, ser alterado para Backup no WAN link manager.

O procedimento rápido para uma ligação principal e uma ligação de reserva:

Configurar por completo ambas as interfaces WAN em Network > Interfaces e testá-las individualmente.
Em Network > WAN link manager, definir o gateway principal como Active e o de reserva como Backup.
No gateway de reserva, selecionar Activate this gateway: If active gateway fails: ANY.
Configurar Failover rules fiáveis para ambos os gateways.
Testar o failover e o failback, ou seja, o regresso à ligação principal, com tráfego DNS, HTTPS e de aplicações real.

Este failover simples do acesso predefinido à Internet não exige uma rota SD-WAN própria. O SD-WAN é necessário quando determinado tráfego deve utilizar caminhos específicos ou quando a seleção do caminho deve basear-se na latência, no jitter e na perda de pacotes.

Compreender corretamente Active, Backup e Load Balancing

O tipo de gateway determina se uma ligação participa normalmente no tráfego de Internet:

Active: se estiverem disponíveis vários gateways ativos, a firewall distribui as novas sessões de acordo com os pesos configurados.
Backup: o gateway só assume o tráfego quando a respetiva condição de ativação é cumprida.

Pelo menos um gateway WAN tem de permanecer Active. Se todos os gateways estiverem marcados apenas como Backup, deixa de existir o caminho WAN predefinido normal; em particular, o tráfego gerado pela própria firewall deixa de poder ser encaminhado.

O Weight não representa largura de banda. No modo weighted round-robin, uma proporção de 2 para 1 significa que a firewall atribui duas novas sessões ao primeiro gateway e a seguinte ao segundo. Um único download não é dividido entre as duas ligações e o volume de dados transferido pode diferir significativamente desta proporção.

Por predefinição, o Sophos Firewall utiliza Session Persistence. Isto não mantém apenas uma ligação existente no mesmo link WAN: consoante o Persistence Factor, outras sessões do mesmo Source IP, por exemplo, também voltam a ser atribuídas a esse link. Depois de iniciar sessão em Option 4: Device Console, o método atual pode ser consultado com um comando apenas de leitura:

show routing wan-load-balancing

O comando não altera qualquer configuração. Mostra se está ativo Session Persistence ou weighted round-robin e ajuda a interpretar uma distribuição de caminhos inesperada. Num desenho exclusivamente Active/Backup, o método é geralmente secundário, porque tanto em funcionamento normal como em caso de falha só está disponível o caminho previsto para cada situação.

O failover WAN não é o mesmo que um failover HA. O WAN link manager muda o caminho para a Internet na mesma firewall. Um cluster HA do Sophos Firewall, pelo contrário, assume o serviço quando falha um equipamento ou uma porta monitorizada.

Preparar o failover WAN

As duas ligações ao fornecedor devem primeiro funcionar de forma independente. Os fundamentos da zona WAN, da atribuição de IP e dos gateways encontram-se em Planear zonas e interfaces no Sophos Firewall.

Um exemplo simples:

WAN1 Fiber: ligação principal, gateway gw-fiber, Type: Active, Weight: 1
WAN2 DSL: ligação de reserva, gateway gw-dsl, Type: Backup
ativação da reserva: If active gateway fails: ANY
ação na ativação: Inherit weight of the failed active gateway
ação no regresso: Serve new connections through restored gateway

Os nomes podem ser escolhidos livremente e devem identificar claramente cada ligação. O tipo de gateway e as ações, por outro lado, são definições funcionais. Antes da comutação, o gateway de reserva já deve apresentar um estado verde e o tráfego real de um cliente deve ter sido testado com sucesso através dessa ligação.

É também necessário um caminho de retorno seguro para a administração. Se a firewall for alterada remotamente, o WebAdmin não deve estar acessível exclusivamente através da ligação que será desligada durante o teste. Uma cópia de segurança atual da configuração, uma janela de manutenção e uma pessoa no local ou um caminho de gestão independente evitam que um simples teste de failover provoque uma interrupção prolongada.

Devem ainda ser registados previamente todos os serviços associados a um endereço IP público. Entre eles encontram-se publicações DNAT, peers IPsec, Remote Access, allowlists de fornecedores, servidores de e-mail e sistemas externos de monitorização. O acesso de saída à Internet pode já funcionar, enquanto estes serviços ainda não estão acessíveis ou autorizados através do novo endereço público.

Configurar Primary/Backup

Verificar as interfaces WAN e o estado dos gateways

Em Network > Interfaces, configurar ambas as portas WAN com os valores estáticos, DHCP ou PPPoE fornecidos pelo respetivo operador. Ao guardar, o gateway WAN físico correspondente é criado automaticamente no WAN link manager.

Um novo gateway começa por estar Active. Depois de adicionar uma ligação exclusivamente de reserva, deve alterar-se imediatamente o tipo para evitar que o tráfego de produção seja distribuído inadvertidamente pelos dois fornecedores.

Os Custom Gateways criados em Routing > Gateways, por exemplo para XFRM, RED ou MPLS, não aparecem no WAN link manager. Pertencem a outro desenho de routing e não são tratados como gateways ISP físicos para este cenário simples.

Configurar o gateway de reserva

Em Network > WAN link manager, editar o gateway da ligação de reserva e definir os seguintes valores:

Type: Backup
Activate this gateway: If active gateway fails
Com uma ligação principal: ANY
Action on activation: Inherit weight of the failed active gateway
Action on failback: Serve new connections through restored gateway
Guardar e verificar o estado do gateway.

Com exatamente um gateway ativo, ANY e ALL têm praticamente o mesmo efeito. A diferença torna-se importante quando existem várias ligações ativas:

ANY: o Backup é ativado assim que falha um dos gateways ativos. É adequado quando se pretende substituir imediatamente a capacidade perdida.
ALL: o Backup só é ativado quando todos os gateways ativos falham. É mais adequado para uma ligação de emergência lenta ou dispendiosa.

Action on activation determina o peso do gateway de Backup quando este fica ativo juntamente com outros gateways disponíveis. Inherit weight of the failed active gateway é uma escolha clara num cenário de substituição simples. Use configured weight é útil quando a reserva tem deliberadamente menor ou maior capacidade e funciona em conjunto com as restantes ligações ativas.

No failback, Serve new connections through restored gateway é a opção menos disruptiva em operação. As novas sessões voltam a utilizar a ligação principal, enquanto as sessões existentes permanecem no caminho de Backup até atingirem o timeout ou serem terminadas. Serve all connections through restored gateway restabelece as ligações existentes e pode interrompê-las. Nas rotas SD-WAN, esta ação só é aplicável se WAN link load balance estiver selecionado como Primary Gateway. Se um único link WAN Active estiver definido diretamente como Primary, apenas as novas ligações são encaminhadas pelo gateway restabelecido.

Escolher Failover rules adequadas

As Failover rules determinam quando um gateway é considerado indisponível. Estão disponíveis:

Testing method: Ping ou TCP
IP address
para TCP, também Port
associação de várias condições de falha com AND ou OR

Uma falha física do cabo já é detetada na interface. O teste de Ping criado por predefinição para o endereço IP do gateway verifica adicionalmente se o equipamento do fornecedor diretamente ligado ou o primeiro hop do fornecedor está acessível. No entanto, pode permanecer verde apesar de já não existir acesso à Internet para lá do router do fornecedor. Por isso, a Sophos recomenda como alvo para gateways WAN/ISP um endereço IP público conhecido, por exemplo 8.8.8.8 ou 8.8.4.4.

Para IPv6, a Sophos indica 2001:4860:4860::8888 como exemplo público. Para verificar o equipamento upstream, utiliza-se o endereço IPv6 do gateway e não o respetivo endereço link-local.

Um único alvo também não representa uma verificação completa do estado. Para um início mais robusto, podem ser utilizados dois endereços IP públicos permanentemente disponíveis e autorizados pela organização:

AND: só a falha de todos os testes associados aciona o failover. Isto reduz comutações indevidas causadas pela indisponibilidade de um único alvo.
OR: a falha de um só teste pode acionar o failover. A reação é mais sensível, mas aumenta o risco de comutações desnecessárias.

8.8.8.8 e 8.8.4.4 são exemplos concretos da Sophos, mas pertencem ao mesmo operador e não representam domínios de falha totalmente independentes. Num ambiente importante, é preferível utilizar dois alvos autorizados pertencentes a operadores diferentes. Um alvo de Ping tem de responder de forma fiável a ICMP; para TCP, é necessário um serviço estável cuja porta possa ser testada.

ANY/ALL no gateway de Backup e AND/OR nas regras de teste respondem a perguntas diferentes. ANY/ALL determina quantos gateways ativos têm de falhar. AND/OR determina como vários testes avaliam a falha de um único gateway.

O valor global Gateway failover timeout no WAN link manager define quando a firewall considera que um link sem resposta falhou. Não existe um valor universalmente correto. Um timeout demasiado curto reage mais depressa, mas pode provocar uma comutação desnecessária em caso de perda de pacotes ou de uma falha breve do alvo de teste. Este valor também é utilizado, entre outras funções, como intervalo de Health Check para grupos de failover IPsec e, por isso, não deve ser alterado isoladamente para um único link WAN. Deve documentar-se o valor inicial, efetuar um teste controlado e só depois ajustá-lo com base no tempo de comutação medido.

Testar o failover e o failback de forma controlada

Um teste ao cabo verifica apenas uma falha local do link. Uma falha no fornecedor para lá de um router que continua acessível só é detetada quando os alvos públicos configurados deixam igualmente de responder. Idealmente, os dois casos devem ser testados separadamente.

Confirmar a janela de manutenção, o plano de reversão e o acesso administrativo alternativo.
Em Network > WAN link manager, documentar o estado dos gateways principal e de reserva.
A partir de um cliente de teste, verificar DNS, HTTPS e uma aplicação importante. Registar também o endereço público de saída atualmente utilizado.
Para testar o link, desligar de forma controlada o cabo WAN principal. Para testar a monitorização propriamente dita, manter o link para a firewall ativo e interromper o upstream após o equipamento do fornecedor, se isso puder ser feito em segurança.
Aguardar mais tempo do que o Gateway failover timeout configurado.
Verificar se o gateway principal aparece como indisponível e o gateway de reserva como ativo.
Iniciar novas sessões DNS, HTTPS, VPN e de aplicações. Verificar a regra de firewall, NAT, acessibilidade do destino e o novo endereço público de saída.
Verificar os eventos Gateway Up/Down no Log viewer. Para uma análise mais aprofundada, dgd.log contém eventos relativos à gestão dos gateways WAN e ao failover dos links.
Restabelecer a ligação principal e verificar separadamente as sessões existentes e as novas. Assim é possível confirmar se ocorre efetivamente o comportamento de failback configurado.
Documentar o estado final, as aplicações e a acessibilidade externa.

Um Ping bem-sucedido apenas comprova que o alvo de teste responde. Não confirma DNS, NAT, VPN, serviços publicados nem uma aplicação empresarial. Para verificar o caminho efetivo dos pacotes, pode utilizar-se o Packet Capture no WebAdmin do Sophos Firewall; a função de dgd.log e de outros ficheiros é explicada em Service Logs do Sophos Firewall.

Erros frequentes e limitações

A ligação de reserva já distribui tráfego de produção: o novo gateway ainda está definido como Active. Para uma ligação exclusivamente de reserva, alterar para Backup.
O Backup não fica ativo quando ocorre uma falha: verificar o estado e o tipo do gateway, ANY/ALL, as Failover rules e o Gateway failover timeout. Com vários gateways ativos, ALL pode impedir deliberadamente a ativação enquanto continuar disponível um caminho ativo.
O gateway está verde, mas a Internet não funciona: o alvo de teste está acessível, mas o DNS, routing, a regra de firewall, NAT ou a aplicação falham. Verificar tráfego real, o Log Viewer e o Packet Capture.
A firewall comuta sem existir uma falha real do fornecedor: um único alvo de teste não responde, OR é demasiado sensível ou o timeout é demasiado curto para a qualidade da ligação. Verificar os alvos e a perda de pacotes medida.
As sessões existentes são interrompidas durante a mudança: o Source IP público ou o estado NAT é alterado. Por esse motivo, os sistemas remotos podem rejeitar a ligação. O failover WAN não garante automaticamente Zero Downtime.
O tráfego de saída funciona, mas os serviços de entrada não: o segundo fornecedor necessita da acessibilidade pública adequada, DNS ou Dynamic DNS, DNAT, regras de firewall e, se necessário, certificados. DNAT para servidores publicados e os fundamentos de NAT ajudam a distinguir estas causas.
A VPN só funciona através da ligação principal: Remote Gateway, endereço local de escuta, FQDN, identidades, configuração do túnel e rota de retorno também têm de ser adequados ao caminho de Backup. Um failover WAN simples não cria uma segunda ligação VPN.

Se aplicações, grupos de utilizadores ou redes de destino tiverem de utilizar ligações diferentes, ou se a seleção do caminho depender da latência, do jitter e da perda de pacotes, esta decisão deve ser configurada em Rotas e Profiles SD-WAN no Sophos Firewall. Para uma ligação móvel de reserva, é ainda necessário considerar o SIM, APN, volume de dados, CGNAT e qualidade do sinal; estes pontos são explicados em Cellular WAN e failover 4G/5G.

Operação

Se necessário, enviar alterações do estado dos gateways por e-mail. Para isso, começar por configurar o Mail Server, o Sender e os Recipients em Administration > Notification settings. Em seguida, ativar o switch global Email notifications em System services > Notification list e selecionar o evento Gateway status em System. A seleção de uma linha de evento, por si só, ainda não envia qualquer e-mail.
Verificar o estado dos gateways e dgd.log após comutações não planeadas.
Testar o failover e o failback pelo menos trimestralmente e após alterações no fornecedor, nas interfaces, NAT, routing ou firmware.
Documentar dependências de endereços IP públicos, peers VPN, allowlists e serviços de entrada.
Definir os responsáveis por falhas do fornecedor, escalamento e regresso ao funcionamento normal.
Verificar regularmente os alvos de teste; um alvo permanentemente alterado ou que deixou de estar acessível não pode determinar a lógica de comutação sem que isso seja detetado.
Com várias ligações ativas, verificar os pesos e a Session Persistence com base na utilização real, e não apenas na largura de banda nominal.