Configurar Alta Disponibilidade (HA) no Sophos Firewall

Alta Disponibilidade, ou HA, liga dois Sophos Firewalls num cluster. Na maioria dos ambientes, Active-Passive com QuickHA é a melhor opção: um firewall processa o tráfego e o segundo assume o serviço em caso de falha ou manutenção. Antes de começar, os dois equipamentos, builds de firmware, licenças, cablagem e acesso de administração têm de ser compatíveis.

Este artigo acompanha o processo desde a escolha do modo HA até à configuração, teste de failover, operação e RMA. HA não substitui um bom desenho de rede nem cópias de segurança.

Escolher o modo HA e a arquitetura

Na maioria dos ambientes de produção, Active-Passive é a melhor variante HA. Um firewall processa todo o tráfego e o segundo fica preparado para assumir o serviço em caso de falha ou manutenção. O desenho é mais simples, o licenciamento é mais económico e o comportamento em caso de falha é mais fácil de compreender.

Active-Active só se justifica quando as suas limitações são aceites de forma consciente. Não se trata de um load balancing simétrico clássico, no qual ambos os firewalls ocupam uma posição equivalente em toda a rede. A Primary Firewall continua a receber o tráfego e distribui determinadas ligações para a Auxiliary Firewall. Nem todos os serviços e tipos de tráfego são distribuídos.

Orientação rápida:

• Máxima estabilidade e operação simples: Active-Passive.
• Utilizar o segundo firewall sem licenças de proteção separadas: Active-Passive.
• É necessário mais débito para determinadas ligações TCP: Avaliar Active-Active.
• Muitos casos de VPN, proxy, RED, NDR ou situações especiais: Preferir Active-Passive.
• Ambiente pequeno ou médio sem um problema claro de desempenho: Active-Passive.
• Requisito de desempenho claro e licenças adequadas para ambos os appliances: Active-Active após testes.

Os dois Sophos Techvids mostram visualmente a configuração e as mudanças de função:

O que significa Alta Disponibilidade

Um cluster HA do Sophos Firewall é composto por dois firewalls. Os equipamentos trocam heartbeats, estado, informações de ligação e dados de configuração através de uma ligação HA dedicada. A configuração é sincronizada da Primary Firewall para a Auxiliary Firewall.

HA protege contra falhas comuns:

• Falha da Primary Firewall
• Falha de energia ou hardware
• Falha de uma interface monitorizada
• Problema de software ou serviço que impede o funcionamento do equipamento
• Atualizações de firmware planeadas
• Mudança de função planeada durante a manutenção

No entanto, HA não resolve todos os problemas:

• Um conjunto incorreto de regras de firewall continua incorreto no cluster.
• A falha de um switch partilhado pode afetar os dois firewalls em simultâneo.
• Um desenho VLAN defeituoso ou um conceito de routing incorreto não são corrigidos automaticamente.
• Logs e reports não são totalmente sincronizados entre os firewalls.
• A cópia de segurança continua a ser obrigatória.

Antes de planear HA, devem estar claros os fundamentos de zonas, interfaces, VLANs, LAGs e bridges. Consultar Planear e configurar zonas e interfaces no Sophos Firewall.

Active-Passive ou Active-Active

Active-Passive

Com Active-Passive, um firewall processa todo o tráfego de produção. O segundo permanece passivo e apenas assume o serviço se o firewall ativo falhar ou se um failover for iniciado manualmente ou por manutenção.

Características habituais:

• A Primary Firewall processa o tráfego.
• A Auxiliary Firewall permanece em standby.
• As sessões são sincronizadas quando o respetivo serviço o suporta.
• Em appliances de hardware, apenas o equipamento titular necessita das subscrições de proteção.
• Durante um failover, a Auxiliary Firewall assume o serviço com o mesmo endereço MAC virtual.
• Em geral, os equipamentos de rede não precisam de reaprender os seus vizinhos.

Active-Passive é normalmente a melhor opção para empresas, filiais, centros de dados e ambientes onde a estabilidade é mais importante do que um possível ganho de desempenho.

Active-Active

Com Active-Active, ambos os firewalls processam tráfego. Ainda assim, a arquitetura permanece assimétrica: a Primary Firewall recebe o tráfego e decide se processa uma ligação ou se a encaminha para a Auxiliary Firewall.

A Sophos utiliza, entre outros critérios, o endereço IP de origem para a distribuição: as ligações TCP de endereços IP de origem pares são normalmente processadas pela Primary, enquanto as de endereços ímpares podem ser enviadas para a Auxiliary. São distribuídas as ligações TCP encaminhadas ou traduzidas. Não são distribuídos o tráfego não TCP, SD-RED e tunelizado, nem as ligações Layer 7 através de DPI ou proxy, incluindo SMTP Proxy, HTTPS, FTP analisado e H.323. A Sophos não suporta load balancers externos à frente do cluster para esta lógica HA.

Ambos os nodes necessitam de licenças adequadas e guardam localmente os logs do tráfego que processam. Por isso, Active-Active só faz sentido com um objetivo de desempenho claro e quando o tráfego relevante beneficia comprovadamente da distribuição. Para obter apenas alta disponibilidade, Active-Passive é normalmente a opção mais simples.

Funções, estado e failover

Funções no cluster HA

• Primary: Equipamento que mantém a configuração central do cluster. Em ambos os modos HA, a Primary recebe o tráfego.
• Auxiliary: Segundo equipamento do cluster. Sincroniza a configuração a partir da Primary e assume o serviço quando necessário.
• Initial primary: Equipamento iniciado como Primary durante a configuração. Em Active-Passive, é normalmente também o titular da licença.
• Preferred primary: Equipamento preferido que deve voltar a ser Primary após um failover quando estiver novamente disponível de forma estável.

