Configurare l'High Availability (HA) su Sophos Firewall

High Availability, abbreviato in HA, collega due Sophos Firewall in un cluster. L’obiettivo non è rendere un singolo firewall indistruttibile, ma gestire il guasto di un dispositivo, di singole porte critiche o di manutenzioni pianificate in modo controllato.

Un ambiente HA non sostituisce comunque un buon design di rete, backup accurati e processi di manutenzione documentati. Un cluster pianificato male può essere più difficile da gestire in caso di errore rispetto a un singolo firewall. Questo articolo spiega quindi non solo dove attivare HA, ma anche come pianificare, configurare, gestire e verificare un cluster HA di Sophos Firewall in caso di errore.

Indice

• Conclusione rapida
• Video guide
• Cosa significa High Availability su Sophos Firewall
• Active-Passive o Active-Active
• Ruoli, stato e architettura
• Requisiti
• Pianificazione e design
• Preparazione della configurazione
• Configurare Active-Passive con QuickHA
• Configurare Active-Active con QuickHA
• Configurazione manuale di HA
• Validare il cluster
• Operatività e manutenzione
• Aggiornamenti firmware e backup
• Risoluzione dei problemi
• Checklist delle best practice

Conclusione rapida

Nella maggior parte degli ambienti produttivi, Active-Passive è la variante HA migliore. Un firewall gestisce tutto il traffico, mentre il secondo è pronto a subentrare in caso di guasto o manutenzione. Il design è più semplice, la licenza è più economica e il comportamento in caso di errore è più facile da comprendere.

Active-Active è utile solo se si accettano consapevolmente i limiti e le restrizioni. Non è un classico bilanciamento del carico simmetrico, in cui entrambi i firewall sono ugualmente posizionati in tutte le parti della rete. Il firewall primario continua a ricevere il traffico e distribuisce alcune connessioni al firewall ausiliario. Non tutti i servizi e non tutti i tipi di traffico vengono distribuiti.

Come orientamento rapido:

• Massima stabilità e gestione semplice: Active-Passive.
• Usare il secondo firewall senza licenza di protezione separata: Active-Passive.
• Serve più throughput per determinate connessioni TCP: valutare Active-Active.
• Molti casi VPN, proxy, RED, NDR o speciali: preferire Active-Passive.
• Ambiente piccolo o medio senza chiaro problema di performance: Active-Passive.
• Requisito di performance chiaro e licenze adatte su entrambe le appliance: Active-Active dopo test.

Video guide

I seguenti Sophos Techvids mostrano visivamente la HA su Sophos Firewall. I video non sostituiscono una pianificazione accurata, ma aiutano a comprendere meglio QuickHA, ruoli, stati e comportamento di base di un cluster HA.

Cosa significa High Availability su Sophos Firewall

Un cluster HA di Sophos Firewall è composto da due firewall. I dispositivi scambiano tramite un HA-Link dedicato heartbeat, stato del dispositivo, informazioni sulle connessioni e dati di configurazione. La configurazione viene sincronizzata dal firewall primario al firewall ausiliario.

HA protegge dai guasti tipici:

• Guasto del firewall primario
• Guasto di alimentazione o hardware
• Guasto di un’interfaccia monitorata
• Problema software o di servizio che rende un dispositivo non operativo
• Aggiornamenti firmware pianificati
• Cambio di ruolo pianificato durante la manutenzione

Tuttavia, HA non risolve ogni problema:

• Una regola firewall errata rimane errata anche nel cluster.
• Un guasto di uno switch comune può influenzare entrambi i firewall contemporaneamente.
• Un design VLAN difettoso o un concetto di routing errato non vengono corretti automaticamente.
• I log e i report non vengono completamente sincronizzati tra i due firewall.
• Un backup rimane comunque obbligatorio.

Chi pianifica HA dovrebbe chiarire in anticipo le basi per zone, interfacce, VLAN, LAG e bridge. A tal fine, è utile la guida Pianificare e configurare zone e interfacce di Sophos Firewall.

Active-Passive o Active-Active

Active-Passive

In modalità Active-Passive, un firewall gestisce tutto il traffico produttivo. Il secondo firewall è passivo e subentra solo se il firewall attivo si guasta o se viene attivato un failover manualmente o tramite manutenzione.

Caratteristiche tipiche:

• Il firewall primario gestisce il traffico.
• Il firewall ausiliario rimane in standby.
• Le sessioni vengono sincronizzate, se supportato dal servizio.
• Solo il dispositivo con licenza necessita delle sottoscrizioni di protezione per le appliance hardware.
• Il firewall ausiliario subentra in caso di failover con lo stesso indirizzo MAC virtuale.
• I dispositivi di rete non devono generalmente reimparare le loro vicinanze.

Active-Passive è generalmente la scelta migliore per ambienti aziendali classici, filiali, data center e ambienti in cui la stabilità è più importante di un possibile guadagno di prestazioni.

Active-Active

In modalità Active-Active, entrambi i firewall gestiscono il traffico. Tuttavia, l’architettura rimane asimmetrica: il firewall primario riceve il traffico e decide se gestire una connessione da solo o inoltrarla al firewall ausiliario.

Sophos utilizza, tra l’altro, l’indirizzo IP di origine per la distribuzione. Le connessioni TCP da indirizzi IP di origine pari vengono tipicamente gestite sul primario, mentre quelle da indirizzi IP di origine dispari possono essere inoltrate all’ausiliario. Il traffico non TCP e alcuni servizi non vengono distribuiti equamente.

Caratteristiche tipiche:

• Entrambi i firewall possono gestire il traffico.
• Il firewall primario rimane il punto di ingresso centrale.
• Entrambi i firewall necessitano di licenze adeguate.
• Non tutti i servizi vengono distribuiti.
• I log e i report vengono generati sul dispositivo che gestisce il traffico.
• La risoluzione dei problemi diventa più complessa, poiché le connessioni possono finire su entrambi i nodi.

Active-Active è utile quando c’è un chiaro obiettivo di prestazioni e si è testato in precedenza se il traffico rilevante viene effettivamente distribuito. Per la pura alta disponibilità, Active-Passive è generalmente più pulito.

