Configurare e testare il failover WAN su Sophos Firewall

Una seconda connessione Internet non diventa automaticamente una linea di riserva su Sophos Firewall. Un nuovo gateway WAN è per impostazione predefinita Active e partecipa quindi al Load Balancing. Per un classico design Primary/Backup, il secondo gateway deve essere impostato su Backup nel WAN link manager.

La procedura rapida per una linea principale e una di riserva:

Configurare completamente entrambe le interfacce WAN in Network > Interfaces e testarle singolarmente.
In Network > WAN link manager, impostare il gateway principale come Active e quello di riserva come Backup.
Per il gateway di backup, selezionare Activate this gateway: If active gateway fails: ANY.
Configurare Failover rules affidabili per entrambi i gateway.
Testare failover e failback, cioè il ritorno alla linea principale, con traffico DNS, HTTPS e applicativo reale.

Per questo semplice failover della connessione Internet predefinita non serve una route SD-WAN dedicata. SD-WAN è necessaria quando determinati flussi devono usare percorsi specifici o quando la scelta del percorso deve basarsi su latenza, jitter e perdita di pacchetti.

Inquadrare correttamente Active, Backup e Load Balancing

Il tipo di gateway determina se una linea partecipa normalmente al traffico Internet:

Active: se sono disponibili più gateway attivi, il firewall distribuisce le nuove sessioni in base ai pesi configurati.
Backup: il gateway subentra solo quando viene soddisfatta la relativa condizione di attivazione.

Almeno un gateway WAN deve restare Active. Se tutti i gateway sono impostati soltanto come Backup, manca il normale percorso WAN predefinito; in particolare, il traffico generato dal firewall non può essere inoltrato.

Il Weight non descrive la larghezza di banda. In modalità weighted round-robin, un rapporto da 2 a 1 significa che il firewall assegna due nuove sessioni al primo gateway e la successiva al secondo. Un singolo download non viene suddiviso tra le due linee e il volume di dati trasferito può discostarsi notevolmente da questo rapporto.

Per impostazione predefinita, Sophos Firewall utilizza Session Persistence. Non rimane sullo stesso link WAN soltanto una singola connessione esistente: a seconda del Persistence Factor, anche altre sessioni dello stesso Source IP possono essere assegnate nuovamente a quel link. Dopo l’accesso a Option 4: Device Console, il metodo attuale è visibile con un comando in sola lettura:

show routing wan-load-balancing

Il comando non modifica nulla. Mostra se sono attivi Session Persistence o weighted round-robin e aiuta quindi a interpretare una distribuzione inattesa dei percorsi. In un design puramente Active/Backup, il metodo è generalmente secondario, perché sia nello stato normale sia in caso di guasto è disponibile un solo percorso previsto.

Il failover WAN non equivale a un failover HA. Il WAN link manager cambia il percorso Internet sullo stesso firewall. Un cluster HA Sophos Firewall, invece, subentra in caso di guasto di un dispositivo o di una porta monitorata.

Preparare il failover WAN

Entrambe le connessioni del provider devono prima funzionare in modo indipendente. I concetti di base relativi a zona WAN, assegnazione IP e gateway sono descritti in Pianificare zone e interfacce Sophos Firewall.

Un esempio semplice:

WAN1 Fiber: linea principale, gateway gw-fiber, Type: Active, Weight: 1
WAN2 DSL: linea di riserva, gateway gw-dsl, Type: Backup
Attivazione della riserva: If active gateway fails: ANY
Azione all’attivazione: Inherit weight of the failed active gateway
Azione al ripristino: Serve new connections through restored gateway

I nomi possono essere scelti liberamente e dovrebbero descrivere chiaramente la connessione. Il tipo di gateway e le azioni sono invece impostazioni funzionali. Prima della commutazione, il gateway di backup dovrebbe già avere uno stato verde e il traffico client reale dovrebbe essere stato testato con successo attraverso questa linea.

Serve inoltre un percorso di ritorno sicuro per l’amministrazione. Se il firewall viene modificato da remoto, WebAdmin non dovrebbe essere raggiungibile esclusivamente attraverso la linea che verrà scollegata durante il test. Un backup aggiornato della configurazione, una finestra di manutenzione e una persona sul posto oppure un percorso di management indipendente evitano che un semplice test di failover si trasformi in un’interruzione prolungata.

Occorre inoltre annotare in anticipo tutti i servizi legati a un indirizzo IP pubblico. Tra questi rientrano pubblicazioni DNAT, endpoint IPsec, Remote Access, allowlist dei provider, mail server e sistemi di monitoraggio esterni. L’accesso Internet in uscita può già funzionare, mentre questi servizi potrebbero non essere ancora raggiungibili o autorizzati tramite il nuovo indirizzo pubblico.

Configurare Primary/Backup

Verificare interfacce WAN e stato dei gateway

In Network > Interfaces, configurare entrambe le porte WAN con i parametri statici, DHCP o PPPoE forniti dal provider. Al salvataggio, il relativo gateway WAN fisico viene creato automaticamente nel WAN link manager.