Valores de estado durante a operação

• Active: O equipamento processa tráfego.
• Passive: O equipamento está preparado, mas não processa tráfego de produção em Active-Passive.
• Standalone: O equipamento não vê o peer ou HA não está totalmente ativo. Ambos os equipamentos podem ficar Standalone se a ligação HA falhar.
• Faulty: O equipamento não está suficientemente saudável para participar normalmente no cluster.

Endereço MAC virtual

O Sophos Firewall utiliza endereços MAC virtuais para as interfaces de produção num cluster HA. Apenas a Primary responde aos pedidos ARP do cluster. Durante um failover, a Auxiliary assume este endereço MAC virtual. Isto ajuda a manter a conectividade de switches, routers e clientes, porque a associação entre IP e MAC não muda de forma fundamental.

O Cluster ID é importante porque é utilizado para o endereço MAC virtual. Se existirem vários clusters HA no mesmo ambiente Layer 2, cada cluster tem de usar um Cluster ID único. Caso contrário, podem ocorrer conflitos de MAC.

O que é sincronizado

• Regras de firewall, policies, objetos, routing e configuração CLI são sincronizados da Primary para a Auxiliary.
• Sessões ativas são sincronizadas de acordo com o protocolo e o serviço.
• Secure Storage Master Key e credenciais WebAdmin são sincronizados.
• A Dedicated HA link não é sincronizada como uma configuração normal de interface de produção.
• A Peer Admin Port é tratada separadamente e não é sincronizada como uma interface normal.
• Logs e reports não são sincronizados entre os equipamentos.

Comportamento do failover

Vários eventos podem iniciar um failover:

• Deixam de ser recebidos heartbeats através da ligação HA
• Falha de uma porta monitorizada
• Falha de energia
• Falha de hardware
• Problema de software ou serviço
• Mudança de função planeada
• Atualização de firmware

Se um único Node iniciar em modo Failsafe, documentar primeiro a sua função e o estado do peer. Verificar uma Sophos Firewall em modo Failsafe mostra o comando de diagnóstico apenas de leitura e explica por que não se devem reiniciar os dois Nodes sem coordenação nem desativar HA com base apenas numa suspeita.

Os heartbeats passam pela ligação HA dedicada. Por predefinição, são utilizados intervalos muito curtos. Se faltarem vários heartbeats consecutivos, o peer é considerado inacessível. O firewall avalia então o estado e executa a mudança de função.

Muitas ligações continuam ou são restabelecidas rapidamente durante um failover. No entanto, o processo não é totalmente transparente para todas as aplicações. Em particular, ligações TCP stateful, sessões web, ligações proxy e determinados cenários VPN podem ser brevemente interrompidos ou ter de ser restabelecidos.

Serviços suportados e limitados

O Sophos HA suporta a maioria dos serviços de firewall, mas alguns têm características especiais.

• Regras de firewall e NAT são sincronizadas. Em Active-Active, é importante saber qual node processa uma ligação.
• VPN funciona em muitos cenários HA, mas nem todos os tipos de sessão mudam sem interrupção. IPsec consegue assumir tráfego UDP/ICMP stateless melhor do que TCP stateful.
• Web Protection funciona no cluster. Em Active-Active, podem surgir alertas de ambos os nodes.
• Email Protection pode gerir quarentena e libertação por node, porque cada equipamento guarda os seus próprios dados para o tráfego de email processado.
• Synchronized Application Control não é adequado para Active-Active quando a função não é suportada na versão SFOS utilizada.
• NDR Essentials só deve ser planeado com Active-Passive em ambientes HA.
• sFlow funciona apenas na Primary em ambientes HA.
• Reports são gerados localmente em cada equipamento. O Sophos Central Firewall Reporting é mais adequado para reports consolidados.
• Cellular WAN tem de ser desativado para HA.
• Os modelos XGS Wi-Fi não suportam HA.

Se o reporting ou a retenção de logs forem importantes, deve planear-se antecipadamente a utilização de um servidor syslog externo ou do Sophos Central Firewall Reporting. Consultar Ativar o Central Firewall Reporting.

Requisitos e desenho de rede

Antes da implementação, os requisitos HA devem ser cuidadosamente comparados com o ambiente. Pequenas diferenças de modelo, firmware, interfaces, Cellular WAN ou plataformas virtuais podem ter consequências importantes.

Compatibilidade de hardware e modelos

• Modelo do appliance: Ambos os firewalls têm de ser do mesmo modelo XGS, por exemplo XGS 2100 com XGS 2100.
• Revisão de hardware: São possíveis revisões de hardware diferentes no mesmo modelo XGS.
• Modelos XGS Wi-Fi: Não suportados. Exemplos: XGS 126w e XGS 136w.
• Flexi Port Modules: Se forem utilizados módulos de expansão, ambos os equipamentos têm de ter o mesmo número de Flexi Ports.
• Firmware: Ambos os equipamentos têm de executar a mesma versão SFOS, incluindo Maintenance Release e build.
• Hardware com appliance virtual: Não podem formar um par HA.

O SFOS 22 já não suporta hardware XG ou SG Series. Antes de uma migração para o SFOS 22, estes equipamentos têm de ser substituídos por um appliance XGS suportado ou por uma plataforma virtual adequada.

Appliances virtuais e de software

Os appliances virtuais e de software também têm de corresponder rigorosamente.

