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 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.
• 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 de endereços IP de origem pares são normalmente processadas pela Primary, enquanto as de endereços ímpares são enviadas para a Auxiliary. São distribuídas as ligações TCP encaminhadas ou traduzidas, incluindo através de interfaces VLAN. Depois de processar uma ligação, a Auxiliary envia os pacotes diretamente para o destino sem regressarem pela Primary. Este método par-ímpar é fixo e não pode ser alterado. 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. 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 HA, as interfaces de produção usam endereços MAC virtuais. 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. 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.
• 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 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.

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 Auxiliary se Preferred primary não estiver selecionado. Se for a Preferred primary, o SFOS sincroniza primeiro os serviços e depois regressa automaticamente. O equipamento que estava a funcionar sozinho reinicia durante este processo. Este failback deve, por isso, ser planeado numa janela de manutenção, mesmo que o cluster permaneça geralmente disponível durante a operação.

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 ambas as 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.

• 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.

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: Ambos os equipamentos de hardware têm de ser claimed no Sophos Fusion (anteriormente 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: 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 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. Desativar HA de forma planeada na Primary atual, transferir as subscrições da Auxiliary para a Primary no Sophos Fusion 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. 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 ou PPPoE, mas estas ligações não têm 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. Em Active-Active, todas as interfaces têm de usar endereços estáticos.

Configurar as interfaces breakout na Primary. Reiniciar primeiro a Primary para aplicar a alteração e depois a Auxiliary. Se a Primary não tiver a configuração breakout correspondente, a sincronização elimina uma configuração breakout existente apenas na Auxiliary.

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. Ambos os nós utilizam a mesma rede de gestão. No entanto, o SFOS sincroniza a configuração normal da interface, incluindo o IP de PortMGMT, da Primary para a Auxiliary, pelo que este IP de interface não pode ser diferente por nó. A definição separada Peer Administration atribui à Auxiliary um IP de administração adicional e diferente na mesma subnet. O QuickHA utiliza automaticamente a interface da sessão WebAdmin atual. Depois de HA ser estabelecido, a Auxiliary só fica acessível através deste endereço Peer Admin a partir da subnet correspondente.

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: Para 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 correspondentes em Network > Interfaces > Advanced settings. Depois utilizar Show recommended settings > Load recommended configuration para negotiation e Forward Error Correction (FEC). Se as recomendações estiverem vazias, desativar Auto-negotiation para Media Type e FEC. Nas outras portas, utilizar Automatic ou valores speed/duplex idênticos e manter MTU e MSS nas predefinições. Quando o QuickHA seleciona uma interface não associada, o SFOS repõe os Advanced settings; verificá-los novamente 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 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.

Compreender e ativar o modo LINCE no Sophos Firewall explica por que motivo o modo não certifica automaticamente a build do SFOS instalada 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. Após a substituição de um equipamento, HA tem, por isso, de ser desativado e reconfigurado.

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.

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

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.

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, 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.
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 um endereço IP próprio para FW02.
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.

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. 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 preparar Active-Passive em Interactive mode. Documentar a Dedicated HA Link, o IP do peer, Peer Administration e a passphrase HA. A Primary pode mostrar Standalone até a nova Auxiliary se juntar.
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, a mesma interface Dedicated HA Link e um endereço IP livre com a mesma subnet mask.
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 a build instalada e não como correção geral de routing.

O segundo controlo ativa ou desativa a distribuição do tráfego elegível entre as 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.

Para eventos HA, abrir Log viewer > System separadamente em cada node e filtrar o período afetado. Para uma análise detalhada, abrir Diagnostics > Tools > Troubleshooting logs > Select files nos dois equipamentos, selecionar pelo menos csc.log e guardar cada pacote separadamente com Download. Só a comparação de ambos os nodes mostra a sequência completa do cluster.

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

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

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.

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:

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, estes procedimentos aplicam-se apenas a Active-Passive. Primeiro 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 um backup atual.

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.

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 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. Transferir um backup atual da Auxiliary saudável e remover o equipamento do registo do Sophos Fusion.
2. Instalar o mesmo firmware build no equipamento de substituição, efetuar o claim 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 antiga Auxiliary nas Factory Settings, efetuar novamente o claim 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: 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 Appliance 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 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. A alteração foi verificada na documentação, mas não testada num equipamento.

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