Ndjekja e lidhjeve (âconntrackâ) Ă«shtĂ« njĂ« funksion kryesor i grumbullit tĂ« rrjetit nĂ« bĂ«rthamĂ«n Linux. Ajo i lejon bĂ«rthamĂ«s tĂ« ndjekĂ« tĂ« gjitha lidhjet ose rrjedhat logjike tĂ« rrjetit dhe nĂ« kĂ«tĂ« mĂ«nyrĂ« tĂ« identifikojĂ« tĂ« gjithĂ« paketat qĂ« pĂ«rbĂ«jnĂ« çdo rrjedh, nĂ« mĂ«nyrĂ« qĂ« ato tĂ« mund tĂ« pĂ«rpunohen sĂ« bashku.
Conntrack është një funksion i rëndësishëm i bërthamës, që përdoret në disa raste kryesore:
- NAT mbështetet në informacionin nga conntrack, kështu që ai mund të trajtojë në mënyrë të njëjtë të gjitha paketat nga një rrjedh. Për shembull, kur një pod i drejtohet një shërbimi Kubernetes, balancuesi i ngarkesës kube-proxy përdor NAT për të drejtuar trafikun në një pod të caktuar brenda klasterit. Conntrack regjistron se për një lidhje të caktuar, të gjitha paketat që dërgohen në IP-në e shërbimit duhet të dërgohen në të njëjtin pod, dhe se paketat që kthehen nga pod-i i prapavijës duhet të kthehen përsëri nga NAT në pod-in nga i cili erdhi kërkesa.
- Firewally me mbikëqyrje të gjendjes, si Calico, bazohen në informacionin nga conntrack për të shtuar trafikun "përgjigjës" në listën e bardhë. Kjo ju lejon të shkruani një politikë rrjeti që thotë: "lejoni pod-in tim të lidhet me çdo adresë IP të largët" pa pasur nevojë të shkruani një politikë për të lejuar përgjigjen e trafikut. (Pa këtë, do të duhej të shtonit një rregull shumë më pak të sigurt "lejoni paketa në pod-in tim nga çdo IP.")
Për më tepër, conntrack zakonisht rrit performancën e sistemit (duke reduktuar konsumimin e kohës së procesorit dhe vonesat e paketave), pasi vetëm paketi i parë në një rrjedhë
duhet të kalojë përpunimin e plotë të stack-ut të rrjetit për të përcaktuar çfarë të bëjë me të. Shikoni postimin "", për të parë një shembull të kësaj në punë.
Megjithatë, conntrack ka kufizimet e tij...
Pra, ku gjithçka shkoi keq?
Tabeli conntrack ka një madhësi maksimale të konfigurueshme dhe, nëse ajo mbushet, lidhjet zakonisht fillojnë të refuzohen ose të ndërpriten. Për të menaxhuar trafikun e shumicës së aplikacioneve, tabela zakonisht ka mjaft hapësirë të lirë dhe kjo kurrë nuk do të bëhet një problem. Megjithatë, ka disa skenarë ku ia vlen të mendoni për përdorimin e tabelës conntrack:
- Rasti më i dukshëm është nëse serveri juaj po përpunon një numër jashtëzakonisht të madh lidhjesh aktive të njëkohshme. Për shembull, nëse tabela juaj conntrack është e konfiguruar për 128k regjistrime, por keni > 128k lidhje të njëkohshme, me siguri do të përballeni me një problem!
- Një rast pak më pak i dukshëm është nëse serveri juaj po përpunon një numër të madh lidhjesh në sekondë. Edhe nëse lidhjet janë të shkurtra, ato vazhdojnë të ndiqen nga Linux për një periudhë të caktuar kohe (në mënyrë standarde 120s). Për shembull, nëse tabela juaj conntrack është e konfiguruar për 128 mijë regjistrime dhe po përpiqeni të përpunoni 1100 lidhje në sekondë, ato do ta kalojnë madhësinë e tabelës conntrack, madje edhe nëse lidhjet janë shumë të shkurtra (128k / 120s = 1092 lidhje / s).
Ka there janĂ« disa lloje aplikacionesh niĆesh qĂ« bien nĂ« kĂ«to kategori. PĂ«r mĂ« tepĂ«r, nĂ«se keni shumĂ« armiq, mbushja e tabelĂ«s conntrack tĂ« serverit tuaj me shumĂ« lidhje gjysmĂ« tĂ« hapura mund tĂ« pĂ«rdoret si njĂ« pjesĂ« e njĂ« sulmi tĂ« tipit "refuzim shĂ«rbimi" (DoS). NĂ« tĂ« dy rastet, conntrack mund tĂ« bĂ«het njĂ« ngushticĂ« kufizuese nĂ« sistemin tuaj. NĂ« disa raste, rregullimi i parametrave tĂ« tabelĂ«s conntrack mund tĂ« jetĂ« i mjaftueshĂ«m pĂ«r tĂ« pĂ«rmbushur nevojat tuaja â duke rritur madhĂ«sinĂ« ose duke reduktuar kohĂ«t e pritjes conntrack (por nĂ«se e bĂ«ni kĂ«tĂ« gabim, do tĂ« pĂ«rballeni me vĂ«shtirĂ«si tĂ« mĂ«dha). PĂ«r raste tĂ« tjera, do tĂ« nevojitet tĂ« anashkaloni conntrack pĂ«r trafikun agresiv.
Shembulli real
Merrni njĂ« shembull konkret: njĂ« ofrues i madh SaaS me tĂ« cilin kemi punuar kishte njĂ« sĂ«rĂ« serverash memcached nĂ« hoste (jo nĂ« makinaè), secili prej tĂ« cilĂ«ve pĂ«rballonte mbi 50,000 lidhje kalimtare nĂ« sekondĂ«.
Ata eksperimento për konfigurimin conntrack, rritën madhësitë e tabelave dhe shkurtuan kohën e gjurmimit, por konfigurimi ishte i pasigurt, duke rritur ndjeshëm konsumimin e RAM-it, që ishte një problem (rreth GB)! Ndërsa lidhjet ishin kaq të shkurtra sa që conntrack nuk krijonte përfitim të zakonshëm në performancë (ulje e konsumit të CPU ose vonesave të paketeve).
Si alternativë, ata iu drejtuan Calico. Politikat e rrjetit të Calico lejojnë që të mos përdoret conntrack për një lloj të caktuar trafiku (duke përdorur për politikën opsionin doNotTrack). Kjo u siguroi atyre nivelin e nevojshëm të performancës plus një nivel të shtuar sigurie, që ofrohet nga Calico.
ĂfarĂ« do tĂ« bĂ«het pĂ«r tĂ« shmangur conntrack?
- Politikat e rrjetit do-not-track zakonisht duhet të jenë simetrike. Në rastin e ofruesit SaaS: aplikacionet e tyre punonin brenda një zone të mbrojtur dhe, përmes politikës së rrjetit, ata mund të shtonin në listën e bardhë trafikun nga aplikacione specifike të tjera, të cilave u jepej leja për të aksesuar memcached.
- Politika do-not-track nuk merr parasysh drejtimin e lidhjes. Kështu, në rastin e një sulmi ndaj serverit memcached, teorikisht është e mundur të përpiqeni të lidhni çdo klient memcached, nëse ai përdor portin e saktë të origjinës. Megjithatë, nëse keni përcaktuar në mënyrë korrekte politikën e rrjetit për klientët tuaj memcached, këto përpjekje për lidhje gjithsesi do të refuzohen nga ana e klientit.
- Politika do-not-track zbatohet për çdo paketë, ndryshe nga politikat e zakonshme, të cilat zbatohet vetëm për paketën e parë nga rrjedha. Kjo mund të rrisë konsumimin e burimeve CPU për një paketë, sepse për çdo paketë nevojitet të zbatohet politika. Por për lidhjet e shkurtra, ky konsum balançohet nga ulja e burimeve për përpunimin e conntrack. Për shembull, në rastin e një ofruesi SaaS, numri i paketave për çdo lidhje ishte shumë i vogël, prandaj shpenzimi shtesë i burimeve CPU për zbatimin e politikave për çdo paketë ishte i justifikuar.
Le të fillojmë testet.
Ne kemi kryer një test në një pod me server memcached dhe shumicë pod-esh klient memcached të lëshuar në nodë të largët, në mënyrë që të mundnim të kryenim një numër të madh lidhjesh në sekondë. Serveri me pod-in e serverit memcached kishte 8 bërthama dhe 512k regjistrime në tabelën conntrack (në përmasë standarde të tabelës për hostin).
Ne matëm ndryshimin në performancë midis: pa politikën rrjetore; me politikën standarde Calico; dhe politikën Calico do-not-track.
Për testin e parë, ne caktuam numrin e lidhjeve në 4.000 në sekondë, kështu që mundëm të fokusohemi në ndryshimin e konsumit të CPU. Nuk kishte dallime të rëndësishme midis mungesës së politikës dhe politikës standarde, por do-not-track rriti konsumimin e CPU përafërsisht me 20%:
Në testin e dytë, ne aktivizuam sa më shumë lidhje që mundëm të gjeneronim klientët tanë dhe matëm numrin maksimal të lidhjeve në sekondë që mund të trajtonte serveri ynë memcached. Siç pritej, në rastin e "pa politika" dhe "politika e zakonshme", të dy arritën limitin conntrack të mbi 4,000 lidhjeve në sekondë (512k / 120s = 4,369 lidhje/s). Me politikën do-not-track, klientët tanë dërguan 60,000 lidhje në sekondë pa asnjë problem. Jemi të sigurt se mund të rritnim këtë numër duke lidhur më shumë klientë, por ndjejmë se këto numra janë mjaftueshëm për të ilustruar mesazhin e këtij artikulli!
PĂ«rfundimi
Conntrack është një funksion i rëndësishëm i bërthamës. Ai kryen detyrën e tij shumë mirë. Përdoret shpesh nga komponentët kyç të sistemit. Megjithatë, në disa skenarë të caktuar, ngarkesa për shkak të conntrack tejkalon përfitimet e zakonshme që ai ofron. Në këtë skenar, politikat rrjetore Calico mund të përdoren për të çaktivizuar selektivisht përdorimin e conntrack që ndihmon në rritjen e nivelit të sigurisë rrjetore. Për të gjithë trafikun tjetër, conntrack vazhdon të mbetet shoku juaj!
Shihni gjithashtu artikuj të tjerë në blogun tonë:
Burimi: habr.com