• Plataforma: Mesmo tipo de appliance e plataforma SFOS.
• Hypervisor: Mesmo tipo de hypervisor.
• Recursos: Mesmo número de núcleos de CPU, recursos comparáveis e o mesmo número de interfaces de rede.
• Firmware: Mesma versão SFOS, incluindo o build.
• Endereços MAC: Em ambientes virtuais, a opção de endereços MAC atribuídos pelo hypervisor pode evitar a necessidade de Promiscuous Mode. Alterar esta opção provoca downtime.

Implementações cloud

Os ambientes cloud têm requisitos adicionais de plataforma. Routing, interfaces virtuais, endereços IP, Security Groups, UDRs e mecanismos de failover específicos da cloud têm de corresponder ao desenho em causa. A abordagem HA normal dos appliances não pode ser transferida sem validação para Azure, AWS ou outros ambientes cloud.

Antes de planear HA para um Sophos Firewall na cloud, deve consultar-se a documentação Sophos atual para a plataforma e a arquitetura da rede cloud.

Licenciamento e registo

O licenciamento HA varia conforme a plataforma e o modo HA. Há três perguntas essenciais: trata-se de hardware ou Virtual/Software? É utilizado Active-Passive ou Active-Active? Qual equipamento é o Initial Primary e, por isso, o titular da licença do cluster? Antes da implementação, estes pontos devem ser comparados com o estado das licenças, números de série e modo pretendido.

Principais pontos de licenciamento:

• Base Firewall: HA exige uma licença Base Firewall. Os appliances de hardware incluem esta licença por predefinição. Os appliances Virtual/Software têm de estar devidamente licenciados.
• Active-Passive Hardware: Apenas o Initial Primary necessita das subscrições de produção. A Auxiliary Firewall recebe uma cópia das subscrições e pode processar tráfego após um failover.
• Active-Active Hardware: Ambos os firewalls necessitam de licenças próprias compatíveis. Os tipos de licença têm de corresponder, embora as datas de expiração possam ser diferentes.
• Active-Passive Virtual/Software: Apenas a Primary necessita das licenças exigidas, incluindo Base Firewall.
• Active-Active Virtual/Software: Ambos os equipamentos necessitam de uma licença Base Firewall própria e das licenças de proteção adicionais adequadas.
• Registo de hardware: Ambos os equipamentos de hardware têm de ser claimed no Sophos Central antes da configuração HA e conseguir sincronizar as licenças.
• Registo Virtual/Software Active-Passive: Segundo a Sophos, em Active-Passive Virtual/Software apenas a Primary é claimed.
• Sophos Central Management: Sincronizar licenças e efetuar o claiming não significa automaticamente que os firewalls possam ser geridos através do Sophos Central Firewall Management. É necessária uma subscrição adicional adequada.
• RMA e suporte: O estado do suporte é importante para substituição de hardware e Advance Replacement. Para hardware Active-Passive, a Sophos identifica Enhanced Plus Support na Primary como um requisito relevante para Advance Hardware Replacement. Em Active-Active, ambos os equipamentos devem ter um estado de suporte adequado.

O Initial Primary é particularmente importante em Active-Passive porque este equipamento detém a licença do cluster. A vista HA indica qual equipamento possui a licença. Deve ser documentado de forma inequívoca no manual de operação.

Se as licenças Active-Active forem diferentes, o load balancing para durante um máximo de três dias. Se a diferença continuar, o firewall desativa HA. Durante a configuração inicial, Active-Active não é ativado se as licenças não corresponderem.

O Initial Primary tem de sincronizar as licenças pelo menos uma vez a cada 90 dias. Em hardware, as subscrições de proteção afetadas deixam de funcionar, enquanto Base Firewall e Enhanced Support permanecem ativos. Em Virtual/Software, a licença Base Firewall é desativada, HA é desativado e outras funções de proteção ficam inativas. Os clusters licenciados online necessitam, por isso, de DNS, hora do sistema correta, routing e acesso à Internet para os serviços de licenciamento Sophos. Os clusters isolados utilizam em alternativa o workflow manual documentado de licenciamento Air-Gap.

Documentar, no mínimo:

• Qual equipamento é o Initial Primary
• Que números de série ou appliance IDs pertencem ao cluster
• Que licenças estão ativas em cada equipamento
• Quando as licenças foram sincronizadas pela última vez
• Que nível de suporte está disponível para RMA ou Advance Replacement
• Quem aprova alterações de licença, renovações e processos RMA

Requisitos de rede

• Ligação HA: Ligação dedicada entre os dois firewalls, idealmente direta através de um cabo Ethernet.
• Zona da ligação HA: Zona DMZ com SSH ativado para a zona.
• Endereços IP da ligação HA: Endereços IP estáticos na mesma subnet, mas diferentes.
• Qualidade da ligação HA: Elevada largura de banda, baixa latência e sem perda de pacotes.
• Switches: Ativar RSTP nos switches ligados às portas do firewall.
• Monitored Ports: Monitorizar apenas portas ligadas e críticas.
• Cellular WAN: Desativar para HA.
• Peer Admin Port: Planear separadamente para manter a Auxiliary Firewall acessível.
• Endereços das interfaces: Active-Active exige endereços IP estáticos em todas as interfaces. Active-Passive permite DHCP ou PPPoE, mas estas ligações não têm session failover.

A ligação HA não transporta tráfego normal de clientes ou servidores. É utilizada apenas para heartbeats, estado, sincronização de sessões, sincronização da configuração e distribuição Active-Active. Ainda assim, é extremamente crítica. Se falhar, ambos os firewalls podem considerar-se Primary. Este cenário de split-brain tem de ser evitado.

A Peer Admin Port fornece acesso operacional separado à Auxiliary Firewall. As portas de administração de ambos os equipamentos têm de estar na mesma subnet, mas utilizar endereços IP diferentes. O QuickHA utiliza automaticamente a interface através da qual está ligada a sessão WebAdmin atual. Depois de HA ser estabelecido, a Auxiliary só fica acessível através do endereço Peer Admin a partir de uma rede adequada.

