Pozn.: Popis v článku vychází z FortiGate FG-300E s FortiOS 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.
Dokumentace pro verzi 6.x se nachází na různých místech
- FortiGate / FortiOS 6.0.0 > Handbook
- FortiGate / FortiOS 6.2
- FortiGate / FortiOS 6.0.0 > Cookbook
- FortiGate / FortiOS 6.2.3 > Cookbook
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.
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.
Následující obrázky ukazují příklad základního zapojení pro cluster a ukázkové schéma clusteru od Fortinetu.
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).
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
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).
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.
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.
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).
Následně můžeme spravovat existující VDOM a vytvářet nové. Musíme být v Global konfiguraci.
- Global > System > VDOM
V 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.
- 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.
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.
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.
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ě).
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.
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.
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.
Díky za super článek!
Díky za skvělý článek. Neplánuješ pokračovat s Fortinetem? Moc mi to pomohlo