CZ 
05.11.2024 Miriam VÍTEJTE V MÉM SVĚTĚ

An English translation is available for this article. Pro tento článek je dostupný anglický překlad.
FortiGate High Availability cluster and Virtual Domains (VDOM)

FortiGate High Availability cluster a Virtual Domains (VDOM)

Upraveno 01.05.2021 09:50 | vytvořeno | Petr Bouška - Samuraj |
Firewall na perimetru sítě je náš centrální bod pro přístup do internetu a dalších sítí. Určitě nechceme, aby šlo o Single Point of Failure, takže potřebujeme řešit redundanci a nejlépe rovnou cluster, který zajistí vysokou dostupnost (High Availability). Cluster nám řeší jednotnou konfiguraci a přepínání jednotek v případě výpadku (nejen zařízení, ale třeba i linky). Když jsme pořídili dvě zařízení, tak je můžeme chtít co nejlépe využít. Pro některé situace se mohou hodit virtuální domény (VDOM). Ty nám dovolí rozdělit FortiGate na několik částí, které pracují samostatně. Tedy vytvořit z jednoho zařízení (nebo clusteru) několik virtuálních firewallů.
zobrazeno: 10 976x (10 889 CZ, 87 EN) | Komentáře [2]

Pozn.: Popis v článku vychází z FortiGate FG-300EFortiOS verzí 6.2.3.

Půl roku jsem vybíral novou firewallovou soustavu. Požadavkem byl cluster dvou HW boxů se slušným výkonem a moderními bezpečnostními funkcemi. Na začátku jsem podle různých informací na internetu vybrat tři výrobce Palo Alto, Checkpoint a Fortinet. Od nich jsem měl demo licence a prováděl jsem dlouhé testování různých scénářů v labu. Nakonec jsem nelehce zvolil jako nejlepší FortiGate. Až časem se ukáže, zda to byla šťastná volba. U každého výrobce se mi líbili jiné vlastnosti a každý má jiné přednosti.

FortiGate FG-300E

Dokumentace pro verzi 6.x se nachází na různých místech

Možnosti řešení vysoké dostupnosti (HA a Cluster)

Dokumentace HA solutions

FortiOS podporuje různá řešení vysoké dostupnosti (High Availability - HA), tedy zajištění nepřerušeného síťového provozu pomocí redundance.

  • VRRP - Virtual Router Redundancy Protocol - standardní protokol pro redundanci routerů, neřeší cluster, ale pouze IP adresu síťové brány, můžeme kombinovat různé typy FortiGate nebo i jiné výrobce či zařízení (třeba router, ale ztrácíme bezpečnost při přepnutí)
  • FGCP - FortiGate Cluster Protocol High Availability - FGCP cluster se tváří jako jedno zařízení, konfigurace je synchronizována, podporuje Active-Active mód, Failover je rychlý a automatický, nastavení jednoduché, ale dá se ladit, poskytuje zvýšenou dostupnost a výkon, díky podpoře
    • device failover protection
    • link failover protection
    • remote link failover protection
    • session failover protection (TCP, UDP, ICMP, IPsec VPN, NAT sessions)
    • active-active HA load balancing
  • FGSP - FortiGate Session Life Support Protocol High Availability - provádí pouze synchronizace session, musíme mít nasazené řešení pro Load Balancing, které směruje provoz na jeden FortiGate (nebo distribuuje), když dojde k výpadku, tak Load Balancer přepne na druhý a Session Failover a Active Session Failover zajistí bez výpadkový provoz na Fortigate (starší verze se jmenovala TCP session synchronization)
  • SLBC - Session-Aware Load Balancing Clustering - potřebuje FortiController (funguje jako Load Balancer) a FortiGate-5000
  • ELBC - Enhanced Load Balanced Clustering - potřebuje FortiSwitch-5000 Load Balancer a FortiGate-5000
  • Content Clustering - potřebuje FortiSwitch-5203Bs nebo FortiController-5902Ds pro rozvažování Content Sessions na FortiGate-5000

Pohledem na možnosti zjistíme, že hlavní kandidát je FortiGate Cluster Protocol High Availability (FGCP). V dokumentaci Fortinet je také nejvíce popisován FGCP cluster a jemu se budeme dále věnovat.

High Availability - FGCP HA - FGCP cluster

Dokumentace FGCP HA, Introduction to the FGCP cluster, High availability

Základní princip

Řešení pro vysokou dostupnost, které využívá protokol FortiGate Cluster Protocol, vytváří cluster ze 2 až 4 FortiGate jednotek. Členové clusteru (cluster unit) musí splňovat

  • jednat se o stejný model
  • se stejnou verzi FortiOS
  • stejnou licencí
  • stejnou HW konfigurací
  • pracovat ve stejném operačním módu (NAT, Transparent)

HA cluster se tváří, že funguje jako jedno zařízení (konfigurujeme společně). Využívá virtuální MAC adresy (a Gratuitous ARP), IP adresy jsou aktivní na jednom zařízení spolu s virtuální MAC. V rámci clusteru se vždy vyjedná, která jednotka je Master a ostatní jsou Slave. Master drží virtuální MAC adresy a k nim má přiřazeny IP adresy. Síťová komunikace jde vždy na Master jednotku.

Schéma FortiGate cluster

Konfigurace clusteru spočívá v nastavení HA parametrů a propojení Heartbeat. FGCP najde další jednotky se stejnou konfigurací a vytvoří cluster. Určuje se primární jednotka (priorita), podporuje link a session failover.

Heartbeat Interface

Mezi jednotkami musí fungovat Heartbeat Interfaces, kde probíhá komunikace FGCP protokolem. Zde se vyjednává cluster a probíhá synchronizace informací a konfigurace. Mezi členy clusteru se synchronizuje téměř celá konfigurace, až na pár výjimek, jako je hostname, nastavení Dashboard, HA priorita, více Synchronizing the configuration.