Un nuovo gateway è inizialmente Active. Dopo aver aggiunto una linea dedicata esclusivamente alla riserva, occorre quindi modificarne subito il tipo, prima che il traffico di produzione venga distribuito involontariamente tra i due provider.

I Custom Gateway creati in Routing > Gateways, ad esempio per XFRM, RED o MPLS, non compaiono nel WAN link manager. Appartengono a un design di routing diverso e non vengono trattati come gateway ISP fisici in questo scenario semplice.

Impostare il gateway di backup

In Network > WAN link manager, modificare il gateway della linea di riserva e impostare i valori seguenti:

Type: Backup
Activate this gateway: If active gateway fails
Con una sola linea principale: ANY
Action on activation: Inherit weight of the failed active gateway
Action on failback: Serve new connections through restored gateway
Salvare e verificare lo stato del gateway.

Con un solo gateway attivo, ANY e ALL hanno praticamente lo stesso effetto. La differenza diventa importante con più linee attive:

ANY: il backup viene attivato non appena uno dei gateway attivi si interrompe. È adatto quando si vuole sostituire immediatamente la capacità persa.
ALL: il backup viene attivato solo quando tutti i gateway attivi sono indisponibili. È più adatto a una linea di emergenza lenta o costosa.

Action on activation determina il peso del gateway di backup quando diventa attivo insieme ad altri gateway ancora disponibili. Inherit weight of the failed active gateway è una scelta comprensibile in un semplice scenario di sostituzione. Use configured weight è utile quando la riserva ha intenzionalmente una capacità inferiore o superiore e opera insieme alle linee attive rimanenti.

Per il failback, Serve new connections through restored gateway è la scelta più prudente dal punto di vista operativo. Le nuove sessioni tornano sulla linea principale, mentre quelle esistenti rimangono sul percorso di backup fino al timeout o alla loro interruzione. Serve all connections through restored gateway ristabilisce le connessioni esistenti e può interromperle. Con le route SD-WAN, questa azione si applica solo se WAN link load balance è selezionato come Primary Gateway. Se come Primary è configurato un singolo link WAN Active, soltanto le nuove connessioni vengono inoltrate tramite il gateway ripristinato.

Scegliere correttamente le regole di failover

Le Failover rules stabiliscono quando un gateway è considerato non raggiungibile. Sono disponibili:

Testing method: Ping o TCP
IP address
per TCP, anche Port
collegamento di più condizioni di errore con AND o OR

Un’interruzione fisica del cavo viene già rilevata sull’interfaccia. Il controllo Ping dell’indirizzo IP del gateway, creato per impostazione predefinita, verifica inoltre se il dispositivo del provider direttamente collegato o il primo hop del provider sono raggiungibili. Può tuttavia restare verde anche quando non è più disponibile l’accesso Internet oltre il router raggiungibile del provider. Per i gateway WAN/ISP, Sophos consiglia quindi un indirizzo IP pubblico noto, ad esempio 8.8.8.8 o 8.8.4.4.

Per IPv6, Sophos indica 2001:4860:4860::8888 come esempio pubblico. Per controllare il dispositivo upstream, usare l’indirizzo IPv6 del gateway e non il relativo indirizzo link-local.

Neppure un singolo target costituisce una verifica completa dello stato. Per una configurazione iniziale più robusta si possono utilizzare due indirizzi IP pubblici, stabilmente raggiungibili e autorizzati dall’organizzazione:

AND: il failover viene attivato soltanto quando falliscono tutti i controlli collegati. Riduce le commutazioni errate dovute all’irraggiungibilità di un singolo target.
OR: è sufficiente il fallimento di un controllo per attivare il failover. Reagisce in modo più sensibile, ma aumenta il rischio di commutazioni non necessarie.

8.8.8.8 e 8.8.4.4 sono esempi concreti forniti da Sophos, ma appartengono allo stesso operatore e non rappresentano domini di guasto completamente indipendenti. In un ambiente importante è preferibile utilizzare due target autorizzati appartenenti a operatori diversi. Un target Ping deve rispondere in modo affidabile a ICMP; per TCP serve un servizio stabile la cui porta possa essere controllata.

ANY/ALL per il gateway di backup e AND/OR nelle regole di controllo rispondono a domande diverse. ANY/ALL stabilisce quanti gateway attivi devono diventare indisponibili. AND/OR determina come più controlli valutano il guasto di un singolo gateway.

Il valore globale Gateway failover timeout nel WAN link manager stabilisce quando il firewall considera guasto un link che non risponde. Non esiste un valore universalmente corretto. Un timeout troppo breve reagisce più rapidamente, ma può causare commutazioni non necessarie in caso di perdita di pacchetti o breve interruzione del target di controllo. Il valore viene utilizzato, tra l’altro, anche come intervallo degli Health Check per i gruppi di failover IPsec e non dovrebbe quindi essere modificato considerando un solo link WAN. Documentare il valore iniziale, testarlo in modo controllato e solo successivamente adattarlo in base al tempo di commutazione misurato.

Testare in modo controllato failover e failback

