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

Recomendação operacional da Avanet: 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. Trata-se de uma recomendação de arquitetura, não de um requisito da Sophos.

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 sincronizados entre os dois 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.
• Quando é utilizado o MAC virtual do cluster, a Auxiliary Firewall assume o serviço com o mesmo endereço MAC virtual durante um failover.
• Neste caso, os equipamentos de rede geralmente 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 o endereço IP de origem para a distribuição: as ligações TCP elegíveis de endereços IP de origem pares são processadas pela Primary, enquanto as de endereços ímpares são enviadas para a Auxiliary. São distribuídos o tráfego TCP encaminhado e as ligações TCP traduzidas, incluindo SNAT e tráfego Virtual Host, também através de interfaces VLAN. Depois de processar uma ligação, a Auxiliary envia os pacotes diretamente para o destino, e não de volta através da Primary. Este método par-ímpar é fixo e não pode ser alterado. O suporte Layer 7 é diferenciado: segundo a Sophos, DPI Engine, proxies transparentes, diretos e Parent Proxies, bem como tráfego SMTP Proxy e HTTPS, são elegíveis para load balancing. FTP analisado e H.323 não são. Também são excluídos o tráfego não TCP, como UDP, ICMP, multicast e broadcast, SD-RED e tráfego TCP e não TCP tunelizado, incluindo VPN. Load balancers externos não são suportados para 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. Esta propriedade mantém-se independentemente de o node estar atualmente Active ou Passive.
• Preferred primary: Equipamento preferido que deve voltar a ser Primary após um failover quando estiver novamente disponível de forma estável.

No modo Active-Passive, o WebAdmin na Auxiliary não mostra Live users, DHCP leases nem ligações IPsec ativas. Este é o comportamento esperado e não comprova uma falha de sincronização. A Primary atualmente ativa é a referência para estes dados de runtime.

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

Quando é utilizado o MAC virtual do cluster, o SFOS atribui endereços MAC virtuais às interfaces físicas, exceto à Dedicated HA Link e às portas de administração. A Dedicated HA Link utiliza o seu próprio endereço MAC físico. Apenas a Primary responde aos pedidos ARP do cluster. Durante um failover, a Auxiliary assume o endereço MAC virtual da respetiva interface de produção. 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. A opção de MAC de interface descrita abaixo é outra variante; não se deve presumir o mesmo comportamento de transferência do MAC virtual.

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. Em Active-Active, ambos os equipamentos trocam o estado e os detalhes das sessões ativas com o peer; a sincronização da configuração, por sua vez, continua a ocorrer da Primary para a Auxiliary.
• Secure Storage Master Key e credenciais WebAdmin são sincronizados.
• Segundo a fonte oficial sobre modos e funções HA, a Dedicated HA link e as portas de administração estão excluídas da sincronização da configuração. As instruções contraditórias sobre o endereçamento de administração são explicadas em Requisitos de rede.
• Logs e reports não são sincronizados entre os equipamentos.

Comportamento do failover

Em Active-Passive, a Auxiliary assume todo o tráfego se a Primary falhar. Em Active-Active, a falha de qualquer um dos dois equipamentos ativos pode levar o peer saudável a assumir o serviço. Se a Auxiliary falhar, a Primary processa sozinha todo o tráfego; isto não implica necessariamente uma mudança de função. Quando um peer deixa de estar disponível, o equipamento restante funciona como Standalone. Por isso, este estado, por si só, não comprova uma falha da ligação HA em ambos os equipamentos; verificar as funções e a acessibilidade dos dois nodes antes de aplicar o runbook de split-brain.

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 descreve o procedimento de diagnóstico seguro 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 através da Dedicated HA Link são pedidos VRRP. O SFOS 22 usa por predefinição 250 ms e 16 heartbeats em falta, com um timeout de heartbeat de 4 segundos. O SFOS 23 usa por predefinição 100 ms e 3 tentativas, com 300 ms de timeout; as ligações HA baseadas em LAG exigem outros valores, como explicado abaixo. Estes timeouts não garantem o tempo de recuperação do tráfego. Nas Monitored Ports, porém, a falha de uma única porta é suficiente para considerar o equipamento indisponível e iniciar um failover.

Indicações divergentes de heartbeat para o SFOS 23: A descrição geral de failover continua a indicar 250 ms e 16 tentativas, enquanto as instruções detalhadas de configuração do SFOS 23 indicam 100 ms e 3 tentativas. Confirmar as predefinições do SFOS 23 no equipamento antes de alterar os valores. Antes de efetuar uma alteração em System services > High availability, documentar os valores efetivamente configurados e a topologia da ligação HA em ambos os nodes. Nem a indicação anterior nem a predefinição de configuração mais curta justificam alterar um cluster existente sem validação; se os valores não forem claros ou não cumprirem o requisito LAG, esclarecer o planeamento com o Sophos Support.

Após o failover, o WebAdmin na anterior Auxiliary Firewall mostra a configuração da Primary. Aplicam-se limites diferentes às sessões ativas:

Quando a Initial Primary regressa, permanece como Auxiliary no cluster se não estiver definida como Preferred primary. Se estiver definida como Preferred primary, o SFOS sincroniza primeiro os serviços e depois efetua automaticamente o failback. Durante este processo, o equipamento que até então funcionava sozinho reinicia. Este failback deve, por isso, ser planeado numa janela de manutenção. As mudanças de função e os reinícios descritos não garantem o processamento sem interrupções das ligações existentes.

Serviços suportados e limitados

O Sophos HA suporta a maioria dos serviços de firewall, mas os limites operacionais diferem significativamente:

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.

Para configuração, limites de segurança e testes, utilizar Configurar o mDNS reflector. A descoberta de serviços não concede acesso às aplicações; o suporte HA não garante sessões de aplicação sem interrupções. Esta afirmação sobre mDNS aplica-se a SFOS 23, não a SFOS 22.

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 Appliance, por exemplo XGS 2100 com XGS 2100.
• Revisão de hardware: São possíveis revisões de hardware diferentes no mesmo modelo XGS Appliance.
• Modelos XGS Appliance 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 e modelo de módulo Flexi Port.
• 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.

Importante: os módulos Flexi Port não podem ser trocados a quente. Para os adicionar, desligar de forma controlada ambos os firewalls, instalar o mesmo modelo de módulo nos dois equipamentos e reiniciar ambos. Em seguida, configurar os novos Flexi Ports apenas na Primary atual, em Network > Interfaces. O SFOS sincroniza esta configuração de portas com a Auxiliary. Não modificar apenas um nó enquanto o cluster estiver em funcionamento.

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 uma XGS Appliance suportada ou por uma plataforma virtual adequada.

