Konexioen jarraipena ("conntrack") Linux kernel sareko pilaren oinarrizko ezaugarri bat da. Nukleoak sare-konexio edo fluxu logiko guztien jarraipena egiteko aukera ematen dio eta, horrela, fluxu bakoitza osatzen duten pakete guztiak identifikatzea, elkarrekin sekuentzialki prozesatu ahal izateko.
Conntrack oinarrizko kasu batzuetan erabiltzen den nukleoaren ezaugarri garrantzitsu bat da:
- NAT conntrack-eko informazioan oinarritzen da, beraz, korronte bereko pakete guztiak berdin tratatu ditzake. Adibidez, pod bat Kubernetes zerbitzu batera sartzen denean, kube-proxy karga-orekatzaileak NAT erabiltzen du trafikoa kluster barruko pod zehatz batera bideratzeko. Conntrack-ek erregistratzen du konexio jakin baterako, IP zerbitzurako pakete guztiak pod berera bidali behar direla, eta backend podak itzultzen dituen paketeak NAT egin behar direla eskaera etorri den podra.
- Calico bezalako suebaki estatutsuek connecttrack-etik "erantzun" trafiko zerrenda zurirako informazioan oinarritzen dira. Horri esker, sareko politika bat idazteko aukera ematen dizu: "Urruneko edozein IP helbidetara konektatzea baimendu nire poda" dioena, erantzunen trafikoa esplizituki baimentzeko politika idatzi beharrik gabe. (Hau gabe, askoz seguruagoa den "baimendu paketeak nire podan edozein IPtik" araua gehitu beharko zenuke).
Gainera, conntrack-ek normalean sistemaren errendimendua hobetzen du (PUZaren kontsumoa eta paketeen latentzia murriztuz) korronte bateko lehen paketea baino ez baita.
sareko pila osoa zeharkatu behar du horrekin zer egin zehazteko. Ikusi mezua "" hau nola funtzionatzen duen adibide bat ikusteko.
Hala ere, conttrack-ek bere mugak ditu...
Beraz, non atera zen dena gaizki?
Conntrack taulak gehienezko tamaina konfiguragarria du, eta bete egiten bada, konexioak baztertzen edo kentzen hasten dira normalean. Taulan nahikoa leku libre dago aplikazio gehienen trafikoa kudeatzeko, eta hori ez da inoiz arazo bihurtuko. Hala ere, badaude conttrack taula erabiltzea kontuan hartu nahi dituzun agertoki batzuk:
- Kasurik nabarmenena zure zerbitzariak aldi berean aktibo dauden konexio kopuru oso handia kudeatzen badu da. Adibidez, zure conntrack taula 128k sarreretarako konfiguratuta badago, baina > 128k aldibereko konexioak badituzu, ziur aski arazoren bat izango duzu!
- Kasu apur bat ez hain agerikoa: zure zerbitzariak segundoko konexio kopuru handia prozesatzen badu. Konexioak iraupen laburrekoak badira ere, Linuxek kontrolatzen jarraitzen dute denbora tarte batean (120s lehenespenez). Adibidez, zure conntrack taula 128k sarreretarako konfiguratuta badago eta segundoko 1100 konexio kudeatzen saiatzen ari bazara, conntrack taularen tamaina gaindituko dute, nahiz eta konexioak oso iraupen laburra izan (128k/120s = 1092 konexio/). s).
Kategoria hauetan sartzen diren hainbat aplikazio nitxo daude. Gainera, aktore txar asko badituzu, zure zerbitzariaren kontrako taula erdi irekitako konexio asko betetzea zerbitzuaren ukapenaren (DOS) eraso baten parte gisa erabil liteke. Bi kasuetan, conntrack zure sisteman botila-lepo mugatzaile bihur daiteke. Zenbait kasutan, conntrack taulako parametroak doitzea nahikoa izan daiteke zure beharrak asetzeko - tamaina handituz edo conntrack-en denbora-muga murriztuz (baina gaizki egiten baduzu, arazo asko izango dituzu). Beste kasuetarako beharrezkoa izango da trafiko erasokorraren kontrako bidea saihestea.
Benetako adibidea
Eman dezagun adibide zehatz bat: lan egin genuen SaaS hornitzaile handi batek ostalarietan memcached zerbitzari batzuk zituen (ez makina birtualetan), eta horietako bakoitzak epe laburreko 50K+ konexio prozesatzen zituen segundoko.
Conntrack-en konfigurazioarekin esperimentatu zuten, mahaiaren tamainak handituz eta jarraipen-denbora murriztuz, baina konfigurazioa ez zen fidagarria, RAM kontsumoa nabarmen handitu zen, eta hori arazo bat zen (GByte-ren ordenan!), eta konexioak hain laburrak ziren, non conntrack-ek ez zuen egin. bere ohiko errendimendu onura sortu (kontsumo murriztuko CPU edo paketeen latentzia).
Calicorengana jo zuten alternatiba gisa. Calico sareko gidalerroek trafiko mota batzuetarako conntrack ez erabiltzeko aukera ematen dute (doNotTrack politika aukera erabiliz). Horrek behar zuten errendimendu maila eman zien, gehi Calicok emandako segurtasun maila gehigarria.
Zein luzera joan beharko duzu conntrack saihesteko?
- Sare-jarraipena egin ezaren politikak, oro har, simetrikoak izan behar dira. SaaS hornitzailearen kasuan: haien aplikazioak eremu babestuaren barruan exekutatzen ziren eta, beraz, sare-politika erabiliz, memcached-era atzitzeko baimena zuten beste aplikazio zehatz batzuen trafikoa zerrenda zuria izan zezaketen.
- Ez jarraitzeko politikak ez du kontuan hartzen konexioaren norabidea. Horrela, memcached zerbitzaria hackeatzen bada, teorikoki saia zaitezke memcached bezeroetako edozeinetara konektatzen, betiere iturburu-ataka zuzena erabiltzen badu. Hala ere, zure memcached bezeroentzako sare-politika behar bezala definitu baduzu, konexio saiakera hauek bezeroaren aldetik baztertuko dira.
- Ez jarraitzeko politika pakete guztietan aplikatzen da, politika arrunten aldean, fluxu bateko lehen paketeari soilik aplikatzen zaizkion politikak ez bezala. Honek pakete bakoitzeko CPU kontsumoa handitu dezake, pakete bakoitzean politika aplikatu behar delako. Baina iraupen laburreko konexioetarako, gastu hori conntrack prozesatzeko baliabideen kontsumoa murriztearekin orekatzen da. Esaterako, SaaS hornitzaile baten kasuan, konexio bakoitzeko pakete kopurua oso txikia zen, beraz, pakete bakoitzari politikak aplikatzean CPU-kontsumo gehigarria justifikatu zen.
Has gaitezen probak egiten
Proba urruneko nodoetan exekutatzen ari den memcached zerbitzari batekin eta urruneko nodoetan exekutatzen ari diren memcached bezero-pod bat duen pod bakar batean egin dugu, segundoko konexio kopuru handia exekutatu ahal izateko. Memcached zerbitzariaren pod-eko zerbitzariak 8 nukleo eta 512k sarrera zituen conntrack taulan (ostalariarentzat konfiguratutako taularen tamaina estandarra).
Honen arteko errendimendu-aldea neurtu dugu: sareko politikarik ez; Calico politika arruntarekin; eta Calico ez jarraitzeko politika.
Lehenengo probarako, segundoko 4.000 konexio kopurua ezarri genuen, beraz, PUZaren kontsumoaren diferentzian zentratu genitzake. Ez zegoen politikarik ezaren eta ohiko politikaren artean ezberdintasun handirik, baina ez jarraitzeak CPUaren kontsumoa %20 inguru handitu zuen:
Bigarren proban, gure bezeroek sor ditzaketen hainbat konexio abiarazi ditugu eta gure memcached zerbitzariak kudeatu ditzakeen gehienezko konexio kopurua segundoko neurtu dugu. Espero zen bezala, "politikarik ez" eta "politika arrunta" kasuek 4,000 konexio baino gehiago segundoko (512k / 120s = 4,369 konexio/s = 60,000 konexio/s). Ez jarraitzeko politika batekin, gure bezeroek XNUMX konexio bidali zituzten segundoko arazorik gabe. Ziur gaude kopuru hori handitu genezakeela bezero gehiago gehituz, baina zenbaki hauek nahikoak direla uste dugu artikulu honen nondik norakoak argitzeko!
Ondorioa
Conntrack nukleoaren ezaugarri garrantzitsu bat da. Primeran egiten du bere lana. Sistemaren osagai nagusiek sarritan erabiltzen dute. Hala ere, zenbait eszenatoki zehatzetan, conntrack-ek eragindako pilaketak ematen dituen onura arruntak gainditzen ditu. Eszenatoki honetan, Calico sareko politikak erabil daitezke conntrack-en erabilera selektiboki desgaitzeko sarearen segurtasuna areagotuz. Beste trafiko guztietarako, conntrack-ek zure laguna izaten jarraitzen du!
Irakurri beste artikulu batzuk ere gure blogean:
Iturria: www.habr.com