Un test del cavo verifica soltanto un guasto del link locale. Un problema del provider a valle di un router ancora raggiungibile viene rilevato solo quando non sono più raggiungibili neppure i target pubblici configurati. Idealmente, i due casi vanno quindi testati separatamente.

Confermare finestra di manutenzione, piano di rollback e accesso amministrativo alternativo.
Documentare in Network > WAN link manager lo stato del gateway principale e di quello di backup.
Da un client di test, verificare DNS, HTTPS e un’applicazione importante. Annotare inoltre l’indirizzo pubblico di uscita attualmente utilizzato.
Per il test del link, scollegare in modo controllato il cavo WAN principale. Per il vero test del monitoraggio, lasciare attivo il collegamento al firewall e interrompere il percorso upstream a valle del dispositivo del provider, se ciò è possibile senza rischi.
Attendere più a lungo del Gateway failover timeout configurato.
Verificare che il gateway principale sia indicato come guasto e quello di backup come attivo.
Avviare nuove sessioni DNS, HTTPS, VPN e applicative. Controllare regola firewall, NAT, raggiungibilità della destinazione e nuovo indirizzo pubblico di uscita.
Controllare nel Log viewer gli eventi Gateway Up/Down. Per un’analisi più approfondita, dgd.log contiene gli eventi relativi alla gestione dei gateway WAN e al failover dei link.
Ripristinare la linea principale e controllare separatamente le sessioni esistenti e quelle nuove. In questo modo si verifica se si manifesta effettivamente il comportamento di failback configurato.
Documentare lo stato finale, le applicazioni e la raggiungibilità esterna.

Un Ping riuscito dimostra soltanto che il target risponde. Non conferma DNS, NAT, VPN, servizi pubblicati o un’applicazione aziendale. Per verificare il percorso effettivo dei pacchetti, è utile Packet Capture in Sophos Firewall WebAdmin; dgd.log e altri file sono descritti in Service Logs di Sophos Firewall.

Errori tipici e limitazioni

La linea di riserva distribuisce già traffico di produzione: il nuovo gateway è ancora impostato su Active. Per una linea esclusivamente di riserva, impostarlo su Backup.
Il backup non viene attivato in caso di guasto: controllare stato del gateway, tipo, ANY/ALL, regole di failover e Gateway failover timeout. Con più gateway attivi, ALL può impedire intenzionalmente l’attivazione finché rimane disponibile almeno un percorso attivo.
Il gateway è verde, ma Internet non funziona: il target di controllo è raggiungibile, mentre DNS, routing, regola firewall, NAT o applicazione non funzionano. Verificare traffico reale, Log Viewer e Packet Capture.
Il firewall commuta senza un vero guasto del provider: un singolo target non risponde, OR è troppo sensibile o il timeout è troppo breve per la qualità della linea. Controllare i target e la perdita di pacchetti misurata.
Le sessioni esistenti si interrompono durante la commutazione: cambiano l’indirizzo sorgente pubblico o lo stato NAT. Gli endpoint remoti possono quindi rifiutare la connessione. Il failover WAN non garantisce automaticamente zero downtime.
Il traffico in uscita funziona, ma i servizi in ingresso no: il secondo provider richiede raggiungibilità pubblica, DNS o Dynamic DNS, DNAT, regole firewall ed eventualmente certificati adeguati. DNAT per server pubblicati e Nozioni di base sul NAT aiutano a individuare la causa.
La VPN funziona solo tramite la linea principale: Remote Gateway, indirizzo locale di ascolto, FQDN, identità, configurazione del tunnel e rotta di ritorno devono essere adatti anche al percorso di backup. Il semplice failover WAN non crea una seconda connessione VPN.

Se applicazioni, gruppi di utenti o reti di destinazione devono utilizzare linee diverse oppure latenza, jitter e perdita di pacchetti devono guidare la scelta del percorso, la decisione va implementata in Route e profili SD-WAN Sophos Firewall. Per una riserva mobile si aggiungono SIM, APN, volume di dati, CGNAT e qualità del segnale; questi aspetti sono descritti in Cellular WAN e failover 4G/5G.

Gestione

Se necessario, segnalare tramite e-mail le variazioni di stato dei gateway. Configurare innanzitutto mail server, mittente e destinatario in Administration > Notification settings. Quindi attivare l’interruttore globale Email notifications in System services > Notification list e selezionare l’evento Gateway status in System. La sola selezione della riga dell’evento non invia alcuna e-mail.
Controllare lo stato dei gateway e dgd.log dopo commutazioni non pianificate.
Testare failover e failback almeno ogni trimestre e dopo modifiche a provider, interfacce, NAT, routing o firmware.
Documentare dipendenze dagli IP pubblici, endpoint VPN, allowlist e servizi in ingresso.
Definire i responsabili per guasti del provider, escalation e ritorno al normale funzionamento.
Controllare regolarmente i target di verifica; un target modificato in modo permanente o non più raggiungibile non deve determinare la logica di commutazione senza che ciò venga rilevato.
Con più linee attive, verificare pesi e Session Persistence in base all’utilizzo reale, non soltanto alla larghezza di banda nominale.