Urmarja e lidhjeve (âconntrackâ) Ă«shtĂ« njĂ« funksion kyç i kafazit rrjetor tĂ« bĂ«rthamĂ«s Linux. Ajo lejon bĂ«rthamĂ«n tĂ« ndjekĂ« tĂ« gjitha lidhjet rrjetore logjike ose rrjedhat dhe kĂ«shtu tĂ« identifikojĂ« tĂ« gjitha paketat qĂ« pĂ«rbĂ«jnĂ« çdo rrjedhĂ«, nĂ« mĂ«nyrĂ« qĂ« ato tĂ« munden tĂ« pĂ«rpunohen sĂ« bashku nĂ« mĂ«nyrĂ« sekuenciale.
Conntrack është një funksion i rëndësishëm i bërthamës, i cili përdoret në disa raste të rëndësishme:
- NAT mbështetet në informacionin nga conntrack, prandaj mund të përpunojë njëlloj 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 klustrit. Conntrack regjistron se për një lidhje të caktuar, të gjitha paketat në IP-në e shërbimit duhet të dërgohen te po ai pod, dhe paketat që kthehen nga pod-i pastrues duhet të drejtohen prapa nga NAT te pod-i nga ku erdhi kërkesa.
- Firewall-et me ndjekje gjendjeje, si Calico, mbĂ«shteten 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Ă«: "lejo pod-in tim tĂ« lidhet me çdo IP tĂ« largĂ«t" pa pasur nevojĂ« tĂ« shkruani njĂ« politikĂ« pĂ«r tĂ« lejuar nĂ« mĂ«nyrĂ« eksplicite trafikun pĂ«rgjigjĂ«s. (Pa kĂ«tĂ«, do tĂ« duhej tĂ« shtonit njĂ« rregull shumĂ« mĂ« pak tĂ« sigurt "lejo paketat nĂ« pod-in tim nga çdo IP").
Për më tepër, conntrack zakonisht rrit performancën e sistemit (duke reduktuar konsumin e kohës së procesorit dhe vonesën e paketave), pasi vetëm paketa e parë në një rrjedhë
duhet tĂ« kalojĂ« pĂ«rpunimin e plotĂ« tĂ« kafazit tĂ« rrjetit pĂ«r tĂ« pĂ«rcaktuar se çfarĂ« duhet tĂ« bĂ«jĂ« me tĂ«. Shihni postimin "â, pĂ«r tĂ« parĂ« njĂ« shembull se si funksionon kjo.
Megjithatë, conntrack ka kufizimet e tij...
Pra, ku shkoi gjithçka keq?
Tavolina conntrack ka një maksimum të konfigurueshëm, dhe nëse ajo mbushet, lidhjet zakonisht fillojnë të refuzohen ose të priten. Për të përpunuar trafikun e shumicës së aplikacioneve, tavolina zakonisht ka mjaft hapësirë të lirë dhe kjo kurrë nuk do të bëhet një problem. Megjithatë, ka disa skenarë kur ia vlen të mendoni për përdorimin e tavolines conntrack:
- Rastësia më e dukshme është nëse serveri juaj përpunon një numër të jashtëzakonshëm lidhjesh aktive në të njëjtën kohë. Për shembull, nëse tabela juaj conntrack është e konfiguruar për 128k regjistrime, por keni më shumë se 128k lidhje të njëkohshme, sigurisht që do të hasni një problem!
- Një rast pak më pak i dukshëm është nëse serveri juaj përpunon një numër të madh lidhjesh në sekondë. Edhe nëse lidhjet janë të përkohshme, ato vazhdojnë të gjurmohen nga Linux për një periudhë të caktuar kohe (në mënyrë standarde 120 sekonda). Për shembull, nëse tabela juaj conntrack është e konfiguruar për 128 mijë regjistrime dhe përpiqeni të përpunoni 1100 lidhje në sekondë, ato do të tejkalojnë madhësinë e tabelës conntrack, edhe nëse lidhjet janë shumë të shkurtra (128k / 120s = 1092 lidhje / s).
Ka disa lloje aplikacionesh niçë qĂ« bien nĂ« kĂ«to kategori. PĂ«rveç kĂ«saj, nĂ«se keni shumĂ« kundĂ«rshtarĂ«, mbushja e tabelĂ«s conntrack tĂ« serverit tuaj me shumĂ« lidhje gjysmĂ« tĂ« hapura mund tĂ« pĂ«rdoret si njĂ« sulm nga lart tĂ« tipo «refuzim shĂ«rbimi» (DOS). NĂ« tĂ« dyja rastet, conntrack mund tĂ« bĂ«het pika e ngushtĂ« qĂ« kufizon 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 shkurtuar kohĂ«t e skadimit 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Ă« duhet tĂ« anashkaloni conntrack pĂ«r trafikun agresiv.
Një shembull real
Të japim një shembull konkret: një ofrues i madh të shërbimeve SaaS me të cilin kemi punuar kishte një sërë serverash memcached në hosta (jo në makinat virtuale), secili prej të cilëve përpunonte më shumë se 50K lidhje të përkohshme në sekondë.
Ata eksperimentuan me konfigurimin e conntrack, rritën madhësitë e tabelave dhe shkurtuan kohën e gjurmimit, por konfigurimi ishte i pasigurt, konsumimi i RAM ishte rritur ndjeshëm, që ishte një problem (rreth GB!), dhe lidhjet ishin aq të shkurtra saqë conntrack nuk krijonte përfitimin e tij të zakonshëm në performancë (reduktimin e konsumit të CPU ose vonesave të paketave).
Si si ndihmoi, 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 opsionin doNotTrack për politikat). Kjo iu sigurua atyre nivelin e nevojshëm të performancës plus një nivel shtesë sigurie që ofrohet nga Calico.
ĂfarĂ« do tĂ« bĂ«het pĂ«r tĂ« anashkaluar conntrack?
- Politikat e rrjetit do-not-track zakonisht duhet të jenë simetrike. Në rastin e ofruesit SaaS: aplikacionet e tyre funksiononin brenda një zone të mbrojtur dhe për shkak të politikës së rrjetit, ata mund të shtonin në listën e bardhë trafikun nga aplikacione të tjera specifike që kishte leje për t'u aksesuar në memcached.
- Politika do-not-track nuk merr parasysh drejtimin e lidhjes. Prandaj, në rast të një sulmi në serverin memcached, teorikisht mund të përpiqet të lidhet me ndonjë nga klientët memcached, nëse ai përdor portin e duhur të origjinës. Megjithatë, nëse e keni përcaktuar saktë politikën e rrjetit për klientët tuaj memcached, këto përpjekje lidhen ende për t'u refuzuar nga ana e klientit.
- Politika do-not-track aplikohet për çdo paketë, në kundërshtim me politikat e zakonshme, të cilat aplikohen vetëm për paketën e parë nga rrjedha. Kjo mund ta rrisë shpenzimin e burimeve CPU për një paketë, pasi për çdo paketë duhet të aplikohet politika. Por për lidhjet afatshkurtra, ky shpenzim kompensohet nga ulja e shpenzimeve për trajtimin e conntrack. Për shembull, në rastin e ofruesit SaaS, numri i paketave për çdo lidhje ishte shumë i vogël, kështu që shpenzimi shtesë i burimeve CPU gjatë aplikimit të politikave për çdo paketë ishte i arsyeshëm.
Le të fillojmë testet
Ne zhvilluam një test në një pod me serverin memcached dhe shumë pod-e klientësh memcached, të nisur në node të largëta, që të mund të ekzekutonim një numër shumë të madh lidhjesh në sekondë. Serveri me pod-in e serverit memcached kishte 8 bërthama dhe 512k shënime në tabelën conntrack (madhësia standarde e tabelës për hostin).
Ne matëm ndryshimin në performancë midis: pa politikë rrjeti; me politikën e zakonshme të Calico; dhe politikën Calico do-not-track.
Për testin e parë ne vendosëm numrin e lidhjeve deri në 4.000 në sekondë, prandaj mundëm të përqëndrohemi në ndryshimin e konsumit të CPU-së. Këtu nuk kishte ndryshime të rëndësishme midis mungesës së politikave dhe politikave të zakonshme, por politika do-not-track rriti konsumimin e CPU-së me rreth 20%:
Në testin e dytë, ne e lansuam sa më shumë lidhje sa mundën klientët tanë dhe matëm numrin maksimal të lidhjeve në sekondë që serveri ynë memcached mund të përballonte. Siç pritej, në rastin 'pa politika' dhe 'politika e zakonshme' të dy arritën limitin e conntrack mbi 4,000 lidhje 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 do të mund të rritnim këtë numër, duke lidhur më shumë klientë, por mendojmë se këto numra janë të mjaftueshme për të ilustruar mesazhin e këtij artikulli!
PĂ«rfundim
Conntrack është një funksion i rëndësishëm i bërthamës. Ai e bën punën e tij shkëlqyeshëm. Shpesh përdoret nga komponentët kyç të sistemit. Sidoqoftë, në disa skenarë të caktuar, ngarkesa për shkak të conntrack e 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 duke e rritur kështu nivelin e sigurisë rrjetore. Për të gjithë trafikun tjetër, conntrack vazhdon të jetë shoku juaj!
Lexoni gjithashtu artikuj të tjerë në blogun tonë:
Burimi: habr.com