Ruoli, stato e architettura

Ruoli nel cluster HA

Valori di stato in operatività

Indirizzo MAC virtuale

Sophos Firewall utilizza indirizzi MAC virtuali per le interfacce produttive nel cluster HA. Solo il primario risponde alle richieste ARP per il cluster. In caso di failover, l’ausiliario assume questo indirizzo MAC virtuale. Ciò mantiene più stabile la raggiungibilità per switch, router e client, poiché l’associazione IP e MAC non cambia radicalmente.

Importante è l’ID del cluster. Questo ID viene utilizzato per l’indirizzo MAC virtuale. Se più cluster HA vengono eseguiti nello stesso ambiente Layer-2, ogni cluster deve avere un ID univoco. Altrimenti possono verificarsi conflitti MAC.

Cosa viene sincronizzato

• Regole firewall, policy, oggetti, routing e configurazione CLI vengono sincronizzati dal Primary all’Auxiliary.
• Sessioni attive vengono sincronizzate a seconda del protocollo e del servizio.
• Secure Storage Master Key e credenziali WebAdmin vengono sincronizzati.
• Dedicated HA link non viene sincronizzato come normale configurazione di interfaccia produttiva.
• Peer Admin Port viene trattato separatamente e non come una normale interfaccia sincronizzata.
• Log e report non vengono sincronizzati tra i dispositivi.

Comportamento del failover

Un failover può essere attivato da vari eventi:

• nessun heartbeat più sull’HA-Link
• guasto di una porta monitorata
• interruzione di corrente
• guasto hardware
• problema software o di servizio
• cambio di ruolo pianificato
• aggiornamento firmware

Gli heartbeat vengono eseguiti tramite l’HA-Link dedicato. Di default vengono utilizzati intervalli molto brevi. Se mancano più heartbeat consecutivi, il peer viene considerato non raggiungibile. Successivamente, il firewall verifica lo stato ed esegue il cambio di ruolo.

In caso di failover, molte connessioni vengono mantenute o rapidamente ristabilite. Tuttavia, un failover non è completamente trasparente per ogni applicazione. In particolare, le connessioni TCP stateful, le sessioni web, le connessioni proxy o alcuni scenari VPN possono interrompersi brevemente o dover essere ristabiliti.

Load Balancing in Active-Active

Active-Active non significa che entrambi i firewall siano posizionati come due router uguali nella rete. Il firewall primario rimane il punto di ingresso centrale e distribuisce alcune connessioni al firewall ausiliario.

Punti importanti:

• Il bilanciamento del carico è disponibile solo in Active-Active.
• Il metodo non può essere liberamente adattato.
• I bilanciatori di carico esterni davanti a un cluster HA non vengono utilizzati da Sophos come design standard per questa logica HA.
• Non tutto il traffico viene distribuito.
• Il traffico non TCP, SD-RED, il traffico incapsulato e alcune funzioni Layer-7 possono essere trattati diversamente.
• La risoluzione dei problemi deve coinvolgere entrambi i nodi.

In pratica, Active-Active dovrebbe essere utilizzato solo se si sa in anticipo quale traffico crea il collo di bottiglia e se esattamente quel traffico viene distribuito.

Servizi supportati e limitati

Sophos HA supporta la maggior parte dei servizi firewall. Tuttavia, alcuni servizi hanno particolarità.

• Regole firewall e NAT vengono sincronizzate. In Active-Active bisogna sapere quale nodo gestisce una connessione.
• VPN funziona in molti scenari HA, ma non ogni tipo di sessione passa senza interruzioni. IPsec può gestire UDP/ICMP stateless meglio di TCP stateful.
• Web Protection funziona nel cluster. In Active-Active gli alert possono provenire da entrambi i nodi.
• Email Protection può essere specifica per nodo per quarantena e rilascio, perché ogni dispositivo salva dati propri per il traffico mail elaborato.
• Synchronized Application Control non è adatta ad Active-Active se la funzione non è supportata nella versione SFOS usata.
• NDR Essentials dovrebbe essere pianificato in HA solo con Active-Passive.
• sFlow funziona in ambienti HA solo sul Primary.
• Reports vengono generati localmente per dispositivo. Report unificati sono più utili tramite Sophos Central Firewall Reporting.
• Cellular WAN deve essere disattivato per HA.
• Modelli XGS Wi-Fi non supportano HA.

Se la reportistica o la conservazione dei log è importante, si dovrebbe pianificare in anticipo se utilizzare un server Syslog esterno o Sophos Central Firewall Reporting. Maggiori dettagli sono disponibili in Attivare Central Firewall Reporting.

Requisiti

Prima di implementare, è necessario verificare attentamente i requisiti HA rispetto al proprio ambiente. In particolare, l’uguaglianza del modello, la versione del firmware, le interfacce, il Cellular WAN e le piattaforme virtuali sono punti in cui piccole deviazioni possono avere grandi effetti in seguito.

Compatibilità hardware e modello

• Modello dell’appliance: entrambe le firewall devono essere dello stesso modello XGS, per esempio XGS 2100 con XGS 2100.
• Revisione hardware: con lo stesso modello XGS sono possibili revisioni hardware diverse.
• Modelli XGS Wi-Fi: non supportati. Esempi sono XGS 126w o XGS 136w.
• Moduli Flexi Port: se si usano moduli di espansione, il numero di Flexi Ports deve essere uguale su entrambi i dispositivi.
• Firmware: entrambi i dispositivi devono usare la stessa versione SFOS, incluso Maintenance Release e Build.
• Hardware più appliance virtuale: non è possibile come coppia HA.

Appliance virtuali e software

Le appliance virtuali o software devono anch’esse essere molto compatibili tra loro.

• Piattaforma: stesso tipo di appliance e stessa piattaforma SFOS.
• Hypervisor: stesso tipo di hypervisor.
• Risorse: stessi core CPU, risorse comparabili e stesso numero di interfacce di rete.
• Firmware: stessa versione SFOS, incluso il Build.
• Indirizzi MAC: in ambienti virtuali, l’opzione per indirizzi MAC assegnati dall’hypervisor può essere rilevante per evitare Promiscuous Mode. Una modifica causa downtime.

