Un cluster FGCP non è «due firewall in ridondanza»: è un apparato solo, che la rete vede con gli stessi indirizzi IP e gli stessi MAC virtuali prima e dopo un guasto. Da qui discendono configurazione, trappole e diagnosi. Formare il cluster è la parte facile; capire chi ha vinto la negoziazione e cosa si è propagato è la parte che si chiede all’esame.

Cosa deve combaciare perché due FortiGate diventino uno

I vincoli sono rigidi. I membri devono essere dello stesso modello, con lo stesso firmware e la stessa configurazione hardware, per esempio lo stesso numero di dischi. Poi ci sono i parametri che devono coincidere perché la negoziazione riesca: modalità, group ID e password. Il group ID in particolare deve essere univoco nel dominio di broadcast: due cluster con lo stesso group ID sulla stessa rete producono conflitti di MAC, perché il group ID concorre a determinare gli indirizzi MAC virtuali.

config system global
    set hostname Sede-FGT-1
end
config system ha
    set mode a-p
    set group-id 1
    set group-name Sede_cluster
    set password ********
    set hbdev ha1 100 ha2 50
end

L’hostname va cambiato subito ed è diverso su ogni membro: è l’unico modo umano per distinguerli negli output. Il cablaggio dell’heartbeat segue una regola letterale: la stessa porta deve andare alla stessa porta, quindi ha1 del primario su ha1 del secondario. Con due membri si usano cavi diretti back-to-back, con più di due uno switch dedicato per ciascuna interfaccia. L’heartbeat sta solo su interfacce fisiche: niente VLAN, aggregate, redundant o porte di switch interno. E usarne una sola non è una scelta, è un rischio: se quel collegamento cade il cluster si spacca in due primari, con IP e MAC identici sulla stessa rete.

Chi diventa primario, e perché

All’accensione ogni membro invia hello sull’interfaccia heartbeat, confronta modalità, password e group ID, e se combaciano negozia. Prima di passare allo stato operativo aspetta il tempo di hello-holddown, 20 secondi di default, per dare a tutti i membri il tempo di farsi trovare.

La selezione del primario si rigioca ogni volta che un membro entra o esce dal cluster, e ogni volta che cambia lo stato di un’interfaccia monitorata. I criteri sono quattro e la documentazione li riassume con due sigle: MUPS quando override è disabilitato — interfacce monitorate, uptime, priorità, numero di serie — e MPUS quando è abilitato, dove priorità e uptime si scambiano di posto. Ogni criterio si valuta solo se il precedente è in parità.

Ne discendono due comportamenti che sorprendono. Primo: con override disabilitato, alzare la priorità di un membro non provoca alcuna commutazione, perché l’uptime viene valutato prima. Secondo: l’uptime conta solo se la differenza supera i cinque minuti (300 secondi, regolabili con ha-uptime-diff-margin), e viene azzerato sia da un riavvio sia dal guasto di un’interfaccia monitorata. Il verdetto non va indovinato: get system ha status ha una sezione «Primary selected using» con lo storico delle motivazioni, e diagnose sys ha dump-by group mostra la differenza di età fra i membri.

Cosa si sincronizza e cosa no

La sincronizzazione è mista, incrementale e periodica, e viaggia sul collegamento heartbeat con TCP/703 e UDP/703. Il primario propaga tutto il resto della configurazione, incluse le altre impostazioni HA, ma alcune cose restano del singolo membro: hostname, widget della dashboard, override, priorità del dispositivo, priorità di virtual cluster, impostazioni dell’interfaccia di gestione riservata e la sua rotta predefinita, quella di ha-mgmt-interface-gateway. Anche licenze e abbonamenti sono individuali; l’eccezione sono i FortiToken Mobile, registrati sul primario e sincronizzati ai secondari.

Lo stato si verifica con get system ha status: la sezione «Configuration Status» riporta in-sync oppure out-of-sync per ogni membro, con il dump dei checksum. Un membro fuori sincronia va sistemato subito, perché una configurazione divergente si scopre nel momento peggiore, cioè al failover.

Modificare le impostazioni a cluster acceso

La regola generale è semplice: si configura il primario e la modifica si propaga. Le eccezioni sono i parametri per membro dell’elenco qui sopra, che vanno impostati su ciascuna unità. Per farlo dal primario si passa alla CLI dell’altro membro:

execute ha manage 1
get system ha status

Alcune modifiche però non sono indolori. Cambiare modalità o group ID fa rinegoziare il cluster e ricalcolare i MAC virtuali: la connettività verso l’apparato si perde temporaneamente, e non è un guasto ma il comportamento atteso. Anche toccare le interfacce monitorate riapre subito la selezione del primario. Sono operazioni da finestra di manutenzione.

L’interfaccia di gestione HA

L’interfaccia di gestione riservata esiste proprio perché il cluster è un apparato solo. Le sue impostazioni e la sua rotta predefinita sono escluse dalla sincronizzazione, così ogni membro conserva un indirizzo proprio; e a differenza delle altre interfacce del primario non assume il MAC virtuale, ma mantiene il proprio MAC reale. Il risultato è una porta fuori banda per raggiungere il singolo membro, secondario compreso, senza dipendere dal ruolo che ricopre in quel momento.

Vale la pena capire perché è preziosa. L’alternativa, execute ha manage, viaggia sul canale HA con EtherType 0x8893: se uno switch di terze parti fra i due membri non inoltra quel tipo di frame, il cluster si forma e l’heartbeat funziona, ma il comando per gestire l’altro membro non risponde. Con un’interfaccia di gestione riservata quel problema non ti tocca, e in diagnosi puoi sempre verificare il passaggio dei frame con diagnose sniffer packet any 'ether proto 0x8890' 6 0 l.