Praćenje konekcije (“conntrack”) je osnovna karakteristika mrežnog stoga Linux kernela. Omogućava kernelu da prati sve logičke mrežne veze ili tokove i na taj način identificira sve pakete koji čine svaki tok tako da se mogu obraditi zajedno uzastopno.
Conntrack je važna karakteristika kernela koja se koristi u nekim osnovnim slučajevima:
- NAT se oslanja na informacije iz conntrack-a tako da može jednako tretirati sve pakete iz istog toka. Na primjer, kada pod pristupi Kubernetes usluzi, kube-proxy balansator opterećenja koristi NAT za usmjeravanje prometa na određeni pod unutar klastera. Conntrack bilježi da za datu vezu svi paketi IP servisu moraju biti poslani u isti pod, i da paketi koje vraća backend pod moraju biti NAT vraćeni u pod iz kojeg je zahtjev došao.
- Zaštitni zidovi sa stanjem kao što je Calico oslanjaju se na informacije od povezivanja do saobraćaja "odgovora" na bijelu listu. Ovo vam omogućava da napišete mrežnu politiku koja kaže "dopusti mojoj podlozi da se poveže na bilo koju udaljenu IP adresu" bez potrebe da pišete politiku koja će eksplicitno dozvoliti promet odgovora. (Bez toga, morali biste dodati mnogo manje bezbedno pravilo "dozvoli pakete u moj pod sa bilo koje IP adrese".)
Dodatno, conntrack obično poboljšava performanse sistema (smanjenjem potrošnje CPU-a i kašnjenja paketa) jer samo prvi paket u toku
mora proći kroz cijeli mrežni stog kako bi odredio što učiniti s njim. Pogledajte objavu"" da vidite primjer kako to funkcionira.
Međutim, conntrack ima svoja ograničenja...
Pa gdje je sve pošlo po zlu?
Conntrack tabela ima konfigurabilnu maksimalnu veličinu, a ako se napuni, veze obično počinju da se odbijaju ili prekidaju. U tablici ima dovoljno slobodnog prostora za rukovanje prometom većine aplikacija i to nikada neće postati problem. Međutim, postoji nekoliko scenarija u kojima biste mogli razmisliti o korištenju tabele conntrack:
- Najočigledniji slučaj je ako vaš server upravlja izuzetno velikim brojem istovremeno aktivnih veza. Na primjer, ako je vaša conntrack tablica konfigurirana za 128k unosa, ali imate >128k istovremenih veza, sigurno ćete naići na problem!
- Nešto manje očigledan slučaj: ako vaš server obrađuje vrlo veliki broj konekcija u sekundi. Čak i ako su veze kratkotrajne, Linux ih i dalje nadgleda neko vrijeme (120s prema zadanim postavkama). Na primjer, ako je vaša conntrack tablica konfigurirana za 128k unosa i pokušavate rukovati sa 1100 veza u sekundi, one će premašiti veličinu tabele conntrack, čak i ako su veze vrlo kratkog vijeka (128k/120s = 1092 konekcije/ s).
Postoji nekoliko nišnih tipova aplikacija koje spadaju u ove kategorije. Osim toga, ako imate puno loših aktera, popunjavanje tabele conntrack vašeg servera sa puno poluotvorenih veza može se koristiti kao dio napada uskraćivanja usluge (DOS). U oba slučaja, conntrack može postati ograničavajuće usko grlo u vašem sistemu. U nekim slučajevima, podešavanje parametara tabele conntrack može biti dovoljno da zadovolji vaše potrebe - povećanjem veličine ili smanjenjem vremena čekanja na conntrack (ali ako to učinite pogrešno, naići ćete na mnogo problema). U drugim slučajevima biće potrebno zaobići conntrack za agresivan saobraćaj.
Pravi primjer
Dajemo konkretan primjer: jedan veliki SaaS provajder s kojim smo radili imao je određeni broj memcached servera na hostovima (ne virtualnim mašinama), od kojih je svaki obrađivao 50K+ kratkoročnih veza u sekundi.
Eksperimentirali su sa konfiguracijom conntrack-a, povećavajući veličinu tablice i smanjujući vrijeme praćenja, ali konfiguracija je bila nepouzdana, potrošnja RAM-a se značajno povećala, što je bio problem (reda od GByta!), a veze su bile toliko kratke da conntrack nije mogao stvori svoju uobičajenu prednost performansi (smanjena potrošnja CPU-a ili kašnjenje paketa).
Okrenuli su se Calico kao alternativi. Calico mrežna pravila vam omogućavaju da ne koristite conntrack za određene vrste saobraćaja (koristeći doNotTrack policy opciju). To im je dalo nivo performansi koji im je bio potreban, plus dodatni nivo sigurnosti koji je pružio Calico.
Koliko dugo ćete morati ići da zaobiđete conntrack?
- Mrežne politike ne-praćenja bi općenito trebale biti simetrične. U slučaju SaaS provajdera: njihove aplikacije su radile unutar zaštićene zone i stoga su, koristeći mrežnu politiku, mogli na bijelu listu prometa iz drugih specifičnih aplikacija kojima je bio dozvoljen pristup memcached-u.
- Politika ne praćenja ne uzima u obzir smjer veze. Stoga, ako je memcached server hakiran, teoretski možete pokušati da se povežete na bilo koji od memcached klijenata, sve dok koristi ispravan izvorni port. Međutim, ako ste ispravno definirali mrežnu politiku za vaše memcached klijente, tada će ovi pokušaji povezivanja i dalje biti odbijeni na strani klijenta.
- Politika ne prati se primjenjuje na svaki paket, za razliku od normalnih politika, koje se primjenjuju samo na prvi paket u toku. Ovo može povećati potrošnju CPU-a po paketu jer se politika mora primijeniti za svaki paket. Ali za kratkotrajne veze, ovaj trošak je balansiran smanjenjem potrošnje resursa za obradu conntrack-a. Na primjer, u slučaju SaaS provajdera, broj paketa za svaku vezu je bio vrlo mali, tako da je dodatna potrošnja CPU-a prilikom primjene politika na svaki paket bila opravdana.
Počnimo sa testiranjem
Izveli smo test na jednom modulu sa memcached serverom i više memcached klijentskih podova koji rade na udaljenim čvorovima tako da smo mogli pokrenuti vrlo veliki broj veza u sekundi. Server sa memcached serverskom podom imao je 8 jezgara i 512k unosa u conntrack tabeli (standardna konfigurisana veličina tabele za host).
Izmjerili smo razliku u performansama između: nema mrežne politike; sa redovnom politikom Calico; i Calico politika nepraćenja.
Za prvi test smo postavili broj konekcija na 4.000 u sekundi, kako bismo se mogli fokusirati na razliku u potrošnji CPU-a. Nije bilo značajnih razlika između bez politike i regularne politike, ali ne prati povećanu potrošnju CPU-a za oko 20%:
U drugom testu, pokrenuli smo onoliko konekcija koliko su naši klijenti mogli generirati i izmjerili maksimalan broj konekcija u sekundi koje je naš memcached server mogao podnijeti. Kao što se i očekivalo, slučajevi „bez politike” i „redovne politike” dostigli su granicu veze od preko 4,000 konekcija u sekundi (512k / 120s = 4,369 konekcija/s). Uz politiku ne prati, naši klijenti su slali 60,000 veza u sekundi bez ikakvih problema. Sigurni smo da bismo mogli povećati ovaj broj dodavanjem više klijenata, ali smatramo da su ovi brojevi već dovoljni da ilustruju poentu ovog članka!
zaključak
Conntrack je važna karakteristika kernela. Svoj posao radi savršeno. Često ga koriste ključne komponente sistema. Međutim, u nekim specifičnim scenarijima, zagušenje zbog conntrack-a nadmašuje normalne prednosti koje pruža. U ovom scenariju, Calico mrežne politike se mogu koristiti za selektivno onemogućavanje korištenja conntrack-a uz povećanje sigurnosti mreže. Za sav ostali promet, conntrack je i dalje vaš prijatelj!
Pročitajte i druge članke na našem blogu:
izvor: www.habr.com