Appliances virtuais e de software

Os appliances virtuais e de software também têm de corresponder rigorosamente. Exemplos de plataformas virtuais incluem Microsoft Hyper-V, VMware e Nutanix Prism; os appliances de software funcionam em hardware próprio. A referência a uma plataforma não dispensa a verificação dos requisitos HA seguintes.

• Plataforma: Mesmo tipo de appliance e plataforma SFOS.
• Hypervisor: Mesmo tipo de hypervisor.
• Recursos: Recursos de hardware atribuídos idênticos, incluindo o mesmo número de núcleos de CPU, bem como 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.

Se o cluster utilizar o endereço MAC virtual gerado pelo SFOS, a plataforma de virtualização tem de aceitar alterações de MAC. No VMware ESXi, definir MAC Address Changes e Forged Transmits como Accept no vSwitch ou port group; os port groups têm de herdar os valores do vSwitch ou ser configurados de forma correspondente. No Hyper-V, ativar Enable MAC address spoofing em todos os adaptadores de rede virtuais de ambos os firewalls, exceto no adaptador da Dedicated HA Link. Em alternativa, selecionar Use host or hypervisor-assigned MAC address no SFOS 22 ou Use interface MAC address no SFOS 23; em appliances virtuais ambas usam o MAC atribuído pelo hypervisor, pelo que estas alterações na plataforma deixam de ser necessárias. A opção do SFOS 23 também usa o MAC de interface em appliances de hardware em vez do MAC virtual do cluster. Ativá-la ou desativá-la atualiza a configuração de interfaces e 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.

Gateway, Bridge e Discover/TAP

HA está disponível nos modos gateway e bridge. O modo Discover ou TAP suporta apenas Active-Passive. Se pelo menos um nó funcionar em modo discover, não é possível criar um cluster Active-Active. Uma interface TAP ativa também impede a configuração Active-Passive. Desativar a interface TAP em ambos os firewalls através da CLI, estabelecer HA e voltar a ativar TAP individualmente em cada nó. TAP permanece ativo também na Auxiliary passiva.

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-na por predefinição, mas a licença termina quando o equipamento atinge o End of Life. Nos appliances cloud, virtuais e de software, a licença Base Firewall não expira, mas tem de estar presente para HA.
• 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: O claiming de ambos os equipamentos de hardware tem de ser efetuado no Sophos Fusion (anteriormente Sophos Central) antes da configuração HA, e ambos os equipamentos têm de 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: Advance Hardware Replacement exige Enhanced Plus Support na Primary de um cluster de hardware Active-Passive. Em Active-Active, cada equipamento exige Enhanced Support ou Enhanced Plus Support.

Gerir o par HA no Sophos Fusion

Um par HA pode ser ligado a switches da camada de acesso, incluindo Sophos Switches. O Sophos Fusion, anteriormente Sophos Central, permite a gestão centralizada dos firewalls e dos Sophos Switches. Isto não substitui um desenho de switches redundante: um switch partilhado pode continuar a afetar ambos os nodes. A visão geral mais antiga do SFOS 23 ainda utiliza o nome Sophos Central; daí não resulta uma arquitetura HA diferente.

Um par HA já criado é gerido no Sophos Fusion como um único par, não como dois firewalls independentes. Ambos os nós necessitam da mesma versão de firmware e, para Central Management, de acesso funcional à Internet por IPv4 e da subscrição adequada. O claiming e a sincronização de licenças, por si só, não ativam a gestão.

Quando dois firewalls já geridos individualmente no Sophos Fusion são unidos num par HA, a Sophos recomenda deregistar primeiro ambos. Estabelecer HA localmente, registar novamente o par concluído para Central Management e, se necessário, movê-lo para outro grupo no Central.

Na Primary atual, abrir System > Sophos Central e selecionar Register both HA devices. Em seguida, ativar Central Management e, no Sophos Fusion em My Products > Firewall Management > Firewalls, abrir Approval Pending para a Primary e confirmar accept-services. Após alguns minutos, o par deve aparecer uma única vez com o ícone HA; as alterações efetuadas no Sophos Fusion passam então a aplicar-se a ambos os firewalls.

O estado no Central não substitui a validação local. Após o registo, verificar localmente as funções HA, a sincronização, o estado das licenças e uma comparação de configuração sem impacto. Se aparecerem duas entradas independentes ou Approval Pending persistir, não deregistar preventivamente nenhum dos firewalls. Comparar primeiro números de série, tenant Central, caminho IPv4 e estado HA local.

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.

Licença no firewall errado – apenas Active-Passive: Se as subscrições Active-Passive tiverem sido atribuídas por engano à Auxiliary em vez da Initial Primary detentora das licenças, a sincronização não é suficiente. Antes de qualquer alteração, documentar o número de série de origem da Auxiliary licenciada por engano e o número de série de destino previsto da Initial Primary, separadamente das funções HA atuais, e conferir estes dados no SFOS e no Sophos Fusion. Este procedimento abreviado de correção só se aplica quando a Primary atual e a Initial Primary são o mesmo equipamento físico. Se forem equipamentos diferentes ou a correspondência não for clara, parar antes de desativar HA ou transferir licenças e esclarecer o procedimento adequado com base nas instruções Sophos ou com o Sophos Support; não improvisar uma mudança de função para regressar à configuração anterior. Só quando a correspondência for inequívoca, desativar HA de forma planeada na Primary atual, transferir as subscrições no Sophos Fusion do número de série de origem documentado para o número de série de destino documentado da Initial Primary e voltar a configurar o cluster Active-Passive. As transferências de licenças também são relevantes para RMA ou mudanças de modelo, mas exigem o procedimento aplicável ao caso concreto. Como os modelos HA têm de ser idênticos, ambos os equipamentos têm de ser substituídos numa mudança de modelo. Em Active-Active, a Auxiliary também tem de possuir as suas próprias licenças. Isto não é um erro e não deve ser corrigido com esta transferência. Não reutilizar este procedimento Active-Passive para RMA Active-Active sem instruções Sophos aplicáveis.

Licenças Active-Active expiradas ou não sincronizadas podem parar o load balancing e desativar HA. Para hardware e Virtual/Software, a Sophos descreve de forma contraditória o início da paragem: o resumo situa-o no fim de três dias, enquanto os detalhes o situam nos primeiros três dias e a desativação HA depois. O início exato continua por esclarecer; não existe um período de tolerância garantido de três dias. Corrigir prontamente os problemas de licenças e, se necessário, acordar com Sophos Support um plano operacional seguro para o build instalado. Durante a configuração inicial, Active-Active não é ativado se as licenças não corresponderem.