Portas e interfaces

• Dedicated HA link: Transporta heartbeats, estado e sincronização da configuração e das sessões. Ligar diretamente ou através de um switch muito fiável. Não utilizar para tráfego de produção.
• Monitored ports: Monitorizam ligações críticas de produção. Monitorizar WAN e uplinks importantes de DMZ ou core, mas não selecionar portas sem utilização.
• Peer Admin Port: Permite aceder ao WebAdmin da Auxiliary. Planear e documentar separadamente; o cliente tem de estar na subnet adequada.
• Interfaces de produção: Ligar LAN, WAN, DMZ, VLANs e LAGs de forma idêntica nos dois firewalls e desenhá-las de modo equivalente.

Podem ser utilizadas interfaces físicas, VLANs ou LAGs como Dedicated HA link. Interfaces Bridge e endereços Alias IP não podem ser utilizados como ligação HA dedicada. O QuickHA pode agrupar até quatro interfaces físicas não associadas numa HA redundant link; num LAG existente, as parent interfaces têm de estar configuradas de forma idêntica em ambos os appliances.

Importante: a Dedicated HA link e uma Monitored Port não podem ser a mesma interface. Se uma interface já utilizada por uma configuração de produção for selecionada como ligação HA, o firewall pode alterar ou remover configurações dependentes. A ligação HA deve, por isso, estar livre e documentada antecipadamente.

Desenho de rede

Ambos os firewalls têm de conseguir assumir a mesma posição na rede durante uma falha. Interfaces de produção, VLAN trunks, LAGs, switchports e ligações ao fornecedor devem, por isso, ser ligados de forma equivalente em ambos os lados. Redundância WAN, SD-WAN e failover do fornecedor continuam a ser tarefas distintas; HA não as substitui.

• Ligar a Dedicated HA link da forma mais direta possível. Se passar por switches, o caminho deve ser estável, com baixa latência e sem perda de pacotes.
• Ativar RSTP nos switches envolvidos e configurar VLANs, trunks e LAGs de forma idêntica em ambos os lados.
• Monitorizar apenas uplinks WAN, core ou DMZ permanentemente ligados. Uma Monitored Port desligada intencionalmente provocaria um failover.
• VLANs e LAGs são suportados, mas têm de utilizar as mesmas parent interfaces nos dois nodes. Bridge Mode funciona, mas é mais complexo de diagnosticar do que Gateway Mode.
• Testar separadamente os cenários VPN, RED e remotos, porque nem todas as sessões são transferidas de forma transparente.
• Restringir conscientemente o acesso de administração e Device Access. Consultar Proteger o acesso ao Sophos Firewall: configurar corretamente Device Access.

Em Active-Active, também tem de ser claro qual o bottleneck reduzido pelo tráfego elegível para distribuição TCP. Se o licenciamento, os serviços e o troubleshooting em ambos os nodes não estiverem definidos, Active-Passive continua a ser a melhor opção.

Aviso: Numa situação de split-brain, ambos os firewalls consideram-se responsáveis. Isto pode provocar utilização duplicada de IP e MAC e uma interrupção de produção. Se a ligação HA falhar, decidir primeiro qual node deve permanecer ativo e desligar o outro de forma controlada ou removê-lo da rede de produção.

Preparar a configuração

Não se deve improvisar na rede de produção antes de configurar HA. Esta preparação poupa muito tempo posteriormente.

Preparar ambos os firewalls

• Instalar a mesma versão SFOS, incluindo o build, em ambos os firewalls.
• Verificar o estado de licenciamento e registo.
• Desativar Cellular WAN.
• Confirmar que os modelos são compatíveis.
• Verificar a configuração dos Flexi Ports.
• Documentar interfaces e switchports.
• Selecionar a porta da ligação HA.
• Ligar diretamente a ligação HA ou verificar o caminho através dos switches.
• Planear a zona DMZ e o acesso SSH para a ligação HA.
• Documentar o acesso administrativo a ambos os equipamentos.
• Criar uma cópia de segurança da configuração existente.
• Se for necessário LINCE, alinhar o modo nos dois equipamentos antes de ativar HA.

FIPS segue uma sequência diferente de LINCE. O modo FIPS 140-3 é primeiro ativado no Primary standalone, o que executa um factory reset; durante o setup HA posterior, a Sophos ativa FIPS automaticamente no Auxiliary.

As cópias de segurança não são opcionais com HA. Deve existir uma cópia antes da configuração, das atualizações de firmware e de alterações importantes nas interfaces. Consultar Criar ou restaurar uma cópia de segurança do Sophos Firewall.

Antes de selecionar Initiate HA, verificar também:

• Admin Ports na mesma subnet, mas com endereços IP diferentes: Caso contrário, HA não pode ser estabelecido corretamente ou a Auxiliary não ficará acessível posteriormente.
• Dedicated HA link sem dependências de produção: HA pode alterar endereços IP das interfaces e configurações dependentes.
• Monitored Ports ligadas em ambos os equipamentos: Uma Monitored Port desligada pode impedir a formação do cluster ou provocar um failover imediato.
• Cluster ID único: Vários clusters HA na mesma área Layer 2 necessitam de endereços MAC virtuais diferentes.
• Backup, SSMK e firmware build documentados: O cluster tem de poder ser reproduzido durante restore, RMA ou reimage.

Definir LINCE antes de HA

Desde o SFOS 21.5 MR1, LINCE não pode ser ativado ou desativado depois de um cluster HA ter sido criado. Se a certificação for necessária, executar o seguinte comando na Device Console em ambos os firewalls ainda independentes.

Aviso: Garantir primeiro um acesso administrativo alternativo através do WebAdmin ou da consola local. O comando ativa LINCE, reinicia o serviço SSH e termina as sessões SSH existentes.

system certification lince enable

Em seguida, verificar o estado LINCE em ambos os equipamentos e só depois criar HA. Durante um restore, o backup e o cluster de destino têm de ter o mesmo estado LINCE.

QuickHA ou Interactive mode

• QuickHA: Situação padrão. Rápido, robusto e suficiente para a maioria das configurações Active-Passive e Active-Active.
• Interactive mode: Útil quando Admin Ports, endereços da ligação HA, Cluster ID, Monitored Ports e valores detalhados têm de ser definidos antes da criação do cluster.

O QuickHA pede inicialmente apenas a função, nome do node, passphrase e Dedicated HA link. A passphrase tem de ter entre 10 e 20 caracteres e incluir pelo menos uma letra maiúscula, uma minúscula, um número e um carácter especial. É utilizada uma única vez para gerar as chaves SSH e depois eliminada. Após a substituição de um equipamento, HA tem, por isso, de ser desativado e reconfigurado.

Os passos seguintes baseiam-se na configuração HA oficial da Sophos, mas são apresentados como uma checklist prática para admins. Em alterações de produção, não basta percorrer o assistente: devem documentar-se antecipadamente as funções, ligação HA, acesso administrativo, backup, estado das licenças e caminho de rollback.

Configurar HA

Active-Passive com QuickHA

1. Preparar a Primary Firewall

1. Iniciar sessão no WebAdmin do firewall que será Primary.
2. Aceder a System services > High availability.
3. Selecionar Primary (active-passive) como modo.
4. Utilizar QuickHA.
5. Atribuir opcionalmente um nome ao node, por exemplo FW01.
6. Definir uma passphrase HA de 10 a 20 caracteres com letra maiúscula, minúscula, número e carácter especial.
7. Guardar temporariamente a passphrase de forma segura, porque será necessária de seguida na Auxiliary Firewall.
8. Selecionar a Dedicated HA link.
9. Selecionar Initiate HA.

Notas:

• Quando o QuickHA utiliza uma interface não associada, a Sophos atribui-lhe a zona DMZ e, por predefinição, 169.254.192.1. SSH é ativado automaticamente para a zona.
• O firewall remove as configurações dependentes da interface selecionada como ligação HA. Por isso, a interface tem de estar livre de dependências de produção.

2. Preparar a Auxiliary Firewall

1. Iniciar sessão no firewall que será Auxiliary.
2. Aceder a System services > High availability.
3. Selecionar Auxiliary como função.
4. Utilizar QuickHA.
5. Atribuir opcionalmente um nome ao node, por exemplo FW02.
6. Introduzir a mesma passphrase HA.
7. Selecionar a mesma porta de ligação HA utilizada na Primary.
8. Selecionar Initiate HA.

Depois de o cluster ser criado, a Primary Firewall sincroniza a configuração com a Auxiliary Firewall. Muitas definições locais da Auxiliary são substituídas. Por isso, antes da configuração HA, a Auxiliary não deve ser configurada em paralelo como firewall de produção independente.

3. Verificar definições avançadas

Após a criação do cluster, verificar os seguintes pontos:

• Estado HA de ambos os nodes
• Função e estado no canto superior direito do WebAdmin
• Dedicated HA link
• Monitored Ports
• Peer Admin Port
• Preferred primary
• Keepalive interval e Attempts
• Titular da licença em Active-Passive
• Registo no Sophos Central, se utilizado

4. Definir Monitored Ports

As Monitored Ports determinam se a falha de uma interface provoca um failover. Candidatos habituais:

• Uplink WAN
• Uplink LAN core
• Uplinks importantes de DMZ ou servidores

Não se devem monitorizar portas que ficam intencionalmente offline, não estão ligadas ou são utilizadas apenas em cenários opcionais. Uma Monitored Port selecionada incorretamente é uma causa comum de failovers inesperados ou de um cluster que não arranca.

Active-Active com QuickHA

Active-Active é configurado de forma semelhante, mas com um objetivo diferente. Ambos os firewalls têm de estar devidamente licenciados antecipadamente.

O processo é igual ao de Active-Passive, mas em FW01 seleciona-se Primary (active-active). Ambos os equipamentos têm de estar claimed, executar o mesmo SFOS build e ter tipos de licença compatíveis; todas as interfaces necessitam de endereços IP estáticos. Monitoring e troubleshooting têm de abranger ambos os nodes, e o tráfego relevante tem de beneficiar da distribuição TCP descrita acima.

Testar após a configuração

Em Active-Active, é necessário testar mais do que apenas o estado HA:

• As ligações são distribuídas por ambos os nodes?
• Os logs estão visíveis nos dois equipamentos?
• As ligações VPN funcionam após uma mudança de função?
• Web Protection, IPS, Application Control e as funções de segurança relevantes funcionam?
• Existem aplicações afetadas pelo comportamento assimétrico?
• Os reports e alertas são gerados conforme esperado?

Interactive mode

Interactive mode é útil quando a lógica automática do QuickHA não oferece controlo suficiente.

Motivos habituais:

• Têm de ser utilizados endereços IP fixos na ligação HA
• A Peer Admin Port tem de ser definida com precisão
• O Cluster ID tem de ser definido de forma consciente
• Existem vários clusters HA no mesmo ambiente Layer 2
• Os appliances virtuais necessitam de opções MAC específicas
• É necessário um rollout muito controlado

Em Interactive mode, configura-se primeiro a Auxiliary e depois a Primary. Assim, evita-se que a deteção do peer na Primary expire enquanto o segundo node ainda está a ser preparado.

