A kapcsolatkövetés („conntrack”) a Linux kernel hálózati verem alapvető funkciója. Lehetővé teszi a kernel számára, hogy nyomon kövesse az összes logikai hálózati kapcsolatot vagy folyamot, és ezáltal azonosítsa az egyes folyamokat alkotó összes csomagot, hogy azokat egymás után együtt lehessen feldolgozni.
A Conntrack egy fontos kernelfunkció, amelyet néhány alapvető esetben használnak:
- A NAT a conntrack információira támaszkodik, így képes azonos adatfolyamból származó összes csomagot egyformán kezelni. Például, amikor egy pod hozzáfér egy Kubernetes szolgáltatáshoz, a kube-proxy terheléselosztója a NAT segítségével irányítja a forgalmat a fürtön belüli adott podra. A Conntrack rögzíti, hogy egy adott kapcsolathoz az IP-szolgáltatáshoz küldött összes csomagot ugyanabba a podba kell küldeni, és a backend pod által visszaküldött csomagokat vissza kell NATálni abba a podba, ahonnan a kérés érkezett.
- Az állapotjelző tűzfalak, mint például a Calico, a connecttrack információira támaszkodnak a „válasz” forgalom engedélyezési listájára. Ez lehetővé teszi, hogy olyan hálózati házirendet írjon, amely azt mondja, hogy "engedélyezze a podatomnak, hogy bármilyen távoli IP-címhez csatlakozzon" anélkül, hogy kifejezetten engedélyeznie kellene a válaszforgalmat. (Enélkül hozzá kellene adni a sokkal kevésbé biztonságos "csomagok engedélyezése a pod-hoz bármely IP-ről" szabályt.)
Ezenkívül a conntrack általában javítja a rendszer teljesítményét (a CPU-fogyasztás és a csomagok késleltetésének csökkentésével), mivel csak az első csomag a folyamban
át kell mennie a teljes hálózati veremen, hogy meghatározza, mit tegyen vele. Lásd a bejegyzést "", hogy példát lássunk a működésére.
A conntrack-nek azonban megvannak a maga korlátai...
Szóval hol romlott el az egész?
A conntrack tábla konfigurálható maximális mérettel rendelkezik, és ha megtelik, a kapcsolatokat általában elutasítják vagy megszakítják. A legtöbb alkalmazás forgalmának kezelésére elegendő szabad hely van a táblázatban, és ebből soha nem lesz probléma. Vannak azonban olyan forgatókönyvek, amelyekben érdemes megfontolni a conntrack tábla használatát:
- A legnyilvánvalóbb eset az, ha a kiszolgáló rendkívül sok egyidejűleg aktív kapcsolatot kezel. Például, ha a conntrack táblája 128 128 bejegyzésre van beállítva, de több mint XNUMX XNUMX egyidejű kapcsolata van, akkor biztosan problémába ütközik!
- Egy kicsit kevésbé nyilvánvaló eset: ha a szervere másodpercenként nagyon sok kapcsolatot dolgoz fel. Még ha a kapcsolatok rövid életűek is, a Linux egy ideig továbbra is felügyeli őket (alapértelmezés szerint 120 másodpercig). Például, ha a conntrack táblája 128 1100 bejegyzésre van beállítva, és Ön 128 kapcsolatot próbál kezelni másodpercenként, akkor ezek meghaladják a conntrack tábla méretét, még akkor is, ha a kapcsolatok nagyon rövid életűek (120k/1092s = XNUMX kapcsolat/ s).
Számos réstípusú alkalmazás tartozik ezekbe a kategóriákba. Ezen túlmenően, ha sok rossz szereplője van, a szerver conntrack táblájának sok félig nyitott kapcsolattal való feltöltése a szolgáltatásmegtagadási (DOS) támadás részeként használható. Mindkét esetben a conntrack korlátozó szűk keresztmetszetgé válhat a rendszerben. Bizonyos esetekben elegendő lehet a conntrack tábla paramétereinek módosítása az Ön igényeinek 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 rosszul csinálja, akkor sok bajba kerülhet). Más esetekben az agresszív forgalom miatt ki kell kerülni a conntrack-et.
Valódi példa
Mondjunk egy konkrét példát: az egyik nagy SaaS-szolgáltató, amellyel dolgoztunk, számos memcached szervert tartalmazott a gazdagépeken (nem virtuális gépeken), amelyek mindegyike több mint 50 XNUMX rövid távú kapcsolatot dolgozott fel másodpercenként.
Kísérleteztek a conntrack konfigurációval, a táblaméretek növelésével és a követési idő csökkentésével, de a konfiguráció megbízhatatlan volt, a RAM-fogyasztás jelentősen megnőtt, ami gondot okozott (GByte-os nagyságrendben!), és a kapcsolatok olyan rövidek voltak, hogy a conntrack nem működött. hozza létre a szokásos teljesítményelőnyét (csökkentett fogyasztású CPU vagy csomagkésés).
Alternatívaként Calicohoz fordultak. A Calico hálózati házirendjei lehetővé teszik, hogy bizonyos típusú forgalom esetén ne használja a conntrack funkciót (a doNotTrack házirend opció használatával). Ez biztosította számukra a szükséges teljesítményszintet, valamint a Calico által biztosított további biztonsági szintet.
Milyen hosszúságot kell megtennie a conntrack megkerüléséhez?
- A nem követhető hálózati házirendeknek általában szimmetrikusnak kell lenniük. A SaaS szolgáltató esetében: alkalmazásaik a védett zónán belül futottak, így a hálózati házirend segítségével engedélyezőlistára tudták tenni a más, a memcached-hez hozzáféréssel rendelkező alkalmazások forgalmait.
- A nem követhető irányelv nem veszi figyelembe a kapcsolat irányát. Így, ha a memcached szervert feltörték, elméletileg megpróbálhat csatlakozni bármelyik memcached klienshez, amennyiben az a megfelelő forrásportot használja. Ha azonban megfelelően definiálta a hálózati házirendet a gyorsítótárban tárolt kliensei számára, akkor ezek a csatlakozási kísérletek továbbra is elutasításra kerülnek az ügyféloldalon.
- A nem követhető házirend minden csomagra vonatkozik, szemben a normál házirendekkel, amelyek csak az áramlás első csomagjára vonatkoznak. Ez növelheti a CPU-fogyasztást csomagonként, mert a házirendet minden csomagra alkalmazni kell. A rövid élettartamú kapcsolatok esetében azonban ezt a költséget ellensúlyozza a kapcsolati feldolgozáshoz szükséges erőforrás-felhasználás csökkenése. Például egy SaaS-szolgáltató esetében az egyes kapcsolatokhoz tartozó csomagok száma nagyon kicsi volt, így indokolt volt a többlet CPU-fogyasztás az egyes csomagokra vonatkozó irányelvek alkalmazásakor.
Kezdjük a tesztelést
A tesztet egyetlen podon futtattuk le egy memcached szerverrel és több, távoli csomópontokon futó memcached ügyfélpoddal, így másodpercenként nagyon sok kapcsolatot tudtunk futtatni. A memcached kiszolgálópoddal rendelkező szerver 8 maggal és 512 XNUMX bejegyzéssel rendelkezett a conntrack táblában (a gazdagép szabványos konfigurált táblázatmérete).
Mértük a teljesítménykülönbséget a következők között: nincs hálózati szabályzat; rendszeres Calico politikával; és a Calico nem követi nyomon szabályzatát.
Az első tesztnél a kapcsolatok számát 4.000-re állítottuk be másodpercenként, így a CPU-fogyasztás különbségére tudtunk koncentrálni. Nem volt szignifikáns különbség az irányelv nélküli és a normál szabályzat között, de a ne kövesse nyomon a megnövekedett CPU-fogyasztást körülbelül 20%-kal:
A második teszt során annyi kapcsolatot indítottunk el, amennyit ügyfeleink generálni tudtak, és megmértük, hogy a memcached szerverünk mennyi kapcsolatot képes kezelni másodpercenként. Ahogy az várható volt, a „no policy” és a „normal policy” esetek is elérték a több mint 4,000 kapcsolat/másodperc korlátot (512k / 120s = 4,369 kapcsolat/s). Ügyfeleink a nyomkövetés tilalmával másodpercenként 60,000 XNUMX kapcsolatot küldtek gond nélkül. Biztosak vagyunk benne, hogy ezt a számot még több ügyfél hozzáadásával növelhetnénk, de úgy érezzük, ezek a számok már elegendőek a cikk lényegének illusztrálására!
Következtetés
A Conntrack egy fontos kernel funkció. Tökéletesen teszi a dolgát. Gyakran használják kulcsfontosságú rendszerelemek. Egyes konkrét forgatókönyvek esetén azonban a torlódások miatti torlódás meghaladja az általa nyújtott szokásos előnyöket. Ebben a forgatókönyvben a Calico hálózati házirendekkel szelektíven letilthatja a conntrack használatát, miközben növeli a hálózat biztonságát. Minden egyéb forgalom esetében a conntrack továbbra is a barátod marad!
Olvassa el blogunk további cikkeit is:
Forrás: will.com