Sledenje povezavam (»conntrack«) je temeljna funkcija omrežnega sklada jedra Linuxa. Jedru omogoča, da spremlja vse logične omrežne povezave ali tokove in s tem prepozna vse pakete, ki sestavljajo vsak tok, tako da jih je mogoče zaporedno obdelati skupaj.
Conntrack je pomembna funkcija jedra, ki se uporablja v nekaterih osnovnih primerih:
- NAT se opira na informacije iz conntrack, tako da lahko enako obravnava vse pakete iz istega toka. Na primer, ko pod dostopa do storitve Kubernetes, izravnalnik obremenitve kube-proxy uporablja NAT za usmerjanje prometa na določen pod znotraj gruče. Conntrack beleži, da morajo biti za dano povezavo vsi paketi za storitev IP poslani istemu bloku in da morajo biti paketi, ki jih vrne zaledni blok, NAT nazaj v blok, iz katerega je prišla zahteva.
- Požarni zidovi z nadzorom stanja, kot je Calico, se zanašajo na informacije iz povezave Connecttrack do prometa »odziva« na beli seznam. To vam omogoča, da napišete omrežno politiko, ki pravi "dovoli mojemu modulu, da se poveže s katerim koli oddaljenim naslovom IP", ne da bi morali napisati politiko, ki izrecno dovoli odzivni promet. (Brez tega bi morali dodati veliko manj varno pravilo "dovoli pakete v moj pod iz katerega koli IP-ja".)
Poleg tega conntrack običajno izboljša delovanje sistema (z zmanjšanjem porabe procesorja in zakasnitve paketov), saj le prvi paket v toku
mora iti skozi celoten omrežni sklad, da ugotovi, kaj narediti z njim. Glej objavo "", da vidite primer, kako to deluje.
Vendar ima conntrack svoje omejitve ...
Torej, kje je šlo vse narobe?
Tabela conntrack ima nastavljivo največjo velikost in če se napolni, se povezave običajno začnejo zavračati ali prekinjati. V tabeli je dovolj prostega prostora za obvladovanje prometa večine aplikacij in to nikoli ne bo problem. Vendar obstaja nekaj scenarijev, v katerih boste morda želeli razmisliti o uporabi tabele conntrack:
- Najbolj očiten primer je, če vaš strežnik obravnava izjemno veliko število sočasno aktivnih povezav. Na primer, če je vaša tabela conntrack konfigurirana za 128k vnosov, vendar imate >128k sočasnih povezav, boste zagotovo naleteli na težavo!
- Nekoliko manj očiten primer: če vaš strežnik obdela zelo veliko število povezav na sekundo. Tudi če so povezave kratkotrajne, jih Linux še nekaj časa nadzoruje (privzeto 120 s). Na primer, če je vaša tabela conntrack konfigurirana za 128k vnosov in poskušate obdelati 1100 povezav na sekundo, bodo te presegle velikost tabele conntrack, tudi če so povezave zelo kratkotrajne (128k/120s = 1092 povezav/ s).
Obstaja več nišnih vrst aplikacij, ki spadajo v te kategorije. Poleg tega, če imate veliko slabih akterjev, bi lahko polnjenje tabele conntrack vašega strežnika s številnimi napol odprtimi povezavami uporabili kot del napada z zavrnitvijo storitve (DOS). V obeh primerih lahko conntrack postane omejujoče ozko grlo v vašem sistemu. V nekaterih primerih lahko prilagoditev parametrov tabele conntrack zadostuje za vaše potrebe – s povečanjem velikosti ali zmanjšanjem časovnih omejitev conntrack (vendar če to storite narobe, boste naleteli na veliko težav). V drugih primerih bo treba obiti conntrack za agresiven promet.
Pravi primer
Navedimo konkreten primer: en velik ponudnik SaaS, s katerim smo sodelovali, je imel na gostiteljih (ne virtualnih strojih) več strežnikov s predpomnjenim pomnilnikom, od katerih je vsak obdelal 50+ kratkotrajnih povezav na sekundo.
Eksperimentirali so s konfiguracijo conntrack, povečevali velikost tabel in skrajšali čas sledenja, vendar je bila konfiguracija nezanesljiva, poraba RAM-a se je znatno povečala, kar je bila težava (približno GB bajtov!), povezave pa so bile tako kratke, da conntrack ni deloval ustvari svojo običajno prednost pri zmogljivosti (zmanjšana poraba procesorja ali zakasnitev paketov).
Kot alternativo so se obrnili na Calico. Omrežni pravilniki Calico vam omogočajo, da ne uporabljate conntrack za določene vrste prometa (z uporabo možnosti pravilnika doNotTrack). To jim je zagotovilo raven zmogljivosti, ki so jo potrebovali, in dodano raven varnosti, ki jo zagotavlja Calico.
Do katere dolžine boste morali iti, da bi obšli conntrack?
- Omrežne politike ne-sledi bi morale biti na splošno simetrične. V primeru ponudnika SaaS: njihove aplikacije so delovale znotraj zaščitenega območja, zato so lahko z uporabo omrežne politike dodali na belo listo promet iz drugih določenih aplikacij, ki jim je bil dovoljen dostop do memcached.
- Politika do-not-track ne upošteva smeri povezave. Če torej pride do vdora v strežnik memcached, se lahko teoretično poskusite povezati s katerim koli odjemalcem memcached, če uporablja pravilna izvorna vrata. Vendar, če ste pravilno definirali omrežno politiko za svoje memcached odjemalce, bodo ti poskusi povezave še vedno zavrnjeni na strani odjemalca.
- Politika ne-sledi se uporablja za vsak paket, v nasprotju z običajnimi politikami, ki se uporabljajo samo za prvi paket v toku. To lahko poveča porabo procesorja na paket, ker je treba pravilnik uporabiti za vsak paket. Toda za kratkotrajne povezave je ta strošek uravnotežen z zmanjšanjem porabe virov za obdelavo conntrack. Na primer, v primeru ponudnika SaaS je bilo število paketov za vsako povezavo zelo majhno, zato je bila dodatna poraba procesorja pri uporabi pravilnikov za vsak paket upravičena.
Začnimo s testiranjem
Preizkus smo izvedli na enem samem podu s strežnikom memcached in več odjemalskimi podom memcached, ki se izvajajo na oddaljenih vozliščih, tako da smo lahko izvajali zelo veliko število povezav na sekundo. Strežnik s strežniško enoto memcached je imel 8 jeder in 512k vnosov v tabeli conntrack (standardna konfigurirana velikost tabele za gostitelja).
Izmerili smo razliko v zmogljivosti med: brez omrežne politike; z redno polico Calico; in pravilnik Calico o ne-sledenju.
Za prvi test smo nastavili število povezav na 4.000 na sekundo, da smo se lahko osredotočili na razliko v porabi procesorja. Med brez pravilnika in običajnim pravilnikom ni bilo bistvenih razlik, vendar se je poraba CPU-ja z ne-sledenjem povečala za približno 20 %:
V drugem preizkusu smo zagnali toliko povezav, kolikor jih lahko ustvarijo naši odjemalci, in izmerili največje število povezav na sekundo, ki jih lahko obvlada naš memcached strežnik. Kot je bilo pričakovano, sta primera »brez pravilnika« in »običajnega pravilnika« oba dosegla mejo conntrack več kot 4,000 povezav na sekundo (512 k/120 s = 4,369 povezav/s). S politiko ne-sledenja so naše stranke brez težav poslale 60,000 povezav na sekundo. Prepričani smo, da bi to število lahko povečali z dodajanjem več strank, vendar menimo, da so te številke že dovolj za ponazoritev bistva tega članka!
Zaključek
Conntrack je pomembna funkcija jedra. Svoje delo opravlja odlično. Pogosto ga uporabljajo ključne komponente sistema. Vendar pa v nekaterih posebnih scenarijih prezasedenost zaradi conntrack odtehta običajne koristi, ki jih zagotavlja. V tem scenariju je mogoče omrežne pravilnike Calico uporabiti za selektivno onemogočanje uporabe conntrack, hkrati pa povečati varnost omrežja. Za ves drugi promet je conntrack še naprej vaš prijatelj!
Preberite tudi druge članke na našem blogu:
Vir: www.habr.com