1. Configurar a Auxiliary

1. Em FW02, aceder a System services > High availability.
2. Selecionar Initial device role > Auxiliary e HA configuration mode > Interactive mode.
3. Definir o nome do node e uma passphrase que cumpra as regras anteriores.
4. Selecionar a porta DMZ livre para a Dedicated HA link. O firewall remove as configurações dependentes existentes desta interface.
5. Guardar e aguardar a confirmação de que a configuração Auxiliary foi aplicada.

2. Configurar a Primary

1. Em FW01, selecionar Primary (active-passive) ou Primary (active-active) e Interactive mode.
2. Definir um Cluster ID único e o nome do node.
3. Introduzir a passphrase de FW02.
4. Indicar a mesma Dedicated HA link e o endereço IP estático da ligação HA da Auxiliary.
5. Selecionar as Monitored ports críticas.
6. Em Peer administration settings, indicar a interface de administração e um endereço IP próprio para FW02.
7. Em appliances virtuais, selecionar se necessário o endereço MAC atribuído pelo host ou hypervisor. Uma alteração posterior provoca downtime.
8. Definir Preferred primary e selecionar Initiate HA.

Depois de criar o cluster, alterar os valores keepalive apenas por um motivo documentado. Por predefinição, o firewall envia um heartbeat a cada 250 milissegundos e considera o peer inacessível após 16 heartbeats em falta.

Validar o cluster

Depois da configuração, o cluster HA deve ser validado sistematicamente.

Verificação no WebAdmin

1. Iniciar sessão na Primary Firewall.
2. Verificar o estado HA no canto superior direito.
3. Aceder a System services > High availability.
4. Verificar funções, estado, números de série e modo.
5. Confirmar que o cluster está sincronizado.
6. Em Active-Passive, verificar qual equipamento detém a licença do cluster.

Verificação por CLI

Na Device Console, o seguinte comando read-only mostra as funções, o estado e a sincronização do cluster. Não altera a configuração:

system ha show details

O Initial Primary titular da licença deve ser verificado principalmente em System services > High availability. Num caso de suporte documentado, o seguinte valor interno read-only na Advanced Shell pode fornecer informação adicional:

nvram get "#li.master"

YES identifica normalmente o Initial Primary e NO a Auxiliary. A Sophos não documenta este comando interno da Advanced Shell como uma interface de administração regular; por isso, a vista HA continua a ser a referência.

Se o acesso à shell ainda não estiver preparado, consultar Ligar ao Sophos Firewall através de SSH.

Teste funcional

• Testar o acesso à Internet a partir de um cliente LAN.
• Testar o acesso a servidores internos.
• Testar VPN.
• Testar cenários DNAT ou WAF.
• Testar DNS e DHCP se o firewall fornecer estes serviços.
• Verificar os logs no Log Viewer.
• Testar uma mudança de função HA durante uma janela de manutenção.
• Documentar depois as funções, o estado e o comportamento das sessões.

Operação e manutenção

Monitorização contínua

Monitorizar o estado HA e das funções, a Dedicated HA link, as Monitored Ports, licenças, firmware, CPU, RAM, disco e serviços centrais. Enviar alertas para o Sophos Central, por email ou para a plataforma de monitorização existente.

Para questões de disco e hardware, considerar ambos os nodes separadamente. Reports locais, ficheiros de log e o estado do SSD podem ser diferentes. Consultar Verificar o armazenamento do Sophos Firewall e gerir reports e Verificar o estado do SSD do Sophos Firewall com SMART.

Logs e reports

Cada node escreve logs do tráfego que processa. Em Active-Active, ambos os equipamentos têm de ser verificados. O Sophos Central Firewall Reporting ou syslog são adequados para uma análise consolidada. Os ficheiros locais são explicados em Resolução de problemas do Sophos Firewall: serviços e logs.

Runbook para a operação HA

Documentar, no mínimo, no runbook de operação:

• Número de série, localização, posição no rack e função de ambos os appliances.
• Dedicated HA link, Peer Admin Port, Cluster ID e Monitored Ports.
• Preferred primary e comportamento esperado após failover.
• Titular da licença, estado do suporte e contacto para RMA.
• Processo e responsabilidade por atualizações de firmware, backup, reimage, substituição de hardware, logs e casos de suporte.

Se o WebAdmin não responder apenas num node, isso não significa automaticamente que todo o cluster HA esteja avariado. Verificar primeiro se basta reiniciar a GUI do WebAdmin ou efetuar um reinício controlado de serviços antes de iniciar um failover ou reboot.

Alterações no cluster

Alterar regras, interfaces e policies apenas na Primary. Antes de alterar interfaces, VLANs, LAGs, zonas, routing, NAT, VPN, Device Access ou SD-WAN:

• Criar uma cópia de segurança.
• Definir uma janela de manutenção.
• Verificar o estado HA.
• Atualizar a documentação.
• Definir um caminho de rollback.
• Testar depois a sincronização e o tráfego.

Atualizações de firmware e cópias de segurança

Atualizações de firmware em ambientes HA

As atualizações de firmware são iniciadas na Primary Firewall. Os equipamentos são atualizados sequencialmente e o cluster pode mudar de função durante o processo.

Processo habitual:

1. Iniciar a atualização na Primary Firewall.
2. A Auxiliary Firewall é atualizada.
3. A Auxiliary Firewall reinicia e assume temporariamente o serviço.
4. A antiga Primary é atualizada.
5. A antiga Primary reinicia.
6. Se Preferred primary estiver ativo, pode ocorrer o regresso ao equipamento preferido.

