Configurare l'High Availability (HA) su Sophos Firewall

High Availability, abbreviato in HA, collega due Sophos Firewall in un cluster. Nella maggior parte degli ambienti, Active-Passive con QuickHA è la scelta migliore: un firewall elabora il traffico e il secondo subentra in caso di guasto o manutenzione. Prima di iniziare, dispositivi, build del firmware, licenze, cablaggio e accesso di gestione devono essere compatibili.

Questo articolo accompagna dalla scelta della modalità HA alla configurazione, al test di failover, all’operatività e all’RMA. HA non sostituisce né un buon design di rete né i backup.

Scegliere modalità HA e architettura

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 vale quanto segue:

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

I due Sophos Techvids mostrano visivamente la configurazione e il cambio di ruolo:

Cosa significa High Availability

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 l’indirizzo IP di origine per la distribuzione: le connessioni TCP da indirizzi IP di origine pari vengono generalmente elaborate dalla Primary, mentre quelle da indirizzi dispari passano all’Auxiliary. Vengono distribuite le connessioni TCP inoltrate o tradotte, comprese quelle su interfacce VLAN. Dopo aver elaborato una connessione, l’Auxiliary invia i pacchetti direttamente alla destinazione senza ritornare attraverso la Primary. Questo metodo pari-dispari è fisso e non può essere modificato. Non vengono distribuiti il traffico non TCP, SD-RED e incapsulato, né le connessioni Layer 7 tramite DPI o proxy, tra cui SMTP Proxy, HTTPS, FTP sottoposto a scansione e H.323. Sophos non supporta load balancer esterni davanti al cluster per questa logica HA.

Entrambi i nodi richiedono licenze adeguate e registrano localmente i log del traffico che elaborano. Active-Active ha quindi senso solo con un obiettivo di prestazioni chiaro e quando il traffico rilevante viene effettivamente distribuito. Per la sola alta disponibilità, Active-Passive è generalmente più lineare.

Ruoli, stato e failover

Ruoli nel cluster HA

• Primary: dispositivo che gestisce la configurazione centrale del cluster. In entrambe le modalità HA, la Primary riceve il traffico.
• Auxiliary: secondo dispositivo del cluster. Sincronizza la configurazione dalla Primary e subentra quando necessario.
• Initial primary: dispositivo avviato come Primary durante la configurazione. In Active-Passive è generalmente anche il dispositivo che detiene la licenza. Questa proprietà rimane invariata indipendentemente dal fatto che il nodo sia attualmente Active o Passive.
• Preferred primary: dispositivo preferito che deve tornare Primary dopo un failover non appena è nuovamente disponibile in modo stabile.

In modalità Active-Passive, WebAdmin sull’Auxiliary non mostra Live users, DHCP leases o connessioni IPsec attive. È il comportamento previsto e non dimostra un errore di sincronizzazione. Per questi dati di runtime fa fede la Primary attualmente attiva.

Valori di stato durante l’operatività

• Active: il dispositivo elabora il traffico.
• Passive: il dispositivo è pronto, ma in Active-Passive non elabora traffico produttivo.
• Standalone: il dispositivo non vede il peer oppure HA non è completamente attivo. In caso di problemi con il HA-Link, entrambi i dispositivi possono diventare Standalone.
• Faulty: il dispositivo non è sufficientemente integro per partecipare normalmente al cluster.

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

Se un singolo Node si avvia in modalità Failsafe, documentare prima il suo ruolo e lo stato del peer. Verificare una Sophos Firewall in modalità Failsafe mostra il comando di diagnostica in sola lettura e spiega perché non bisogna riavviare entrambi i Nodes senza coordinamento né disattivare HA sulla base di semplici supposizioni.

Gli heartbeat sul Dedicated HA Link sono richieste VRRP. Per impostazione predefinita, Sophos Firewall invia un heartbeat ogni 250 millisecondi. Il peer viene considerato non raggiungibile solo dopo 16 heartbeat consecutivi mancanti. Per le Monitored Ports, invece, è sufficiente il guasto di una sola porta perché il dispositivo sia considerato non disponibile e venga attivato il failover.

Dopo il failover, WebAdmin sulla precedente Auxiliary Firewall mostra la configurazione della Primary. Alle sessioni attive si applicano limiti diversi:

Quando torna la Initial Primary, rimane Auxiliary se Preferred primary non è selezionato. Se è la Preferred primary, SFOS sincronizza prima i servizi e poi esegue automaticamente il ritorno. Il dispositivo che fino a quel momento operava da solo si riavvia durante il processo. Questo failback deve quindi essere pianificato in una finestra di manutenzione, anche se il cluster in genere rimane disponibile durante l’operazione.

Servizi supportati e limitati

Sophos HA supporta la maggior parte dei servizi firewall, ma i limiti operativi differiscono notevolmente:

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 e design di rete

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 e il modello dei moduli Flexi Port devono essere uguali 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.

Importante: i moduli Flexi Port non sono sostituibili a caldo. Per aggiungerli, spegnere in modo controllato entrambi i firewall, installare lo stesso modello di modulo su entrambi i dispositivi e riavviarli. Configurare quindi i nuovi Flexi Ports solo sul Primary corrente in Network > Interfaces. SFOS sincronizza questa configurazione delle porte con l’Auxiliary. Non modificare un solo nodo mentre il cluster è in funzione.

SFOS 22 non supporta più hardware XG o SG Series. Prima della migrazione a SFOS 22, questi dispositivi devono essere sostituiti con un’appliance XGS supportata o con una piattaforma virtuale adeguata.

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.

Se il cluster usa l’indirizzo MAC virtuale generato da SFOS, la piattaforma di virtualizzazione deve accettare le variazioni MAC. In VMware ESXi, impostare MAC Address Changes e Forged Transmits su Accept nel vSwitch o nel port group; i port group devono ereditare i valori del vSwitch o essere configurati di conseguenza. In Hyper-V, attivare Enable MAC address spoofing su tutti gli adattatori di rete virtuali di entrambi i firewall, tranne quello del Dedicated HA Link. In alternativa, selezionare Use host or hypervisor-assigned MAC address in HA; queste modifiche alla piattaforma non sono quindi necessarie.

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.

Gateway, Bridge e Discover/TAP

HA è disponibile nelle modalità gateway e bridge. La modalità Discover o TAP supporta solo Active-Passive. Se almeno un nodo opera in modalità discover, non è possibile creare un cluster Active-Active. Anche un’interfaccia TAP attiva impedisce la configurazione Active-Passive. Disattivare l’interfaccia TAP su entrambi i firewall tramite CLI, stabilire HA e riattivare TAP singolarmente su ciascun nodo. TAP rimane attivo anche sull’Auxiliary passiva.

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 includono per default, ma termina quando il dispositivo raggiunge l’End of Life. Nelle appliance cloud, virtuali e software la licenza Base Firewall non scade, ma deve essere presente per HA.
• 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 claimati in Sophos Central prima della configurazione HA e devono 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: Advance Hardware Replacement richiede Enhanced Plus Support sul Primary di un cluster hardware Active-Passive. In Active-Active, ogni dispositivo richiede Enhanced Support o Enhanced Plus Support.

Gestire la coppia HA in Sophos Central

Una coppia HA già configurata viene gestita in Sophos Central come una singola coppia, non come due firewall indipendenti. Entrambi i nodi devono avere la stessa versione firmware e, per Central Management, accesso Internet IPv4 funzionante e la sottoscrizione adeguata. Il claiming e la sincronizzazione delle licenze, da soli, non attivano la gestione.

Quando due firewall già gestiti singolarmente in Sophos Central vengono uniti in una coppia HA, Sophos consiglia di deregistrare prima entrambi. Stabilire HA localmente, registrare nuovamente la coppia completa per Central Management e, se necessario, spostarla in un altro gruppo Central.

Sul Primary attuale, aprire System > Sophos Central e selezionare Register both HA devices. Quindi attivare Central Management e, in Sophos Central sotto My Products > Firewall Management > Firewalls, aprire Approval Pending per il Primary e confermare accept-services. Dopo alcuni minuti la coppia dovrebbe comparire una sola volta con l’icona HA; le modifiche da Sophos Central vengono quindi applicate a entrambi i firewall.

Lo stato in Central non sostituisce la verifica locale. Dopo la registrazione, controllare localmente ruoli HA, sincronizzazione, stato delle licenze e un confronto di configurazione privo di impatto. Se compaiono due voci indipendenti o Approval Pending rimane, non deregistrare preventivamente nessuno dei firewall. Confrontare prima numeri di serie, tenant Central, percorso IPv4 e stato HA locale.

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.

Licenza sul firewall errato: se le Subscription sono state assegnate per errore all’Auxiliary anziché all’Initial Primary, la sincronizzazione non è sufficiente. Disattivare HA in modo pianificato sul Primary corrente, trasferire le Subscription dall’Auxiliary al Primary in Sophos Central e configurare nuovamente il cluster HA. Lo stesso trasferimento di licenza è necessario in caso di RMA o sostituzione di modelli meno recenti. Poiché i modelli HA devono essere identici, in caso di cambio modello devono essere sostituiti entrambi i dispositivi.

Se le licenze in Active-Active non corrispondono, il load balancing si interrompe per un massimo di tre giorni. Se la differenza persiste, la firewall disattiva HA. Durante la configurazione iniziale, Active-Active non viene attivato con licenze non corrispondenti.

L’Initial Primary deve sincronizzare le licenze almeno una volta ogni 90 giorni. Sulle appliance hardware, in caso contrario si interrompono le Subscription di protezione interessate, mentre Base Firewall ed Enhanced Support rimangono attivi. Sulle appliance Virtual/Software, la licenza Base Firewall viene disattivata, HA viene disabilitato e le altre funzioni di protezione diventano inattive. I cluster con licenze online richiedono quindi DNS, ora di sistema corretta, routing e accesso Internet ai servizi di licenza Sophos. I cluster isolati utilizzano invece il workflow manuale Air Gap documentato.

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.
• Indirizzi delle interfacce: Active-Active richiede indirizzi IP statici su tutte le interfacce. Active-Passive consente DHCP o PPPoE, ma per queste connessioni non è disponibile il failover delle sessioni.

In Active-Passive, le interfacce di produzione possono usare DHCP, DHCP Prefix Delegation o PPPoE, ma il Dedicated HA Link e le due porte di amministrazione richiedono comunque indirizzi statici. In Active-Active, tutte le interfacce devono avere indirizzi statici.

Configurare le interfacce breakout sul Primary. Riavviare prima il Primary per applicare la modifica e poi l’Auxiliary. Se sul Primary non esiste la configurazione breakout corrispondente, la sincronizzazione elimina una configurazione breakout presente solo sull’Auxiliary.

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. Non può essere riutilizzato per HSRP, perché i messaggi hello HSRP non attraversano il Dedicated HA Link. 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 dedicato alla firewall Auxiliary. Entrambi i nodi usano la stessa rete di management. SFOS sincronizza però la normale configurazione dell’interfaccia, incluso l’IP PortMGMT, dal Primary all’Auxiliary; questo IP non può quindi essere diverso per nodo. L’impostazione separata Peer Administration assegna all’Auxiliary un IP di amministrazione aggiuntivo e diverso nella stessa subnet. QuickHA usa automaticamente l’interfaccia della sessione WebAdmin corrente. Dopo la creazione HA, l’Auxiliary è raggiungibile solo tramite questo indirizzo Peer Admin dalla subnet corrispondente.

L’indirizzo predefinito delle porte normali è 172.16.16.16; il PortMGMT dedicato delle appliance più grandi usa 10.0.1.1. Il Primary è raggiungibile da qualsiasi zona in cui HTTPS è consentito in Administration > Device access. Per accedere al WebAdmin dell’Auxiliary, l’endpoint di amministrazione deve trovarsi nella stessa subnet della sua porta di amministrazione.

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. QuickHA può raggruppare fino a quattro interfacce fisiche non associate in un HA redundant link; se si usa un LAG già configurato, le interfacce parent devono essere strutturate allo stesso modo su entrambe le appliance.

Porte ad alta velocità: Per le porte 25, 50 e 100 GbE delle XGS 7500/8500 Series, selezionare su entrambi i lati lo stesso Link mode con velocità e duplex corrispondenti in Network > Interfaces > Advanced settings. Usare quindi Show recommended settings > Load recommended configuration per negotiation e Forward Error Correction (FEC). Se i valori consigliati sono vuoti, disattivare Auto-negotiation per Media Type e FEC. Per le altre porte usare Automatic o valori speed/duplex identici e mantenere MTU e MSS predefiniti. Quando QuickHA seleziona un’interfaccia non associata, SFOS ne reimposta gli Advanced settings; ricontrollarli dopo la creazione HA.

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.

