🥇Keď vám Linux conntrack už nie je partnerom

Sledovanie pripojení („conntrack“) je základnou funkciou sieťového zásobníka jadra Linux. Umožňuje jadru sledovať všetky logické sieťové pripojenia alebo toky a tým identifikovať všetky pakety, ktoré tvoria každý tok, aby ich bolo možné spracovávať sekvenčne.

Conntrack je dôležitá funkcia jadra, ktorá sa používa v niektorých základných prípadoch:

NAT sa opiera o informácie z conntracku, takže je schopné spracovávať všetky pakety z jedného toku rovnako. Napríklad, keď pod pristupuje k službe Kubernetes, vyrovnávač zaťaženia kube-proxy využíva NAT na presmerovanie prevádzky na konkrétny pod v rámci klastra. Conntrack zaznamenáva, že pre konkrétne pripojenie musia byť všetky pakety k IP služby odoslané na ten istý pod, a že pakety vracované backendovým podom musia byť NAT-om nasmerované späť do podu, z ktorého prišla požiadavka.
Firewall-y s sledovaním stavu, ako je Calico, sa opierajú o informácie z conntracku, aby pridali „odpovedajúcu“ prevádzku do bieleho zoznamu. To vám umožňuje napísať sieťovú politiku, ktorá hovorí: „dovoliť môjmu podu pripojiť sa k akémukoľvek vzdialenému IP adresu“ bez toho, aby ste museli písať politiku na explicitné povolenie odpovedajúcej prevádzky. (Bez toho by ste museli pridať oveľa menej bezpečné pravidlo „povoliť pakety do môjho podu z akéhokoľvek IP“.)

Okrem toho, conntrack zvyčajne zvyšuje výkon systému (znižovaním spotreby procesorového času a časov oneskorenia paketov), pretože iba prvý paket v prúde
musí prejsť úplným spracovaním sieťového zásobníka, aby sa zistilo, čo s ním robiť. Pozrite si príspevok „Porovnanie režimov kube-proxy“, aby ste videli príklad toho, ako to funguje.

Napriek tomu má conntrack svoje obmedzenia...

Takže, kde to všetko išlo zle?

Tabuľka conntrack má nastaviteľnú maximálnu veľkosť a ak sa zaplní, pripojenia zvyčajne začnú odmietať alebo prerušovať. Na spracovanie prevádzky väčšiny aplikácií je v tabuľke zvyčajne dostatok voľného miesta, a to sa nikdy nestane problémom. Napriek tomu existuje niekoľko scenárov, pri ktorých stojí za zamyslenie nad použitím tabuľky conntrack:

Najzjavnejší prípad nastáva, ak váš server spracováva extrémne veľké množstvo súčasných aktívnych pripojení. Napríklad, ak je vaša tabuľka conntrack nastavená na 128k záznamov, ale máte > 128k súčasných pripojení, určite natrafíte na problém!
Menej zjavný prípad: ak váš server spracováva veľmi veľké množstvo pripojení za sekundu. Aj keď sú pripojenia krátkodobé, Linux ich naďalej sleduje počas určitého časového obdobia (predvolene 120s). Napríklad, ak je vaša tabuľka conntrack nastavená na 128 tisíc záznamov a pokúšate sa spracovať 1100 pripojení za sekundu, prekročia veľkosť tabuľky conntrack, aj keď sú pripojenia veľmi krátke (128k / 120s = 1092 pripojení / s).

Existuje niekoľko špecifických typov aplikácií, ktoré spadajú do týchto kategórií. Okrem toho, ak máte veľa nepriateľov, zaplnenie tabuľky conntrack vášho servera mnohými polootvorenými pripojeniami môže byť využité v rámci útoku typu „odmietnutie služby“ (DOS). V oboch prípadoch sa conntrack môže stať obmedzujúcim užším miestom vo vašej systéme. V niektorých prípadoch môže byť nastavenie parametrov tabuľky conntrack dostatočné pre splnenie vašich potrieb — zvýšením veľkosti alebo skrátením časových limitov conntrack (ale ak to urobíte nesprávne, čelíte veľkým problémom). Pre iné prípady bude potrebné obísť conntrack pre agresívny prenos.

Skutočný príklad

Uvedieme konkrétny príklad: jeden veľký poskytovateľ SaaS, s ktorým sme pracovali, mal radu serverov memcached na hostiteľoch (nie virtuálnych strojoch), pričom každý spracovával viac ako 50K krátkodobých pripojení za sekundu.