Komunikace mezi jednotkami se označuje jako FGCP (HA) Heartbeat. Pokud komunikace nefunguje, tak FortiGate pracují jako samostatné jednotky (což v praxi znamená nefunkčnost sítě, dojde ke Split Brain Syndrome). Doporučuje se jednotky propojit přímo (bez switche, ale i to je možné) a více porty/kabely.

Active-Passive vs. Active-Active

Cluster můžeme provozovat ve dvou módech

  • Active-Passive - Failover HA - hot standby failover protection, primární jednotka (Master) zpracovává provoz, na podřízené jednotky (Slave) v standby state se synchronizuje konfigurace a sleduje stav primární jednotky, poskytuje transparentní Failover při selhání jednotky nebo interface (link), je možno nastavit session failover (session pickup)
  • Active-Active - Load Balancing HA - standardně distribuuje zpracování proxy-based security profile na všechny členy clusteru, pokud je session akceptována politikou, kde není security profiles (neznamená takové výpočetní zatížení), tak není rozvažována a zpracovává ji primární jednotka, je možno nastavit rozvažování i dalších session, primární jednotka přijímá veškerou komunikaci a rozvažuje ji s podřízenými jednotkami, ostatní fungování je stejné jako Active-Passive

Virtual clustering

Dokumentace Virtual clustering

Speciální možnost je vytvořený Active-Passive cluster rozdělit na dva virtuální clustery. Jde o rozšíření High Availability pro cluster dvou (na některých místech dokumentace se mluví o tom, že mohou být pouze 2, někde se zmiňuje, že lze přidat 3. a 4., které ale pracují ve standby módu) FortiGate jednotek s více VDOM (popíšeme dále). Označuje se jako Virtual clustering s VDOM partitioning. Každý virtuální cluster má nastavenu jako Master jinou jednotku. Ke každému clusteru můžeme přiřadit různé VDOM. Dosáhneme tak rozložení zátěže (plnému využití obou FortiGate).

Pozn.: Fortinet v dokumentaci mluví o tom, že Virtual clustering můžeme provozovat ve dvou režimech. Jeden je HA v Active-Passive módu a využití více VDOM s VDOM partitioning. To je logické, máme dva virtuální clustery, v každém je aktivní jiný FortiGate, a rozdělíme, kam patří která VDOM. V dokumentaci se ale mluví o tom, že můžeme využít HA v Active-Active módu bez VDOM partitioning. Píše se pouze, že pak vše funguje stejně jako Active-Active HA bez VDOM, a primární FortiGate přijímá všechen provoz. Nevím, proč by se v tom případě mluvilo o Virtual clustering, protože rozdělení clusteru na dva virtuální se provede nastavením VDOM partitioning.

Zapojení FGCP clusteru

Na členech clusteru musíme zapojovat stejným způsobem stejné interface a připojit vždy do stejného switche (to uvádí dokumentace). Použití stejných rozhraní (portů) je logické, jelikož mají jednotky stejnou konfiguraci, tak musí odkazovat na stejný port.

FortiGate FG-300E schéma

Následující obrázky ukazují příklad základního zapojení pro cluster a ukázkové schéma clusteru od Fortinetu.

FortiGate příklad základního zapojení pro cluster Fortinet obrázek FortiGate cluster

Rozhraní pro správu v rámci clusteru - Management

Správu můžeme provádět přes libovolný port, ale většina zařízení má jeden interface označený jako MGMT (není HW akcelerován). Ten je ideální použít jako dedikovaný management port (nepoužijeme jej pro provoz). Běžně nastavíme každému zařízení nějakou IP adresu na MGMT port a přes ni provádíme konfiguraci zařízení.

Po vytvoření clusteru se i MGMT port stane členem clusteru. To znamená, že se synchronizuje konfigurace, takže port získá IP adresu (nastavení) z Master FortiGate. Ta je aktivní na Master zařízení spolu s virtuální MAC adresou, takže nás vždy připojí na Master FortiGate. To v praxi znamená, že na správu FortiGate (clusteru) se dostaneme přes IP adresu, kterou měl Master při vytváření clusteru. V hlavičce vidíme jméno switche, ke kterému jsme připojeni. Pokud se stane Masterem druhý switch, tak se přes stejnou adresu připojíme k němu. Původní IP adresa, kterou měla druhá jednotka, neodpovídá a není nikde použita.

Většina konfigurace se synchronizuje, takže je jedno, který switch konfigurujeme a nastavení se projeví na obou (spravujeme celý cluster). Ale některé věci se týkají pouze jednotky, ke které jsme připojeni. Například restart. Pomocí příkazové řádky se můžeme z jednoho FortiGate připojit na druhý (komunikace jde skrze heartbeat interface) a provádět jeho konfiguraci.

Další možnost, jak se připojit na jednotlivé členy clusteru, je Management Interface Reservation. V tom případě potřebujeme vyhradit další port, který se vyjme z clusteru. Na každém zařízení mu přiřadíme jinou IP adresu a přes ni se můžeme připojit k danému zařízení. Standardně nám stále zůstává sdílená cluster management adresa.

Jako nejlepší se mi zdá poslední možnost. Využijeme existující (dedikovaný) MGMT port s přiřazenou adresou, které můžeme říkat VIP (Virtual IP). A speciálním příkazem přidáme druhou IP adresu na každém zařízení jinou. Fortinet to označuje jako In-band management. Tento jeden příkaz na rozhraní se nereplikuje v rámci clusteru.

Konfigurace jiného člena clusteru pomocí CLI

Můžeme si vypsat údaje o clusteru, kde vidíme členy a jejich SN.

FW1 # get system ha status | grep "HA oper"
Master: FG3H0E5854407122, HA operating index = 0
Slave : FG3H0E5854407589, HA operating index = 1

