It-traċċar tal-konnessjoni ("conntrack") huwa karatteristika ewlenija tal-munzell tan-netwerking tal-kernel Linux. Jippermetti li l-qalba żżomm kont tal-konnessjonijiet jew il-flussi tan-netwerk loġiċi kollha u b'hekk tidentifika l-pakketti kollha li jiffurmaw kull fluss sabiex ikunu jistgħu jiġu pproċessati flimkien b'mod sekwenzjali.
Conntrack hija karatteristika importanti tal-qalba li tintuża f'xi każijiet bażiċi:
- NAT tiddependi fuq informazzjoni minn conntrack sabiex tkun tista' tittratta l-pakketti kollha mill-istess fluss b'mod ugwali. Pereżempju, meta pod jaċċessa servizz Kubernetes, il-kube-proxy load balancer juża NAT biex jidderieġi t-traffiku lejn pod speċifiku fi ħdan il-cluster. Conntrack jirreġistra li għal konnessjoni partikolari, il-pakketti kollha għas-servizz IP għandhom jintbagħtu lill-istess pod, u li l-pakketti rritornati mill-pod backend għandhom jiġu NATed lura lill-pod li minnu tkun ġiet it-talba.
- Firewalls Stateful bħal Calico jiddependu fuq informazzjoni minn connecttrack għal whitelist tat-traffiku ta '"rispons". Dan jippermettilek tikteb politika tan-netwerk li tgħid "jħalli l-pod tiegħi jgħaqqad ma' kwalunkwe indirizz IP remot" mingħajr ma jkollok għalfejn tikteb politika biex tippermetti b'mod espliċitu t-traffiku ta 'rispons. (Mingħajr dan, inti jkollok iżżid ir-regola ħafna inqas sigura "jħalli pakketti għall-pod tiegħi minn kwalunkwe IP".)
Barra minn hekk, conttrack tipikament itejjeb il-prestazzjoni tas-sistema (billi jnaqqas il-konsum tas-CPU u l-latenza tal-pakkett) peress li l-ewwel pakkett biss fi stream
trid tgħaddi mill-munzell kollu tan-netwerk biex tiddetermina x'għandek tagħmel magħha. Ara l-post "" biex tara eżempju ta' kif taħdem.
Madankollu, conttrack għandu l-limitazzjonijiet tiegħu...
Allura fejn mar kollox ħażin?
It-tabella tal-conntrack għandha daqs massimu konfigurabbli, u jekk timtela, il-konnessjonijiet normalment jibdew jiġu rrifjutati jew imwaqqfa. Hemm biżżejjed spazju ħieles fit-tabella biex jimmaniġġja t-traffiku tal-biċċa l-kbira tal-applikazzjonijiet, u dan qatt mhu se jsir problema. Madankollu, hemm ftit xenarji li fihom tista' tkun trid tikkunsidra li tuża t-tabella conttrack:
- L-aktar każ ovvju huwa jekk is-server tiegħek jimmaniġġja numru estremament kbir ta 'konnessjonijiet attivi fl-istess ħin. Pereżempju, jekk it-tabella conntrack tiegħek hija kkonfigurata għal 128k entrati, iżda għandek> 128k konnessjonijiet konkorrenti, żgur li se tiffaċċja problema!
- Każ kemmxejn inqas ovvju: jekk is-server tiegħek jipproċessa numru kbir ħafna ta 'konnessjonijiet kull sekonda. Anke jekk il-konnessjonijiet huma ta 'ħajja qasira, jibqgħu jiġu mmonitorjati minn Linux għal xi perjodu ta' żmien (120s b'mod awtomatiku). Pereżempju, jekk it-tabella conntrack tiegħek hija kkonfigurata għal 128k entrati u qed tipprova timmaniġġja 1100 konnessjoni kull sekonda, dawn jaqbżu d-daqs tat-tabella conntrack anke jekk il-konnessjonijiet huma ta 'ħajja qasira ħafna (128k/120s = 1092 konnessjoni/s ).
Hemm diversi tipi ta 'niċċa ta' apps li jaqgħu f'dawn il-kategoriji. Barra minn hekk, jekk għandek ħafna atturi ħżiena, il-mili tat-tabella tal-kontrack tas-server tiegħek b'ħafna konnessjonijiet nofshom miftuħa jista 'jintuża bħala parti minn attakk ta' ċaħda ta 'servizz (DOS). Fiż-żewġ każijiet, conttrack jista 'jsir ostakolu li jillimita fis-sistema tiegħek. F'xi każijiet, l-aġġustament tal-parametri tat-tabella tal-conntrack jista 'jkun biżżejjed biex jissodisfa l-bżonnijiet tiegħek - billi żżid id-daqs jew tnaqqas il-timeouts tal-conntrack (iżda jekk tagħmel dan ħażin, ikollok ħafna problemi). Għal każijiet oħra jkun meħtieġ li l-conntrack jiġi bypass għal traffiku aggressiv.
Eżempju reali
Ejja nagħtu eżempju speċifiku: fornitur SaaS kbir wieħed li ħdimna miegħu kellu numru ta 'servers memcached fuq hosts (mhux magni virtwali), li kull wieħed minnhom ipproċessa 50K + konnessjonijiet għal żmien qasir kull sekonda.
Huma esperimentaw bil-konfigurazzjoni tal-conntrack, żiedu d-daqsijiet tal-mejda u naqqsu l-ħin tat-traċċar, iżda l-konfigurazzjoni ma kinitx affidabbli, il-konsum tar-RAM żdied b'mod sinifikanti, li kienet problema (fl-ordni ta 'GBytes!), U l-konnessjonijiet kienu tant qosra li conntrack ma kienx toħloq il-benefiċċju tal-prestazzjoni tas-soltu tagħha (CPU ta 'konsum imnaqqas jew latenza tal-pakkett).
Huma daru lejn Calico bħala alternattiva. Il-politiki tan-netwerk Calico jippermettulek li ma tużax conttrack għal ċerti tipi ta’ traffiku (bl-użu tal-għażla tal-politika doNotTrack). Dan tahom il-livell ta’ prestazzjoni li kellhom bżonn, flimkien mal-livell miżjud ta’ sigurtà pprovdut minn Calico.
Liema tulijiet ser ikollok tmur biex tevita conttrack?
- Il-politiki tan-netwerk li ma jintraċċawx għandhom ġeneralment ikunu simetriċi. Fil-każ tal-fornitur tas-SaaS: l-applikazzjonijiet tagħhom dam f'żona protetta u għalhekk, bl-użu tal-politika tan-netwerk, setgħu jillistaw it-traffiku minn applikazzjonijiet speċifiċi oħra li ngħataw aċċess għal memcached.
- Il-politika do-no-track ma tqisx id-direzzjoni tal-konnessjoni. Għalhekk, jekk is-server memcached jiġi hacked, teoretikament tista 'tipprova tikkonnettja ma' kwalunkwe mill-klijenti memcached, sakemm juża l-port tas-sors korrett. Madankollu, jekk iddefinijt b'mod korrett il-politika tan-netwerk għall-klijenti memcached tiegħek, allura dawn it-tentattivi ta 'konnessjoni xorta se jiġu rrifjutati min-naħa tal-klijent.
- Il-politika do-not-track hija applikata għal kull pakkett, għall-kuntrarju tal-politiki normali, li huma applikati biss għall-ewwel pakkett fi fluss. Dan jista 'jżid il-konsum tas-CPU għal kull pakkett minħabba li l-politika trid tiġi applikata għal kull pakkett. Iżda għal konnessjonijiet ta' ħajja qasira, din l-ispiża hija bbilanċjata bit-tnaqqis fil-konsum tar-riżorsi għall-ipproċessar tal-conntrack. Pereżempju, fil-każ ta 'fornitur SaaS, in-numru ta' pakketti għal kull konnessjoni kien żgħir ħafna, għalhekk il-konsum addizzjonali ta 'CPU meta jiġu applikati politiki għal kull pakkett kien iġġustifikat.
Ejja nibdew nittestjaw
Għamilna t-test fuq pod wieħed b'server memcached u pods multipli tal-klijenti memcached li jaħdmu fuq nodi remoti sabiex inkunu nistgħu nħaddmu numru kbir ħafna ta 'konnessjonijiet kull sekonda. Is-server bil-pod server memcached kellu 8 cores u 512k entrati fit-tabella conntrack (id-daqs standard tal-mejda konfigurat għall-host).
Aħna kejlu d-differenza fil-prestazzjoni bejn: l-ebda politika tan-netwerk; b'politika Calico regolari; u Calico do-no-track policy.
Għall-ewwel test, aħna stabbilixxew in-numru ta 'konnessjonijiet għal 4.000 kull sekonda, sabiex inkunu nistgħu niffukaw fuq id-differenza fil-konsum tas-CPU. Ma kien hemm l-ebda differenzi sinifikanti bejn l-ebda politika u l-politika regolari, iżda l-konsum ta' CPU miżjuda b'madwar 20% ma ssegwix:
Fit-tieni test, nedejna konnessjonijiet daqs kemm il-klijenti tagħna setgħu jiġġeneraw u kejlu n-numru massimu ta 'konnessjonijiet kull sekonda li s-server memcached tagħna jista' jimmaniġġja. Kif mistenni, il-każijiet ta’ “l-ebda politika” u ta’ “politika regolari” it-tnejn laħqu l-limitu ta’ konnessjoni ta’ aktar minn 4,000 konnessjoni kull sekonda (512k / 120s = 4,369 konnessjoni/s). B'politika ta 'do-not-track, il-klijenti tagħna bagħtu 60,000 konnessjoni kull sekonda mingħajr problemi. Aħna żgur li nistgħu nżidu dan in-numru billi nżidu aktar klijenti, iżda nħossu li dawn in-numri diġà huma biżżejjed biex juru l-punt ta 'dan l-artikolu!
Konklużjoni
Conntrack hija karatteristika importanti tal-qalba. Jagħmel xogħolu perfettament. Ħafna drabi tintuża minn komponenti ewlenin tas-sistema. Madankollu, f'xi xenarji speċifiċi, il-konġestjoni dovuta għall-conntrack tisboq il-benefiċċji normali li tipprovdi. F'dan ix-xenarju, il-politiki tan-netwerk Calico jistgħu jintużaw biex jiskonnettjaw b'mod selettiv l-użu ta 'conntrack filwaqt li tiżdied is-sigurtà tan-netwerk. Għat-traffiku l-ieħor kollu, contrack jibqa' ħabib tiegħek!
Aqra wkoll artikli oħra fuq il-blog tagħna:
Sors: www.habr.com