Sei sulla pagina 1di 18

HA è la configurazione del cluster delle macchine FG che lavora tramite un protocollo proprietario FGCP,

che determina la sincronizzazione, determina gli hello, la verifica dello stato di salute del cluster.
Il FG può agganciarsi/partecipare ad un gruppo VRRP. Il cluster FG è qualcosa di più di una semplice
ridondanza del primo salto, anche perché il VRRP fornisce semplicemente la ridondanza del Gateway, nulla
ha a che vedere con le sessioni, sincronizzazione del NAT, con le policy, oggetto, e così via. Il concetto del
cluster prevede da 1 a 4 FG, dei quali 1 è il Master e tutti gli altri Slave che lavoreranno in 2 modalità:
Active-passive e Active-Active. La stessa Fortinet suggerisce che rarissimamente è necessario superare il
numero di 2 Appliance in Cluster HA. Quindi possiamo considera questo limite 4 come un limite teorico,
comunque esistente, al massimo sono 4 ma normalmente troveremo 2 Appliance.

Un cluster HA utilizzato con il protocollo FGCP, prevede: 2 FG identici con: stesso firmware, stesso
apparato, stesse licenze, in realtà le licenze potrebbero essere differenti ma verrà applicato al Cluster il set
di licenze condiviso e minimo e non solo devono essere identiche le macchine, ma per lavorare in Cluster le
macchine devono essere inserite nella topologia esattamente alla stessa maniera, avere la stessa
configurazione e cioè, se siamo collegati allo switch-1 con FG1 tramite la porta3, anche la porta3 del FG2
deve essere collegato allo stesso switch-1, perché FG2 deve poter prendere il posto di FG1 non solo lato
LAN ma in qualunque segmento della rete (anche WAN). Una caratteristica del Cluster, è la
sincronizzazione della configurazione (ci sono alcuni elementi che non vengono sincronizzati, tipo host-
name, priorità, la mgmt interface, override), sempre quella del Master che viene applicata a quella dello
Slave. Non c’è un numero di revisione, vale sempre la regola che quella del Master si applica a quella dello
Slave anche se il Master venisse allontanato dalla produzione per manutenzione, quindi bisogna fare
sempre attenzione a chi è il Master e qual è il criterio per l’elezione del Master. Come fa un FG a definirsi
MASTER? Il 1° criterio è avere il maggior numero di Interface monitorate che siano up e connesse. Per
esempio in un Cluster di questo tipo io vado a monitorare la porta3 e porta1, che senso avrebbe eleggere
FG2 come Master se la porta3 fosse scollegata? nessun senso, perché non avrebbe la stessa operatività.
Possiamo escludere dal monitoraggio nel Cluster altre porte, magari quelle meno importanti ma i segmenti
più importanti per i quali vogliamo garantire HA, devono essere incluse nel monitoraggio. Se stacco un cavo
automaticamente il FW perderà la priorità nell’elezione di Master. Il 2° criterio è l’UPTIME HA, che non è
l’UPTIME del dispositivo, significa da quanto tempo un FG è agganciato al Cluster con un delta/tolleranza di
5 minuti. Il 3° criterio è la priorità più alta e se anche la priorità dovesse essere uguale si ragiona sul serial
number maggiore, che rappresenta il 4° criterio.
E’ possibile controllare l’elezione del Master & Slave e si può fare con il cosiddetto OVERRIDE, abilitandolo
farà cambiare di posto il 2° e 3° criterio, quindi la priorità verrà prima dell’UPTIME HA.
La priorità è quel parametro deterministico sotto il nostro controllo, che può condizionare l’elezione.
Trattandosi di macchine identiche, stesso HW, stessi dischi, moduli di espansione, piattaforma....perché
scegliere l’uno piuttosto che l’altro? forse per fare della manutenzione critica, ma giocare con il FAILOVER
con lo spostamento del Master, relativo del backup, è un’operazione che interrompe il traffico, ma è
possibile fare in modo che quando si lavora in modalità A-P, vengano sincronizzate anche le sessioni,
perché in A-P qualora una macchina dovesse perdere il ruolo di Master verrà fatto un FAILOVER, ma le
sessioni non sarebbero pronte a meno che di non aver impostato il pick-up session, e cioè, anche la
sincronizzazione di tutto ciò che è STATEFUL. E’ possibile sincronizzare le sessioni IPsec, le sessioni TCP, con
un comando apposito è possibile sincronizzare anche le sessioni connectionless, ICMP, UDP, non è mai
possibile sincronizzare le sessioni SSL VPN, quindi in caso di FAILOVER l’SSL VPN cade giù e bisogna ripartire
da capo. Senza il session pick-up, anche in modalità A-P le sessioni non essendo sincronizzate dovranno
essere manualmente ripristinate dagli utenti, per esempio banalmente, un Browser dovrà avere la pagina
aggiornata e cioè si dovrà richiedere il 1° pacchetto SYN che creerà la sessione all’interno del FG che è
diventato Master dopo il FAILOVER. In assenza di OVERRIDE si può resettare l’UPTIME HA. Il protocollo
FGCP non attraversa gli stessi link come il VRRP utilizzato per esempio nella VLAN servita in ridondanza; si
vanno ad utilizzare 1 o più link (normalmente più di 1), che sono i cosiddetti HEART-BEAT o HB-DEV (heart
beat device), che sono 1 attiva e l’altra eventualmente di backup, possono anche essere differenti, e sono
porte dedicate al traffico FGCP.

Questo traffico FGCP utilizza degli ETHER-TYPE proprietari, e cioè dedicati a Fortinet, e sono diversi, tipo:
(0x8890,0x8891,0x8893), quindi stiamo parlando di traffico che non è IP, non è 0x0806 come ARP, 0x0800
come IP, quindi FGCP non è un traffico IP, ma è un pacchetto, una PDU FGCP dedicata a Fortinet.
Questa cosa è interessante perché:
Per eseguire in ambiente Cloud delle simulazioni Fortinet, uno dei principali problemi è, verificare se le
macchine virtuali FG in collegamento tra di loro tramite degli switch virtuali, possono effettivamente
comunicare con questo ETHER-TYPE non canonici (0x0800,0x0806,0x86DD), e cioè non sono i classici
ETHER-TYPE in uso; e spesso il Cloud service provider potrebbe non garantire la consegna di frame con
ETHER-TYPE particolari in contesti Cloud.
Le porte di HB sono dedicate esclusivamente al traffico FGCP.
Descrizione di come funziona il Forwarding del traffico:
FG1 e FG2 avranno la stesse configurazioni se agganciati allo stesso Gruppo, il group ID che è un parametro
del cluster, di default vale 0, normalmente non si configura, ma qualora nello stesso segmento fossero
presenti 2 cluster differenti, allora sarebbe necessario. Allora capite bene che se nella stessa lan fossero
presenti 2 cluster separati ci sarebbe una confusione allora il group ID va configurato quando c’è più di un
cluster, altrimenti possiamo non configurarlo. Un parametro che dovremo configurare è il group name e il
group password, e dopodiché se imposteremo l’OVERRIDE avremo cura di fare la priorità.