As atualizações de firmware devem, ainda assim, ser efetuadas numa janela de manutenção. Embora o processo seja concebido para minimizar a downtime, determinadas sessões, ligações VPN ou aplicações especiais podem reagir brevemente.

Consultar Atualização de firmware do Sophos Firewall: preparação e boas práticas.

Pattern Updates

Os Pattern Updates são instalados na Primary e sincronizados automaticamente com a Auxiliary. Isto também se aplica a ambientes onde as atualizações são controladas ou instaladas offline.

Num ambiente HA isolado, deve ficar claro qual node é o Initial Primary e qual é atualmente Primary antes de cada Pattern Update ou atualização manual de licença. O processo Air-Gap é descrito em Operar o licenciamento Air-Gap e os Pattern Updates do Sophos Firewall.

Backup e restore

Backup e restore têm particularidades em ambientes HA:

• Criar backups regularmente e antes de cada alteração importante.
• Efetuar o restore na Primary Firewall atual.
• Após um restore, ambos os firewalls são removidos do registo do Sophos Central e têm de ser registados novamente.
• Um restore provoca reinício e downtime, não um failover normal.
• Restaurar num cluster HA um backup sem configuração HA desativa HA, que tem depois de ser reconstruído.
• Se LINCE estiver ativo, o backup e o cluster de destino têm de ter o mesmo estado LINCE.

Se o cluster utilizar Sophos Central Synchronized Security, o par HA tem de ser removido da gestão do Central antes de o equipamento ser devolvido através do processo RMA. Após a substituição, o novo cluster HA é novamente registado no Central. Isto evita conflitos na sincronização de números de série e licenças com o equipamento antigo que ainda permanece registado.

Substituir a Auxiliary após RMA

Substituir ou efetuar reimage de um node provoca uma interrupção planeada. Os processos seguintes aplicam-se a Active-Passive; em Active-Active, o procedimento concreto deve ser planeado com o Sophos Support.

1. Verificar se o modelo e a revisão de hardware do equipamento de substituição são adequados e instalar exatamente o mesmo firmware build da Primary saudável.
2. Efetuar o claim do equipamento de substituição no Sophos Central e transferir a licença do equipamento Auxiliary avariado.
3. Mudar os cabos do equipamento avariado para o equipamento de substituição.
4. Na Primary saudável, desativar HA em System services > High availability.
5. Na Advanced Shell, verificar se msync terminou:

service -S | grep msync

O estado esperado é UNTOUCHED ou STOPPED. O comando não altera nada; outro estado significa que HA ainda não deve ser reconstruído. Em seguida, voltar a configurar a Primary saudável como Primary e o equipamento de substituição como Auxiliary.

Substituir a Primary após RMA

1. Transferir um backup atual da Auxiliary saudável e remover o equipamento do registo do Sophos Central.
2. Instalar o mesmo firmware build no equipamento de substituição, efetuar o claim no Sophos Central e transferir a licença da Primary avariada.
3. Restaurar o backup no equipamento de substituição.
4. Mudar os cabos da Auxiliary saudável para o equipamento de substituição. A partir desse momento, o equipamento de substituição processa o tráfego como firewall standalone.
5. Repor a antiga Auxiliary nas Factory Settings, efetuar novamente o claim no Sophos Central e ligar os cabos previstos.
6. Reconstruir HA com o equipamento de substituição como Primary e o equipamento reposto como Auxiliary.

Aviso: Backup/restore, Factory Reset e mudanças de cabos provocam downtime. Antes de começar, documentar números de série, Initial Primary, firmware build, transferência de licença, estado no Central e caminho de rollback.

Para a reinstalação técnica, consultar Reinstalar o Sophos Firewall OS: reimage com uma pen USB. Se existir uma avaria de hardware ou um processo RMA, planear também Preparar corretamente uma avaria de hardware e RMA Sophos.

Resolução de problemas

Em falhas complexas, deve trabalhar-se de forma metódica: verificar primeiro estado, ligação HA, Monitored Ports, versão de firmware e estado das licenças; só depois analisar casos especiais ou recomendações do fabricante. Assim, fica claro se o problema está realmente relacionado com HA ou se é causado por licenciamento, uma interface, firmware ou monitorização.

Logs e locais de diagnóstico importantes

• Estado HA: System services > High availability.
• Event Logs: Log viewer > System.
• Troubleshooting Logs: Monitor & Analyze > Logs > Troubleshooting logs ou através de SSH em /log.
• Detalhes HA por CLI: Consultar a verificação CLI única em Validar o cluster.
• Problemas de interface: show network interfaces, ifconfig, dmesg nos casos de diagnóstico adequados.
• Titular da licença: System services > High availability.

Os seguintes ficheiros são particularmente úteis para o diagnóstico inicial:

• ha.log: Erros de configuração, criação HA bem-sucedida e mudanças de estado.
• ha_pair.log: Deteção do peer no QuickHA.
• ha_tunnel.log: Túnel SSH através da Dedicated HA link.
• msync.log: Sincronização da configuração HA.
• ctsyncd.log: Sincronização de sessões Conntrack.
• filesync.log: Sincronização de ficheiros relacionada com serviços, por exemplo para rotas dinâmicas ou DHCP.

Cada node guarda apenas os logs e reports do tráfego que processa. Para aceder à Auxiliary, iniciar sessão através do respetivo endereço Peer Admin ou consultar os ficheiros de log por SSH nesse node.

Para uma análise mais profunda, consultar Resolução de problemas CLI no Sophos Firewall: comandos importantes.

Sintomas HA comuns