Experimentovali s konfiguráciou conntrack, zvyšovali veľkosti tabuliek a skracovali doby sledovania, ale konfigurácia bola nestabilná, výrazne sa zvýšila spotreba RAM, čo bol problém (okolo GB!), a pripojenia boli tak krátke, že conntrack nezískal svoj obvyklý výhodu v oblasti výkonu (zníženie spotreby CPU alebo oneskorení paketov).

Ako alternatívu sa obrátili na Calico. Sieťové politiky Calico umožňujú nepoužívať conntrack pre určitý typ prevádzky (používajúci možnosť doNotTrack pre politiky). To im zabezpečilo potrebnú úroveň výkonu plus dodatočnú úroveň bezpečnosti poskytovanú Calico.

Čo budete musieť urobiť, aby ste obchádzali conntrack?

Sieťové politiky do-not-track by mali byť zvyčajne symetrické. V prípade poskytovateľa SaaS: ich aplikácie fungovali vo vnútornej chránenej oblasti, a preto s pomocou sieťovej politiky mohli pridať do bielej listiny prevádzku z iných konkrétnych aplikácií, ktorým bol umožnený prístup k memcached.
Politika do-not-track nezohľadňuje smer pripojenia. Takže v prípade hacknutia memcached servera sa teoreticky môžete pokúsiť pripojiť k akémukoľvek z memcached klientov, ak použije správny zdrojový port. Avšak, ak ste správne definovali sieťovú politiku pre svojich klientov memcached, tieto pokusy o pripojenie budú stále zamietnuté na strane klienta.
Politika do-not-track sa uplatňuje na každý paket, na rozdiel od obyčajných politík, ktoré sa uplatňujú iba na prvý paket zo streamu. To môže zvýšiť spotrebu procesora pre jeden paket, pretože pre každý paket je potrebné uplatniť politiku. Ale pre krátkodobé pripojenia sa táto spotreba vyrovnáva znížením spotreby zdrojov na spracovanie conntrack. Napríklad, v prípade poskytovateľa SaaS bolo množstvo paketov pre každé pripojenie veľmi malé, takže dodatočné náklady na procesor pri uplatňovaní politík na každý paket boli ospravedlnené.

Prejdime na testovanie.

Robili sme test na jednom pod'e s memcached serverom a mnohými podmi memcached klientov, spustenými na vzdialených nodoch, aby sme mohli spúšťať veľmi veľké množstvo pripojení za sekundu. Server s pod'om memcached servera mal 8 jadier a 512k záznamov v tabulke conntrack (štandardne nastavená veľkosť tabulky pre hostiteľa).
Merali sme rozdiel vo výkonnosti medzi: bez sieťovej politiky; s obyčajnou Calico politikou; a politikou Calico do-not-track.

Pre prvý test sme nastavili počet pripojení na 4.000 za sekundu, aby sme mohli sústrediť pozornosť na rozdiely v spotrebe CPU. Tu neboli významné rozdiely medzi absenciou politiky a bežnou politikou, ale do-not-track zvýšila spotrebu CPU približne o 20%.

V druhom teste sme spustili toľko pripojení, koľko mohli naši klienti vygenerovať, a merali sme maximálny počet pripojení za sekundu, ktoré dokázal spracovať náš memcached server. Ako sa očakávalo, v prípade „bez politík“ a „bežnej politiky“ obidve dosiahli limit conntracku viac ako 4,000 pripojení za sekundu (512k / 120s = 4,369 pripojení/s). S politikou do-not-track naši klienti odosielali 60,000 pripojení za sekundu bez akýchkoľvek problémov. Sme presvedčení, že by sme mohli toto číslo zvýšiť pripojením väčšieho počtu klientov, ale cítime, že tieto čísla už stačia na to, aby ilustrovali posolstvo tohto článku!

Záver

Conntrack je dôležitá funkcia jadra. Perfektne plní svoju úlohu. Často ho používajú kľúčové komponenty systému. Avšak v niektorých špecifických scenároch preťaženie kvôli conntracku prevažuje nad bežnými výhodami, ktoré ponúka. V tomto scenári môžu byť sieťové politiky Calico použité na výberové vypnutie využívania conntracku, čím sa zvyšuje úroveň sieťovej bezpečnosti. Pre všetok ostatný prenos ostáva conntrack vaším partnerom!