ENCAPSULATION:
Il Gateway del Pc quale sarà? supponiamo che i FG siano configurabili come Gateway delle macchine,
quindi avremo switch di L2 senza vlan in maniera molto semplificata, il Gateway sia in modalità A-A che A-P
sarà il Master.
Supponiamo che il Gateway ha l’indirizzo IP 10.0.1.254, questo IP lo avranno entrambe le porte1 (nel
nostro esempio) dei 2 FG, perché la configurazione è sincronizzata. Quindi Il traffico, quando il pc chiederà il
supporto del Gateway per raggiungere la destinazione remota, farà per primo un ARP per chiedere qual è il
mac-address del 10.0.1.254 e risponderà il Master con un MAC virtuale, e tale MAC virtuale non sarà
presente solo per le porte1 dove sono attestate le LAN ma anche per le porte3 che si interfacciano verso lo
switch di WAN:
Le porte2 dell’HB-DEV non partecipano all’inoltro del traffico e hanno degli indirizzi 169.254.0.x, .1, .2, .3 e
così via... hanno degli indirizzi link-local. Come sappiamo già per il VRRP, qualora il FG-1 dovesse fare uno
SWITCHOVER, il FG2 dovrà fare in modo che il suo switch aggiorni la sua mac-address table, abbinando il
mac-address virtuale alla porta corretta. Se il FG1 è il Master, il FG2 ha lo stesso IP ma continua ad avere il
suo mac-address fisico, perché il mac-address è quello fisico inalterato. Quindi il traffico attraverserà la
porta1 del FG1 e uscirà dalla porta3 (ovviamente il Fw in NAT mode) sempre con il mac-address sorgente
quello virtuale. Quindi in modalità A-P utilizza lo stesso meccanismo del VRRP, con l’unica estensione del
fatto che il mac-address virtuale è dappertutto (in ogni interfaccia). Mentre cosa succede in modalità A-A?
non c’è più di 1 mac-address virtuale, per esempio non è come in CISCO col GLBP che ci sono tanti mac-
address virtuali, ma ce ne sarà sempre 1. Quindi come sarebbe il percorso del traffico nella situazione A-A?
il Pc manda comunque un ARP e riconosce come Gateway il FG1, quindi inoltrerà il traffico sempre alla
porta1 di FG1 e poi sarà cura del MASTER se scaricare questa sessione verso un altro attivo, e cioè questo
stesso pacchetto verrà incapsulato verso il mac-address fisico dello Slave, il traffico che uscirà dalla porta3
di FG2 non avrà più come mac-address sorgente quello virtuale, perché altrimenti il traffico di ritorno di
questa sessione verrà gestito dal Master che non ha la sessione attiva per questo traffico. Quindi il traffico
uscente da FG2 (Slave) avrà il mac-address fisico della porta3 perchè il traffico in uscita di un FW slave usa
il mac-address fisico e non quello virtuale. Così facendo il traffico di ritorno lo switch WAN lo manda alla
macchina che ha la sessione attiva. A questo punto il FG2 che cosa farà? poiché la destinazione dell’IP è
nota, (e cioè l’IP del Pc), il traffico di ritorno non occorrerà mandarla indietro al FG1, ma potrà mandarlo
direttamente al Pc senza doverlo restituire al Master, perché le sessioni non sono mai abbinate al mac-
address, ma sono sempre abbinate all’IP sorgente, quindi lo Slave non avrà necessità di mandarlo indietro
al Master per poi mandarlo al Pc.
La chiave è che:
Il virtual-mac lo usa solo il Master, e qualora un altro apparato dovesse utilizzare lo stesso mac-address,
quel mac-address flapperebbe da una porta all’altra in uno switch e questo causerebbe o un’interruzione
del traffico o il bloccaggio delle porte. Molti switch si proteggono quando un mac-address si presenta
repentinamente da una porta all’altra, questo è sintomo di Loop e quindi reagiscono bloccando le porte.
Quindi è indispensabile in modalità A-A che il traffico gestito dallo Slave sia originato col mac-address fisico
e venga ricevuto col mac-address fisico. Allora se il Master comunque deve gestire ogni traffico in ingresso,
come mai viene prevista la modalità A-A? La modalità A-A è consigliata si, per creare le sessioni, ma per
cercare di scaricare tutto l’onere dell’UTM, perché l’applicazione dei security profile impegnano la CPU, e
quindi l’idea è appunto quella di cercare di scaricare le sessioni che necessitano di ispezione.

Procediamo alla configurazione del nostro LAB:

N.B. sebbene le porte3 prenderanno una configurazione IP tramite il DHCP; in un Cluster è sconsigliato e
non è ragionevole utilizzare un DHCP e quindi sul FG1 (qui noi lo facciamo anche su FG2, ma in realtà
essendo un Cluster la configurazione è sincronizzata) verifichiamo qual è attualmente l’indirizzo IP della
porta3 ereditato dal DHCP e lo dobbiamo riassegnare staticamente:
Stessa cosa faremo su FG2, però se il FG2 non dovesse avere ancora un indirizzo IP sulla porta3, magari è
perché il DHCP non ha ancora funzionato, quindi andremo a sollecitare il DHCP spegnendo e riaccendendo
la porta3:

Una volta ottenuto l’IP dal DHCP, lo andiamo a riassegnare staticamente come nel FG1:
Aggiungiamo anche gli accessi amministrativi HTTP e HTTPS anche se questa configurazione verrà ereditata
dalla sincronizzazione del Cluster.

Se mi collego ad un FG da CLI, come faccio a vedere se sono in Cluster o no?


Lo vedrò con il comando “get system status” che è l’equivalente di “show version” di Cisco:
Ma anche il comando “get system ha” mi dice che è standalone:

Sono indicati anche gli ETHER-TYPE particolari che vengono utilizzati:


Osserviamo che di default l’OVERRIDE è disabilitato e la priorità di default è 128.

Procediamo con la configurazione del Cluster tramite la GUI:

ATTENZIONE: esiste anche un altro termine che è il Virtual Cluster, ed è un Cluster costituito al massimo da
2 FG con i VDOM, dove per ogni VDOM, il FG può essere Master o Slave in maniera indipendente. Quindi
quando si parla di Virtual Cluster si parla di un HA distinto per VDOM con una limitazione al massimo di soli
2 FG e non 4.
Un’ipotesi di questo caso, potrebbe essere in un contesto Multi-Tenant, dove potremmo mettere a
disposizione le nostre apparecchiature per un Cliente, dando loro la possibilità di definire l’HA in maniera
autonoma, e questa Feature si chiama Virtual Cluster.

