Sledovanie pripojení („conntrack“) je základnou funkciou sieťového zásobníka jadra Linuxu. 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é spracovať postupne.
Conntrack je dôležitá funkcia jadra, ktorá sa používa v niektorých základných prípadoch:
- NAT sa spolieha na informácie z conntrack, takže môže zaobchádzať so všetkými paketmi z rovnakého toku rovnako. Napríklad, keď modul pristupuje k službe Kubernetes, nástroj na vyvažovanie záťaže kube-proxy používa NAT na nasmerovanie prevádzky na konkrétny modul v rámci klastra. Conntrack zaznamenáva, že pre dané pripojenie musia byť všetky pakety do služby IP odoslané do rovnakého modulu a že pakety vrátené backendovým modulom musia byť NATované späť do modulu, z ktorého prišla požiadavka.
- Stavové brány firewall, ako je Calico, sa spoliehajú na informácie z Connecttracku na bielu listinu „reakcie“. To vám umožňuje napísať sieťovú politiku, ktorá hovorí „povoliť môjmu podu pripojiť sa k akejkoľvek vzdialenej IP adrese“ bez toho, aby ste museli písať politiku, ktorá by explicitne povolila odozvu. (Bez toho by ste museli pridať oveľa menej bezpečné pravidlo „povoliť pakety do môjho modulu z akejkoľvek adresy IP“.)
Okrem toho conntrack zvyčajne zlepšuje výkon systému (znížením spotreby CPU a latencie paketov), pretože iba prvý paket v streame
musí prejsť celým sieťovým zásobníkom, aby sa zistilo, čo s ním robiť. Pozri príspevok "“, aby ste videli príklad toho, ako to funguje.
Conntrack má však svoje obmedzenia...
Kde sa to teda všetko pokazilo?
Tabuľka conntrack má konfigurovateľnú maximálnu veľkosť a ak sa zaplní, pripojenia sa zvyčajne začnú odmietať alebo rušiť. V tabuľke je dostatok voľného miesta na zvládnutie prevádzky väčšiny aplikácií a nikdy to nebude problém. Existuje však niekoľko scenárov, v ktorých by ste mohli zvážiť použitie tabuľky conntrack:
- Najzrejmejším prípadom je, ak váš server spracováva extrémne veľký počet súčasne aktívnych pripojení. Napríklad, ak je vaša tabuľka conntrack nakonfigurovaná na 128 128 záznamov, ale máte viac ako XNUMX XNUMX súbežných pripojení, určite narazíte na problém!
- Trochu menej zrejmý prípad: ak váš server spracuje veľmi veľký počet pripojení za sekundu. Aj keď sú pripojenia krátkodobé, bude ich Linux nejaký čas monitorovať (štandardne 120 s). Napríklad, ak je vaša tabuľka conntrack nakonfigurovaná na 128 1100 záznamov a pokúšate sa spracovať 128 120 spojení za sekundu, presiahnu veľkosť tabuľky conntrack, aj keď sú spojenia veľmi krátke (1092 k/XNUMX s = XNUMX XNUMX spojení/ s).
Existuje niekoľko špecifických typov aplikácií, ktoré spadajú do týchto kategórií. Navyše, ak máte veľa zlých hercov, naplnenie tabuľky conntrack vášho servera množstvom polootvorených pripojení by sa mohlo použiť ako súčasť útoku odmietnutia služby (DOS). V oboch prípadoch sa conntrack môže stať obmedzujúcou prekážkou vo vašom systéme. V niektorých prípadoch môže stačiť úprava parametrov tabuľky conntrack, aby vyhovovali vašim potrebám – zväčšením veľkosti alebo znížením časových limitov conntrack (ak to však urobíte zle, narazíte na veľa problémov). V ostatných prípadoch bude potrebné pre agresívnu dopravu obísť konntrack.
Skutočný príklad
Uveďme konkrétny príklad: jeden veľký poskytovateľ SaaS, s ktorým sme spolupracovali, mal niekoľko serverov uložených v memcached na hostiteľoch (nie virtuálnych počítačoch), z ktorých každý spracovával viac ako 50 XNUMX krátkodobých pripojení za sekundu.
Experimentovali s konfiguráciou conntrack, zväčšovali veľkosť tabuliek a skracovali čas sledovania, ale konfigurácia bola nespoľahlivá, výrazne sa zvýšila spotreba RAM, čo bol problém (rádovo v GB!), a pripojenia boli také krátke, že conntrack nefungoval. vytvoriť jeho obvyklú výkonnostnú výhodu (znížená spotreba CPU alebo latencia paketov).
Ako alternatívu sa obrátili na Calico. Sieťové zásady Calico vám umožňujú nepoužívať conntrack pre určité typy prevádzky (pomocou možnosti politiky doNotTrack). To im poskytlo úroveň výkonu, ktorú potrebovali, plus pridanú úroveň zabezpečenia, ktorú poskytuje Calico.
Aké dĺžky budete musieť prejsť, aby ste obišli conntrack?
- Sieťové zásady „nesledovať“ by mali byť vo všeobecnosti symetrické. V prípade poskytovateľa SaaS: ich aplikácie bežali v chránenej zóne, a preto pomocou sieťovej politiky mohli pridať na zoznam povolenú prevádzku z iných špecifických aplikácií, ktoré mali povolený prístup k memcached.
- Politika do-not-track nezohľadňuje smer pripojenia. Ak je teda server memcached napadnutý, môžete sa teoreticky pokúsiť pripojiť ku ktorémukoľvek z klientov memcached, pokiaľ používa správny zdrojový port. Ak ste však správne definovali sieťovú politiku pre svojich klientov uložených v pamäti memcach, tieto pokusy o pripojenie budú na strane klienta stále odmietnuté.
- Politika nesledovania sa aplikuje na každý paket, na rozdiel od bežných politík, ktoré sa aplikujú iba na prvý paket v toku. To môže zvýšiť spotrebu CPU na paket, pretože politika sa musí aplikovať na každý paket. Ale pre krátkodobé pripojenia sú tieto náklady vyvážené znížením spotreby zdrojov na spracovanie conntrack. Napríklad v prípade poskytovateľa SaaS bol počet paketov pre každé pripojenie veľmi malý, takže dodatočná spotreba CPU pri aplikácii politík na každý paket bola opodstatnená.
Začnime testovať
Test sme vykonali na jednom module so serverom memcached a viacerými klientskymi modulmi memcached spustenými na vzdialených uzloch, takže sme mohli spustiť veľmi veľký počet pripojení za sekundu. Server s memcached server pod mal 8 jadier a 512 XNUMX záznamov v tabuľke conntrack (štandardne nakonfigurovaná veľkosť tabuľky pre hostiteľa).
Merali sme výkonnostný rozdiel medzi: žiadnou sieťovou politikou; s pravidelnou politikou Calico; a Calico do-not-track policy.
Pri prvom teste sme nastavili počet pripojení na 4.000 20 za sekundu, aby sme sa mohli zamerať na rozdiel v spotrebe CPU. Neexistovali žiadne významné rozdiely medzi žiadnou politikou a bežnou politikou, ale nesledovať zvýšenú spotrebu CPU o približne XNUMX %:
V druhom teste sme spustili toľko pripojení, koľko mohli naši klienti vygenerovať, a zmerali sme maximálny počet pripojení za sekundu, ktoré náš server s memcachedom zvládol. Ako sa očakávalo, prípady „žiadna politika“ a „bežná politika“ dosiahli limit pripojenia viac ako 4,000 512 pripojení za sekundu (120 k / 4,369 s = 60,000 XNUMX pripojení/s). S politikou do-not-track naši klienti bez problémov odoslali XNUMX XNUMX spojení za sekundu. Sme si istí, že by sme mohli zvýšiť toto číslo pridaním ďalších klientov, ale myslíme si, že tieto čísla sú už dostatočné na ilustráciu pointy tohto článku!
Záver
Conntrack je dôležitá vlastnosť jadra. Svoju prácu robí dokonale. Často ho používajú kľúčové komponenty systému. V niektorých špecifických scenároch však preťaženie v dôsledku conntracku prevažuje nad bežnými výhodami, ktoré poskytuje. V tomto scenári je možné použiť sieťové politiky Calico na selektívne zakázanie používania conntrack a zároveň zvýšiť bezpečnosť siete. Pre všetku ostatnú premávku je conntrack naďalej vaším priateľom!
Prečítajte si aj ďalšie články na našom blogu:
Zdroj: hab.com