🥇Kada vam Linux conntrack više nije prijatelj

Praćenje veza („conntrack“) je osnovna funkcija mrežnog stoga Linux jezgra. Omogućuje jezgru da prati sve logičke mrežne veze ili tokove, čime se identifikuju svi paketi koji čine svaki tok, omogućavajući njihovu sekvencijalnu obradu.

Conntrack je važna funkcija jezgra koja se koristi u nekim osnovnim slučajevima:

NAT se oslanja na informacije iz conntrack-a, tako da može jednako obraditi sve pakete iz jednog toka. Na primer, kada pod poziva Kubernetes servis, kube-proxy balancer opterećenja koristi NAT za usmeravanje prometa na određeni pod unutar klastera. Conntrack beleži da svi paketi za određenu vezu moraju biti poslati istom pod-u, i da se paketi koje vraća pod backend-a moraju NAT-om vratiti u pod iz kojeg je zahtev došao.
Vatrozidovi sa praćenjem stanja, kao što je Calico, oslanjaju se na informacije iz conntrack-a kako bi dodali "odgovarajući" promet na belu listu. Ovo vam omogućava da napišete mrežnu politiku koja kaže: "dozvoli mom pod-u da se povezuje sa bilo kojom udaljenom IP adresom" bez potrebe za pisanjem politike za eksplicitno odobravanje povratnog prometa. (Bez ovoga biste morali dodati mnogo manje bezbedno pravilo "dozvoli pakete u moj pod sa bilo kog IP-a." )

Pored toga, conntrack obično poboljšava performanse sistema (smanjujući potrošnju procesorskog vremena i vreme kašnjenja paketa), jer samo prvi paket u toku
mora proći kroz kompletnu obradu mrežnog stoga kako bi se odredilo šta učiniti s njim. Pogledajte post "Upoređivanje režima kube-proxy‘ da vidite primer kako to funkcioniše.

Međutim, conntrack ima svoja ograničenja…

Dakle, gde je sve pošlo po zlu?

Conntrack tabela ima prilagodljivu maksimalnu veličinu, i kada se napuni, veze se obično počinju odbijati ili prekidati. Za obradu prometa većine aplikacija, u tabeli ima dovoljno slobodnog mesta i to nikada neće postati problem. Ipak, postoji nekoliko scenarija u kojima vredi razmisliti o korišćenju conntrack tabele:

Naj očigledniji slučaj je kada vaš server obrađuje izuzetno veliki broj aktivnih povezanih spojeva istovremeno. Na primjer, ako je vaša conntrack tablica podešena na 128k zapisa, ali imate više od 128k istovremenih veza, sigurno ćete naići na problem!
Malo manje očigledan slučaj je kada vaš server obrađuje vrlo veliki broj veza po sekundi. Čak i ako su veze kratkotrajne, Linux ih nastavља pratiti tokom određenog vremenskog razdoblja (po defaultu 120s). Na primjer, ako je vaša conntrack tablica podešena na 128 tisuća zapisa i pokušavate obraditi 1100 veza u sekundi, one će premašiti veličinu conntrack tablice, čak i ako su veze vrlo kratkotrajne (128k / 120s = 1092 veze / s).

Postoji nekoliko specifičnih tipova aplikacija koje spadaju u ove kategorije. Osim toga, ako imate mnogo protivnika, popunjavanje conntrack tablice vašeg servera brojnim poluotvorenim vezama može se koristiti u okviru napada tipa "odbijanje usluge" (DoS). U oba slučaja, conntrack može postati ograničavajuće usko grlo u vašem sustavu. U nekim slučajevima, podešavanje parametara conntrack tablice može biti dovoljno da zadovolji vaše potrebe - povećavanjem veličine ili smanjenjem vremenskih ograničenja conntrack (ali ako to uradite pogrešno, naići ćete na velike poteškoće). Za druge slučajeve bit će potrebno zaobići conntrack za agresivni promet.

Stvaran primjer

Uzmimo konkretan primjer: jedan veliki SaaS davatelj usluga s kojim smo radili imao je niz memcached servera na hostovima (ne virtualnim mašinama), od kojih je svaki obrađivao više od 50K kratkotrajnih veza u sekundi.