Em Active-Passive, sincronizar as licenças da Primary. O Initial Primary detentor das licenças tem de as sincronizar pelo menos uma vez a cada 90 dias. Caso essa sincronização não seja efetuada, 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.

Em Active-Active, em hardware e Virtual/Software, sincronizar individualmente as licenças dos dois equipamentos com Sophos Fusion e verificar o sucesso na Primary e na Auxiliary. Tipos de licença correspondentes e a posse de licenças não substituem este passo. Em hardware, Base Firewall e Enhanced Support permanecem ativos durante os problemas de licenças descritos; em Virtual/Software, uma licença Base Firewall desativada desativa HA e torna as outras licenças inativas. Não utilizar a indicação não esclarecida de três dias como intervalo de sincronização.

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 com sucesso pela última vez; em Active-Active, registar o estado e a hora separadamente para ambos os nós
• 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, DHCP Prefix Delegation ou PPPoE. A ligação PPPoE não tem session failover.

Em Active-Passive, as interfaces de produção podem utilizar DHCP, DHCP Prefix Delegation ou PPPoE, mas a Dedicated HA Link e ambas as portas de administração continuam a exigir endereços estáticos; para os endereços de administração, cumprir a verificação prévia da contradição documental descrita abaixo. Em Active-Active, todas as interfaces têm de usar endereços estáticos. A limitação documentada de PPPoE não estabelece uma exceção geral de session failover para interfaces DHCP: a atribuição de endereços e o tráfego do protocolo DHCP são distintos da preservação de sessões TCP encaminhadas. Aplicar os limites por protocolo e serviço indicados acima, sem presumir uma garantia geral de preservação das sessões em interfaces DHCP.

As interfaces breakout são configuradas na Primary. Ao criar uma nova configuração breakout, reiniciar primeiro a Primary para aplicar a alteração e, em seguida, reiniciar a Auxiliary. Se a configuração breakout correspondente já existir na Primary, reiniciar apenas a Auxiliary após a sincronização. Se não existir uma configuração breakout correspondente na Primary, a sincronização elimina uma configuração breakout existente apenas na Auxiliary. Os diferentes casos são explicados em Configurar interfaces breakout.

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. Não pode ser reutilizada para HSRP, porque as mensagens hello HSRP não atravessam o Dedicated HA Link. 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. O QuickHA utiliza automaticamente a interface da sessão WebAdmin atual; após estabelecer HA, o acesso à Auxiliary através do endereço Peer Admin exige um endpoint na mesma subnet. As instruções oficiais sobre endereçamento de administração contradizem-se: a fonte sobre modos e funções HA exclui a Dedicated HA link e as portas de administração da sincronização, e os requisitos de interfaces HA exigem dois endereços IP de administração/gestão estáticos, diferentes e na mesma subnet. Porém, o guia inicial da porta de gestão proíbe endereços PortMGMT diferentes em HA, alegando que a configuração é sincronizada. Um IP PortMGMT partilhado com um IP Peer Administration adicional não constitui uma reconciliação estabelecida destas instruções. Antes da configuração ou de alterações aos endereços de gestão, documentar as funções Primary/Auxiliary atuais (ou as funções previstas para equipamentos autónomos), o build SFOS exato instalado, a interface de administração selecionada e os IPs atuais; guardar uma cópia de segurança segura e garantir uma via administrativa separada por consola ou acesso local. Verificar o comportamento aplicável ao build instalado com base nas instruções pertinentes ou esclarecer com o Sophos Support. Se a contradição não estiver resolvida, parar antes de selecionar Initiate HA ou alterar os endereços de gestão.

O endereço predefinido das portas normais é 172.16.16.16; a PortMGMT dedicada dos appliances maiores utiliza 10.0.1.1. A Primary fica acessível a partir de qualquer zona em que HTTPS esteja permitido em Administration > Device access. Para aceder ao WebAdmin da Auxiliary, o endpoint de administração tem de estar na mesma subnet da respetiva porta de administração.

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.

No SFOS 23, uma Dedicated HA link com LAG ou VLAN sobre LAG exige Keepalive request interval × Keepalive attempts ≥ 2500 ms. A predefinição de configuração do SFOS 23, 100 ms × 3 = 300 ms, não cumpre este requisito LAG e não deve ser aplicada aqui sem alterações. Um exemplo permitido é 250 ms × 10 tentativas = 2500 ms, não uma predefinição universal. O QuickHA cria uma HA redundant link como LAG quando se seleciona mais de uma interface física não associada, pelo que este requisito também se aplica a essa topologia; verificar a configuração real da ligação. Não presumir que o QuickHA negoceia automaticamente valores adequados; verificar os valores configurados antes de confiar no cluster.

Portas de alta velocidade: Nas portas de 25, 50 e 100 GbE das XGS 7500/8500 Series, selecionar em ambos os lados o mesmo Link mode, com velocidade e duplex adequados, em Network > Interfaces > Advanced settings e guardar com Save. Depois, voltar a abrir a interface para edição, utilizar Show recommended settings > Load recommended configuration para a negociação e Forward Error Correction (FEC) e guardar novamente com Save. Se as recomendações continuarem vazias após guardar pela primeira vez e voltar a abrir a interface, desativar Auto-negotiation para Media Type e FEC e guardar a alteração. Nas outras portas, utilizar Automatic ou valores de velocidade/duplex idênticos e manter MTU e MSS nos valores predefinidos. Quando o QuickHA seleciona uma interface não associada, o SFOS repõe os respetivos Advanced settings; verificar novamente estes valores após estabelecer HA.

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.
• Nós HA geograficamente separados só são adequados através de uma rede Layer 2 de baixa latência no mesmo domínio de broadcast. A Dedicated HA Link permanece na mesma subnet IP; latência elevada ou perda de pacotes tornam este desenho inadequado.
• 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 na Primary standalone, o que executa um factory reset; durante o setup HA posterior, a Sophos ativa FIPS automaticamente na 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:

• Endereçamento das Admin Ports validado para o build instalado: Resolver previamente a contradição entre os requisitos HA e o guia de PortMGMT descrita acima. Documentar funções Primary/Auxiliary atuais ou previstas para equipamentos autónomos, build SFOS exato, interface de administração e IPs atuais; garantir uma cópia de segurança segura e acesso separado por consola ou administração local. Confirmar as instruções aplicáveis ou consultar o Sophos Support. Se a contradição persistir, parar antes de Initiate HA ou de alterações aos endereços de gestão.
• 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.

