Předpokladem tohoto článku je zprovozněný keepalived, kterým se článek dále podrobněji nezabývá. Předpokládá se, že virtualizovány jsou jak vnější, tak i vnitřní interface.
Synchronizace connection trackingu – rychlá odpověď
Pro synchronizaci connection tracking tabulky je možné použít nástroj conntrackd, který je vyvíjen jedním z členů NetFilter týmu (www.netfilter.org). Autor na nástroji stále pracuje. Drobnou nevýhodu spatřuji v tom, že nástroj je vyvíjen vždy pro aktuální verzi kernelu a může být zpětně nekompatibilní (na úrovni zdrojového kódu) se staršími verzemi. Toto není komplikací v případě základní funkcionality. Pokud je ale potřeba podpora pro nějaký nový protokol, může se stát, že i po získání patche se vám tento nepodaří aplikovat na starší kernel.
Nástroj conntrackd je distribuován v rámci většího balíku conntrack-tools (aktuální verze 0.9.5) a může být stažen například z people.netfilter.org/pablo/conntrack-tools.
Synchronizace connection trackingu – podrobněji
Nástroj conntrackd je potřeba přeložit (distribuují se pouze zdrojové kódy). Pro překlad aktuální verze bude potřeba knihovna libnetfilter_conntrack verze alespoň 0.0.80 a knihovna libnfnetlink verze alespoň 0.0.16. Dále je potřeba zkontrolovat, zda je v kernel povoleno zasílání událostí connection trackingu.
Jak nástroj funguje? Conntrackd je démon, který nedělá nic jiného, než že zachytává události zasílané connection tracking tabulkou (o vzniku nového connection trackingu, o smazání, atd.) a podle nich aktualizuje svou interní cache. Tato cache je pak propagována na záložní stroj. Způsoby, jak se tyto změny propagují, jsou dva. V perzistentním režimu je v případě vzniku nového connection trackingu tento záznam okamžitě propagován na záložní stroj. Pak se pravidelně v uživatelem definované periodě (viz níže) zasílá celá tabulka. Tudíž je zaručeno, že démon na záložním stroji obsahuje v jistém čase vždy přesný obraz tabulky na zálohovaném stroji. Trochu jiný přístup používá synchronizace pomocí NACK (negative acknowledgement) protokolu. Ten propaguje pouze změny, a pouze, pokud nastanou. Může se tedy stát, že obrazy connection tracking tabulek na záložním a zálohovaném stroji si zcela neodpovídají. Výměnou získáme nižší servisní provoz. Dále bude detailněji popsán pouze persistentní režim.
Nyní zbývá vyřešit jen problém, aby byla connection tracking tabulka kernelu ve vhodný okamžik nahrazena interní tabulkou udržovanou démonem. K tomuto účelu slouží scripty script_backup.sh a script_master.sh, které jsou součástí balíku conntrack-tools a není nutné je nijak modifikovat. Tyto skripty je potřeba zavolat v okamžiku výpadku, kdy se keepalived přepne ze stavu MASTER do stavu BACKUP, resp. naopak. Toho se dá docílit doplněním konfigurace keepalived o dva řádky.
vrrp_sync_group G1 { ... notify_master /etc/conntrackd/script_master.sh notify_backup /etc/conntrackd/script_backup.sh }
Vlastní konfigurace nástroje conntrackd se standardně ukládá do souboru /etc/conntrackd/contrackd.conf
. Vzorová konfigurace systému jako celku pak vypadá například takto:
keepalived.conf:
vrrp_sync_group G1 { group { VI_1 VI_2 } notify_master /etc/conntrackd/script_master.sh notify_backup /etc/conntrackd/script_backup.sh } vrrp_instance VI_1 { interface eth1 state SLAVE virtual_router_id 61 priority 80 advert_int 3 virtual_ipaddress { 192.168.0.100 } } vrrp_instance VI_2 { interface eth0 state SLAVE virtual_router_id 62 priority 80 advert_int 3 virtual_ipaddress { 192.168.1.100 } }
Jednotlivé atributy byly probírány minule. Konfigurace keepalived je zde jen pro účely definice kontextu nutného pro nastavení conntrackd.
conntrackd.conf:
Sync { Mode PERSISTENT { RefreshTime 15 CacheTimeout 180 CommitTimeout 180 } Multicast { IPv4_address 225.0.0.50 IPv4_interface 192.168.100.100 Interface eth2 Group 3780 } Checksum on } General { HashSize 8192 HashLimit 65535 LogFile /var/log/conntrackd.log LockFile /var/lock/conntrack.lock UNIX { Path /tmp/sync.sock Backlog 20 } SocketBufferSize 262142 SocketBufferSizeMaxGrown 655355 } IgnoreTrafficFor { IPv4_address 127.0.0.1 # loopback IPv4_address 192.168.0.1 IPv4_address 192.168.1.1 IPv4_address 192.168.100.100 # dedicated link ip IPv4_address 192.168.0.100 # virtual IP 1 IPv4_address 192.168.1.100 # virtual IP 2 } IgnoreProtocol { UDP ICMP IGMP VRRP }
Zajímavými atributy jsou: atribut RefreshTime, který udává, po jaké době (v sekundách) se bude synchronizovat interní obraz connection tracking tabulky udržovaný v conntrackd. CacheTimeout – říká, jak dlouho mají zůstat v cache démona záznamy, pokud démon nedostává zprávy (od connection tracking tabulky) o jejich stavu. Ve skupině Multicast je definována multicastová ip adresa pro skupinu strojů, které dohromady tvoří (pro potřeby tohoto článku) virtuální stroj. Jak je vidět, je možné nastavit ignorování záznamů jak podle konkrétní cílové ip adresy, tak i podle typu L4 protokolu. Navíc je v některých případech, jmenovitě např. u tcp, možné nastavit ignorování záznamů, které odpovídají určitému stavu spojení (je možné zálohovat např. jen stavy odpovídající sestaveným – ESTABLISHED
– spojením). Toho docílíme definováním atributu Replicate [ESTABLISHED|TIMED_WAIT|...]
ve skupině atributů Sync.
Konec
V tomto díle byl představen poslední nástroj použitý pro vytvoření vysoce dostupného firewallu. Kombinací dvou představených utilit (keepalived z minulého dílu a conntrackd) je tedy možné postavit funkční, fyzicky redundantní firewall, a tím zvýšit dostupnost a spolehlivost spojení vnitřní a vnější sítě. Jediné, co je potřeba, je trocha času na vyladění konfigurace.