ProHoster > Blogs > Administrācija > Kad Linux conntrack jums vairs nav draugs

Kad Linux conntrack jums vairs nav draugs

Kad Linux conntrack jums vairs nav draugs

Savienojumu izsekoÅ”ana (ā€œconntrackā€) ir pamatfunkcija Linux kodola tÄ«kla kaudzē. Tā ļauj kodolam sekot visām loÄ£iskajām tÄ«kla savienojumiem vai plÅ«smām, tādējādi identificējot visus paketus, kas veido katru plÅ«smu, lai tos varētu secÄ«gi apstrādāt kopā.

Conntrack ir svarīga kodola funkcija, kas tiek izmantota dažos pamata gadījumos:

  • NAT balstās uz informāciju no conntrack, tādējādi tas var vienādi apstrādāt visus paketus no vienas plÅ«smas. Piemēram, kad pods sazinās ar Kubernetes pakalpojumu, kube-proxy slodzes balansētājs izmanto NAT, lai novirzÄ«tu satiksmi uz konkrētu podu iekŔējā klasterÄ«. Conntrack reÄ£istrē, ka visiem pakotnēm, kas adresētas pakalpojuma IP, jābÅ«t nosÅ«tÄ«tām uz to paÅ”u podu, un ka paketes, ko atgriež backend pod, jānovirza NAT atpakaļ uz podu, no kura saņemts pieprasÄ«jums.
  • Stāvokļa izsekoÅ”anas ugunsmÅ«ri, piemēram, Calico, balstās uz informāciju no conntrack, lai pievienotu ā€œatbildesā€ satiksmi baltajai sarakstā. Tas ļauj jums uzrakstÄ«t tÄ«kla politiku, kas saka: ā€žatļaut manam podam savienoties ar jebkuru tālu IP adresiā€, nevis jānosaka politika, kas skaidri atļauj atbildes satiksmi. (Bez tā jums bÅ«tu jāpieŔķir daudz mazāk droÅ”a norma ā€žatļaut paketes manam pod ar jebkuru IPā€.)

Turklāt conntrack parasti uzlabo sistēmas veiktspēju (samazinot procesora laika patēriņu un paketes aiztures laiku), jo tikai pirmajam paketam plūsmā
jāiet cauri pilnai tÄ«kla kaudzes apstrādei, lai noteiktu, ko ar to darÄ«t. Skatiet ierakstu ā€œKube-proxy režīmu salÄ«dzinājumsā€, lai redzētu piemēru, kā tas darbojas.

Tomēr conntrack ir savi ierobežojumi...

Tātad, kur viss iegāja greizajā ceļā?

Conntrack tabulai ir pielāgojams maksimālais izmērs, un, ja tā piepildās, savienojumi parasti sāk tikt noraidīti vai pārtraukti. Lielākajai daļai lietojumu satiksmes sarakstos brīvā vieta parasti ir pietiekama, un tas nekad pārvērtīsies par problēmu. Tomēr ir daži scenāriji, kad vajadzētu apsvērt izmantot conntrack tabulu:

  • AcÄ«mredzamākais gadÄ«jums ir tad, ja jÅ«su serveris apstrādā ārkārtÄ«gi lielu vienlaicÄ«gu aktÄ«vo savienojumu skaitu. Piemēram, ja jÅ«su conntrack tabula ir konfigurēta uz 128k ierakstiem, bet jums ir vairāk nekā 128k vienlaicÄ«gu savienojumu, jÅ«s noteikti saskarsities ar problēmām!
  • Mazāk acÄ«mredzams gadÄ«jums: ja jÅ«su serveris apstrādā ļoti lielu savienojumu skaitu sekundē. Pat ja savienojumi ir Ä«slaicÄ«gi, Linux tos turpina uzskaitÄ«t kaut kādu laiku (noklusējuma iestatÄ«jums ir 120s). Piemēram, ja jÅ«su conntrack tabula ir konfigurēta uz 128 tÅ«kst. ierakstiem un mēģināt apstrādāt 1100 savienojumus sekundē, tie pārsniegs conntrack tabulas lielumu, pat ja savienojumi ir ļoti Ä«slaicÄ«gi (128k / 120s = 1092 savienojumi / s).

Ir vairāki specifiski aplikāciju veidi, kas ietilpst Å”ajās kategorijās. Turklāt, ja jums ir daudz ļaunprātÄ«gu lietotāju, tad jÅ«su servera conntrack tabulas piepildÄ«Å”ana ar daudziem pusatvērtiem savienojumiem var tikt izmantota kā uzbrukums, kas pazÄ«stams kā "denial of service" (DOS). Abos gadÄ«jumos conntrack var kļūt par ierobežojoÅ”o Å”aurās vietas jÅ«su sistēmā. Dažos gadÄ«jumos nav nepiecieÅ”ams neko darÄ«t, vienkārÅ”i mainot conntrack tabulas parametrus, palielinot lielumu vai samazinot laika ierobežojumus (bet, ja to izdarÄ«siet nepareizi, jums bÅ«s grÅ«tÄ«bas). Citiem gadÄ«jumiem bÅ«s nepiecieÅ”ams apiet conntrack agresÄ«vas satiksmes gadÄ«jumā.

Reāls piemērs

Pieņemsim konkrētu piemēru: viens liels SaaS pakalpojumu sniedzējs, ar kuru mēs strādājām, bija vairāki memcached serveri uz hostiem (ne virtuālajām maŔīnām), no kuriem katrs apstrādāja 50K+ Ä«slaicÄ«gu savienojumu sekundē.