Compreender e ativar o modo LINCE no Sophos Firewall explica por que motivo o modo não certifica automaticamente o build do SFOS instalado e quais algoritmos SSH devem ser verificados antes da ativação.

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. Antes de substituir um equipamento num par HA ainda em funcionamento, HA tem, por isso, de ser desativado e depois reconfigurado com o equipamento de substituição. As secções correspondentes mais abaixo explicam o estado inicial específico após RMA e as descrições divergentes de reimage.

Os equipamentos QuickHA preparados continuam a procurar o peer até o encontrarem. Podem, por isso, ser configurados antecipadamente e ligados mais tarde no destino. Assim que um equipamento encontra o peer e o estabelecimento de HA está em curso, este processo de discovery já não pode ser interrompido. A seleção das interfaces, a passphrase e o peer previsto devem, portanto, estar corretos antes de ambas as ligações HA ficarem acessíveis ao mesmo tempo.

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.

Nomes dos nós no QuickHA: No SFOS 22, a atribuição de nomes é opcional. No SFOS 23, as instruções detalhadas pedem um nome para o nó, enquanto os exemplos de configuração continuam a indicá-lo como opcional. Por isso, a checklist seguinte atribui nomes diferentes e facilmente reconhecíveis aos dois equipamentos. Trata-se de uma orientação conservadora, não de uma prova de que a GUI rejeita um campo de nome vazio.

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 um nome único ao nó, 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 um nome ao nó diferente do nome da Primary, 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 Fusion, se utilizado

4. Definir Monitored Ports

As Monitored Ports determinam se a falha de uma interface provoca um failover. O campo de seleção chama-se Select ports to be monitored no SFOS 22 e Monitored interfaces nas instruções detalhadas do SFOS 23. 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.

Podem selecionar-se interfaces físicas, LAGs e interfaces não associadas com uma VLAN configurada. Uma interface não associada sem VLAN não pode ser selecionada como Monitored Port. As Monitored Ports exigem endereços IP estáticos em ambos os modos HA.

O SFOS 23 permite um máximo de 24 Monitored ports. Manter a seleção separada da Dedicated HA link e incluir apenas ligações de produção realmente necessárias.

HA também funciona sem Monitored Ports selecionadas. Nesse caso, a falha de uma porta de produção, por si só, não provoca um failover; falhas de heartbeat, do equipamento ou de energia podem continuar a provocar uma mudança de função. Todas as portas efetivamente selecionadas têm de estar ligadas em ambos os nós. A monitorização do estado das portas não deteta todas as falhas de um fornecedor a montante.

As definições HA avançadas, como Monitored interfaces, Peer administration, Preferred primary e os valores keepalive, são alteradas na Primary atual após estabelecer HA com o QuickHA. Antes disso, verificar a cópia de segurança, a janela de manutenção e a disponibilidade de acesso administrativo seguro; as alterações a Peer administration ou aos endereços de gestão, bem como Initiate HA, têm de respeitar a verificação prévia da contradição documental acima e não prosseguir se continuar por resolver. A alteração de MAC descrita acima provoca downtime. Se a ligação HA for baseada em LAG, respeitar o requisito de keepalive e não alterar os valores no estado Standalone ou Faulty. Após efetuar a seleção pretendida, voltar ao início da página e selecionar Initiate HA. A Primary sincroniza então as alterações com a Auxiliary. Em seguida, verificar em ambos os nós as funções HA, o estado, a sincronização e os valores alterados; se existirem diferenças, comparar primeiro a ligação HA e os logs dos dois equipamentos. Esta etapa de conclusão também se aplica à variante Active-Active apresentada a seguir e é distinta da adesão inicial dos dois equipamentos ao cluster.

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?
• As licenças de ambos os nós foram sincronizadas individualmente com sucesso, com o estado e a hora registados separadamente?
• 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.

Antes da configuração, concluir a verificação prévia do endereçamento de administração descrita acima e permitir SSH e Ping/Ping6 para a zona DMZ em ambos os equipamentos em Administration > Device access. O Interactive mode seleciona inicialmente e de forma automática a primeira interface DMZ como Dedicated HA link. Se essa interface não estiver prevista para HA ou tiver dependências de produção, selecionar antes de guardar uma interface física, VLAN ou LAG preparado que esteja livre.

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. O campo chama-se Dedicated peer HA link IPv4 address no SFOS 22 e Peer IPv4 address of dedicated HA link nas instruções detalhadas do SFOS 23. Os dois endereços da ligação HA têm de estar na mesma subnet. Este endereço é o IP da ligação HA, não o endereço de administração definido em Peer administration settings; a relação deste último com o IP da interface tem de ser esclarecida previamente, como descrito acima.
5. Selecionar as Monitored ports críticas; o SFOS 23 permite no máximo 24.
6. Em Peer administration settings, indicar a interface de administração e o endereço IP de FW02 apenas depois de concluir a verificação prévia da contradição de endereçamento descrita acima para o build instalado. Se não estiver resolvida, parar antes de alterar endereços de gestão ou selecionar Initiate HA.
7. Se necessário, selecionar Use host or hypervisor-assigned MAC address para appliances virtuais no SFOS 22, ou Use interface MAC address no SFOS 23. A opção SFOS 23 usa o MAC do hypervisor em appliances virtuais e o MAC de interface em hardware, em vez do MAC virtual do cluster. Ativá-la ou desativá-la provoca downtime.
8. Definir Preferred primary e selecionar Initiate HA.

Depois de criar o cluster, alterar os valores keepalive apenas por um motivo documentado. O SFOS 22 permite intervalos de 250–500 ms e 16–24 tentativas; as predefinições de 250 ms e 16 tentativas dão 4 segundos de timeout. O SFOS 23 permite 100–500 ms e 3–24 tentativas; as predefinições de 100 ms e 3 tentativas dão 300 ms. Para Dedicated HA links do SFOS 23 com LAG ou VLAN sobre LAG, o produto tem de ser pelo menos 2500 ms: 250 ms × 10 tentativas é um exemplo permitido, não a predefinição geral. Verificar também os LAGs redundantes criados pelo QuickHA. Estes valores não podem ser alterados enquanto os equipamentos tiverem estado Standalone ou Faulty. Após o timeout, a nova Primary efetua verificações internas antes de começar a processar tráfego. Nenhum destes timeouts garante o tempo de recuperação do tráfego.