Deployment in cloud

Negli ambienti cloud si applicano ulteriori requisiti di piattaforma. Routing, interfacce virtuali, indirizzi IP, Security Groups, UDR o meccanismi di failover specifici del cloud devono adattarsi al design cloud specifico. L’approccio HA normale per le appliance non può essere trasferito senza verifica su Azure, AWS o altri ambienti cloud.

Se un Sophos Firewall viene eseguito nel cloud, si dovrebbe verificare la documentazione Sophos aggiornata per la piattaforma specifica e l’architettura di rete cloud prima di pianificare HA.

Licenze e registrazione

La licenza HA varia a seconda della piattaforma e della modalità HA. Tre domande sono cruciali: si tratta di hardware o virtuale/software? Si utilizza Active-Passive o Active-Active? E quale dispositivo è l’Initial Primary, cioè il dispositivo che detiene la licenza per il cluster? Questi punti dovrebbero essere verificati prima dell’implementazione con lo stato della licenza, i numeri di serie e la modalità di destinazione.

I punti di licenza più importanti:

• Base Firewall: per HA è necessaria una licenza Base Firewall. Le appliance hardware la hanno di default. Le appliance virtuali/software devono essere licenziate in modo adeguato.
• Active-Passive Hardware: solo il dispositivo Initial Primary necessita delle Subscription produttive. La firewall Auxiliary riceve una copia delle Subscription e può gestire traffico dopo un failover.
• Active-Active Hardware: entrambe le firewall necessitano di licenze adatte. I tipi di licenza devono corrispondere, le date di scadenza possono essere diverse.
• Active-Passive Virtual/Software: solo il Primary necessita delle licenze necessarie, inclusa Base Firewall.
• Active-Active Virtual/Software: entrambi i dispositivi necessitano di una propria licenza Base Firewall e di ulteriori licenze di protezione adeguate.
• Registrazione Hardware: entrambi i dispositivi hardware devono essere noti in Sophos Central o nel Sophos Licensing Portal e poter sincronizzare le licenze.
• Registrazione Virtual/Software Active-Passive: in Active-Passive Virtual/Software, secondo Sophos viene claimato solo il Primary.
• Sophos Central Management: sincronizzazione licenze e claiming non significano automaticamente che le firewall siano gestite anche tramite Sophos Central Firewall Management. Serve una Subscription aggiuntiva adatta.
• RMA e supporto: per sostituzione hardware e Advance Replacement è importante lo stato del supporto. In Active-Passive Hardware, Sophos indica Enhanced Plus Support sul dispositivo Primary come requisito rilevante per Advance Hardware Replacement. In Active-Active lo stato del supporto deve essere adeguato su entrambi i dispositivi.

Importante: in Active-Passive, l’Initial Primary è particolarmente importante, poiché questo dispositivo detiene la licenza per il cluster. Nella vista HA, sul dispositivo corrispondente è indicato che detiene la licenza per il cluster. In caso di dubbio, il dispositivo dovrebbe essere documentato chiaramente nel manuale operativo.

Se le licenze in Active-Active non corrispondono, secondo Sophos, inizialmente il bilanciamento del carico si interrompe. Se la discrepanza persiste, HA può essere disattivato. In una configurazione iniziale, Active-Active HA con licenze non corrispondenti non viene attivato correttamente. Pertanto, un controllo delle licenze è obbligatorio nella routine operativa.

Per le appliance virtuali/software, la licenza Base Firewall è particolarmente critica. Se viene disattivata o se l’Initial Primary non può sincronizzare la licenza per un periodo prolungato, HA può essere disattivato e altre funzioni di protezione diventano inattive. È rilevante qui una sincronizzazione con il server delle licenze almeno una volta ogni 90 giorni. Per gli ambienti produttivi, ciò significa che il cluster HA non deve solo funzionare tecnicamente, ma deve anche poter raggiungere regolarmente il server delle licenze.

Per l’operatività, si dovrebbe documentare almeno:

• quale dispositivo è l’Initial Primary
• quali numeri di serie o ID delle appliance appartengono al cluster
• quali licenze sono attive su quale dispositivo
• quando le licenze sono state sincronizzate l’ultima volta
• quale livello di supporto è disponibile per RMA o Advance Replacement
• chi autorizza le modifiche alle licenze, i rinnovi e i processi RMA

Requisiti di rete

• HA-Link: connessione dedicata tra le due firewall, idealmente direttamente con cavo Ethernet.
• Zona HA-Link: zona DMZ con SSH attivato per la zona.
• Indirizzi IP HA-Link: indirizzi IP statici nella stessa subnet, ma indirizzi diversi.
• Qualità HA-Link: alta larghezza di banda, bassa latenza, nessuna perdita di pacchetti.
• Switch: attivare RSTP sugli switch collegati alle porte firewall.
• Monitored Ports: monitorare solo porte effettivamente collegate e critiche.
• Cellular WAN: disattivare per HA.
• Peer Admin Port: pianificare separatamente, in modo che la firewall Auxiliary rimanga raggiungibile.

L’HA-Link non gestisce traffico normale di client o server. È solo rilevante per heartbeat, stato, sincronizzazione delle sessioni, sincronizzazione delle configurazioni e distribuzione Active-Active. Tuttavia, è estremamente critico. Se l’HA-Link si guasta, entrambi i firewall possono credere di essere primari. Proprio questo scenario di split-brain deve essere evitato.

Il Peer Admin Port è un accesso operativo proprio alla firewall Auxiliary. Le porte amministrative di entrambi i dispositivi devono trovarsi nella stessa subnet, ma usare indirizzi IP diversi. Dopo la creazione HA, la firewall Auxiliary è raggiungibile solo tramite questo indirizzo Peer Admin e solo da una rete adatta. Se entrambi i dispositivi usano ancora lo stesso IP di default o le porte admin si trovano in subnet diverse, HA fallisce oppure l’Auxiliary non è più raggiungibile in modo pulito.

Porte e interfacce