Pro konfiguraci jiného člena cluster, než ke kterému jsme připojeni, se můžeme přepnout v CLI. Použití otazníku nám zobrazí seznam ostatních členů, a jaký máme použít index pro přepnutí (očividně neodpovídá indexu ze stavu HA).

FW1 # execute ha manage ?
<id>    please input peer box index.
<0>   Subsidary unit FG3H0E5854407589
FW1 # execute ha manage 0 admin
FW2 # 

Nastavení přímého přístupu na členy clusteru

Můžeme využít Management Interface Reservation v konfiguraci HA, Fortinet to označuje jako Out-of-band management. Problém je, že nemůžeme použít interface, přes který jsme připojeni, tedy standardně MGMT. Ten nyní sdílí (VIP) adresu, kterou jsme měli nastavenu, a používá ji primární FortiGate. Když chceme přímý přístup na členy clusteru, tak potřebujeme další interface a dvě IP adresy. Pokud rezervujeme interface, tak mu zůstává originální MAC adresa. Tato konfigurace je popsána v Out-of-band management.

Druhá možnost je In-band management, kdy můžeme využít existující MGMT interface a sdílet jej i pro přímý přístup k zařízením. Fortinet popisuje v článku In-band management. Konfigurace se musí provést v příkazové řádce. Pomocí jednoho příkazu přidáme management IP adresu k určitému interface (zde MGMT) pro každého člena clusteru. Tento příkaz se nesynchronizuje v rámci clusteru. Management IP adresa by měla patřit do stejného subnetu jako již existující IP adresa na interface. Ale musí jít o jiný subnet než mají ostatní interface.

Konfigurace In-band management

config system interface
edit mgmt
    set management-ip 192.168.1.11/24
end

Praktický příklad konfigurace

FW1 # config system interface
FW1 (interface) # edit mgmt
FW1 (mgmt) # show 
config system interface
edit "mgmt"
	set vdom "root"
	set ip 192.168.1.10 255.255.255.0
	set allowaccess ping https ssh http fgfm
	set type physical
	set dedicated-to management
	set role lan
	set snmp-index 2
next
end
FW1 (mgmt) # set management-ip 192.168.1.11/24
FW1 (mgmt) # end
FW1 # execute ha manage 0 admin
FW2 # config system interface
FW2 (interface) # edit mgmt
FW2 (mgmt) # set management-ip 192.168.1.12/24
FW2 (mgmt) # end

Na interface si můžeme vypsat údaje, kde je vidět fyzická i virtuální MAC adresa.

FW1 # get hardware nic mgmt | grep HWaddr
Current_HWaddr      00:09:0f:09:00:01
Permanent_HWaddr    04:d6:90:53:33:0a

Rozhraní pro cluster - Heartbeat

Heartbeat je rozhraní pro komunikaci clusteru. Fortinet všude v dokumentaci uvádí, že většina modelů má dva HA interface označené HA1 a HA2 (to je například i nižší model FG-100E). Model FG-300E má pouze jeden heartbeat interface se jménem HA (není HW akcelerován). Nikde jsem nenašel zmínku, proč to tak je, a jak se doporučuje zapojit. Patrně musíme zvolit jako druhý HA libovolný port. Propojíme tedy například porty HA a Port16 přímým patch kabelem mezi dvěma FortiGate jednotkami.

V dokumentaci se uvádí, že jako HA interface můžeme použít libovolný fyzický port. Ale nemůže se jednat o switch port. To patrně znamená, pokud spojíme některé porty FortiGate do switche (Hardware, Software nebo Virtual), tak tyto porty nemůžeme použít (některé modely mají defaultně vytvořený switch).

Pro Heartbeat interface se doporučuje (FGCP best practices)

  • použít alespoň 2 Heartbeat interface a nastavit jim jinou prioritu
  • Heartbeat interface mezi dvěma jednotkami přímo propojit (bez switche)
  • nemonitorovat vyhrazené Heartbeat interface
  • alespoň jeden interface by neměl být připojen do NP4 nebo NP6 procesoru

Redundantní připojení do sítě

Dokumentace Full mesh HA, HA with 802.3ad aggregate interfaces, HA with redundant interfaces

Pokud chceme dosáhnout vysoké dostupnosti a vytvoříme cluster FW, tak bychom měli mít redundantní i další síťové prvky, aby nikde na cestě nebyl Single Point of Failure. Pokud by byly oba FortiGate připojeny pouze do jednoho switche, tak v případě jeho výpadku přestane fungovat celá komunikace. Každé síťové rozhraní (interface), tedy připojení do určité komunikační sítě, by mělo být připojeno pomocí dvou portů do dvou přepínačů. V případě clusteru musíme být identické připojení i na druhé jednotce.

Jednoduché schéma je na následujícím obrázku. Fortinet takové zapojení označuje jako Full Mesh HA. Mělo by řešit výpadek libovolného aktivního prvku nebo síťového spoje (link či port).

FortiGate zapojení Full Mesh HA - redundantní linky

Pozn.: Další věc, která mi přijde nejasná v dokumentaci Fortinet. Pro zapojení clusteru uvádí You must connect all matching interfaces in the cluster to the same switch. Ve chvíli, kdy chci konfigurovat Full Mesh, tak mám dva switche (i když ideálně ve stacku). Je správné zapojení, kdy Port 1 z obou FW vede do Switch 1 a Port 2 do Switch 2. Nebo naopak Port 1 FW1 do Switch 1, Port 2 FW1 do Switch 2, Port 1 FW2 do Switch 2 a Port 2 FW2 do Switch 1, jak je uvedeno v dokumentaci Full mesh HA example?

