Hlavní navigace

Vysoce dostupný firewall s pomocí Conntrackd

20. 11. 2007
Doba čtení: 4 minuty

Sdílet

V minulé části seriálu o vysoce dostupném firewallu byl představen jeden z (několika) nástrojů, který umožňuje vytvořit z více fyzických strojů jeden virtuální. Tímto způsobem můžeme vytvořit virtuální router. V poslední části seriálu si představíme nástroj pro synchronizaci tabulek connection trackingu.

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.netfil­ter.org/pablo/con­ntrack-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_con­ntrack 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:

CS24_early

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.

Byl pro vás článek přínosný?

Autor článku