Sledování připojení („conntrack“) je základní funkcí síťového zásobníku linuxového jádra. Umožňuje jádru sledovat všechna logická síťová připojení nebo toky, a tím identifikovat všechny pakety, které tvoří každý tok, aby je bylo možné zpracovat postupně.
Conntrack je důležitá funkce jádra, která se používá v některých základních případech:
- NAT se spoléhá na informace z conntrack, takže může zacházet se všemi pakety ze stejného proudu stejně. Když například pod přistupuje ke službě Kubernetes, nástroj pro vyrovnávání zatížení kube-proxy používá NAT k nasměrování provozu na konkrétní pod v rámci clusteru. Conntrack zaznamenává, že pro dané připojení musí být všechny pakety do služby IP odeslány do stejného modulu a že pakety vrácené backendovým modulem musí být NATovány zpět do modulu, ze kterého požadavek přišel.
- Stavové firewally, jako je Calico, spoléhají na informace z Connecttracku až po whitelist „response“ provozu. To vám umožňuje napsat síťovou zásadu, která říká „povolit mému podu připojit se k jakékoli vzdálené IP adrese“, aniž byste museli psát zásadu, která by explicitně povolila provoz s odpovědí. (Bez toho byste museli přidat mnohem méně bezpečné pravidlo „povolit pakety do mého modulu z jakékoli IP“.)
Navíc conntrack obvykle zlepšuje výkon systému (snížením spotřeby CPU a latence paketů), protože pouze první paket ve streamu
musí projít celý síťový zásobník, aby se zjistilo, co s ním dělat. Viz příspěvek"“, abyste viděli příklad, jak to funguje.
Conntrack má však svá omezení...
Tak kde se to všechno podělo?
Tabulka conntrack má konfigurovatelnou maximální velikost, a pokud se zaplní, připojení obvykle začnou být odmítnuta nebo zrušena. V tabulce je dostatek volného místa pro provoz většiny aplikací a nikdy to nebude problém. Existuje však několik scénářů, ve kterých byste mohli zvážit použití tabulky conntrack:
- Nejzřetelnější případ je, pokud váš server zpracovává extrémně velký počet současně aktivních připojení. Pokud je například vaše tabulka conntrack nakonfigurována pro 128k záznamů, ale máte >128k souběžných připojení, určitě narazíte na problém!
- Trochu méně zřejmý případ: pokud váš server zpracovává velmi velký počet připojení za sekundu. I když jsou připojení krátkodobá, Linux je nadále po určitou dobu monitoruje (ve výchozím nastavení 120 s). Pokud je například vaše tabulka conntrack nakonfigurována pro 128 1100 záznamů a pokoušíte se zpracovat 128 120 připojení za sekundu, překročí velikost tabulky conntrack, i když jsou připojení velmi krátká (1092 k/XNUMX s = XNUMX XNUMX připojení/ s).
Do těchto kategorií spadá několik speciálních typů aplikací. Navíc, pokud máte hodně špatných herců, naplnění tabulky conntrack vašeho serveru spoustou napůl otevřených připojení může být použito jako součást útoku denial of service (DOS). V obou případech se conntrack může stát omezujícím úzkým hrdlem ve vašem systému. V některých případech může stačit úprava parametrů tabulky conntrack, aby vyhovovaly vašim potřebám – zvýšením velikosti nebo snížením časových limitů conntrack (pokud to ale uděláte špatně, narazíte na spoustu problémů). Pro ostatní případy bude nutné pro agresivní provoz konntrack obejít.
Skutečný příklad
Uveďme konkrétní příklad: jeden velký poskytovatel SaaS, se kterým jsme spolupracovali, měl na hostitelích řadu serverů uložených v memcachingu (nikoli virtuálních počítačů), z nichž každý zpracovával 50 XNUMX+ krátkodobých připojení za sekundu.
Experimentovali s konfigurací conntrack, zvětšováním velikosti tabulek a zkrácením doby sledování, ale konfigurace byla nespolehlivá, spotřeba RAM se výrazně zvýšila, což byl problém (řádově GB!), a spojení byla tak krátká, že conntrack nefungoval. vytvořit jeho obvyklou výkonnostní výhodu (snížená spotřeba CPU nebo latence paketů).
Jako alternativu se obrátili na Calico. Síťové zásady Calico vám umožňují nepoužívat conntrack pro určité typy provozu (pomocí možnosti zásady doNotTrack). To jim poskytlo požadovanou úroveň výkonu a navíc přidanou úroveň zabezpečení, kterou poskytuje Calico.
Jakou délku budete muset zajít, abyste obešli conntrack?
- Síťové zásady „nesledovat“ by měly být obecně symetrické. V případě poskytovatele SaaS: jejich aplikace běžely v chráněné zóně, a proto pomocí síťových zásad mohli přidat provoz z jiných konkrétních aplikací, kterým byl povolen přístup k memcached.
- Zásada do-not-track nebere v úvahu směr připojení. Pokud je tedy server memcached hacknutý, můžete se teoreticky pokusit připojit ke kterémukoli z klientů memcached, pokud používá správný zdrojový port. Pokud jste však správně definovali síťovou politiku pro své klienty v memcachingu, budou tyto pokusy o připojení na straně klienta stále odmítnuty.
- Zásada nesledování se aplikuje na každý paket, na rozdíl od normálních zásad, které se aplikují pouze na první paket v toku. To může zvýšit spotřebu CPU na paket, protože zásady musí být aplikovány na každý paket. Ale u připojení s krátkou životností jsou tyto náklady vyváženy snížením spotřeby zdrojů pro zpracování conntrack. Například v případě poskytovatele SaaS byl počet paketů pro každé připojení velmi malý, takže další spotřeba CPU při aplikaci politik na každý paket byla oprávněná.
Začněme testovat
Test jsme provedli na jednom modulu se serverem memcached a více moduly klientů v memcached běžících na vzdálených uzlech, takže jsme mohli spustit velmi velký počet připojení za sekundu. Server s memcached server pod měl 8 jader a 512k záznamů v tabulce conntrack (standardně nakonfigurovaná velikost tabulky pro hostitele).
Měřili jsme rozdíl ve výkonu mezi: žádná síťová politika; s pravidelnou politikou Calico; a Calico do-not-track policy.
Pro první test jsme nastavili počet připojení na 4.000 za vteřinu, takže jsme se mohli zaměřit na rozdíl ve spotřebě CPU. Nebyly žádné významné rozdíly mezi žádnou politikou a běžnou politikou, ale nesledovat zvýšenou spotřebu CPU asi o 20 %:
Ve druhém testu jsme spustili tolik připojení, kolik mohli naši klienti vygenerovat, a změřili jsme maximální počet připojení za sekundu, které náš server s memcached dokázal zpracovat. Jak se očekávalo, případy „žádná politika“ a „běžná politika“ dosáhly limitu připojení více než 4,000 512 připojení za sekundu (120 k / 4,369 s = 60,000 XNUMX připojení/s). Díky zásadě do-not-track odeslali naši klienti bez problémů XNUMX XNUMX spojení za sekundu. Jsme si jisti, že bychom toto číslo mohli zvýšit přidáním dalších klientů, ale domníváme se, že tato čísla jsou již dostatečná pro ilustraci smyslu tohoto článku!
Závěr
Conntrack je důležitá vlastnost jádra. Svou práci dělá perfektně. Často jej využívají klíčové systémové komponenty. V některých konkrétních scénářích však přetížení v důsledku conntrack převáží běžné výhody, které poskytuje. V tomto scénáři lze zásady sítě Calico použít k selektivnímu zakázání použití conntrack a zároveň ke zvýšení zabezpečení sítě. Pro veškerý ostatní provoz je conntrack i nadále vaším přítelem!
Přečtěte si také další články na našem blogu:
Zdroj: www.habr.com