Viņi eksperimentēja ar conntrack konfigurāciju, palielinot tabulu izmērus un samazinot izsekoÅ”anas laiku, bet konfigurācija bija nestabila, ievērojami palielinājās RAM patēriņŔ, kas bija problēma (vairākos GB!), un savienojumi bija tik Ä«si, ka conntrack nesniedza parasto veiktspējas uzlabojumu (samazinot CPU patēriņu vai paketes aizturi).

Kā alternatÄ«vu viņi vērÅ”as pie Calico. Calico tÄ«kla politikas ļauj neizmantot conntrack noteiktam trafika veidam (izmantojot doNotTrack opciju politiku). Tas nodroÅ”ināja nepiecieÅ”amo veiktspējas lÄ«meni, kā arÄ« papildu droŔības lÄ«meni, ko sniedz Calico.

Uz ko būs jādodas, lai apejot conntrack?

  • TÄ«kla politikas do-not-track parasti jābÅ«t simetriskām. SaaS pakalpojumu sniedzēja gadÄ«jumā: to lietotnes darbojās aiz aizsargātas zonas, un tāpēc izmantojot tÄ«kla politiku, tie varēja pievienot baltajā sarakstā trafiku no citiem konkrētiem lietotnēm, kurām tika atļauts piekļūt memcached.
  • Politika do-not-track neņem vērā savienojuma virzienu. Tādējādi, ja memcached serveris tiek uzlauzts, teorētiski var mēģināt pieslēgties jebkuram no memcached klientiem, ja tam ir pareizais sākuma ports. Tomēr, ja esat pareizi noteicis tÄ«kla politiku saviem memcached klientiem, tad Å”ie pieslēgÅ”anās mēģinājumi vienalga tiks noraidÄ«ti klienta pusē.
  • Politika do-not-track tiek piemērota katram paketēm, atŔķirÄ«bā no parastajām politikām, kas tiek piemērotas tikai pirmajai paketēm no plÅ«smas. Tas var palielināt CPU resursu patēriņu uz vienu paketi, jo katrai paketēm ir jāpielieto politika. Taču Ä«slaicÄ«gu savienojumu gadÄ«jumā Å”is izdevums tiek lÄ«dzsvarots ar resursu patēriņa samazināŔanu, apstrādājot conntrack. Piemēram, SaaS pakalpojumu sniedzēja gadÄ«jumā katra savienojuma paketēm bija ļoti maz, tādēļ papildus CPU resursu izdevumi, piemērojot politikas katrai paketēm, bija pamatoti.

Sāksim testÄ“Å”anu

Mēs veicām testu vienā pod'ā ar memcached serveri un daudziem pod'iem ar memcached klientiem, kas darbojās attālinātās mezglos, lai mēs varētu izveidot ļoti lielu savienojumu skaitu sekundē. Memcached servera pod'ā bija 8 kodoli un 512k ierakstu conntrack tabulā (standarta konfigurētais tabulas izmērs resursdatoram).
Mēs mērÄ«jām veiktspējas atŔķirÄ«bu starp: bez tÄ«kla politikas; ar parasto Calico politiku; un Calico do-not-track politiku.

Pirmajā testā mēs noteicām savienojumu skaitu lÄ«dz 4,000 sekundē, tāpēc varējām koncentrēties uz CPU patēriņa atŔķirÄ«bām. Å eit nebija bÅ«tisku atŔķirÄ«bu starp politikas neesamÄ«bu un parasto politiku, taču do-not-track palielināja CPU patēriņu par aptuveni 20%.

Kad Linux conntrack jums vairs nav draugs

Otrajā testā mēs palaidām tik daudz savienojumu, cik tikai varēja Ä£enerēt mÅ«su klienti, un mērijām maksimālo savienojumu skaitu sekundē, ko spēja apstrādāt mÅ«su memcached serveris. Kā gaidÄ«ts, 'bez politikas' un 'parastā politika' abi sasniedza conntrack robežu vairāk nekā 4,000 savienojumiem sekundē (512k / 120s = 4,369 savienojumi/s). Ar do-not-track politiku mÅ«su klienti sÅ«tÄ«ja 60,000 savienojumus sekundē bez jebkādām problēmām. Mēs esam pārliecināti, ka varētu palielināt Å”o skaitli, pieslēdzot vairāk klientu, bet jÅ«tam, ka Å”ie cipari jau pietiek, lai ilustrētu Ŕī raksta bÅ«tÄ«bu!

Kad Linux conntrack jums vairs nav draugs

Secinājums

Conntrack ir svarÄ«ga kodola funkcija. Tas lieliski paveic savu darbu. To bieži izmanto sistēmas galvenie komponenti. Tomēr noteiktās situācijās, noslogojums dēļ conntrack pārsniedz parastās priekÅ”rocÄ«bas, ko tas sniedz. Å ajā scenārijā Calico tÄ«kla politikas var tikt izmantotas, lai izvēles veidā atslēgtu conntrack izmantoÅ”anu, vienlaikus paaugstinot tÄ«kla droŔības lÄ«meni. Visam pārējām straumēm conntrack turpinās bÅ«t jÅ«su sabiedrotais!

Izlasiet arī citus rakstus mūsu emuārā:

Avots: habr.com

Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster