🥇Ko Linux conntrack več ni vaš zaveznik

Sledenje povezavam (‘conntrack’) je osnovna funkcija omrežnega sklopa jedra Linux. Omogoča jedru, da sledi vsem logičnim omrežnim povezavam ali pretokom in tako identificira vse pakete, ki sestavljajo vsak tok, da jih lahko obdeluje skupaj.

Conntrack je pomembna funkcija jedra, ki se uporablja v nekaterih osnovnih primerih:

NAT se opira na informacije iz conntrack, zato lahko enako obravnava vse pakete iz enega toka. Na primer, ko pod dostopa do storitve Kubernetes, load balancer kube-proxy uporablja NAT za usmerjanje prometa na določen pod znotraj klasterja. Conntrack zabeleži, da morajo biti vsi paketi za določeno povezavo poslani na isti pod in da morajo biti paketi, ki jih vrne pod iz zadnjega dela, usmerjeni nazaj v pod, iz katerega je prišel zahtevek.
Ogenjščitniki s sledenjem stanja, kot je Calico, se opirajo na informacije iz conntrack, da dodajo odgovorni promet na bel seznam. To vam omogoča, da napišete omrežno politiko, ki pravi: "dovoli mojemu podu povezati se z vsakim oddaljenim IP-naslovom" brez potrebe po pisanju politike za izrecno dovoljenje povratnega prometa. (Brez tega bi morali dodati precej manj varno pravilo, "dovoli pakete v moj pod z vsakega IP-ja.")

Poleg tega conntrack običajno povečuje zmogljivost sistema (zmanjšuje porabo procesorskega časa in čas zamude paketov), saj mora le prvi paket v toku
preiti skozi celotno obdelavo omrežnega sklada, da se ugotovi, kaj storiti z njim. Oglejte si objavo "Primerjava načinov kube-proxy», da vidite primer, kako to deluje.

Vendar pa ima conntrack svoje omejitve...

Torej, kje je šlo vse narobe?

Tabela conntrack ima nastavljen največji prilagodljiv velikost in ko se napolni, se povezave običajno začnejo zavračati ali prekinjati. Za obdelavo prometa večine aplikacij je v tabeli običajno dovolj prostega prostora in nikoli ne postane težava. Vendar pa obstajajo nekateri scenariji, kjer se splača razmisliti o uporabi tabele conntrack:

Najbolj očiten primer je, če vaš strežnik obdeluje izjemno veliko število hkrati aktivnih povezav. Na primer, če je vaša tabela conntrack nastavljena na 128k zapisov, vendar imate več kot 128k hkratnih povezav, se boste zagotovo srečali s težavami!
Malo manj očiten primer je, če vaš strežnik obdeluje zelo veliko število povezav na sekundo. Tudi če so povezave kratkotrajne, jih Linux še vedno spremlja določeno obdobje (privzeto 120s). Na primer, če je vaša tabela conntrack nastavljena na 128 tisoč zapisov in poskušate obdelati 1100 povezav na sekundo, bodo presegli velikost tabele conntrack, četudi so povezave zelo kratke (128k / 120s = 1092 povezav / s).

Obstaja več nišnih tipov aplikacij, ki spadajo v te kategorije. Poleg tega, če imate veliko nasprotnikov, lahko zapolnitev tabele conntrack vašega strežnika z mnogimi polodprtimi povezavami služi kot del napada tipa 'denial of service' (DOS). V obeh primerih lahko conntrack postane omejevalni ozki pas v vašem sistemu. V nekaterih primerih so nastavitve tabelarnh parametrov conntrack morda zadostne, da zadostijo vašim potrebam — z povečanjem velikosti ali skrajšanjem časovnih omejitev conntrack (ampak, če to storite napačno, se lahko znajdete v velikih težavah). Za druge primere bo potrebno obiti conntrack za agresiven promet.

Resničen primer

Oglejmo si konkreten primer: en velik SaaS ponudnik, s katerim smo delali, je imel vrsto strežnikov memcached na gostiteljih (ne virtualnih strojih), od katerih je vsak obdeloval več kot 50K kratkotrajnih povezav na sekundo.

Eksperimentirali so z nastavitvami conntrack, povečevali velikosti tabel in skrajševali čas sledenja, vendar je bila konfiguracija nezanesljiva, poraba RAM-a je znatno narasla, kar je predstavljalo težave (približno GB!), hkrati pa so bile povezave tako kratke, da conntrack ni prinesel običajnih dobičkov pri zmogljivosti (zmanjšanje porabe CPU ali zakasnitev paketov).

Kot alternativa so se obrnili na Calico. Mrežne politike Calico omogočajo izogibanje conntracku za določene vrste prometa (z uporabo možnosti doNotTrack v politikah). To jim je zagotovilo potrebno raven zmogljivosti ter dodatno raven varnosti, ki jo nudi Calico.

Kaj bo potrebno storiti, da obidete conntrack?

Mrežne politike do-not-track so običajno simetrične. V primeru SaaS ponudnika: njihova aplikacija je delovala znotraj zaščitene cone in zato so preko mrežne politike lahko dodali v bel seznam promet iz drugih specifičnih aplikacij, katerih dostop do memcached je bil dovoljen.
Politika do-not-track ne upošteva smeri povezave. Tako bi v primeru hekerskega napada na memcached strežnik teoretično lahko poskušali povezati s katerim koli od memcached odjemalcev, če uporablja pravilen izvorni port. Vendar, če ste pravilno določili mrežno politiko za svoje memcached odjemalce, bodo ti poskusi povezovanja še vedno zavrnjeni na strani odjemalca.
Politika do-not-track se uporablja za vsak paket, v nasprotju z običajnimi politkami, ki se uporabljajo le za prvi paket iz toka. To lahko poveča porabo procesorskih virov na en paket, saj je treba politiko uporabiti za vsak paket. Vendar pa za kratkoročne povezave ta strošek uravnava zmanjšana poraba virov za obdelavo conntracka. Na primer, v primeru SaaS ponudnika je bilo število paketov za vsako povezavo zelo majhno, zato je bil dodaten strošek procesorskih virov pri uporabi politik na vsakem paketu upravičen.

Pričnimo s testi

Izvedli smo test na enem podu z memcached strežnikom in številnimi podi memcached odjemalcev, nameščenimi na oddaljenih nodah, da smo lahko izvajali zelo veliko število povezav na sekundo. Strežnik z podom memcached strežnika je imel 8 jeder in 512k zapisov v tabeli conntrack (standardna nastavitev velikosti tabele za gostitelja).
Izmerili smo razliko v zmogljivosti med: brez mrežne politike; z običajno Calico politiko; in Calico do-not-track politiko.

Za prvi test smo postavili število povezav na 4.000 na sekundo, zato smo se lahko osredotočili na razliko v porabi CPU. Tukaj ni bilo bistvenih razlik med pomanjkanjem politike in običajno politiko, vendar je do-not-track povečala porabo CPU za približno 20%.

V drugem testu smo zagnali toliko povezav, kolikor so jih lahko generirali naši odjemalci, in merili smo največje število povezav na sekundo, ki jih je lahko obdelal naš memcached strežnik. Kot smo pričakovali, sta pri 'brez politik' in 'običajni politiki' oba dosegla meja conntrack z več kot 4.000 povezavami na sekundo (512k / 120s = 4.369 povezav/s). S politiko do-not-track so naši odjemalci pošiljali 60.000 povezav na sekundo brez kakršnih koli težav. Prepričani smo, da bi to število lahko povečali z vključitvijo večjega števila odjemalcev, vendar menimo, da so te številke že dovolj, da ilustrujejo sporočilo tega članka!

Zaključek

Conntrack je pomembna funkcija jedra. Odlično opravlja svoje delo. Pogosto ga uporabljajo ključne komponente sistema. Vendar pa v nekaterih specifičnih scenarijih obremenitev zaradi conntracka prevlada nad običajnimi prednostmi, ki jih nudi. V tem scenariju se lahko omrežne politike Calico uporabijo za selektivno onemogočanje uporabe conntracka pri tem pa povečajo raven omrežne varnosti. Za ves ostali promet ostaja conntrack vaš zaveznik!