Eksperimentirali su s konfiguracijom conntrack, povećavali veličine tablica i skraćivali vremena praćenja, ali konfiguracija je bila nepouzdana, znatno se povećala potrošnja RAM-a, što je bio problem (desetci GB!), a veze su bile toliko kratke da conntrack nije ostvarivao svoju uobičajenu dobit u performansama (smanjenje potrošnje CPU-a ili kašnjenja paketa).

Kao alternativu, obratili su se Calico-u. Mrežne politike Calico omogućuju da se ne koristi conntrack za određene vrste prometa (koristeći opciju doNotTrack za politike). To im je osiguralo potrebnu razinu performansi plus dodatnu razinu sigurnosti koju pruža Calico.

Na što ćete morati pristati da bisteobišli conntrack?

Mrežne politike do-not-track obično trebaju biti simetrične. U slučaju SaaS pružatelja: njihove aplikacije radile su unutar zaštićene zone i stoga su pomoću mrežne politike mogli staviti na bijelu listu promet s drugih konkretnih aplikacija kojima je bio dopušten pristup memcached-u.
Politika do-not-track ne uzima u obzir smjer veze. Tako, u slučaju napada na memcached server, teoretski se može pokušati povezati s bilo kojim od memcached klijenata ako koristi pravi izvorni port. Međutim, ako ste ispravno definirali mrežnu politiku za svoje memcached klijente, taj će pokušaj povezivanja i dalje biti odbijen na strani klijenta.
Politika do-not-track primjenjuje se na svaki paket, za razliku od uobičajenih politika koje se primjenjuju samo na prvi paket iz toka. To može povećati opterećenje CPU-a za jedan paket, jer se politika mora primijeniti na svaki paket. No, za kratkoročne veze ovo opterećenje se izjednačuje smanjenjem potrošnje resursa za obradu conntrack-a. Na primjer, u slučaju SaaS pružatelja, broj paketa za svaku vezu bio je vrlo mali, stoga je dodatna potrošnja CPU-a pri primjeni politika na svaki paket bila opravdana.

Krenimo s testovima

Proveli smo test na jednom podu s memcached serverom i mnoštvom podova memcached klijenata, pokrenutih na udaljenim čvorovima, tako da smo mogli pokrenuti vrlo veliki broj veza u sekundi. Server s podom memcached servera imao je 8 jezgri i 512k zapisa u conntrack tablici (standardno postavljena veličina tablice za host).
Mjereni smo razliku u performansama između: bez mrežne politike; s uobičajenom Calico politikom; i Calico do-not-track politikom.

Za prvi test postavili smo broj konekcija na 4.000 u sekundi, tako da smo mogli fokusirati na razliku u potrošnji CPU-a. Nije bilo značajnih razlika između odsustva politike i uobičajene politike, ali je do-not-track povećao potrošnju CPU-a za otprilike 20%.

U drugom testu pokrenuli smo onoliko konekcija koliko su naši klijenti mogli generirati i mjerili smo maksimum broj konekcija u sekundi koje je mogao obraditi naš memcached server. Kako se i očekivalo, u slučaju „bez politika“ i „uobičajena politika“ oboje je dostiglo limit conntracka od više od 4.000 konekcija u sekundi (512k / 120s = 4.369 konekcija/s). S do-not-track politikom naši klijenti su slali 60.000 konekcija u sekundi bez ikakvih problema. Sigurni smo da bismo mogli povećati ovaj broj spajanjem većeg broja klijenata, ali smatramo da su ovi brojevi već dovoljni da ilustriraju poantu ovog članka!

Zaključak

Conntrack je važna funkcija jezgra. Odlično obavlja svoj posao. Često ga koriste ključne komponente sustava. Međutim, u nekim određenim scenarijima, preopterećenje zbog conntracka nadmašuje uobičajene prednosti koje pruža. U ovom scenariju, mrežne politike Calico mogu se koristiti za selektivno isključivanje korištenja conntracka, istovremeno povećavajući razinu mrežne sigurnosti. Za sav ostali promet conntrack ostaje vaš prijatelj!

Također pročitajte druge članke na našem blogu:

Izvor: habr.com