Pro vytvoření redundantního připojení (budeme mluvit o spojení dvou fyzických interface, ale může jich být více) do sítě podporuje FortiGate dvě metody:

  • Redundant interfaces - jednoduché řešení, umožňuje kombinovat fyzické interface do jednoho redundantního rozhraní, provoz zpracovává první fyzický interface, v případě výpadku či rozpojení se provoz přepne na další
  • Link Aggregation - využití agregace linek dle IEEE 802.3ad (Fortinet uvádí tuto normu, která byla v roce 2008 přesunuta do IEEE 802.1ax), označuje se často jako Port Channel, používá management protokol LACP (Link Aggregation Control Protocol), umožňuje kombinovat fyzické interface do jednoho agregovaného rozhraní (logické linky), zvyšuje odolnost proti výpadku, ale také možnou propustnost (provoz se distribuuje na všechny fyzická rozhraní v lince)

Zapojení pomocí redundantních rozhraní můžeme použít vždy a nejsou speciální nároky. Provoz je zpracováván jedním fyzickým rozhraním. Použití agregace linek nám navíc může poskytnou zvětšení propustnosti (za určitých podmínek) a stále zachovává zvýšení dostupnosti, ale vyžaduje podporu na síťovém přepínači. Všechna fyzická rozhraní zpracovávají provoz. Agregaci linek jsem popisoval v několika článcích Link Aggregation.

Redundant interfaces - redundantní rozhraní

Pro síťovou komunikaci je důležité, jaké se používají MAC adresy. V případě samostatného FortiGate získá redundantní interface MAC adresu prvního fyzického rozhraní (všechny zařazené porty budou mít stejnou MAC adresu). V případě HA clusteru se pro clusterová rozhraní využívají virtuální MAC adresy (má je přiřazena Master jednotka). Redundantní interface získá virtuální MAC adresu prvního fyzického rozhraní.

Konfigurace redundantních rozhraní

  • Network > Interfaces
  • Create New > Interface
  • zadáme nějaký název Name
  • jako typ rozhraní zvolíme Type: Redundant Interface
  • pod Interface members přidáme fyzická rozhraní, která chceme spojit

Link Aggregation - agregovaná rozhraní

Při použití LACP se vyjednává přes všechny interface v lince. V případě samostatného FortiGate se používá MAC adresa prvního fyzického rozhraní pro unikátní identifikaci agregované linky. V případě HA clusteru se použije virtuální MAC adresu prvního fyzického rozhraní.

V případě HA clusteru bychom na switchi měli vytvořit více Link Aggregation Group (LAG). Vždy společné porty z jednoho FortiGate spojit do společné LAG. Tedy například FW1 porty 1 a 2 vytvoří první skupinu, FW2 porty 1 a 2 vytvoří druhou skupinu. Pokud máme připojeny další agregované porty, tak například FW1 porty 3 a 4 vytvoří třetí skupinu a FW2 porty 3 a 4 vytvoří čtvrtou skupinu.

Konfigurace agregovaného rozhraní

  • Network > Interfaces
  • Create New > Interface
  • zadáme nějaký název Name
  • jako typ rozhraní zvolíme Type: 802.3ad Aggregate
  • pod Interface members přidáme fyzická rozhraní, která chceme spojit
FortiGate Interfaces - vytvoření 802.3ad Aggregate rozhraní

Konfigurace Cisco switche

Agregované rozhraní se na zařízeních Cisco označuje jako EtherChannel nebo PortChannel, konfiguraci jsem popisoval v článcích Cisco IOS 21 - EtherChannel, Link Agregation, PAgP, LACP, NIC Teaming a Cisco NX-OS 1 - Virtual Port Channel. Příklad nastavení:

SWITCH(config)#interface range g1/0/10, g2/0/10
SWITCH(config-if-range)#channel-group 10 mode active
Creating a port-channel interface Port-channel 10
SWITCH(config-if-range)#exit
SWITCH(config)#interface port-channel 10
SWITCH(config-if)#description FW1
SWITCH(config-if)#switchport mode access
SWITCH(config-if)#switchport access vlan 10
SWITCH(config-if)#interface range g1/0/10, g2/0/10
SWITCH(config-if-range)#no shutdown

Konfigurace a vytvoření clusteru

Dokumentace Basic configuration steps, HA active-active cluster setup

  • System > HA

Pro vytvoření FGCP clusteru připravíme síťové propojení a nastavíme základní parametry v System > HA. Po konfiguraci obou jednotek se automaticky vytvoří cluster. Proces zvolení primární jednotky (Master) je popsán v Primary unit selection with override disabled (default).

FortiGate System > HA konfigurace

Základní parametry

  • Mode - Active-Passive, Active- Active, Standalone
  • Device priority - vyšší priorita znamená větší šanci, aby byl Master
  • Group name - jméno skupiny (max. 32 znaků), slouží k identifikaci clusteru
  • Password - heslo pro danou skupinu
  • Group ID - pouze v CLI, vytváří se z něj virtuální MAC
  • Heartbeat interfaces - přes tyto rozhraní probíhá clusterová komunikace, doporučuje se nastavit minimálně dva a definovat jejich prioritu, komunikace probíhá skrze interface s nejvyšší prioritou, v případě jeho výpadku se přepne na další, pokud žádný není, tak jednotky začnou fungovat samostatně (standalone), což je problém

Rozšířené parametry

  • Session pickup - povoluje Session failover, pokud dojde k Failover, tak komunikační session pokračují, není podporováno pro session, kde se používá proxy-based security profiles, ale podporuje flow-based security profiles, pokud není zapnuto, tak se musí po Failover obnovit uživatelské session (třeba připojení přes FW na SSH, stahování souboru se přeruší, apod.), zapnutí znamená větší zátěž
  • Monitor interfaces - nastavíme sledované interface, pokud takový selže nebo je odpojen, dojde k Failover na druhou jednotku
  • Management Interface Reservation - standardně se mezi členy clusteru synchronizuje konfigurace, takže se oběma nastaví stejná IP adresa pro MGMT interface, pokud chceme získat přímý přístup na správu jednotlivých členů clusteru, tak musíme nastavit rozhraní jako část HA konfigurace (ta se nesynchronizuje), pak můžeme nastavovat různé IP adresy, přístupy a další parametry, včetně specifických statických route pro mgmt
  • Unicast Heartbeat - pokud vytváříme cluster nad FortiGate VM, tak můžeme používat unicast
  • VDOM partitioning - zapíná Virtual Clustering (vytvořený HA cluster se rozdělí na dva virtuální), je k dispozici pouze pro Active-Passive, určujeme, které VDOM patří do Virtual cluster 1 (zde je vždy root) a Virtual cluster 2, dále můžeme nastavit prioritu pro druhý cluster

Odpojení jednotky z clusteru

Členy clusteru můžeme jednoduše odebrat, kdy se stanou opět samostatnými (Standalone). A později vrátit zpět do clusteru.

  • System > HA
  • vybereme jednotku, Remove device from HA cluster
  • musíme vybrat interface pro management a zadat IP adresu

HA override

Dokumentace Disabling override (recommended)

Defaultně je override vypnuto (disabled). Pokud zapneme, tak se častěji vyjednává výběr primární jednotky. Zajistí to, aby jednotka určená jako primární byla primární dokud je dostupná, například po restartu. Jinak řečeno, využívá se nastavení priority pro určení Master jednotky. Ale způsobuje to více přepínání provozu (což může způsobit výpadky session). Většinou je to zbytečné a obtěžující, protože jsou obě jednotky stejné, tak by nám mělo být jedno, která obsluhuje provoz. Ale hodí se pro Virtual Clustering.

Pozn.: Pozor si musíme dát, pokud chceme měnit toto nastavení za provozu. Pokud jej zapneme, a jako Master jednotka není ta, která mám nastavenu vyšší prioritu, tak dojde k přepnutí. Stejně tak, pokud nastavení vypneme, tak může dojít k přepnutí.

Konfigurace se provádí z CLI a musí se provést pro každou jednotku zvlášť (nastavené priority zařízení a zapnutí override).

config system ha
    set override disable
end

Můžeme také nastavit zpoždění

set override-wait-time 10

Výběr primární jednotky (Master Node)

Určení HA Master jednotky se provádí podle hodnot v daném pořadí

  • Port Monitor (připojené sledované porty)
  • System Uptime (proces hatalk) - déle běžící bude Master (defaultně pouze, pokud je rozdíl větší než 5 minut)
  • hodnota priority zařízení (Device Priority) - vyšší priorita bude Master
  • sériové číslo (Device Serial Number) - vyšší hodnota bude Master

Pokud zapneme HA Priority Override, tak se změní

  • Port Monitor (připojené sledované porty)
  • hodnota priority zařízení (Device Priority) - vyšší priorita bude Master
  • System Uptime (proces hatalk) - déle běžící bude Master (defaultně pouze, pokud je rozdíl větší než 5 minut)
  • sériové číslo (Device Serial Number) - vyšší hodnota bude Master

Důležitý je malý detail. Hodnota HA Uptime se ignoruje, pokud je rozdíl času mezi jednotkami menší, než 5 minut (300 vteřin). Když provádíme upgrade HA clusteru, tak asi chceme minimalizovat výpadky, tak bychom chtěli pouze jedno přepnutí primární jednotky. Ale při upgradu nastartuje druhý node třeba po 2 minutách od prvního, takže se ignoruje, že se restartoval později, a rozhoduje se podle dalších hodnot. A to může způsobit, že se opět stane Masterem a dojde k přepnutí.

Naštěstí můžeme nastavit, jaký rozdíl časů se ignoruje.

config system ha
    set ha-uptime-diff-margin 90
end

Technical Note: Methodology for replacing a HA slave unit, Technical Tip: Restoring HA master role after a failover using 'diag sys ha reset uptime' (ha 'set override disable' context), Technical Tip: How to verify HA cluster members individual uptime

Kontrola stavu clusteru

FW (global) # get system ha status 

HA Health Status: OK
Model: FortiGate-300E Mode: HA A-P Group: 0 Debug: 0
Cluster Uptime: 123 days 15:11:16
Cluster state change time: 2020-09-27 09:06:34
Master selected using:
  virtual cluster 1:
     FG1... is selected as the master because it has the largest value of override priority.
     FG1... is selected as the master because it's the only member in the cluster.
     FG1... is selected as the master because it has the largest value of override priority.
  virtual cluster 2:
     FG2... is selected as the master because it has the largest value of override priority.
     FG1... is selected as the master because it's the only member in the cluster.
     FG1... is selected as the master because the peer member FG2... has SET_AS_SLAVE flag set.
     FG2... is selected as the master because it has the largest value of override priority.
ses_pickup: disable
override: vcluster1 enable, vcluster2 enable
Configuration Status:
    FG1...(updated 4 seconds ago): in-sync
    FG2...(updated 1 seconds ago): in-sync
System Usage stats:
    FG1...(updated 4 seconds ago):
        sessions=63669, average-cpu-user/nice/system/idle=55%/0%/3%/40%, memory=52%
    FG2...(updated 1 seconds ago):
        sessions=2634, average-cpu-user/nice/system/idle=0%/0%/2%/97%, memory=30%
HBDEV stats:
    FG1...(updated 4 seconds ago):
        ha: physical/1000auto, up, rx-bytes/packets/dropped/errors=151589181168/425635980/0/0, tx=104081226556/421353983/0/0
        port16: physical/1000auto, up, rx-bytes/packets/dropped/errors=34341895694/53408858/0/0, tx=34442496900/53399220/0/0
    FG2...(updated 1 seconds ago):
        ha: physical/1000auto, up, rx-bytes/packets/dropped/errors=4771617/31187/0/0, tx=10549194/33071/0/0
        port16: physical/1000auto, up, rx-bytes/packets/dropped/errors=1809225/2805/0/0, tx=1691090/2630/0/0