• Dedicated HA link: serve per heartbeat, stato, sincronizzazione configurazione e sessioni. Collegarlo direttamente o tramite uno switch molto affidabile. Non usare per traffico produttivo.
• Monitored ports: monitorano link produttivi critici. Monitorare WAN, importanti uplink DMZ o core, ma non selezionare porte inutilizzate.
• Peer Admin Port: consente l’accesso al WebAdmin Auxiliary. Pianificarlo e documentarlo separatamente; il client deve trovarsi nella subnet adatta.
• Interfacce di produzione: LAN, WAN, DMZ, VLAN e LAG vanno cablati e progettati in modo identico su entrambe le firewall.

Come Dedicated HA link sono possibili interfacce fisiche, VLAN o LAG. Le interfacce bridge e gli indirizzi IP alias non possono essere utilizzati come HA-Link dedicato. Se un LAG viene utilizzato come HA-Link, le interfacce parent devono essere strutturate allo stesso modo su entrambe le appliance.

Importante: Dedicated HA link e Monitored Port non possono essere la stessa interfaccia. Se un’interfaccia è già usata in una configurazione produttiva e viene comunque selezionata come HA-Link, la firewall può modificare o rimuovere configurazioni dipendenti dell’interfaccia. Per questo l’HA-Link deve essere libero e documentato in anticipo.

Pianificazione e design

Topologia consigliata per Active-Passive

Un design tipico Active-Passive appare così:

• entrambi i firewall si trovano nello stesso rack o in rack vicini
• tutte le interfacce produttive sono collegate allo stesso modo
• WAN va su switch ridondanti o passaggi provider documentati accuratamente
• LAN/DMZ vanno su strutture switch ridondanti
• l’HA-Link è collegato direttamente
• è previsto un accesso di gestione o amministrazione separato
• le porte WAN e core/DMZ sono definite come porte monitorate

Il punto più importante: il secondo firewall deve poter assumere la stessa posizione di rete in caso di errore. Pertanto, VLAN, trunk, LAG, porte switch e connessioni provider devono essere pianificati in modo coerente.

Topologia consigliata per Active-Active

Active-Active richiede la stessa pulizia fisica di Active-Passive, ma anche una chiara aspettativa sul traffico distribuibile.

Prima di Active-Active, si dovrebbe rispondere:

• Quale traffico è il collo di bottiglia?
• Esattamente quel traffico viene distribuito in Active-Active?
• Entrambe le appliance sono completamente e adeguatamente licenziate?
• I log, i report e i processi di risoluzione dei problemi sono preparati per entrambi i nodi?
• Ci sono servizi come VPN, NDR, Synchronized Application Control o scenari proxy che parlano contro Active-Active?

Senza una risposta chiara, Active-Passive è la scelta migliore.

LAN, WAN, DMZ e HA-Link

• LAN: zonare accuratamente le reti interne. Pianificare le VLAN non solo tecnicamente, ma anche dal punto di vista della sicurezza.
• WAN: considerare separatamente connessione provider, gateway di failover e SD-WAN rispetto a HA. HA non sostituisce un concetto di ridondanza WAN.
• DMZ: mantenere reti server e pubblicazioni esterne separate dalle reti client.
• HA-Link: connessione propria, indirizzata staticamente, zona DMZ, SSH consentito per DMZ. Non condurre comunicazioni utente o server su di esso.
• Management: limitare consapevolmente accesso amministrativo, Device Access e ACL.

Per proteggere i servizi firewall locali, si adatta Proteggere l’accesso a Sophos Firewall: configurare correttamente Device Access.

Requisiti degli switch

Gli switch sono spesso il fattore di rischio invisibile in HA. Un cluster HA funziona solo bene quanto l’ambiente Layer-2 sottostante.

Raccomandazioni:

• Attivare RSTP sugli switch coinvolti.
• Configurare i trunk in modo identico su entrambi i firewall.
• Consentire le VLAN su tutte le porte coinvolte in modo coerente.
• Costruire i LAG in modo identico.
• Non selezionare porte monitorate incomplete o non utilizzate.
• Collegare l’HA-Link il più direttamente possibile.
• Se l’HA-Link passa attraverso switch, il percorso deve essere stabile, a bassa latenza e senza perdita di pacchetti.

VLAN, LAG, bridge e RED

VLAN e LAG sono possibili in HA, ma aumentano i requisiti di pianificazione. Il cluster HA non dovrebbe essere il primo luogo in cui viene testato un design VLAN o LAG.

• VLAN: pianificare in modo identico su entrambi i dispositivi. Considerare l’interfaccia parent. VLAN come HA-Link è possibile, ma solo con un design molto pulito.
• LAG: utile per uplink core o connessioni switch ridondanti. Le interfacce parent devono essere coerenti.
• Bridge: HA in Bridge Mode è supportato, ma rende più complesso il troubleshooting. Per nuovi design, Gateway Mode è di solito più trasparente.
• RED: scenari RED e remoti possono influenzare HA, soprattutto se le reti vengono estese tra sedi. Verificare prima performance, latenza e scenari di errore.
• VPN: il failover VPN funziona in modo diverso a seconda del protocollo e del tipo di sessione. Testare IPsec e Remote Access separatamente.

Evitare lo split-brain

Lo split-brain significa che entrambi i firewall credono di essere attivi o standalone responsabili. Questo può accadere se l’HA-Link si guasta, ma i dispositivi rimangono comunque nella rete di produzione.

Misure:

• Non instradare l’HA-Link attraverso percorsi switch insicuri o instabili.
• Preferire la connessione diretta per l’HA-Link.
• Selezionare consapevolmente le porte monitorate.
• Configurare correttamente RSTP.
• Nessun cablaggio asimmetrico.
• Verificare lo stato HA dopo ogni modifica a switch o VLAN.
• Modificare i valori di keepalive solo con una ragione.

Preparazione della configurazione

Prima di configurare HA, non si dovrebbe improvvisare nella rete produttiva. Questa preparazione risparmia molto tempo in seguito.

Preparazione di entrambi i firewall