Divergência na documentação da API do SFOS 22: A descrição de Keepalive attempts indica 8–16 tentativas, enquanto a restrição detalhada do parâmetro e o exemplo XML indicam 16–24. 8–16 não constitui um segundo intervalo confirmado; aplicar a restrição detalhada indicada acima. Antes de efetuar alterações, documentar o build SFOS instalado e os valores keepalive atuais de ambos os nós. Se os limites aplicáveis continuarem por esclarecer, esclarecê-los com o Sophos Support antes de efetuar uma alteração; os requisitos LAG continuam a ter de ser respeitados.

Verificação prévia da API para SFOS 22 e 23: As tabelas de parâmetros documentam ClusterId como um número inteiro opcional de 0–63, com valor predefinido 0, e NodeName como uma cadeia de caracteres obrigatória com 1–30 caracteres. Mesmo com o valor predefinido documentado, cada cluster na rede Layer 2 partilhada tem de utilizar uma Cluster ID própria para evitar conflitos de MAC virtuais. Estes metadados da API não alteram as indicações da GUI descritas acima sobre a atribuição opcional ou obrigatória de nomes, nem comprovam qualquer validação na GUI. A tabela utiliza a grafia ClusterId e o exemplo XML utiliza ClusterID; daí não resulta uma correspondência testada entre as tags nem um payload funcional para a API.

Nas definições HA avançadas do SFOS 23, Monitor hardware components é opcional e acrescenta um desencadeante de failover quando é detetado um problema num dispositivo de armazenamento, além da deteção de falhas de heartbeat e interfaces monitorizadas. Não presumir que esteja ativado por predefinição nem que detete todas as falhas de hardware.

Nota sobre a API do SFOS 23: A tabela de parâmetros da API apresenta HardwareMonitor como parâmetro escalar opcional (SCALAR, Mandatory: No), com os valores Enable e Disable e a predefinição documentada da API Enable. Este valor da documentação não comprova a definição real na GUI nem o estado do equipamento em funcionamento. Verificar a definição no equipamento instalado; o âmbito limitado a dispositivos de armazenamento descrito acima mantém-se.

O exemplo XML da API do SFOS 23 continua a incluir Number(250-500) e Number(16-24). Estes marcadores não correspondem aos intervalos da tabela, 100–500 ms e 3–24 tentativas, e não devem ser copiados como limites completos. Isto não comprova que o produto rejeite os valores inferiores nem um comportamento testado da API.

Ligar uma nova Auxiliary virtual como HA spare

Para uma nova Auxiliary virtual em Active-Passive, o Setup Assistant pode utilizar Connect as HA spare. Este procedimento é uma alternativa à configuração descrita acima, que começa pela Auxiliary e utiliza dois equipamentos já existentes: a nova VM spare não é previamente configurada como Auxiliary. Antes de selecionar Initiate HA, concluir a verificação prévia da contradição de endereçamento de administração descrita acima para o build instalado; se continuar por resolver, parar. A configuração automática da porta de administração não resolve essa contradição. Active-Active ou dois firewalls Virtual/Software existentes continuam a exigir QuickHA ou Interactive mode em ambos os equipamentos.

1. Na Primary existente, permitir SSH para DMZ em Administration > Device access e selecionar Primary (active-passive) e Interactive mode em System services > High availability. No SFOS 23, introduzir uma Cluster ID e um nome para o nó antes de selecionar Initiate HA; as instruções do SFOS 22 descrevem a introdução da Cluster ID e a alteração do nome do nó como opcionais. Se existirem vários clusters HA na mesma rede Layer 2, utilizar uma Cluster ID diferente para cada cluster para evitar conflitos de endereços MAC virtuais. Documentar de forma segura a Dedicated HA Link, o respetivo IP e máscara de sub-rede, o IP previsto do peer, Peer Administration e a passphrase HA utilizada na Primary. Depois, selecionar Initiate HA; no SFOS 23, voltar ao início da página para o fazer. As instruções Sophos para a spare documentam, neste ponto, antes da adesão da nova VM, a mensagem HA could not be enabled e, temporariamente, o estado Standalone. Nesta fase de configuração, nenhum destes sinais, por si só, comprova a falha de um cluster já concluído.
2. Instalar o novo firewall virtual com exatamente o mesmo build do SFOS, iniciar o Setup Assistant e definir uma nova palavra-passe de administrador.
3. Selecionar Connect as HA spare e introduzir o número de série da Primary existente, a mesma passphrase HA anteriormente utilizada na Primary e documentada de forma segura, e a mesma interface Dedicated HA Link. Para a nova spare, utilizar um endereço IP próprio, livre e diferente do da Primary, na sub-rede da Dedicated HA Link da Primary existente, com uma máscara de sub-rede idêntica; tem de corresponder ao IP do peer preparado nessa configuração. Não pressupor uma passphrase de uma Auxiliary supostamente já configurada.
4. Selecionar Apply, Continue e Finish. O SFOS cria a Auxiliary, atribui um número de série iniciado por HAAUX e configura automaticamente a Dedicated HA Link e a porta de administração.
5. Após alguns minutos, atualizar o WebAdmin da Auxiliary e iniciar sessão novamente. Verificar depois na Primary as funções, a sincronização, Peer Admin, Monitored Ports e failover.

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

Verificar os parâmetros operacionais do SFOS 22

O SFOS 22 publica dois controlos HA adicionais. Ambos devem ser lidos antes de qualquer alteração:

system ha auxiliary_system_traffic_through_dedicated_link show
system ha load-balancing show

O primeiro controlo determina o caminho do tráfego de sistema enviado pela própria Auxiliary Firewall. Por predefinição, todo este tráfego passa pelo Dedicated HA Link. Além de all, estão disponíveis none e only_dynamic_interface. A Sophos não define com maior precisão quais os fluxos considerados uma interface dinâmica no último modo. Esta opção só deve ser usada num caso confirmado para o build instalado e não como correção geral de routing.

O segundo controlo ativa ou desativa a distribuição do tráfego elegível entre os firewalls. Não substitui a escolha do modo HA nem torna elegíveis para load balancing os serviços e túneis excluídos acima. As alterações são efetuadas individualmente numa janela de manutenção, guardando antes ambos os outputs show:

system ha auxiliary_system_traffic_through_dedicated_link [all|none|only_dynamic_interface]
system ha load-balancing [on|off]

Em seguida, verificam-se as funções, a sincronização, o Dedicated HA Link, novas sessões, logs locais dos nós e ligações de sistema iniciadas pela própria Auxiliary. Para rollback, repõe-se o valor observado anteriormente. A Sophos documenta all como predefinição apenas para o primeiro controlo; não se assume uma predefinição para load balancing.

O Initial Primary titular da licença deve ser verificado em System services > High availability. A Sophos também documenta a seguinte verificação CLI oficial na Advanced Shell:

nvram get "#li.master"

YES identifica o Initial Primary que detém as licenças do cluster; NO identifica o equipamento configurado como Auxiliary. O comando é read-only. A vista HA continua a ser mais prática para verificações diárias, mas a saída da shell também está documentada oficialmente.

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 Fusion, 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.

A Auxiliary envia reports por email apenas quando o report contém dados nesse node, por exemplo atividade de email ou Pattern Updates. Não envia reports sem dados, como Security Dashboard ou Security Audit. A ausência de um email para estes tipos de report não comprova, por si só, uma falha.

Em Active-Active, o IP de origem fornece uma primeira indicação do node onde se esperam os logs: para tráfego TCP elegível, os endereços pares correspondem à Primary e os ímpares à Auxiliary. Isto não se aplica de forma geral aos tipos de tráfego excluídos acima nem substitui a comparação de ambos os equipamentos, sobretudo após uma mudança de função.

Para eventos HA, abrir Log viewer > System separadamente em cada node. Em Add filter, selecionar o filtro e o valor adequados para o período afetado e aplicá-los com o botão Add filter. Para uma análise detalhada, abrir Diagnostics > Tools > Troubleshooting logs > Select files nos dois equipamentos e selecionar csc.log, correspondente ao serviço central que gere os restantes serviços. Selecionar também os ficheiros HA descritos abaixo em Logs e locais de diagnóstico importantes e guardar cada pacote separadamente com Download. Para reconstruir a sequência de funcionamento do cluster, comparar os registos de ambos os nodes e ter em atenção lacunas temporais ou logs que tenham sido sujeitos a rotação.

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.

Sincronização manual e mudança de função forçada

A sincronização automática é o funcionamento normal. Utilizar Sync auxiliary device na Primary ou Auxiliary apenas para resolver um problema de sincronização confirmado. A Auxiliary reinicia, executa uma sincronização completa da base de dados e dos ficheiros relacionados e permanece Auxiliary. Os logs e reports continuam locais em cada nó. O firewall termina todas as ligações com masquerading durante o processo, pelo que a operação deve ser planeada numa janela de manutenção.

Em Active-Passive, forçar a Auxiliary a assumir o controlo com Switch to passive device na Primary atual ou Switch to active device na Auxiliary atual. A Primary atual reinicia. Trata-se de uma mudança de função planeada com risco para as sessões, não de um simples comutador.

Desativar HA de forma controlada

As FAQs HA da Sophos para SFOS 22 e 23 indicam como requisito geral desativar HA antes de um reimage, antes de substituir um node no par HA e antes de transferir licenças entre os nodes. A passphrase de utilização única para o túnel SSH é eliminada após o estabelecimento do túnel; por isso, para um novo equipamento, HA tem de ser desativado e reconfigurado. Este requisito não substitui o planeamento específico de cada caso: os detalhes de reimage abaixo contêm uma divergência documental, e os procedimentos RMA pressupõem que já existe um node saudável no estado Standalone HA. Planear antecipadamente a cópia de segurança, o acesso administrativo garantido, a janela de manutenção e a reconstrução; para a correção de licenças Active-Passive, cumprir também a condição relativa aos números de série e às funções descrita acima.

Sempre que possível, desativar HA na Primary atual em System services > High availability > Disable HA. O nó utilizado determina o resultado:

Acesso através do Fusion a partir do SFOS 22 MR1: A lista Sophos Known Issues, NC-186855, descreve uma exceção ao comportamento geral indicado acima: se HA for desativado na interface da firewall aberta através do Sophos Fusion/Central por FRP-SSO, a Auxiliary pode permanecer em Standalone com HA ativado, enquanto HA já está desativado na Primary. Isto cria um risco de split-brain. Após a ação, verificar separadamente o estado HA em ambos os dispositivos. Se os estados forem contraditórios, suspender a reconstrução planeada e coordenar a recuperação com o Sophos Support antes de voltar a operar os dispositivos como par. Um diálogo de confirmação bem-sucedido na Primary não é uma verificação suficiente. Em 24 de outubro de 2026, o registo não indica uma versão corrigida.

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 o tempo de indisponibilidade, determinadas sessões, ligações VPN ou aplicações especiais podem sofrer uma breve interrupção ou necessitar de restabelecer a ligação.

Um rollback de firmware do par HA segue o mesmo processo e não exige que HA seja desativado previamente.

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

Criar backups regularmente e antes de cada alteração importante. Se LINCE estiver ativo, o backup e o cluster de destino têm de ter o mesmo estado LINCE. Existem três cenários de restore:

Active-Active e Bridge-VLAN: Cada node escreve os seus próprios logs. Em SFOS 22 Active-Active, apenas a Primary processa o tráfego recebido em interfaces VLAN configuradas em Bridge Interfaces. As descrições de configuração e interfaces do SFOS 23 omitem esta restrição, mas a omissão não confirma distribuição de carga. Até o Sophos Support confirmar o comportamento para o build SFOS 23 e a topologia utilizados, planear este tráfego de forma conservadora apenas na Primary e não depender da distribuição para dimensionar a capacidade.

Acesso à quarentena: Cada node guarda a sua própria quarentena e envia o seu próprio Quarantine Digest. Os administradores libertam um email no node que o processou. Os utilizadores libertam emails em quarentena através do User Portal. O User Portal mostra apenas emails em quarentena na Primary atual.

Atenção com um backup sem HA: As descrições Sophos para SFOS 22 e 23 contradizem-se quanto ao estado da Auxiliary após este restore: o texto indica que conserva a configuração anterior, enquanto o resumo indica uma reposição de fábrica, exceto para o Peer Admin Port e o Dedicated HA Link. Nem a conservação completa nem a reposição de fábrica constituem, portanto, um comportamento confirmado. Não confiar na conservação da configuração da Auxiliary. Primeiro guardar as configurações externamente, documentar os endereços IP de administração e as credenciais e planear downtime e a reconstrução de HA. Antes de depender do estado incerto da Auxiliary, esclarecer o procedimento para o build SFOS instalado com Sophos Support.

Se a Primary estava registada como gateway Sophos ZTNA, deve ser novamente adicionada como gateway no Sophos ZTNA após o restore no cluster HA.

Reimage de nós HA em Active-Passive

Um reimage interrompe a operação e, segundo a Sophos, aplica-se apenas a Active-Passive. Antes de começar, executar system diagnostics show version-info na Device Console de ambos os nós, documentar o firmware, incluindo o build, e a Initial Primary, e guardar externamente uma cópia de segurança atual.

Âmbito dos procedimentos seguintes: No início, FW1 é simultaneamente a Primary atual e a Initial Primary titular das licenças; FW2 é a Auxiliary atual. Estes nomes identificam os mesmos equipamentos físicos durante todo o procedimento, mesmo após uma mudança de função. O objetivo é voltar a ter FW1 como Primary e FW2 como Auxiliary. Se a Primary atual e a Initial Primary forem equipamentos diferentes, não improvisar com estes procedimentos: primeiro, identificar as funções e o titular das licenças com base nas instruções Sophos aplicáveis ou com o Sophos Support.

Esclarecer a divergência documental antes do reimage: As FAQs HA para SFOS 22 e 23 exigem, de forma geral, a desativação de HA antes do reimage. No entanto, as instruções detalhadas de Active-Passive descrevem, para o reimage da Primary e de ambos os nodes, uma mudança de função com Switch to passive device seguida de reinstalação, sem indicar um passo separado Disable HA. A mudança de função não equivale à desativação de HA; a omissão não comprova uma exceção geralmente segura. Por isso, as sequências detalhadas abaixo mantêm-se como procedimentos documentados, mas contraditórios neste ponto. Antes de os executar, definir um plano firme para as funções, Initial Primary, build instalado, cópia de segurança, downtime e caminho de retorno, e esclarecer a ordem adequada com o Sophos Support se for necessário seguir esta sequência detalhada divergente. Se a ordem não estiver esclarecida, parar antes da mudança de função ou da reinstalação; não inserir por iniciativa própria um passo de desativação na sequência.

Se FW1 estiver registado para Central Management, cancelar o seu registo antes de cada um dos três procedimentos. Depois, no mesmo tenant Sophos Central/Fusion, verificar em My Products > Firewall Management > Firewalls que a entrada de FW1 já não existe. Só então prosseguir com a cópia de segurança, a desativação de HA ou a mudança de função. Esta verificação aplica-se ao registo no Firewall Management, não apenas ao Synchronized Security.

Reinstalar apenas a Auxiliary FW2

1. Após o cancelamento do registo e a verificação descritos acima, guardar externamente a cópia de segurança de FW1 e desativar HA em FW1, nunca em FW2.
2. Na Advanced Shell de FW1, utilizar service -S | grep msync para verificar se msync apresenta o estado UNTOUCHED ou STOPPED. Caso contrário, não prosseguir.
3. Reinstalar FW2 com exatamente a mesma versão de firmware, incluindo o build, de FW1. Iniciar sessão localmente e configurar exclusivamente WAN para acesso à Internet, sem configurar interfaces LAN ou DMZ. Depois, efetuar o claiming de FW2, se ainda não tiver sido efetuado.
4. Reconstruir HA com FW1 como Primary e FW2 como Auxiliary.

Reinstalar apenas a Primary FW1

1. Após o cancelamento do registo e a verificação, guardar externamente a cópia de segurança de FW1 e utilizar Switch to passive device para que FW2 assuma o serviço. As identidades dos equipamentos mantêm-se inalteradas.
2. Reinstalar FW1 com exatamente a mesma versão de firmware, incluindo o build, de FW2. Iniciar sessão localmente, configurar apenas WAN para acesso à Internet, sem configurar interfaces LAN ou DMZ, e efetuar o claiming de FW1, se ainda não tiver sido efetuado.
3. Para o restauro, desligar todos os cabos de FW1, exceto o do PC de administração, restaurar a cópia de segurança, voltar a ligar os cabos e devolver o tráfego de FW2 a FW1.
4. Em seguida, repor FW2 nas definições de fábrica. Iniciar sessão localmente, configurar exclusivamente WAN para acesso à Internet, sem configurar interfaces LAN ou DMZ, e efetuar o claiming, se ainda não tiver sido efetuado.
5. Reconstruir HA com FW1 como Primary e FW2 como Auxiliary.

Reinstalar e atualizar ambos os nós

1. Efetuar o cancelamento do registo, a verificação, a cópia de segurança e a mudança de função como no reimage da Primary. No entanto, instalar em FW1 a versão de destino, incluindo o build de destino. Depois, iniciar sessão localmente, configurar apenas WAN para acesso à Internet, sem configurar interfaces LAN ou DMZ, e efetuar o claiming, se ainda não tiver sido efetuado.
2. Para o restauro, desligar todos os cabos de FW1, exceto o do PC de administração, restaurar aí a cópia de segurança, voltar a ligar os cabos e devolver o tráfego de FW2 a FW1.
3. Ao contrário do reimage apenas da Primary, não se limitar agora a repor FW2 nas definições de fábrica: reinstalá-lo também com exatamente a mesma versão de destino, incluindo o build, de FW1. Iniciar sessão localmente, configurar exclusivamente WAN para acesso à Internet, sem configurar interfaces LAN ou DMZ, e efetuar o claiming, se ainda não tiver sido efetuado.
4. Reconstruir o cluster Active-Passive com FW1 como Primary e FW2 como Auxiliary. A interrupção planeada inclui também esta segunda etapa de reinstalação e adesão ao cluster.

Se o cluster utilizar Sophos Fusion 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. Ambas as variantes RMA detalhadas pressupõem que o node saudável restante já funciona como Standalone HA: a Primary saudável no RMA da Auxiliary e a Auxiliary saudável no RMA da Primary. Só para este estado inicial as fontes descrevem o claiming e a transferência de licenças do equipamento de substituição antes da posterior desativação de HA ou reposição do node saudável, respetivamente. Não aplicar esta ordem à substituição num par HA ainda em funcionamento; nesse caso, aplica-se o requisito geral das FAQs de desativar HA previamente. Se o estado inicial não corresponder ou não for claro, parar antes da substituição ou da transferência de licenças e planear o procedimento 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. Preparar primeiro o acesso local no equipamento de substituição. No exemplo de portas documentado, ligar um PC de administração com suporte para DHCP à porta 1 e abrir https://172.16.16.16:4444; ligar WAN à porta 2 e configurá-la no Setup Assistant para acesso à Internet. Se a disposição das portas for diferente, utilizar as portas de administração e WAN correspondentes ao modelo do equipamento. Não configurar quaisquer outras interfaces. Só depois efetuar o claiming do equipamento de substituição no Sophos Fusion 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. Descarregar uma cópia de segurança atual da Auxiliary saudável e deregistar esse equipamento do Sophos Fusion. Antes de prosseguir, verificar no mesmo tenant Sophos Central/Fusion, em My Products > Firewall Management > Firewalls, que a entrada dessa Auxiliary saudável já não existe.
2. Instalar o mesmo build de firmware no equipamento de substituição e iniciar sessão localmente. No exemplo de portas documentado, ligar um PC de administração com suporte para DHCP à porta 1 e abrir https://172.16.16.16:4444; configurar WAN na porta 2 no Setup Assistant para acesso à Internet. Se a disposição das portas for diferente, utilizar as portas de administração e WAN correspondentes ao modelo do equipamento. Não configurar quaisquer outras interfaces. Só depois efetuar o claiming no Sophos Fusion 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 anterior Auxiliary nas definições de fábrica e preparar novamente o acesso local: no exemplo de portas documentado, ligar um PC de administração com suporte para DHCP à porta 1 e abrir https://172.16.16.16:4444, depois configurar WAN na porta 2 no Setup Assistant para acesso à Internet. Se a disposição das portas for diferente, utilizar as portas de administração e WAN correspondentes ao modelo do equipamento. Não configurar quaisquer outras interfaces. Só depois efetuar novamente o claiming no Sophos Fusion 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: Diagnostics > Tools > Troubleshooting logs > Select files 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 Appliance idênticos e compatíveis.