Master: FW1           , FG1..., HA cluster index = 1
Slave : FW2           , FG2..., HA cluster index = 0
number of vcluster: 2
vcluster 1: work 169.254.0.2
Master: FG1..., HA operating index = 0
Slave : FG2..., HA operating index = 1
vcluster 2: standby 169.254.0.1
Slave : FG1..., HA operating index = 1
Master: FG2..., HA operating index = 0

Následující příkaz můžeme spustit na různých členech clusteru a uvidíme HA uptime daného člena. U položky uptime vidíme časový rozdíl mezi oběma jednotkami.

FW (global) # diag sys ha dump-by vcluster 
<hatalk>             HA information.

vcluster_nr=1
  vcluster_0: start_time=1619848517(2021-05-01 07:55:17), state/o/chg_time=2(work)/2(work)/1619848517(2021-05-01 07:55:17)
  pingsvr_flip_timeout/expire=3600s/2351s
  FG1...: ha_prio/o=1/1, link_failure=0, pingsvr_failure=0, flag=0x00000000, uptime/reset_cnt=143/0
  FG2...: ha_prio/o=0/0, link_failure=0, pingsvr_failure=0, flag=0x00000001, uptime/reset_cnt=0/0

FW (global) # diagnose sys ha dump-by group
<hatalk>             HA information.
group-id=0, group-name='FWcluster'
has_no_hmac_password_member=0

gmember_nr=2
FG1...: ha_ip_idx=1, hb_packet_version=27, last_hb_jiffies=0, linkfails=0, weight/o=0/0, support_hmac_password=1
FG2...: ha_ip_idx=0, hb_packet_version=10, last_hb_jiffies=563059, linkfails=19, weight/o=0/0, support_hmac_password=1
hbdev_nr=2: ha(mac=04d5..17, last_hb_jiffies=563059, hb_lost=0), port16(mac=04d5..05, last_hb_jiffies=563059, hb_lost=0),

vcluster_nr=1
vcluster_0: start_time=1619848380(2021-05-01 07:53:00), state/o/chg_time=2(work)/3(standby)/1619852520(2021-05-01 09:02:00)
pingsvr_flip_timeout/expire=3600s/2110s
FG1...: ha_prio/o=0/0, link_failure=0, pingsvr_failure=0, flag=0x00000001, uptime/reset_cnt=143/0
FG2...: ha_prio/o=1/1, link_failure=0, pingsvr_failure=0, flag=0x00000000, uptime/reset_cnt=0/0

Manuální přepnutí

Technical Tip: How to force HA failover, (Technical Tip: Virtual Cluster HA FailOver Do's and Don'ts)

execute ha failover set 1

Doporučení pro FGCP cluster

Dokumentace FGCP best practices

  • použít mód Active-Active
  • pojmenovat jednotky i interface
  • spíše nepoužívat Session pickup
  • nastavit monitoring, když nastane cluster Failover (mail, SNMP, Syslog)
  • nepoužívat HA override

Virtuální domény - Virtual Domains (VDOM)

Dokumentace Virtual Domains, Virtual Domains, VDOM configuration

Virtuální domény (VDOM) rozdělí FortiGate na dvě nebo více virtuálních jednotek, které pracují nezávisle. Pro každou VDOM přidělujeme fyzické porty, určité prostředky, můžeme vytvořit správce dané VDOM. Udržují se oddělené politiky a routovací tabulky. Většina FortiGate modelů podporuje 10 VDOM (další se dají dokoupit).

Pozn.: Pokud zapneme VDOM, tak není podporován Security Fabric. Moc to Fortinet nezmiňuje, ale hledal jsem proč mi chybí nastavení pro FortiTelemetry a Security Rating (zde ještě začalo jít o licencovanou funkci) a toto je důvod. Od FortiOS 6.2.0 je podporován Security Fabric pro Split-task VDOM mode, Split-Task VDOM Support.

Schéma FortiGate VDOM

Díky VDOM můžeme kombinovat NAT a Transparent mode (v různých VDOM). Provozovat multi-tenant řešení (managed security service provider). Nebo šetřit prostředky, pokud nám stačí výkon jednoho FortiGate, místo více zařízení. VDOM můžeme použít nad clusterem (dvě fyzická zařízení spojíme do jednoho virtuálního a toto virtuálně rozdělíme na více samostatných zařízení).

Root VDOM a Global

I když nepoužíváme VDOM, tak existuje skrytá doména root VDOM. Po zapnutí VDOM se zobrazí a obsahuje všechny prostředky, také obsahuje všechnu konfiguraci a politiky (protože bez VDOM probíhala konfigurace v root). Po zapnutí VDOM se globální nastavení provádí mimo VDOM v části označené Global. Tato nastavení ovlivňují celý FortiGate, správu provádí hlavní administrátor.

VDOM root můžeme ponechat pro správu (běžné řešení), ale můžeme ji také využít jako standardní virtuální doménu. Nelze ji změnit název. Připojením na Management VDOM můžeme spravovat globální nastavení i všechny VDOM.

VDOM módy

Patrně od verze FortiOS 6.2 se při zapínání VDOM rozhodujeme mezi dvěma módy:

  • Split-task VDOM mode - (novinka) jedna VDOM je použita pouze pro správu, ostatní pro řízení provozu
  • Multi VDOM mode - můžeme vytvořit více VDOM, které pracují nezávisle

Častěji patrně využijeme Multi VDOM mode. V tomto módu Fortinet uvádí, že můžeme provozovat tři hlavní konfigurační typy (v rámci zapnutí VDOM toto nerozlišujeme). Ty se liší hlavně tím, zda mezi VDOM použijeme inter-VDOM routing.

  • Independent VDOMs
  • Management VDOM
  • Meshed VDOMs

Konfigurace VDOM

  • System > Settings - Virtual Domains

Nejprve musíme zapnout používání VDOM a zvolit mód, v jakém budou pracovat. V nastavení v časti System Operation Settings je přepínač Virtual Domains.

FortiGate System > Settings - Virtual Domains zapnutí

Po zapnutí VDOM se musíme znovu přihlásit, protože se změní GUI. V levém horním rohu pak přepínáme konfiguraci jednotlivých VDOM a globálního nastavení (pokud jsme přihlášeni jako administrátor s dostatečnými právy).

Fortigate přepínání globální konfigurace a VDOM

Následně můžeme spravovat existující VDOM a vytvářet nové. Musíme být v Global konfiguraci.

  • Global > System > VDOM
FortiGate System > VDOM vytváření a správa

editaci VDOM můžeme nastavovat omezení zdrojů. Nejedná se o klasické zdroje, jako je CPU či paměť, ale počty aktivních session, FW politik, uživatelů, apod.

  • Global > Network > Interfaces

V Globální konfiguraci můžeme přiřazovat jednotlivé interface do požadované VDOM.

FortiGate zařazení interface do VDOM
  • Global > System > Administrators

V Globální konfiguraci můžeme vytvářet účty správců pro jednotlivé VDOM. Když se přihlásí správce, který má přiřazenu jednu VDOM, tak nevidí přepínání v levém horním rohu.

FortiGate vytvoření správce pro VDOM

Použití CLI s VDOM

Ve chvíli, kdy zapneme používání VDOM, tak se lehce změní konfigurace pomocí příkazové řádky. Stejně jako v GUI se musíme přepínat mezi jednotlivými VDOM a globální konfigurací, tak to samé musíme použít v CLI. Musíme být ve správné konfigurační části, abychom mohli použít běžné příkazy.

FW1 # config vdom
FW1 (vdom) # edit root
current vf=root:0
FW1 (root) # end
FW1 # config global 
FW1 (global) # get system ha status

Inter-VDOM routing

Dokumentace Inter-VDOM routing, Inter-VDOM links and virtual clustering

Mezi virtuálními doménami můžeme vytvořit interní propojení, které umožní komunikaci. Provoz proudí skrze inter-VDOM link, který se skládá z virtuálního interface v každé VDOM (nevyžaduje nastavení IP adresy). I když nepřiřadíme na virtuální interface IP adresu, tak jej v politikách a jinde můžeme odkazovat jménem. V případě virtual clustering můžeme vytvářet inter-VDOM link pouze mezi VDOM v rámci jednoho virtuálního clusteru.

Vytvoření inter-VDOM linku mezi dvěma VDOM v NAT módu (v případě Virtual cluster pod Global):

  • Network > Interfaces
  • Create New > VDOM link

Využití VDOM pro separaci zón

Pokud máme jeden firewall (či cluster), tak je běžné zapojení, že nám FW odděluje komunikaci interní sítě (LAN) od internetu a k tomu se zapojuje DMZ (demilitarized zone) pro umístění serverů dostupných z internetu. Do lokální sítě by neměla být povolena žádná komunikace z internetu. Hrubé logické schéma je na následujícím obrázku.

síťové zapojení s DMZ a jedním firewallem

Jako více bezpečné se doporučuje zapojení, kdy máme dva firewally (či clustery), ideálně od různých výrobců. Externí FW (Front End či Perimetr) umožňuje komunikaci pouze do a z DMZ. Interní FW (Back End) povoluje pouze komunikaci z lokální sítě do DMZ. Komunikace z interní sítě do internetu musí projít skrze dva FW. Z internetu je povolena komunikace pouze do DMZ. Útočník musí kompromitovat dva FW, aby se dostal do interní sítě. Případně je možné zapojení, kdy jsou v DMZ dvě oddělené sítě, a servery musí mít síťová rozhraní do každé z nich (komunikace může projít pouze skrze určitý server). Opět jednoduché logické schéma.

síťové zapojení s DMZ a dvěma firewally (řešení s duálním firewallem)

Pokud vybudujeme FortiGate HA cluster, a nemáme k dispozici druhý FW cluster, tak můžeme využít VDOM a rozdělit náš cluster na dvě virtuální domény. Samozřejmě to není stejně bezpečné, jako dva fyzické FW různých výrobců, ale myslím, že lepší než řešení s jedním FW.

Virtual clustering - HA Cluster s VDOM partitioning

Dokumentace Virtual clustering, FGCP Virtual Clustering with two FortiGates (expert)

Pozn.: Vlastnost VDOM partitioning se mi hodně líbí. Bohužel jsem zjistil, že pokud ji použijeme, tak je problém s IPsec Site to Site VPN (FortiGate IPsec VPN, debug a problémy, a možná i něčím dalším). Již mi v minulosti jeden specialista říkal, že by radši tuto vlastnost nepoužíval.

Pokud máme FGCP cluster a VDOM, tak můžeme využít Virtual clustering. Jde o rozšíření High Availability pro cluster dvou FortiGate jednotek v Active-Passive módu s více VDOM. Po zapnutí VDOM Partitioning se náš cluster rozdělí na dva virtuální clustery (Virtual cluster 1 a Virtual cluster 2), kde každý má nastaven jiný FortiGate jako Master. Všechny VDOM jsou přiřazeny na první cluster, ale můžeme některé přesunout na druhý (root VDOM nelze přesunout). Pokud tedy vytvoříme dvě VDOM a každou přiřadíme do jiného virtuálního clusteru, tak bude standardně každou komunikaci zpracovávat jiný hardware FortiGate. Můžeme tak naplno využít oba boxy a zachovat ochranu proti výpadku.

Pozn.: Velmi důležitá věc, pokud používáme tuto konfiguraci. Pro řadu nastavení či zobrazení hodnot se musím připojit na fyzickou jednotku, kde je daná VDOM aktivní. Nemůžeme tedy využít virtuální management IP. Například při použití debug v CLI nebo monitory v GUI (IPsec občas zobrazuje tunel jako dole, občas ukazuje správně).

Schéma FortiGate Virtual cluster s VDOM partitioning

Nastavení VDOM Partitioning

  • Global > System > HA - VDOM Partitioning