• Portare entrambi i firewall alla stessa versione SFOS, incluso il Build.
• Verificare lo stato della licenza e della registrazione.
• Disattivare il Cellular WAN.
• Assicurarsi che i modelli siano compatibili.
• Verificare l’equipaggiamento dei Flexi Port.
• Documentare le interfacce e le porte switch.
• Determinare la porta HA-Link.
• Collegare direttamente l’HA-Link o verificare il percorso switch.
• Pianificare la zona DMZ e l’accesso SSH per l’HA-Link.
• Documentare l’accesso amministrativo a entrambi i dispositivi.
• Creare un backup della configurazione esistente.

I backup non sono opzionali in HA. Prima della configurazione, degli aggiornamenti firmware e delle modifiche maggiori alle interfacce, dovrebbe essere disponibile un backup. Le basi sono descritte in Creare o ripristinare un backup di Sophos Firewall.

Prima di fare clic su Initiate HA va verificato anche:

• Admin ports nella stessa subnet, ma con IP diversi: altrimenti HA non si crea correttamente o l’Auxiliary non sarà raggiungibile dopo.
• Dedicated HA link senza dipendenze produttive: HA può modificare indirizzi IP e configurazioni dipendenti delle interfacce.
• Monitored Ports collegati su entrambi i dispositivi: una Monitored Port scollegata può impedire il cluster o causare subito failover.
• Cluster ID univoco: più cluster HA nello stesso dominio Layer-2 richiedono MAC virtuali diverse.
• Backup, SSMK e firmware build documentati: per restore, RMA o reimage il cluster deve essere riproducibile.

QuickHA o configurazione manuale

• QuickHA: caso standard. Veloce, robusto e sufficiente per la maggior parte delle configurazioni Active-Passive e Active-Active.
• Configurazione manuale: utile quando porte admin, HA-Link, Cluster ID, indirizzi peer e valori di dettaglio devono essere specificati consapevolmente.

QuickHA riconosce il peer tramite le interfacce HA-Link scelte. Una volta che i dispositivi si sono trovati, il cluster viene costruito. La passphrase viene utilizzata per stabilire il tunnel SSH crittografato e successivamente non viene trattata come una password riutilizzabile. Se un dispositivo viene sostituito, HA deve essere disattivato e riconfigurato.

I passaggi descritti qui si basano sulla configurazione HA ufficiale di Sophos, ma sono formulati come una checklist amministrativa pratica. Per modifiche produttive, non si dovrebbe solo cliccare attraverso l’assistente, ma documentare in anticipo ruoli, HA-Link, accesso admin, backup, stato della licenza e percorso di ritorno.

Configurare Active-Passive con QuickHA

1. Preparare il firewall primario

1. Accedere al WebAdmin sul firewall che diventerà primario.
2. Passare a System services > High availability.
3. Selezionare la modalità Primary (active-passive).
4. Utilizzare QuickHA.
5. Facoltativamente, assegnare un nome al nodo, ad esempio FW01.
6. Impostare una passphrase HA.
7. Memorizzare in modo sicuro la passphrase, poiché sarà necessaria subito sul firewall ausiliario.
8. Selezionare il Dedicated HA link.
9. Avviare Initiate HA.

Note:

• L’HA-Link non deve avere dipendenze produttive.
• Se QuickHA utilizza un’interfaccia non vincolata, Sophos assegna a questa interfaccia la zona DMZ e imposta le configurazioni specifiche per HA.
• L’HA-Link utilizza indirizzi IP statici nell’area Link-Local se QuickHA utilizza i valori predefiniti.
• SSH deve essere consentito per la zona HA-Link, poiché il tunnel HA viene stabilito su di esso.

2. Preparare il firewall ausiliario

1. Accedere al firewall che diventerà ausiliario.
2. Passare a System services > High availability.
3. Selezionare il ruolo Auxiliary.
4. Utilizzare QuickHA.
5. Facoltativamente, assegnare un nome al nodo, ad esempio FW02.
6. Inserire la stessa passphrase HA.
7. Selezionare la stessa porta HA-Link come sul lato primario.
8. Avviare Initiate HA.

Dopo la configurazione, il firewall primario sincronizza la configurazione sul firewall ausiliario. Sul firewall ausiliario, molte impostazioni locali vengono sovrascritte. Pertanto, il firewall ausiliario non dovrebbe essere configurato parallelamente come firewall produttivo autonomo prima della configurazione HA.

3. Verificare le impostazioni avanzate

Dopo la configurazione del cluster, non si dovrebbe semplicemente chiudere, ma verificare i seguenti punti:

• Stato HA di entrambi i nodi
• Ruolo e stato in alto a destra nel WebAdmin
• Dedicated HA link
• Porte monitorate
• Peer Admin Port
• Preferred primary
• Intervallo di keepalive e tentativi
• Titolare della licenza in Active-Passive
• Registrazione Sophos Central, se utilizzata

4. Impostare le porte monitorate

Le porte monitorate determinano se un guasto dell’interfaccia attiva un failover. Candidati tipici:

• Uplink WAN
• Uplink core LAN
• Uplink DMZ o server importanti

Non si dovrebbero monitorare porte che a volte sono intenzionalmente offline, non cablate o utilizzate solo per scenari opzionali. Una porta monitorata impostata in modo errato è una causa comune di failover inaspettati o di un cluster che non si avvia.

Configurare Active-Active con QuickHA

Active-Active viene configurato in modo simile, ma con un obiettivo diverso. Prima, entrambi i firewall devono essere adeguatamente licenziati.

1. Verificare in anticipo

• Entrambi i firewall hanno licenze adeguate.
• I tipi di licenza corrispondono.
• Entrambi i dispositivi sono registrati.
• Entrambi i dispositivi eseguono la stessa versione SFOS, incluso il Build.
• Il traffico rilevante beneficia effettivamente di Active-Active.
• I servizi con limitazioni Active-Active sono stati verificati.
• Il monitoraggio e la risoluzione dei problemi sono progettati per entrambi i nodi.

2. Configurare il firewall primario

1. Passare a System services > High availability.
2. Selezionare Primary (active-active).
3. Utilizzare QuickHA.
4. Assegnare un nome al nodo.
5. Impostare la passphrase HA.
6. Selezionare il Dedicated HA link.
7. Avviare HA.

3. Configurare il firewall ausiliario

1. Sul secondo dispositivo, passare a System services > High availability.
2. Selezionare Auxiliary.
3. Utilizzare QuickHA.
4. Inserire la stessa passphrase.
5. Selezionare la stessa porta HA-Link.
6. Avviare HA.

4. Testare dopo la configurazione

In Active-Active, è necessario testare più del semplice stato HA:

• Le connessioni vengono distribuite su entrambi i nodi?
• I log sono visibili su entrambi i dispositivi?
• Le connessioni VPN funzionano dopo un cambio di ruolo?
• Funzionano Web Protection, IPS, Application Control e le funzionalità di sicurezza rilevanti?
• Ci sono applicazioni che si comportano in modo asimmetrico?
• I report e gli avvisi vengono generati come previsto?

Configurazione manuale di HA

La configurazione manuale di HA è utile quando la logica automatica di QuickHA non offre abbastanza controllo.

Motivi tipici:

• si desidera utilizzare indirizzi IP HA-Link fissi
• il Peer Admin Port deve essere definito esattamente
• l’ID del cluster deve essere impostato consapevolmente
• esistono più cluster HA nello stesso ambiente Layer-2
• le appliance virtuali devono essere eseguite con opzioni MAC specifiche
• è necessario un rollout molto controllato

Nella configurazione manuale, si prepara prima il firewall ausiliario e poi si configura il firewall primario. Il primario deve conoscere l’indirizzo IP HA-Link del peer.

Campi importanti:

• Operation mode: Active-Passive o Active-Active.
• Initial device role: Primary o Auxiliary.
• Dedicated HA link: interfaccia per heartbeat, stato e sincronizzazione.
• Peer HA link IPv4: indirizzo dell’interfaccia HA-Link sul secondo dispositivo.
• Cluster ID: base per indirizzi MAC virtuali. Impostare in modo univoco per più cluster.
• Monitored ports: porte critiche il cui guasto dovrebbe attivare un failover.
• Peer administration settings: accesso alla firewall Auxiliary.
• Preferred primary: dispositivo che dovrebbe tornare Primary dopo un failover.
• Keepalive interval / Attempts: sensibilità del rilevamento HA. Modificare solo consapevolmente.

Validare il cluster

Dopo la configurazione, il cluster HA dovrebbe essere verificato sistematicamente.

Verifica WebAdmin

1. Accedere al firewall primario.
2. Verificare lo stato HA in alto a destra.
3. Passare a System services > High availability.
4. Verificare ruoli, stato, numeri di serie e modalità.
5. Assicurarsi che il cluster sia sincronizzato.
6. In Active-Passive, verificare quale dispositivo detiene la licenza per il cluster.

Verifica CLI

Nella Device Console, è possibile visualizzare lo stato HA:

system ha show details

Se non è chiaro quale dispositivo sia l’Initial Primary con licenza, questo valore può essere utile nella Advanced Shell:

nvram get "#li.master"

YES indica il dispositivo primario iniziale, NO il dispositivo ausiliario. Tali comandi dovrebbero essere documentati e utilizzati solo in casi di manutenzione o diagnosi chiari.

Se l’accesso alla shell non è ancora preparato, aiuta la guida Connettersi a Sophos Firewall tramite SSH.

Test funzionale

• Testare un client dalla LAN a Internet.
• Testare l’accesso ai server interni.
• Testare VPN.
• Testare scenari DNAT o WAF.
• Testare DNS e DHCP, se la firewall fornisce questi servizi.
• Verificare i log nel Log Viewer.
• Testare il cambio di ruolo HA in una finestra di manutenzione.
• Documentare quindi ruoli, stato e comportamento delle sessioni.

Operatività e manutenzione

Monitoraggio continuo

Un cluster HA dovrebbe essere monitorato attivamente. Solo perché due firewall sono nel rack, l’ambiente non è automaticamente ad alta disponibilità.

Dovrebbero essere monitorati:

• Stato HA
• Stato dei ruoli Primary/Auxiliary
• HA-Link
• Porte monitorate
• Stato delle licenze e delle sottoscrizioni
• Versioni firmware
• Risorse come CPU, RAM, disco
• Servizi centrali come IPS, Web, VPN, DNS, DHCP
• Log nel Log Viewer
• Avvisi in Sophos Central o via e-mail

Per i temi di disco e hardware, si dovrebbero considerare separatamente entrambi i nodi. I report locali, i file di log e lo stato SSD possono differire. Si adattano gli articoli Verificare lo spazio di archiviazione di Sophos Firewall e gestire i report e Verificare la salute dell’SSD di Sophos Firewall tramite SMART.

Log e report

I log e i report non vengono semplicemente fusi in un unico archivio dati locale. Ogni dispositivo scrive log per il traffico che gestisce. In Active-Active, questo è particolarmente importante, poiché il traffico può apparire su entrambi i nodi.

Sophos Central Firewall Reporting è utile in ambienti HA, poiché può analizzare centralmente i dati su più firewall. I log di troubleshooting locali si trovano sul firewall stesso. L’articolo Sophos Firewall Troubleshooting: Servizi e log spiega quali servizi e file di log sono rilevanti per le analisi.

Runbook per l’operatività HA

Un cluster HA necessita di un breve runbook operativo. Dovrebbe indicare quale dispositivo è l’Initial Primary, quali porte vengono monitorate, come raggiungere l’ausiliario, chi autorizza gli aggiornamenti firmware e quando HA viene disattivato per sostituzione o reimage.

Documentare almeno:

• Numero di serie, posizione, posizione nel rack e ruolo di entrambe le appliance.
• Dedicated HA link, Peer Admin Port, Cluster ID e porte monitorate.
• Preferred primary e comportamento previsto dopo il failover.
• Titolare della licenza, stato del supporto e contatto RMA.
• Procedura per aggiornamento firmware, backup, reimage e sostituzione hardware.
• Persona responsabile per log, Central Reporting, Syslog e casi di supporto.

Se solo il WebAdmin su un nodo è bloccato, non significa automaticamente che l’intero cluster HA sia difettoso. In tal caso, si dovrebbe verificare se un riavvio della GUI WebAdmin o un riavvio controllato del servizio è sufficiente prima di attivare un failover o un riavvio.

Modifiche al cluster

Le modifiche alla configurazione vengono effettuate sul firewall primario. Il firewall ausiliario non è il luogo per modifiche normali a regole, interfacce o policy.

Prima di modifiche maggiori:

• Creare un backup.
• Definire una finestra di manutenzione.
• Verificare lo stato HA.
• Aggiornare la documentazione.
• Stabilire un percorso di rollback.
• Dopo la modifica, verificare la sincronizzazione e il traffico.

Questo vale in particolare per:

• Interfacce
• VLAN
• LAG
• Zone
• Routing
• NAT
• VPN
• Device Access
• SD-WAN

Aggiornamenti firmware e backup

Aggiornamenti firmware in ambienti HA

Gli aggiornamenti firmware vengono avviati sul firewall primario. I dispositivi vengono aggiornati uno alla volta e il cluster può cambiare ruolo durante il processo.

Procedura tipica:

1. Avviare l’aggiornamento sul firewall primario.
2. Il firewall ausiliario viene aggiornato.
3. Il firewall ausiliario si riavvia e assume temporaneamente il controllo.
4. Il precedente primario viene aggiornato.
5. Il precedente primario si riavvia.
6. Se il preferred primary è attivo, può avvenire un ritorno al dispositivo preferito.

Tuttavia, vale la pena: gli aggiornamenti firmware appartengono a una finestra di manutenzione. Anche se il processo è progettato per minimizzare i tempi di inattività, alcune sessioni, connessioni VPN o applicazioni speciali possono reagire brevemente.

Per la preparazione, si adatta Aggiornamento firmware di Sophos Firewall - Preparazione e best practice.

Aggiornamenti pattern

Gli aggiornamenti pattern vengono installati sul firewall primario e sincronizzati sul firewall ausiliario. Questo vale anche per ambienti in cui gli aggiornamenti vengono controllati o installati offline.

Se un cluster HA viene eseguito in un ambiente isolato, prima di ogni aggiornamento pattern o licenza manuale, dovrebbe essere chiaro quale nodo è l’Initial Primary e quale nodo è attualmente primario. La procedura Air-Gap è descritta in Gestire la licenza Air-Gap e gli aggiornamenti pattern di Sophos Firewall.

Backup e ripristino

Backup e ripristino hanno particolarità in ambienti HA:

• I backup dovrebbero essere creati regolarmente e prima di ogni modifica maggiore.
• Il ripristino avviene sul firewall primario attuale.
• Dopo il ripristino, entrambi i firewall vengono deregistrati da Sophos Central e devono essere registrati nuovamente.
• Il ripristino causa un riavvio e un downtime, non un normale failover.
• Se un backup senza configurazione HA viene ripristinato su un cluster HA, HA viene disattivato e deve essere ricostruito.

Sostituzione di un nodo del cluster

Durante la sostituzione o il reimage di un nodo, HA non dovrebbe semplicemente continuare con il vecchio peer.

Punti importanti:

• Sophos distingue nel processo RMA se viene sostituita l’Auxiliary o il Primary.
• RMA e reimage in Active-Passive causano downtime pianificato e non dovrebbero essere trattati come un normale failover.
• Prima del reimage o della sostituzione, disattivare HA in modo pulito.
• Documentare la versione e il build del firmware.
• Creare un backup.
• Identificare il titolare della licenza.
• Rimuovere il dispositivo da Sophos Central Management se viene restituito o sostituito.
• Registrare il nuovo dispositivo.
• Configurare nuovamente HA, poiché la vecchia passphrase HA non viene riutilizzata per un nuovo dispositivo.

Se viene sostituita l’Auxiliary, il Primary sano di solito continua inizialmente come dispositivo HA standalone. Se viene sostituito il Primary, bisogna chiarire con particolare attenzione quale dispositivo era l’Initial Primary, quale backup viene usato e quando i cavi vengono spostati sul dispositivo sostitutivo. In entrambi i casi vanno documentati modello, revisione hardware, versione firmware, build, trasferimento licenza, stato Sophos Central e stato msync. Il servizio e il relativo file di log sono classificati nell’articolo Sophos Firewall Troubleshooting: Servizi e log.

Per la nuova installazione tecnica, si adatta Reinstallare Sophos Firewall OS: Reimage con USB-Stick. Se è presente un guasto hardware o un processo RMA, dovrebbe essere pianificato anche Preparare correttamente un guasto hardware e RMA di Sophos.

Risoluzione dei problemi

In caso di problemi profondi, si dovrebbe rimanere strutturati: prima verificare stato, HA-Link, porte monitorate, versione firmware e stato della licenza, poi considerare casi speciali o indicazioni del produttore. In questo modo, rimane chiaro se esiste un vero problema HA o se licenza, interfaccia, versione firmware o monitoraggio causano l’errore.

Log importanti e luoghi di diagnosi

• Stato HA: System services > High availability.
• Event Logs: Log viewer > System.
• Troubleshooting Logs: Diagnostics > Tools o tramite SSH sotto /log.
• Dettagli HA CLI: system ha show details.
• Problemi di interfaccia: show network interfaces, ifconfig, dmesg in casi di diagnosi appropriati.
• Titolare della licenza: vista HA WebAdmin o nvram get "#li.master".

Per analisi più approfondite, spesso aiuta l’articolo Sophos Firewall CLI Troubleshooting: comandi importanti.

Errori HA tipici

• Il cluster non si forma, versione firmware o build diversa: verificare la versione su entrambi i dispositivi e portarli alla stessa versione SFOS.
• Il cluster non si forma, modello o appliance non compatibile: verificare modello e numero di serie. Per hardware HA usare solo modelli XGS compatibili e uguali.
• HA could not be enabled: il Dedicated HA link potrebbe non essere connesso o il peer non raggiungibile. Verificare stato porta, cavo, switch e ping sull’IP HA-Link, poi stabilizzare cablaggio o HA-Link.
• HA-Link down: cavo, porta switch, VLAN o LAG possono essere difettosi. Verificare stato interfaccia, speed/duplex, trunk VLAN e membri LAG.
• Entrambi i dispositivi diventano Standalone: HA-Link guasto, rischio di split-brain. Verificare connessione fisica HA-Link e percorso switch, spegnere controllatamente un dispositivo, riparare HA-Link e poi riavviare.
• Auxiliary WebAdmin non raggiungibile: Peer Admin Port, subnet, route o Device Access non combaciano. Verificare IP dell’admin port e accesso dalla rete di management.
• Validation failed for HA interface IP: porte admin o indirizzi HA-Link non sono nella subnet attesa. Verificare indirizzi IP e /log/syslog.log e correggere l’indirizzamento.
• Failover avviene inaspettatamente: spesso una Monitored Port è guasta o scelta male. Verificare Monitored Ports e stato switch e monitorare solo porte critiche e stabili.
• Failover non avviene: probabilmente la porta rilevante non è monitorata. Inserire porte WAN, core o DMZ critiche come Monitored Ports.
• Active-Active non distribuisce come previsto: il tipo di traffico potrebbe non essere load-balanced. Verificare tipo di connessione, protocollo e log di entrambi i nodi; se il vantaggio non è chiaro, usare Active-Passive o adattare il design.
• Log apparentemente mancanti: il traffico potrebbe essere stato gestito dall’altro nodo o il logging non essere attivo. Verificare su entrambi i nodi e nel Log Viewer, attivare logging nelle regole e usare Central Reporting o Syslog.
• Report diversi: i report locali sono specifici per nodo. Confrontare i report dei due dispositivi o usare Sophos Central Firewall Reporting.
• Problema di licenza in Active-Active: i tipi di licenza potrebbero non coincidere. Verificare Licensing su entrambe le firewall e allineare le licenze.
• Problemi dopo firmware update: un nodo non è stato aggiornato correttamente o il cluster non è sincronizzato. Verificare stato HA, versioni firmware e log; nei cluster produttivi usare una finestra di manutenzione e coinvolgere Sophos Support.
• HA-Link Flexi-Port non funziona: speed/duplex o auto-negotiation non combaciano. Verificare Interface Advanced settings su entrambi i dispositivi e configurare entrambi i lati allo stesso modo o usare una porta fissa.

Procedura in caso di guasto HA-Link

Se l’HA-Link dedicato si guasta, è necessaria cautela. Entrambi i firewall potrebbero non vedersi più. Nel caso peggiore, entrambi i dispositivi inviano ARP/GARP e tentano di rivendicare la MAC del cluster per sé.

Procedura sicura:

1. Stabilizzare lo stato della rete.
2. Decidere quale dispositivo dovrebbe rimanere attivo.
3. Spegnere controllatamente l’altro dispositivo o scollegarlo dalla rete di produzione.
4. Riparare cavo HA-Link, porta switch, VLAN o LAG.
5. Riavviare il dispositivo.
6. Verificare lo stato HA.
7. Controllare log e ruoli.

Comandi CLI rilevanti

system ha show details

Mostra i dettagli HA nella Device Console.

show network interfaces

Aiuta con lo stato dell’interfaccia e le informazioni sul collegamento.

nvram get "#li.master"

Mostra nella Advanced Shell se il dispositivo è l’Initial Primary con licenza.

dmesg | grep PortE

Può fornire indicazioni su fluttuazioni di collegamento in caso di problemi hardware/interfaccia specifici.

Non ogni comando appartiene a ogni ambiente. Per i sistemi produttivi vale: prima documentare lo stato, poi verificare miratamente.

Checklist delle best practice

Pianificazione

• Verificare Active-Passive come variante standard.
• Utilizzare Active-Active solo con un chiaro obiettivo di prestazioni.
• Verificare entrambi i dispositivi per modello, firmware, Flexi Ports e licenze.
• Collegare l’HA-Link in modo dedicato e il più direttamente possibile.
• Selezionare consapevolmente le porte monitorate.
• Pianificare l’accesso di gestione su Primary e Auxiliary.
• Documentare in modo univoco l’ID del cluster.
• Documentare il design degli switch, VLAN e LAG.
• Pianificare RSTP sugli switch rilevanti.
• Considerare lo scenario di split-brain.
• Documentare il processo di backup e ripristino.

Implementazione

• Creare un backup in anticipo.
• Portare entrambi i firewall alla stessa versione SFOS.
• Disattivare il Cellular WAN.
• Preparare l’HA-Link con indirizzamento statico e zona DMZ.
• Consentire SSH per la zona HA-Link.
• Nominare chiaramente Primary e Auxiliary.
• Utilizzare la passphrase solo per la configurazione e non trattarla come password admin permanente.
• Dopo QuickHA, verificare le impostazioni avanzate.
• Impostare le porte monitorate solo quando è chiaro quali collegamenti sono stabili e critici.
• Testare il failover in una finestra di manutenzione.

Operatività

• Verificare regolarmente lo stato HA.
• Monitorare licenze e sincronizzazione.
• Eseguire aggiornamenti firmware solo preparati e con finestra di manutenzione.
• Testare regolarmente i backup.
• Effettuare modifiche alla configurazione solo sul Primary.
• Dopo modifiche a switch, VLAN o interfacce, verificare lo stato HA.
• Includere i log di entrambi i nodi.
• Utilizzare Sophos Central Firewall Reporting o Syslog per analisi più lunghe.
• Sostituzione o reimage di un nodo solo con disabilitazione HA pianificata e riconfigurazione.

Cose da non fare

• Non clusterizzare modelli diversi.
• Non pianificare modelli Wi-Fi XGS per HA.
• Non lasciare attivo il Cellular WAN in HA.
• Non impostare porte non cablate come porte monitorate.
• Non utilizzare VLAN instabili o percorsi switch come HA-Link.
• Non condurre servizi produttivi sull’HA-Link.
• Non considerare Active-Active come un semplice raddoppio delle prestazioni.
• Non aspettarsi o pianificare modifiche sul firewall ausiliario.
• Non eseguire ripristini senza finestra di manutenzione.

FAQ