Design di rete

Entrambe le firewall devono poter assumere la stessa posizione di rete in caso di guasto. Interfacce produttive, trunk VLAN, LAG, porte switch e connessioni del provider devono quindi essere cablati in modo equivalente su entrambi i lati. Ridondanza WAN, SD-WAN e failover del provider restano attività separate: HA non li sostituisce.

• Collegare il Dedicated HA link direttamente, se possibile. Se passa attraverso switch, il percorso deve essere stabile, a bassa latenza e senza perdita di pacchetti.
• Nodi HA geograficamente separati sono sensati solo attraverso una rete Layer 2 a bassa latenza nello stesso dominio broadcast. Il Dedicated HA Link rimane nella stessa subnet IP; latenza elevata o perdita di pacchetti rendono il design inadatto.
• Attivare RSTP sugli switch coinvolti e configurare VLAN, trunk e LAG in modo identico su entrambi i lati.
• Monitorare solo uplink WAN, core o DMZ collegati in modo permanente. Una Monitored Port volutamente scollegata causa altrimenti un failover.
• VLAN e LAG sono supportati, ma devono utilizzare le stesse interfacce parent su entrambi i nodi. Bridge Mode funziona, ma è più complesso da diagnosticare rispetto a Gateway Mode.
• Testare separatamente scenari VPN, RED e remoti, perché non tutte le sessioni vengono trasferite in modo trasparente.
• Limitare consapevolmente accesso di management e Device Access. Vedere Proteggere l’accesso a Sophos Firewall: configurare correttamente Device Access.

Per Active-Active deve inoltre essere chiaro quale collo di bottiglia viene ridotto dal traffico TCP realmente distribuibile. Se licenze, servizi e troubleshooting su entrambi i nodi non sono definiti, Active-Passive resta la scelta migliore.

Attenzione: in caso di split-brain, entrambe le firewall si considerano responsabili. Ciò può causare un uso duplicato di indirizzi IP e MAC e un’interruzione della produzione. Se l’HA-Link si guasta, stabilire prima quale nodo deve restare attivo e arrestare l’altro in modo controllato o scollegarlo dalla rete di produzione.

Preparare la 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.
• Se LINCE è necessario, uniformare la modalità su entrambi i dispositivi prima di configurare HA.

FIPS segue una sequenza diversa da LINCE. La modalità FIPS 140-3 viene prima attivata sul Primary standalone, provocando un factory reset; durante il successivo setup HA, Sophos attiva automaticamente FIPS sull’Auxiliary.

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.

Definire LINCE prima di HA

A partire da SFOS 21.5 MR1, LINCE non può più essere attivato o disattivato dopo la creazione di un cluster HA. Se la certificazione è necessaria, eseguire il comando seguente nella Device Console su entrambe le firewall ancora autonome.

Avvertenza: Prima assicurarsi che WebAdmin o la console locale siano disponibili come accesso amministrativo alternativo. Il comando attiva LINCE, riavvia il servizio SSH e interrompe le sessioni SSH esistenti.

system certification lince enable

Verificare quindi lo stato LINCE su entrambi i dispositivi e solo dopo configurare HA. In caso di restore, il backup e il cluster di destinazione devono avere lo stesso stato LINCE.

Comprendere e attivare la modalità LINCE su Sophos Firewall spiega perché la modalità non certifica automaticamente la build SFOS installata e quali algoritmi SSH devono essere verificati prima dell’attivazione.

QuickHA o Interactive mode

• QuickHA: caso standard. Veloce, robusto e sufficiente per la maggior parte delle configurazioni Active-Passive e Active-Active.
• Interactive mode: utile quando Admin Ports, indirizzi HA-Link, Cluster ID, Monitored Ports e valori dettagliati devono essere definiti prima della configurazione.

QuickHA richiede inizialmente solo ruolo, nome del nodo, passphrase e Dedicated HA link. La passphrase deve contenere da 10 a 20 caratteri, almeno una lettera maiuscola, una minuscola, un numero e un carattere speciale. Viene utilizzata una sola volta per generare le chiavi SSH e poi eliminata. In caso di sostituzione di un dispositivo, HA deve quindi essere disattivato e riconfigurato.