Zapnutí Virtual clustering se provede jednoduše v nastavení HA, kde editujeme Master FortiGate a zapneme VDOM Partitioning (musíme mít mode Active-Passive, aby bylo nastavení dostupné). Níže můžeme přiřazovat jednotlivé VDOM na virtuální clustery.

Také můžeme nastavit prioritu pro Secondary Cluster. Dobré je nastavit hodnoty opačně, než na primárním clusteru. Po potvrzení OK uvidíme dva virtuální clustery. V druhém clusteru klineme na druhý FortiGate (zde by měl být Master) a nastavíme mu prioritu.

FortiGate HA - VDOM Partitioning

Pro Virtual clustering se automaticky zapíná HA override, ale nastaví se pouze na druhý cluster a druhý node. Pokud chceme plně využít, tak musíme ručně nastavit v CLI pro prvního člena clusteru. Možná šlo o problém FortiOS 6.2.3 nebo nastavení v GUI. Nastavoval jsem v CLI na FortiOS 6.2.7 a po zadání příkazu set vcluster2 enable se zapnulo override na oba virtuální clustery. Po aplikaci konfigurace (end) se příkaz přenes na druhý node a tak zde se zapnul override (i přesto, že jsem ho na Master vypnul).

Virtuální clustery využívají společné Heartbeat Interfaces.

FortiGate Virtual clustering

Výpis nastavení v CLI (konfiguraci) vypadá také jednoduše

FW1
config system ha
    set group-name "FWcluster"
    set mode a-p
    set password ENC zzz
    set hbdev "ha" 200 "port16" 100 
    set vcluster2 enable
    set override enable
    set priority 200
    config secondary-vcluster
        set override enable
        set priority 100
        set vdom "FWEXT" 
    end
end
 
FW2 
config system ha
    set group-name "FWcluster"
    set mode a-p
    set password ENC zzz
    set hbdev "ha" 200 "port16" 100 
    set vcluster2 enable
    set override enable
    set priority 100
    config secondary-vcluster
        set override enable
        set priority 200
        set vdom "FWEXT" 
    end
end

Měl jsem vypnutý VDOM Partitioning a chtěl jsem jej zapnout bez ovlivnění provozu. Podíval jsem se na nastavení priorit obou členů clusteru a připojil se na Master do CLI. Nastavil jsem mu vyšší prioritu (mohlo by stačit stejnou hodnotu jako Slave), zapnul virtuální cluster a pro druhý vcluster nastavil VDOM a prioritu (nevím, zda je to schválně, ale ta hodnota se nastavila automaticky).

FW2 (global) # 
config system ha
    set priority 200
    set vcluster2 enable
    config secondary-vcluster
        set priority 200
        set vdom "FWEXT" 
    end
end

Vznikl druhý virtuální cluster, ale Master zůstal pro oba stále stejná jednotka. Můžeme se podívat v GUI nebo vypsat.

get system ha status 

Zkontroloval jsem konfiguraci na druhé jednotce (část výpisu).

FW1 (ha) # show
config system ha
    set vcluster2 enable
    set override enable
    set priority 200
    config secondary-vcluster
        set override enable
        set priority 100
        set vdom "FWEXT" 
    end
end

Pro přesun druhého virtuálního cluster na druhou jednotku stačí změnit prioritu druhého vcluster na jedné jednotce. Přepnutí je okamžité, ale přeruší se navázané session (v praxi mi dokonce některé zůstanou aktivní).

FW2 (global) # 
config system ha
    config secondary-vcluster
        set priority 50
    end
end

Vypnutí VDOM Partitioning

Kvůli podezření, že při zapnutém VDOM Partitioning (Virtual clustering) nefungují správně IPsec VPN (to se ukázalo oprávněné), jsem potřeboval tuto funkci vypnout. Nikde ve Fortinet dokumentaci jsem k tomu nenašel žádnou zmínku. Potřeboval jsem to udělat bezpečně s minimálním výpadkem. Nakonec jsem to provedl a zjistit docela důležitou věc.

Přemýšlel jsem, zda provést konfiguraci v CLI, ale zvolil jsem jednoduše v GUI. Pouze přesunout poslední VDOM z Virtual cluster 2 nelze (jedna tam musí zůstat). Vypnul jsem přepínač VDOM Partitioning a uložil nastavení. Změna proběhal víceméně okamžitě. Jedna VDOM se přesunula na druhý node. Patrně to přerušilo session v dané VDOM, ale pingy, které skrze ni procházely, nezaznamenaly žádný výpadek.

Následně jsem v CLI provedl vypnutí override, protože je to pro Active-Passive HA cluster doporučené.

config system ha
   set override disable
end

A to nebyl dobrý krok pro situaci, kdy jsem chtěl minimální výpadky. FortiGate přestal pro určení Master jednotky používat prioritu (is selected as the master because it has the largest value of override priority), ale začal používat jiné hodnoty (is selected as the master because it has the largest value of uptime). A v tu chvíli přepnul Master Node (přesunul všechny VDOM), takže se přerušily všechny session skrze FW.

Související články:

Fortinet FortiGate a další

Bezpečnostní řešení firmy Fortinet. Nejvíce zaměřeno na Next Generation Firewall (NGFW) FortiGate. Konfigurace FW, politik, NATu, ale také VPN a možností autentizace. Okrajově práce s logy pomocí FortiAnalyzer a s klienty pomocí FortiClient EMS.

Bezpečnost

Nástroje zajišťující bezpečnost. Primárně Firewall a podobné.

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže.

Komentáře
  1. [1] Karel

    Díky za super článek!

    Sobota, 07.03.2020 17:51 | odpovědět
  2. [2] Michal

    Díky za skvělý článek. Neplánuješ pokračovat s Fortinetem? Moc mi to pomohlo

    Úterý, 01.12.2020 15:28 | odpovědět
Přidat komentář

Vložit tag: strong em link

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách