🥇Kdy vám již Linux conntrack není spojencem

Sledování připojení („conntrack“) je základní funkcí síťového zásobníku jádra Linux. Umožňuje jádru sledovat všechny logické síťové připojení nebo toky a tím identifikovat všechny pakety, které tvoří každý tok, aby je bylo možné zpracovávat postupně společně.

Conntrack je důležitá funkce jádra, která se používá v některých hlavních případech:

NAT se spoléhá na informace od conntrack, takže může stejně zpracovávat všechny pakety z jednoho toku. Například když pod žádá o službu Kubernetes, vyvažovač zatížení kube-proxy používá NAT pro směrování provozu na konkrétní pod uvnitř klastru. Conntrack zaznamenává, že pro určité připojení musí být všechny pakety do IP služby odesílány do stejného pod, a že pakety vrácené backendovým podem musí být NAT směrovány zpět do podu, ze kterého přišel požadavek.
Firewall s sledováním stavu, jako je Calico, se spoléhá na informace od conntrack, aby mohl přidávat „odpovídající“ provoz do whitelistu. To vám umožňuje napsat síťovou politiku, která říká: „umožnit mému podu připojit se k jakékoli vzdálené IP adrese“ bez nutnosti psát politiku pro explicitní povolení odpovídajícího provozu. (Bez toho byste museli přidat mnohem méně bezpečné pravidlo „povolit pakety do mého podu z jakékoli IP“.)

Kromě toho conntrack obvykle zvyšuje výkon systému (snižuje spotřebu procesorového času a latenci paketů), protože pouze první paket v toku
musí projít úplným zpracováním síťového zásobníku, aby se zjistilo, co s ním dělat. Podívejte se na příspěvek „Porovnání režimů kube-proxy“, abyste viděli příklad toho, jak to funguje.

Nicméně, conntrack má své omezení...

Takže, kde se to všechno pokazilo?

Tabulka conntrack má nastavitelné maximální velikosti a pokud se naplní, připojení obvykle začnou být odmítána nebo přerušena. Pro zpracování provozu většiny aplikací je v tabulce obvykle dostatek volného místa a nikdy to nepřeroste v problém. Nicméně existuje několik scénářů, ve kterých byste měli zvážit použití tabulky conntrack:

Nejdůležitější případ nastává, když váš server zpracovává mimořádně velké množství současně aktivních připojení. Například pokud je vaše tabulka conntrack nastavena na 128k záznamů, ale máte více než 128k současných připojení, určitě narazíte na problém!
O něco méně zřejmý případ: pokud váš server zpracovává velmi velké množství připojení za sekundu. I když jsou připojení krátkodobá, Linux je sleduje po určitou dobu (výchozí nastavení je 120 s). Například pokud je vaše tabulka conntrack nastavena na 128 tisíc záznamů a pokoušíte se zpracovat 1100 připojení za sekundu, překročí to velikost tabulky conntrack, i když jsou připojení velmi krátká (128k / 120 s = 1092 připojení/s).

Existuje několik specifických typů aplikací, které spadají do těchto kategorií. Dále, pokud máte hodně nepřátel, může být zaplnění tabulky conntrack vašeho serveru mnoha polootevřenými připojeními využito v rámci útoku typu „odmítnutí služby“ (DOS). V obou případech se conntrack může stát limitujícím úzkým místem ve vaší systému. V některých případech může být úprava parametrů tabulky conntrack dostačující pro splnění vašich potřeb — zvýšením velikosti nebo zkrácením časových limitů conntrack (ale pokud to uděláte špatně, budete čelit velkým potížím). V jiných případech bude třeba obejít conntrack pro agresivní provoz.

Skutečný příklad

Uveďme konkrétní příklad: jeden velký poskytovatel SaaS, se kterým jsme spolupracovali, měl řadu memcached serverů na hostitelích (ne virtuálních strojích), z nichž každý zpracovával více než 50K krátkodobých připojení za sekundu.

Zkoušeli experimentovat s konfigurací conntrack, zvyšovali velikosti tabulek a zkracovali čas sledování, ale konfigurace byla nespolehlivá, výrazně vzrostla spotřeba RAM, což bylo problémem (které bylo na úrovni gigabajtů!), a připojení byla tak krátká, že conntrack nedosahoval obvyklých přínosů v výkonu (snížení spotřeby CPU nebo latence paketů).

Jako alternativu se obrátili na Calico. Síťové politiky Calico umožňují nevyužívat conntrack pro určitý typ provozu (použitím možnosti doNotTrack pro politiky). To jim zajistilo potřebnou úroveň výkonu a navíc další úroveň zabezpečení poskytovanou Calico.

Co vše budete muset udělat, abyste obcházeli conntrack?

Politiky do-not-track by měly být obvykle symetrické. V případě poskytovatele SaaS: jejich aplikace pracovaly uvnitř chráněné zóny, a proto pomocí síťové politiky mohli přidat do whitelistu provoz z jiných konkrétních aplikací, kterým byl povolen přístup k memcached.
Politika do-not-track nezohledňuje směr spojení. Takže, v případě hacku memcached serveru, by se teoreticky dalo pokusit připojit k jakémukoli z memcached klientů, pokud používá správný výchozí port. Nicméně, pokud jste správně definovali síťovou politiku pro své klienty memcached, tyto pokusy o připojení budou i tak odmítnuty na straně klienta.
Politika do-not-track se aplikuje na každý paket, na rozdíl od běžných politik, které se aplikují pouze na první paket z toku. To může zvýšit spotřebu CPU na jeden paket, protože pro každý paket je třeba aplikovat politiku. Ale pro krátkodobá spojení se tato spotřeba vyrovnává se snížením spotřeby prostředků na zpracování conntrack. Například v případě poskytovatele SaaS bylo počet paketů pro každé spojení velmi malé, takže dodatečná spotřeba CPU při aplikaci politik na každý paket byla odůvodněná.

Přejdeme k testování

Prováděli jsme test na jednom podu s memcached serverem a množstvím podů memcached klientů spuštěných na vzdálených uzlech, abychom mohli provádět velmi vysoký počet spojení za sekundu. Server s podmem memcached serveru měl 8 jader a 512k záznamů v tabulce conntrack (standardně nastavená velikost tabulky pro hostitele).
Měřili jsme rozdíl ve výkonu mezi: bez síťové politiky; s běžnou Calico politikou; a s Calico do-not-track politikou.

Pro první test jsme nastavili počet připojení na 4 000 za sekundu, takže jsme se mohli zaměřit na rozdíly v CPU. Mezi absencí politiky a běžnou politikou nebyly významné rozdíly, ale politika do-not-track zvýšila spotřebu CPU přibližně o 20 %:

Ve druhém testu jsme spustili tolik připojení, kolik naši klienti mohli generovat, a měřili maximální počet připojení za sekundu, který náš server memcached zvládnul. Jak se očekávalo, v případě „bez politik“ a „běžná politika“ obě dosáhly limitu conntrack nad 4 000 připojení za sekundu (512k / 120s = 4 369 připojení/s). S politikou do-not-track naši klienti odesílali 60 000 připojení za sekundu bez jakýchkoli problémů. Jsme si jisti, že bychom toto číslo mohli zvýšit připojením více klientů, ale cítíme, že tato čísla jsou již dostatečná k ilustraci poselství tohoto článku!

Závěr

Conntrack je důležitá funkce jádra. Výborně plní svou práci. Často je využíván klíčovými komponentami systému. V některých specifických scénářích však zatížení kvůli conntracku převyšuje běžné výhody, které přináší. V tomto scénáři mohou být síťové politiky Calico použity k selektivnímu zakázání používání conntracku, čímž se zvyšuje úroveň síťové bezpečnosti. Pro veškerý ostatní provoz zůstává conntrack vaším spojencem!