I dispositivi QuickHA preparati continuano a cercare il peer finché non lo trovano. Possono quindi essere configurati in anticipo e collegati successivamente nella sede di destinazione. Quando un dispositivo ha scoperto il peer e la creazione HA è in corso, questo processo di discovery non può più essere interrotto. La selezione delle interfacce, la passphrase e il peer previsto devono quindi essere corretti prima che entrambi i link HA siano raggiungibili contemporaneamente.

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 HA

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 da 10 a 20 caratteri con lettera maiuscola, lettera minuscola, numero e carattere speciale.
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:

• Se QuickHA utilizza un’interfaccia non associata, Sophos le assegna la zona DMZ e, per impostazione predefinita, 169.254.192.1. SSH viene attivato automaticamente per la zona.
• La firewall rimuove le configurazioni dipendenti dell’interfaccia HA-Link selezionata. L’interfaccia deve quindi essere libera da dipendenze produttive.

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.

È possibile selezionare interfacce fisiche, LAG e interfacce non associate con una VLAN configurata. Un’interfaccia non associata senza VLAN non può essere selezionata come Monitored Port.

Active-Active con QuickHA

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

La procedura corrisponde ad Active-Passive, ma su FW01 si seleziona Primary (active-active). Prima della configurazione, entrambi i dispositivi devono essere claimati, utilizzare lo stesso Build SFOS e avere tipi di licenza adeguati; tutte le interfacce richiedono indirizzi IP statici. Monitoraggio e troubleshooting devono coprire entrambi i nodi e il traffico rilevante deve beneficiare della distribuzione TCP descritta sopra.

Test 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?

Interactive mode

Interactive mode è utile quando la logica automatica di QuickHA non offre abbastanza controllo.

Prima della configurazione, consentire SSH e Ping/Ping6 per la zona DMZ su entrambi i dispositivi in Administration > Device access. Interactive mode seleziona inizialmente e in modo automatico la prima interfaccia DMZ come Dedicated HA link. Se questa interfaccia non è destinata a HA o ha dipendenze produttive, selezionare prima del salvataggio un’interfaccia fisica, VLAN o LAG preparata e libera.

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

In Interactive mode si configura prima l’Auxiliary e poi la Primary. In questo modo il rilevamento del peer sulla Primary non scade mentre il secondo nodo viene ancora preparato.

1. Configurare l’Auxiliary

1. Su FW02 passare a System services > High availability.
2. Selezionare Initial device role > Auxiliary e HA configuration mode > Interactive mode.
3. Definire il nome del nodo e una passphrase conforme alle regole indicate sopra.
4. Selezionare la porta DMZ libera per il Dedicated HA link. Il firewall elimina le configurazioni dipendenti esistenti di questa interfaccia.
5. Salvare e attendere la conferma che la configurazione dell’Auxiliary sia stata applicata.

2. Configurare la Primary

1. Su FW01 selezionare Primary (active-passive) oppure Primary (active-active) e Interactive mode.
2. Definire una Cluster ID univoca e il nome del nodo.
3. Inserire la passphrase di FW02.
4. Specificare lo stesso Dedicated HA link e l’indirizzo IP statico HA-Link dell’Auxiliary.
5. Selezionare le Monitored ports critiche.
6. In Peer administration settings, specificare l’interfaccia di management e un indirizzo IP dedicato per FW02.
7. Per le appliance virtuali, se necessario, selezionare l’indirizzo MAC assegnato dall’host o dall’hypervisor. Una modifica successiva causa downtime.
8. Definire Preferred primary e selezionare Initiate HA.

Dopo la configurazione, modificare i valori di keepalive solo per un motivo documentato. Gli intervalli consentiti sono da 250 a 500 millisecondi per l’intervallo e da 16 a 24 tentativi. Il valore predefinito di 250 millisecondi e 16 tentativi produce un timeout di quattro secondi. Questi valori non possono essere modificati quando i dispositivi hanno stato Standalone o Faulty. Dopo il timeout, la nuova Primary esegue controlli interni prima di iniziare a elaborare il traffico.

Collegare una nuova Auxiliary virtuale come HA spare

Per una nuova Auxiliary virtuale in Active-Passive, il Setup Assistant può usare Connect as HA spare. Active-Active o due firewall Virtual/Software già esistenti richiedono ancora QuickHA o Interactive mode su entrambi i dispositivi.

1. Sul Primary esistente, consentire SSH per DMZ in Administration > Device access e preparare Active-Passive in Interactive mode. Documentare Dedicated HA Link, IP del peer, Peer Administration e passphrase HA. Il Primary può mostrare Standalone finché la nuova Auxiliary non si collega.
2. Installare il nuovo firewall virtuale con esattamente lo stesso build SFOS, avviare il Setup Assistant e impostare una nuova password amministratore.
3. Selezionare Connect as HA spare e inserire il numero di serie del Primary esistente, la stessa passphrase HA, la stessa interfaccia Dedicated HA Link e un indirizzo IP libero con la stessa subnet mask.
4. Selezionare Apply, Continue e Finish. SFOS crea l’Auxiliary, assegna un numero di serie che inizia con HAAUX e configura automaticamente il Dedicated HA Link e la porta di amministrazione.
5. Dopo alcuni minuti, aggiornare WebAdmin dell’Auxiliary e accedere nuovamente. Verificare poi sul Primary ruoli, sincronizzazione, Peer Admin, Monitored Ports e failover.

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, il seguente comando read-only mostra ruoli, stato e sincronizzazione del cluster. Non modifica la configurazione:

system ha show details

Verificare i parametri operativi di SFOS 22

SFOS 22 pubblica due controlli HA aggiuntivi. Entrambi vanno letti prima di qualsiasi modifica:

system ha auxiliary_system_traffic_through_dedicated_link show
system ha load-balancing show

Il primo controllo determina il percorso del traffico di sistema inviato dalla stessa Auxiliary Firewall. Per impostazione predefinita, tutto questo traffico passa sul Dedicated HA Link. Oltre a all, sono disponibili none e only_dynamic_interface. Sophos non definisce con maggiore precisione quali flussi siano considerati un’interfaccia dinamica nell’ultima modalità. Questa opzione va quindi usata solo per un caso confermato sul build installato, non come correzione generale del routing.

Il secondo controllo attiva o disattiva la distribuzione del traffico idoneo tra i firewall. Non sostituisce la selezione della modalità HA e non rende idonei al load balancing i servizi e i tunnel esclusi sopra. Eseguire le modifiche singolarmente in una finestra di manutenzione e salvare prima entrambi gli output show:

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

Verificare quindi ruoli, sincronizzazione, Dedicated HA Link, nuove sessioni, log locali dei nodi e connessioni di sistema avviate dalla stessa Auxiliary. Per il rollback, ripristinare il valore rilevato in precedenza. Sophos documenta all come valore predefinito solo per il primo controllo; non si presume un valore predefinito per il load balancing.

Il dispositivo che detiene la licenza come Initial Primary si verifica in System services > High availability. Sophos documenta inoltre il seguente controllo CLI ufficiale nella Advanced Shell:

nvram get "#li.master"

YES identifica l’Initial Primary che detiene le licenze del cluster; NO identifica il dispositivo configurato come Auxiliary. Il comando è read-only. La vista HA rimane più pratica per i controlli quotidiani, ma anche l’output della shell è documentato ufficialmente.

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

È necessario monitorare stato HA e ruoli, Dedicated HA link, Monitored Ports, licenze, firmware, CPU, RAM, disco e servizi centrali. Gli avvisi devono essere inoltrati a Sophos Central, via e-mail o al sistema di monitoring esistente.

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

Ogni nodo scrive i log del traffico che elabora. In Active-Active è quindi necessario controllare entrambi i dispositivi. Per un’analisi comune sono adatti Sophos Central Firewall Reporting o Syslog. I file locali sono spiegati in Sophos Firewall Troubleshooting: Servizi e log.

L’Auxiliary invia email di report solo per i report che contengono dati su quel nodo, ad esempio attività email o Pattern Updates. Non invia report senza dati, come Security Dashboard o Security Audit. L’assenza di un’email per questi tipi di report non dimostra quindi, da sola, la presenza di un guasto.

Per gli eventi HA, aprire Log viewer > System separatamente su ogni nodo e filtrare il periodo interessato. Per un’analisi dettagliata, aprire Diagnostics > Tools > Troubleshooting logs > Select files su entrambi i dispositivi, selezionare almeno csc.log e salvare separatamente ogni pacchetto con Download. Solo il confronto dei due nodi mostra la sequenza completa del cluster.

Runbook per l’operatività HA

Nel runbook operativo 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 e responsabilità per aggiornamento firmware, backup, reimage, sostituzione hardware, log 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

Modificare regole, interfacce e policy solo sulla Primary. Prima di modificare interfacce, VLAN, LAG, zone, routing, NAT, VPN, Device Access o SD-WAN:

• Creare un backup.
• Definire una finestra di manutenzione.
• Verificare lo stato HA.
• Aggiornare la documentazione.
• Stabilire un percorso di rollback.
• Verificare quindi sincronizzazione e traffico.

Sincronizzazione manuale e cambio di ruolo forzato

La sincronizzazione automatica è il funzionamento normale. Utilizzare Sync auxiliary device sul Primary o sull’Auxiliary solo per risolvere un problema di sincronizzazione confermato. L’Auxiliary si riavvia, esegue una sincronizzazione completa del database e dei file correlati e rimane Auxiliary. Log e report restano locali su ciascun nodo. Durante il processo il firewall interrompe tutte le connessioni con masquerading, quindi l’operazione deve essere pianificata in una finestra di manutenzione.

In Active-Passive, forzare l’Auxiliary a subentrare con Switch to passive device sul Primary corrente o Switch to active device sull’Auxiliary corrente. Il Primary corrente si riavvia. È un cambio di ruolo pianificato con rischio per le sessioni, non un semplice interruttore.

Disattivare HA in modo controllato

Quando possibile, disattivare HA sul Primary corrente in System services > High availability > Disable HA. Il nodo utilizzato determina il risultato:

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 Preferred primary è attivo, può avvenire un ritorno al dispositivo preferito.

Gli aggiornamenti firmware devono comunque essere eseguiti in 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.

Il rollback del firmware della coppia HA segue lo stesso processo e non richiede la disattivazione preventiva di HA.

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

Aggiornamenti pattern

Gli aggiornamenti pattern vengono installati sulla Primary e sincronizzati automaticamente sull’Auxiliary. 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

Creare backup regolarmente e prima di ogni modifica importante. Se LINCE è attivo, il backup e il cluster di destinazione devono avere lo stesso stato LINCE. Esistono tre casi di ripristino:

Se il Primary era registrato come gateway Sophos ZTNA, aggiungerlo nuovamente come gateway in Sophos ZTNA dopo il ripristino sul cluster HA.

Reimage dei nodi HA in Active-Passive

Un reimage interrompe l’operatività e, secondo Sophos, queste procedure si applicano solo ad Active-Passive. Eseguire prima system diagnostics show version-info nella Device Console di entrambi i nodi, documentare firmware, build e Initial Primary e salvare esternamente un backup aggiornato.

Se il cluster utilizza Sophos Central Synchronized Security, la coppia HA deve essere rimossa dalla gestione Central prima di restituire il dispositivo tramite il processo RMA. Dopo la sostituzione, il nuovo cluster HA viene registrato nuovamente in Central. Questo evita conflitti nella sincronizzazione di numeri di serie e licenze con il vecchio dispositivo ancora registrato.

Sostituzione dell’Auxiliary dopo RMA

La sostituzione o il reimage di un nodo causa un’interruzione pianificata. Le procedure seguenti valgono per Active-Passive; per Active-Active, il processo concreto deve essere pianificato con Sophos Support.

1. Verificare modello e revisione hardware del dispositivo sostitutivo e installare esattamente lo stesso Build firmware della Primary sana.
2. Claimare il dispositivo sostitutivo in Sophos Central e trasferire la licenza del dispositivo Auxiliary guasto.
3. Spostare i cavi dal dispositivo guasto a quello sostitutivo.
4. Sulla Primary sana, disattivare HA in System services > High availability.
5. Nella Advanced Shell, verificare che msync sia terminato:

service -S | grep msync

Il risultato previsto è UNTOUCHED o STOPPED. Il comando non modifica nulla; uno stato diverso indica che HA non deve ancora essere ricostruito. Configurare quindi la Primary sana come Primary e il dispositivo sostitutivo come Auxiliary.

Sostituzione della Primary dopo RMA

1. Scaricare un backup aggiornato dall’Auxiliary sana e deregistrare il dispositivo da Sophos Central.
2. Portare il dispositivo sostitutivo allo stesso Build firmware, claimarlo in Sophos Central e trasferire la licenza della Primary guasta.
3. Ripristinare il backup sul dispositivo sostitutivo.
4. Spostare i cavi dell’Auxiliary sana sul dispositivo sostitutivo. Da questo momento, il dispositivo sostitutivo elabora il traffico come firewall autonoma.
5. Ripristinare l’Auxiliary precedente alle impostazioni di fabbrica, claimarla nuovamente in Sophos Central e collegare i cavi previsti.
6. Ricostruire HA con il dispositivo sostitutivo come Primary e il dispositivo ripristinato come Auxiliary.

Attenzione: backup/restore, Factory Reset e spostamento dei cavi causano downtime. Numeri di serie, Initial Primary, Build firmware, trasferimento licenze, stato Central e percorso di rollback devono essere documentati prima di iniziare.

Per la nuova installazione tecnica, si adatta Reinstallare Sophos Firewall OS: Reimage con chiavetta USB. 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: Monitor & Analyze > Logs > Troubleshooting logs o tramite SSH sotto /log.
• Dettagli HA CLI: vedere l’unica verifica CLI descritta in Validare il cluster.
• Problemi di interfaccia: show network interfaces, ifconfig, dmesg in casi di diagnosi appropriati.
• Titolare della licenza: System services > High availability.

Per una prima analisi, questi file sono particolarmente utili:

• ha.log: errori di configurazione, configurazione HA riuscita e cambi di stato.
• ha_pair.log: rilevamento del peer in QuickHA.
• ha_tunnel.log: tunnel SSH sul Dedicated HA link.
• msync.log: sincronizzazione della configurazione HA.
• ctsyncd.log: sincronizzazione delle sessioni Conntrack.
• filesync.log: sincronizzazione di file specifici dei servizi, per esempio per route dinamiche o DHCP.

Ogni nodo conserva solo log e report del traffico che elabora. Per l’Auxiliary, accedere tramite il relativo indirizzo Peer Admin oppure consultare i file di log via SSH su quel nodo.

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. Se il nodo interessato si è effettivamente riavviato e non ha soltanto cambiato ruolo, verificare il riavvio inatteso in modo specifico per quel nodo.
• 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.

Altri comandi CLI

Oltre alla verifica dello stato HA in Validare il cluster, il seguente comando read-only nella Device Console mostra

show network interfaces

lo stato delle interfacce e dei link. Per il Dedicated HA link e le Monitored Ports collegate sono previsti stati UP.

Per i link flap, passare alla shell tramite Device Management > Advanced Shell e sostituire PortE con il nome reale dell’interfaccia:

dmesg | grep PortE

L’output filtra i messaggi del kernel per questa interfaccia. Ripetuti messaggi link-up/link-down indicano problemi di cavo, transceiver, porta o negoziazione. Il comando non modifica nulla; dmesg contiene però solo il buffer kernel corrente e non sostituisce un’analisi dei log a lungo termine.

La verifica fisica completa con ethtool, dati del modulo e casi speciali noti è descritta in Scegliere e verificare SFP e SFP+ su Sophos Firewall.

Prima di ogni intervento approfondito, salvare output e timestamp. I comandi sono stati verificati rispetto alla documentazione Sophos attuale, ma non eseguiti sull’hardware specifico del cliente.

Checklist per il go-live

• Scelta motivata tra Active-Passive e Active-Active.
• Modelli, Flexi Ports, Build SFOS, stato LINCE, claiming e licenze verificati.
• Backup e percorso di rollback disponibili.
• Dedicated HA link libero, stabile e possibilmente collegato direttamente.
• VLAN, LAG, porte switch e RSTP coerenti su entrambi i lati.
• Accesso Peer Admin all’Auxiliary testato.
• Scelte come Monitored Ports solo interfacce stabili e critiche.
• Cluster ID, Initial Primary, Preferred primary e numeri di serie documentati.
• WebAdmin, stato CLI e log rilevanti verificati.
• LAN, Internet, server, VPN, DNAT/WAF, DNS e DHCP testati funzionalmente.
• Failover e ritorno testati in una finestra di manutenzione.
• Monitoring e procedure firmware, restore e RMA documentati nel runbook.

FAQ

Fonti ufficiali: Registrazione e licenze · LINCE in ambienti HA · RMA in un cluster Active-Passive · FAQ HA