La configurazione HA essendo una configurazione di sistema, andremo nella sezione GUI:


La priorità avrà senso solo se c’è l’OVERRIDE abilitato.
Dalla GUI notiamo che ci chiederà solo il nome, e non ci chiede l’id del gruppo che ricordiamo essere
importante solo se fossero presenti nello stesso Broadcast domain più Cluster, quindi capiamo che alcune
opzioni avanzate da CLI dovranno essere abilitate.
Session pick-up: Siccome la sincronizzazione tramite FGCP non è soltanto della configurazione ma è anche
eventualmente degli stati: sessioni, tabelle di Routing, DHCP lease, insomma tutto ciò che dinamicamente il
FW ha offerto. Quindi il Session pick-up, comporta delle sincronizzazioni incrementali, anche sullo stato di
questi elementi dinamici; in questo caso i client dovranno resettare/aggiornare le loro connessioni; ma nel
nostro LAB per il momento lo lasciamo disabilitato.
Monitor interfaces: cosa si monitora in un Cluster? non si monitorano le HB-DEV, sono monitorate da sole,
cioè non vanno inserite come parametro “chi ne ha di più diventa Master”. Quindi normalmente vengono
monitorate le interfacce che sono collegate agli elementi critici della rete, nel nostro caso saranno le porte1
della LAN e le porte3 della WAN. Le Heartbeat interfaces nel nostro LAB, è la porta2, che è una sola
operativa (che non è una buona pratica perché normalmente ce ne sono più di 1) sulla base della priorità
HB-DEV assegnata.
Management Interface Reservation: possiamo configurare un’interfaccia per la configurazione autonoma
dei singoli Appliance, ed è una configurazione che non sarà sincronizzata perché altrimenti non potremmo
gestire singolarmente le due macchine.
Unicast Heartbeat: per indicare direttamente chi è il destinatario, normalmente si utilizza di default il
169.254.0.x con un indirizzo determinato dal numero seriale, quindi il più alto numero seriale avrà il .1, poi
il .2, .3 e così via....
Quindi questa Macchina va già in Cluster, ma è un Cluster da solo costituito da una sola macchina.

Andiamo sulla CLI a fare Troubleshooting perché abbiamo perso connettività con la GUI:

Possiamo utilizzare anche il “get system ha status”, che mi dice il perché io sono Master:
E come possiamo notare dall’output, è perché siamo l’unico membro del cluster, mentre se ci fosse stato
anche lo Slave lo avremmo letto in basso come ultima riga.

Anche il comando “get system status” ci dice lo stato attuale dell’HA:


Eventualmente si potrebbe resettare l’UPTIME dell’HA per forzare l’elezione di un nuovo Master qualora
l’OVERRIDE non fosse abilitato, e quindi qualora l’UPTIME fosse un parametro più importante rispetto alla
priorità:

Possiamo notare che nonostante il reset l’UPTIME incrementa, questo vuol dire che il comando appena
dato, funziona solo se un Cluster è effettivo e cioè è formato da più di una macchina, perché se è da solo
come nel nostro caso,non lo considera.

Perché sto facendo passare del tempo? per far passare quel Delta /tolleranza, noi in ogni caso proviamo ad
agganciare il FG2 al Cluster:
Stiamo agganciando il FG2 tramite il protocollo FGCP e a sto giro non abbiamo neanche perso la GUI, però
notiamo che si è eletto Master il FG2:

Perché si è eletto Master il FG2? forse perché non è passato quel Delta di default che sono i 5 minuti?
andiamo a verificare da CLI:
Stesso numero di porte monitorate (2 da entrambi i lati ed entrambe attive/Up), l’UPTIME-HA non abbiamo
fatto OVERRIDE quindi poi considera l’UPTIME-HA che è chiaramente maggiore nell’altro (FG1), che tra
l’altro è un numero che, se rimane inferiore ai 5 minuti il delta, si sincronizza anche l’ UPTIME-HA e diventa
determinante soltanto se il delta è maggiore di 5 minuti. La Priorità era uguale perché non c’era
l’OVERRIDE, e alla fine ha vinto il serial number, quindi siamo scesi fino al punto 4.

Per controllare in maniera deterministica chi è il Master su entrambi dobbiamo andare ad impostare
l’OVERRIDE e contestualmente attribuire una priorità diversa:

Ancora però nonostante abbiamo abilitato l’OVERRIDE non cambierà nulla perché la priorità è uguale,
ancora UPTIME-HA:

A questo punto dobbiamo replicare questa configurazione anche su FG1:


Nel frattempo vedrò messaggi di log che appariranno sulla console di FG1, dove mi dirà che ci sta provando
a configurarlo e che non è sincronizzato con l’altra macchina:
Il fatto che non è in “SYNC” e che è Slave, lo vedo anche perché ho un prompt con il segno “#”:

N.B. priorità e OVERRIDE sono parametri della configurazione che non vengono sincronizzati:

N.B. Su FG1 rispetto al LAB precedente notiamo che è cambiata la configurazione, questo perché ha preso
la configurazione di FG2 in quanto era Master e non c’è un meccanismo di recupero della configurazione
prima del FAILOVER. Quindi quando facciamo HA, è importante fare sempre un Backup delle
configurazioni, così eventualmente possiamo recuperare la configurazione precedente dalle revisioni.
N.B. In produzione per evitare un disservizio o problemi sulla rete causato da un FAILOVER, visto che i 5
minuti del DELTA è un concetto un po’ relativo, abilitare sempre l’OVERRIDE e la priorità prima di
agganciare i FW al Cluster, lasciando su quello che decidiamo debba essere lo Slave, la priorità di default e
dopo lo agganciamo.

N.B. Lo SLAVE non ha una tabella di Routing:

MASTER:

SLAVE:

Proviamo a cambiare in modalità A-A:

Ovviamente su FG2 sincronizza in automatico la modalità:

Ma anche in modalità A-A continua a non mostrare la tabella di Routing sullo SLAVE:
Andiamo a vedere il mac-address di una interfaccia in uso in un MASTER:
Notiamo che la porta2 ha un mac-address in uso e uno scritto nella ROM del dispositivo, quindi un BA
secondo CISCO:

Andiamo a vedere il mac-address di una interfaccia, in uso, in un SLAVE:


Il mac-address in uso è quello fisico, e questo, è ciò che ci consentirà di utilizzare per esempio una modalità
A-A secondo il percorso che abbiamo descritto precedentemente:
N.B. il penultimo Byte del mac-address è relativo al gruppo quindi sarà distinto per gruppi e da ciò capiamo
che il gruppo id andrà impostato in presenza di più Cluster per non fare confusione.
In assenza di una MGMT Interface riservata come faccio a controllarlo da CLI uno SLAVE? sarò buttato fuori
dall’accesso amministrativo della macchina, posso eventualmente abbandonarlo, ma non lo voglio
abbandonare, perdiamo la connettività GUI perché cambia l’indirizzo IP sulla porta.
Abbandonare uno SLAVE, nel momento in cui lo facciamo verrà richiesto un indirizzo di gestione, per
gestire la macchina abbandonata perché nel frattempo ha una configurazione del tutto inconsistente
perché è una replica del Master e quindi serve assegnarle un indirizzo di gestione per poterla amministrare
da remoto. Queste macchine dalla versione 60 in su hanno un accesso in console, però ovviamente senza
un modem o un Access Server, per accedere in console si va in locale.

Sono entrambi attivi come possiamo notare e se vado per disconnetterli, prima di farlo:
Mi darà la possibilità di assegnargli una interfaccia per gestirlo da remoto in quanto ha una configurazione
del tutto inconsistente:

FG ci dà la possibilità accedendo da remoto su un MASTER, di poter entrare nella CLI specifica dello SLAVE,
Indicando il numero che è corrispondente all’ID dello SLAVE e osserviamo che cambierà il prompt, e da qui
poi possiamo procedere con tutte le modifiche che vogliamo:
N.B. il delta di differenziale presente nell’UPTIME-HA viene tollerato dalle macchine e corrompe la
configurazione, quindi è buona pratica, quella di impostare l’OVERRIDE e di determinare chi è il MASTER
settando la priorità sia su FG1 che FG2, altrimenti si fa casino se dovessimo impostarla solo su una
macchina.

Aggiornamento del firmware di un cluster:

Viene caricato sulla macchina MASTER che gestirà da sola il processo di aggiornamento degli altri SLAVE.
Quindi io carico il firmware sul MASTER, tramite l’HBDEV viene trasferito sul o sugli SLAVE presenti, questi
vengono aggiornati e riavviati e una volta che tutti gli SLAVE sono aggiornati, ad uno di questi viene
assegnato il ruolo del Master e il traffico così transiterà su una macchina già upgradata e il vecchio MASTER
procederà al proprio upgrade.