• O cluster não se forma; a versão ou o build do firmware é diferente: Verificar a versão em ambos os equipamentos e instalar a mesma versão SFOS nos dois firewalls.
• O cluster não se forma; o modelo ou appliance não corresponde: Verificar o modelo e o número de série. Para HA de hardware, utilizar apenas modelos XGS idênticos e compatíveis.
• HA could not be enabled: A Dedicated HA link pode não estar ligada ou o peer pode estar inacessível. Verificar o estado da porta, cabo, switch e ping para o IP da ligação HA; depois estabilizar a cablagem ou a ligação HA.
• Ligação HA down: O cabo, switchport, VLAN ou LAG pode estar avariado. Verificar estado da interface, speed/duplex, VLAN trunk e membros LAG.
• Ambos os equipamentos ficam Standalone: A ligação HA falhou e existe risco de split-brain. Verificar a ligação física e o caminho através dos switches, desligar um equipamento de forma controlada, reparar a ligação HA e reiniciar depois.
• WebAdmin da Auxiliary inacessível: Peer Admin Port, subnet, rota ou Device Access não correspondem. Verificar o IP da Admin Port e o acesso a partir da rede de administração.
• Validation failed for HA interface IP: As Admin Ports ou os endereços da ligação HA não estão na subnet esperada. Verificar os endereços IP e /log/syslog.log, e corrigir o endereçamento.
• Failover inesperado: Frequentemente, uma Monitored Port falhou ou foi selecionada incorretamente. Verificar as Monitored Ports e o estado do switch; monitorizar apenas portas realmente críticas e estáveis. Se o node afetado reiniciou realmente e não mudou apenas de função, deve verificar-se o reinício inesperado nesse node.
• O failover não ocorre: Provavelmente a porta relevante não está monitorizada. Adicionar portas WAN, core ou DMZ críticas como Monitored Ports.
• Active-Active não distribui como esperado: O tipo de tráfego pode não ser load-balanced. Verificar tipo de ligação, protocolo e logs de ambos os nodes; se o benefício não for claro, utilizar Active-Passive ou adaptar o desenho.
• Parece que faltam logs: O tráfego pode ter sido processado pelo outro node ou o logging pode estar desativado. Verificar ambos os nodes e o Log Viewer, ativar logging nas regras e utilizar Central Reporting ou syslog.
• Os reports são diferentes: Os reports locais dependem do node. Comparar os reports dos dois equipamentos ou utilizar o Sophos Central Firewall Reporting.
• Problema de licença em Active-Active: Os tipos de licença podem não corresponder. Verificar Licensing em ambos os firewalls e alinhar as licenças.
• Problemas após uma atualização de firmware: Um node pode não ter sido atualizado corretamente ou o cluster pode não estar sincronizado. Verificar estado HA, versões de firmware e logs; utilizar uma janela de manutenção em clusters de produção e envolver o Sophos Support.
• A ligação HA Flexi Port não funciona: Speed/duplex ou auto-negotiation podem não corresponder. Verificar Interface Advanced settings em ambos os equipamentos e configurar os dois lados de forma idêntica ou utilizar uma porta fixa.

Procedimento em caso de falha da ligação HA

Se a ligação HA dedicada falhar, deve proceder-se com cuidado. Os firewalls deixam de se ver. No pior caso, ambos os equipamentos enviam ARP/GARP e tentam reclamar o MAC do cluster.

Procedimento seguro:

1. Estabilizar o estado da rede.
2. Decidir qual equipamento deve permanecer ativo.
3. Desligar o outro equipamento de forma controlada ou removê-lo da rede de produção.
4. Reparar o cabo, switchport, VLAN ou LAG da ligação HA.
5. Reiniciar o equipamento.
6. Verificar o estado HA.
7. Verificar logs e funções.

Comandos CLI adicionais

Além da consulta do estado HA em Validar o cluster, o seguinte comando read-only na Device Console mostra

show network interfaces

o estado das interfaces e ligações. São esperados estados UP para a Dedicated HA link e as Monitored Ports ligadas.

Para link flaps, aceder à shell através de Device Management > Advanced Shell e substituir PortE pelo nome real da interface:

dmesg | grep PortE

O output filtra mensagens do kernel para esta interface. Mensagens repetidas de link-up/link-down indicam problemas de cabo, transceiver, porta ou negociação. O comando não altera nada, mas dmesg contém apenas o buffer atual do kernel e não substitui uma análise de logs a longo prazo.

A análise física completa com ethtool, dados do módulo e casos especiais conhecidos está explicada em Selecionar e verificar SFP e SFP+ no Sophos Firewall.

Antes de qualquer intervenção mais profunda, guardar primeiro os outputs e timestamps. Os comandos foram verificados com a documentação Sophos atual, mas não foram executados no hardware específico do cliente.

Checklist de entrada em produção

• Active-Passive ou Active-Active escolhido com uma justificação documentada.
• Modelos, Flexi Ports, SFOS build, estado LINCE, claiming e licenças verificados.
• Backup e caminho de rollback disponíveis.
• Dedicated HA link livre, estável e ligada da forma mais direta possível.
• VLANs, LAGs, switchports e RSTP consistentes em ambos os lados.
• Acesso Peer Admin à Auxiliary testado.
• Apenas interfaces estáveis e críticas selecionadas como Monitored Ports.
• Cluster ID, Initial Primary, Preferred primary e números de série documentados.
• WebAdmin, estado CLI e logs relevantes verificados.
• LAN, Internet, servidores, VPN, DNAT/WAF, DNS e DHCP testados funcionalmente.
• Failover e retorno testados numa janela de manutenção.
• Processos de monitorização, firmware, restore e RMA registados no runbook.

Perguntas frequentes

Fontes oficiais: Registo e licenças · LINCE em ambientes HA · RMA num cluster Active-Passive · FAQ de HA