🥇Amikor a Linux conntrack már nem a társad

A kapcsolatkövetés („conntrack”) a Linux kernel hálózati veremének alapvető funkciója. Lehetővé teszi a kernel számára, hogy nyomon kövesse az összes logikai hálózati kapcsolatot vagy áramlatot, ezáltal azonosítva minden egyes áramlatot alkotó csomagot, hogy azokat együttesen, sorrendben lehessen kezelni.

A Conntrack egy fontos kernel funkció, amelyet bizonyos alapvető esetekben használnak:

A NAT a conntrack információira támaszkodik, így ugyanolyan módon képes kezelni az egy áramlatból származó összes csomagot. Például amikor egy pod egy Kubernetes szolgáltatáshoz fordul, a kube-proxy terheléselosztó NAT-ot használ a forgalom irányítására egy adott podhoz a klaszterben. A Conntrack rögzíti, hogy egy adott kapcsolat esetén minden csomagot az IP-szolgáltatásra ugyanahhoz a podhoz kell küldeni, és hogy a backend pod által visszaérkező csomagokat a NAT-nak vissza kell irányítania abba a podba, ahonnan a kérés érkezett.
A kapcsolatkövetéssel rendelkező tűzfalak, mint például a Calico, a conntrack információira támaszkodnak, hogy „visszaérkező” forgalmat tegyenek fehérlistára. Ez lehetővé teszi, hogy olyan hálózati politikát írjon, amely azt mondja: „engedélyezd a podomnak, hogy csatlakozzon bármely távoli IP-címhez”, anélkül, hogy külön politikát kellene írnia a válaszforgalom kifejezett engedélyezéséhez. (Nélküle sokkal kevésbé biztonságos szabályt kellett volna hozzáadnia: „engedélyezni a csomagokat a podomba bármely IP-től”.)

Ezenkívül a conntrack általában növeli a rendszer teljesítményét (csökkentve a CPU-időt és a csomagok késleltetését), mivel csak az áramlat első csomagjának kell átkelnie a hálózati verem teljes feldolgozásán, hogy meghatározza, mi legyen vele. Nézze meg a „
A kube-proxy módok összehasonlítása” című bejegyzést, hogy példát lásson arra, hogyan működik ez.Mindazonáltal a conntracknak megvannak a maga korlátai...

Tehát hol ment el minden rosszul?

A conntrack táblázatának testreszabható maximális mérete van, és ha megtelik, a kapcsolatok általában elutasításra vagy megszakításra kerülnek. A legtöbb alkalmazás forgalmának kezelésére elegendő szabad hely van a táblázatban, és ez soha nem válik problémává. Mindazonáltal van néhány olyan forgatókönyv, amikor érdemes megfontolnia a conntrack táblázat használatát:

A conntrack táblának állítható maximális mérete van, és ha betelik, a kapcsolatok általában elkezdenek elutasítani vagy megszakadni. A legtöbb alkalmazás forgalmának kezeléséhez elegendő szabad hely található a táblában, és ez soha nem lesz probléma. Ennek ellenére léteznek bizonyos forgatókönyvek, amikor érdemes megfontolni a conntrack táblával való munkát:

A legkézenfekvőbb eset az, ha a szervere rendkívül nagy számú egyidejű kapcsolatot kezel. Például, ha a conntrack táblája 128 ezer bejegyzésre van beállítva, de több mint 128 ezer egyidejű kapcsolatod van, akkor biztosan problémába ütközöl!
Egy kicsit kevésbé nyilvánvaló eset: ha a szervered nagyon nagy számú kapcsolatot kezel másodpercenként. Még ha a kapcsolatok rövid ideig tartanak is, a Linux egy ideig (alapértelmezés szerint 120 másodpercig) továbbra is nyomon követi őket. Például, ha a conntrack táblád 128 ezer bejegyzésre van beállítva, és próbálsz 1100 kapcsolatot kezelni másodpercenként, azok túllépik a conntrack tábla méretét, még ha a kapcsolatok nagyon rövidek is (128k / 120s = 1092 kapcsolat / s).

Több speciális alkalmazástípust is érinthetnek ezek a kategóriák. Ezenkívül, ha sok rosszindulatú támadóval rendelkezel, akkor a szervered conntrack tábláját félig nyitott kapcsolatokkal való feltöltés a 'szolgáltatásmegtagadás' (DOS) típusú támadás részeként is felhasználható. Mindkét esetben a conntrack szűk keresztmetszetet jelenthet a rendszeredben. Egyes esetekben a conntrack táblparamétereinek beállítása elegendő lehet az igényeid kielégítésére — a méret növelésével vagy a conntrack időtúllépések csökkentésével (de ha ezt rosszul csinálod, nagy nehézségekkel kell szembenézned). Más esetekben a conntrack megkerülésére lesz szükség az agresszív forgalom esetén.

Valódi példa

Hozzunk egy konkrét példát: egy nagy SaaS szolgáltató, akivel dolgoztunk, számos memcached-szerverrel rendelkezett a gazdákon (nem virtuális gépeken), mindegyik több mint 50 ezer rövid idejű kapcsolatot kezelt másodpercenként.

Kísérleteztek a conntrack konfigurációjával, növelték a táblák méretét és csökkentették a nyomkövetési időt, de a konfiguráció megbízhatatlanná vált, jelentősen megnövekedett a RAM használat, ami probléma volt (akár gigabájtokkal!), és a kapcsolatok annyira rövidek voltak, hogy a conntrack nem tudta megvalósítani a szokásos teljesítményjavulást (a CPU fogyasztás vagy a csomagok késlekedése csökkenése).

Alternatív megoldásként a Calicohoz fordultak. A Calico hálózati politikák lehetővé teszik a conntrack használatának elkerülését bizonyos típusú forgalom esetén (a politikák doNotTrack opciójának használatával). Ez biztosította számukra a szükséges teljesítményszintet, plusz egy extra biztonsági szintet, amelyet a Calico kínál.

Mire hajlandóak a conntrack megkerüléséhez?

A do-not-track hálózati politikáknak általában szimmetrikusnak kell lennie. SaaS szolgáltató esetén: az alkalmazásaik védett zónában működtek, így a hálózati politikák révén fehérlistára tehették más, memcached-hez való hozzáférést kapott konkrét alkalmazások forgalmát.
A do-not-track politika nem veszi figyelembe a kapcsolat irányát. Tehát, ha a memcached szervert feltörték, elméletileg megpróbálhatnak csatlakozni bármelyik memcached klienshez, ha a megfelelő kimenő portot használja. Azonban, ha helyesen határozta meg a memcached kliensek hálózati politikáját, ezek a csatlakozási kísérletek akkor is elutasításra kerülnek a kliens oldalán.
A do-not-track politika minden egyes csomagra vonatkozik, ellentétben a hagyományos politikákkal, amelyek csak az áramlás első csomagjára vonatkoznak. Ez megnövelheti a CPU erőforrások fogyasztását egy csomag esetén, mivel minden csomagra alkalmazni kell a politikát. De rövid idejű kapcsolatok esetén ez a költség kiegyenlítődik a conntrack feldolgozási erőforrásainak csökkentésével. Például, egy SaaS szolgáltató esetében a kapcsolatokhoz tartozó csomagok száma nagyon kicsi volt, így a politikák minden csomagra való alkalmazásához kapcsolódó többlet CPU költség indokolt volt.

Kezdjük a teszteket.

Egy memcached szerverrel rendelkező podon és több memcached klienssel rendelkező podon végeztük a tesztet, amelyeket távoli csomópontokon futtattunk, lehetővé téve ezzel, hogy másodpercenként nagyon nagy számú kapcsolatot lehessen létrehozni. A memcached szerver pod 8 maggal és 512k bejegyzéssel rendelkezett a conntrack táblában (az alapértelmezés szerint beállított táblaméret a gazdagépen).
Mértük a teljesítménybeli különbséget: hálózati politika nélkül; hagyományos Calico politikával; és Calico do-not-track politikával.

Az első teszthez 4.000 kapcsolatra állítottuk be a számot másodpercenként, így a CPU-fogyasztás különbségére tudtunk összpontosítani. Itt nem voltak jelentős eltérések a politikák hiánya és a szokásos politika között, de a do-not-track körülbelül 20%-kal növelte a CPU-fogyasztást:

A második teszt során annyi kapcsolatot indítottunk, amennyit az ügyfeleink generálni tudtak, és megmértük a memcached szerverünk által kezelhető maximális kapcsolatszámot másodpercenként. Mint várható volt, a "politikák nélküli" és az "átlagos politika" esetén mindkettő elérte a conntrack határértékét, amely meghaladta a 4.000 kapcsolatra másodpercenként (512k / 120s = 4.369 kapcsolat/s). A do-not-track politikával az ügyfeleink 60.000 kapcsolatot küldtek másodpercenként problémák nélkül. Biztosak vagyunk benne, hogy ezt a számot növelhettük volna, ha több ügyfelet csatlakoztatunk, de úgy érezzük, hogy ezek a számok már elegendőek ahhoz, hogy illusztrálják a cikk üzenetét!

Zárás

A conntrack egy fontos kernel funkció. Nagyszerűen végzi a dolgát. Gyakran használják a rendszer kulcskomponensei. Azonban bizonyos specifikus forgatókönyvekben a conntrack okozta terhelés felülmúlja a megszokott előnyöket, amelyeket nyújt. Ebben az esetben a Calico hálózati politikákat használhatunk, hogy szelektíven kikapcsoljuk a conntrack használatát, miközben növeljük a hálózati biztonsági szintet. Minden egyéb forgalom esetén a conntrack továbbra is a társad marad!