• HA could not be enabled: A Sophos documenta esta mensagem imediatamente após Initiate HA na Primary, antes da adesão da spare, apenas na configuração descrita acima com uma nova HA spare virtual; também descreve aí o estado temporário Standalone. Isto não constitui uma autorização geral para ignorar esta mensagem. Se persistir após a conclusão do assistente da spare e da fase de espera e atualização, ou se surgir noutra configuração, a Dedicated HA link pode não estar ligada ou o peer pode estar inacessível. Garantir que as interfaces da ligação HA dedicada dos dois equipamentos estão ligadas diretamente por cabo Ethernet ou através do switch previsto. Em ambos os nodes, verificar em Network > Interfaces se a interface selecionada para a ligação HA apresenta Connected. Na Primary, utilizar a ferramenta de ping em Diagnostics > Tools para verificar o IP da ligação HA dedicada da Auxiliary, e não o respetivo endereço Peer Admin. As respostas comprovam a acessibilidade básica, mas ainda não uma sincronização HA concluída. Se não houver respostas, verificar e corrigir primeiro o cabo, o caminho através do switch, o estado da ligação e o IP/subnet da ligação HA; depois, repetir o ping e voltar a verificar as funções e a sincronização.

• 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: Procurar esta mensagem exata em /log/syslog.log na Primary. A Sophos associa-a a portas de administração que não estão na mesma subnet; comparar os endereços das Admin Ports dos dois equipamentos. Verificar adicionalmente, como requisito separado, se os endereços da ligação HA estão na mesma subnet, sem os tratar como causa comprovada desta mensagem. Antes de corrigir o endereçamento de gestão, cumprir a verificação prévia descrita acima para esclarecer a contradição entre as fontes: documentar as funções, o build SFOS instalado, a interface de administração e os IPs atuais, garantir uma cópia de segurança e acesso administrativo separado por consola ou acesso local, e verificar o comportamento de endereçamento aplicável ou esclarecê-lo com o Sophos Support. Se o comportamento não estiver esclarecido, parar antes de alterar os endereços.

• 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 falha após uma atualização: nos modelos 1U XGS 2100, XGS 2300, XGS 3100, XGS 3300, XGS 4300 e XGS 4500, HA pode não ser estabelecida quando se utiliza uma Flexi Port como Dedicated HA link. Após a atualização e o reinício do primeiro equipamento, a sua Interface speed deixa de estar definida como Auto negotiation, enquanto o segundo continua a utilizar Auto negotiation.

  Antes de alterar a definição: documentar as funções HA e as definições das portas de ambos os equipamentos, garantir uma cópia de segurança e acesso de administração separado, e utilizar uma janela de manutenção. Em caso de split-brain, seguir primeiro o procedimento de falha da ligação HA apresentado abaixo: decidir qual o node que deve permanecer ativo e desligar o outro da rede de produção ou encerrá-lo de forma controlada. Não reiniciar ambos os nodes sem coordenação.

  1. Em ambos os equipamentos, abrir Network > Interfaces.
  2. Selecionar a interface Flexi Port afetada e abrir Advanced settings.
  3. Definir Interface speed como Auto negotiation.

  Depois, verificar o estado da ligação, as funções HA, a sincronização e o tráfego de produção. Se o problema persistir, guardar as definições e os logs de ambos os nodes e contactar o Sophos Support. Restaurar os valores anteriores documentados apenas através de uma alteração controlada, com acesso de administração garantido; isso pode voltar a provocar a falha da ligação HA. Em alternativa, planear a utilização de uma porta integrada como Dedicated HA link, e não de um valor de velocidade fixo.

WebAdmin e VPN Portal inacessíveis durante a sincronização de certificados

As notas de versão do SFOS 22.0 MR3 Build 576 de 16 de outubro de 2026 indicam a correção de NC-186809: a sincronização de certificados podia falhar na Auxiliary quando determinados nomes de ficheiros de certificados começavam por dois pontos consecutivos (..); consequentemente, WebAdmin e VPN Portal ficavam inacessíveis. Distinguir este cenário de problemas gerais de routing ou Device Access e guardar a build, o node afetado, a hora e os logs de sincronização disponíveis. Não mudar nomes nem eliminar certificados com base numa suspeita. Perante indícios compatíveis, envolver o suporte e planear uma mudança de firmware suportada, com acesso de gestão garantido; depois, verificar novamente ambos os portais e a sincronização HA.

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 apenas de leitura na Device Console mostra o estado das interfaces e ligações:

show network interfaces

São esperados estados UP para a Dedicated HA link e as Monitored Ports ligadas.

No mesmo output de show network interfaces, localizar a interface física afetada pelo seu nome real e verificar, além do estado da ligação, os contadores disponíveis de perdas de pacotes (Drops), erros e colisões. Nem todos os builds apresentam todos os contadores; a ausência de dados não equivale a um valor zero. Guardar o output com o node, a interface e o timestamp e compará-lo com uma observação posterior: contadores crescentes ajudam a delimitar problemas de interface, cabo ou negociação, mas, por si só, não comprovam uma causa concreta. Substituir o cabo ou corrigir Speed/Duplex apenas de forma controlada, com acesso administrativo garantido e as precauções HA/Split-Brain descritas acima; depois, voltar a comparar os contadores, o estado da ligação, as funções e a sincronização. Estes contadores de interface são distintos dos Drops de pacotes causados por regras de firewall e do respetivo Drop Capture.

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.

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