Praćenje veze ("conntrack") temeljna je značajka mrežnog skupa jezgre Linuxa. Omogućuje jezgri 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 sekvencijalno.
Conntrack je važna značajka jezgre 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 balanser opterećenja koristi NAT za usmjeravanje prometa na određeni pod unutar klastera. Conntrack bilježi da za danu vezu, svi paketi za IP uslugu moraju biti poslani na isti modul i da se paketi koje vraća backend modul moraju NAT-ovati natrag na modul iz kojeg je zahtjev došao.
- Vatrozidi s praćenjem stanja, kao što je Calico, oslanjaju se na informacije iz connecttrack-a za promet "odgovora" na bijelu listu. To vam omogućuje da napišete mrežnu politiku koja kaže "dopusti mom modulu da se poveže s bilo kojom udaljenom IP adresom" bez potrebe da napišete politiku koja eksplicitno dopušta promet odgovora. (Bez ovoga, morali biste dodati puno manje sigurno pravilo "dopusti pakete u moj modul s bilo koje IP adrese".)
Osim toga, conntrack obično poboljšava performanse sustava (smanjenjem potrošnje CPU-a i kašnjenja paketa) budući da samo prvi paket u toku
mora proći kroz cijeli mrežni stog kako bi odredio što učiniti s njim. Pogledajte post "" da vidite primjer kako to funkcionira.
Međutim, conntrack ima svoja ograničenja...
Pa gdje je sve pošlo po zlu?
Tablica conntrack ima maksimalnu veličinu koja se može konfigurirati, a ako se napuni, veze se obično počinju odbijati ili prekidati. U tablici ima dovoljno slobodnog prostora za upravljanje prometom većine aplikacija, a to nikada neće postati problem. Međutim, postoji nekoliko scenarija u kojima biste mogli razmotriti korištenje tablice conntrack:
- Najočitiji slučaj je ako vaš poslužitelj rukuje izuzetno velikim brojem istovremeno aktivnih veza. Na primjer, ako je vaša conntrack tablica konfigurirana za 128k unosa, ali imate >128k istodobnih veza, sigurno ćete naići na problem!
- Nešto manje očit slučaj: ako vaš poslužitelj obrađuje jako velik broj veza u sekundi. Čak i ako su veze kratkotrajne, Linux ih nastavlja nadzirati neko vrijeme (120 s prema zadanim postavkama). Na primjer, ako je vaša conntrack tablica konfigurirana za 128k unosa 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 nišnih vrsta aplikacija koje spadaju u ove kategorije. Osim toga, ako imate puno loših aktera, punjenje tablice conntrack vašeg poslužitelja s 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 sustavu. U nekim slučajevima, prilagođavanje parametara conntrack tablice može biti dovoljno da zadovolji vaše potrebe - povećanjem veličine ili smanjenjem conntrack timeouta (ali ako to učinite pogrešno, naići ćete na mnogo problema). U drugim slučajevima bit će potrebno zaobići conntrack za agresivan promet.
Pravi primjer
Navedimo konkretan primjer: jedan veliki SaaS pružatelj usluga s kojim smo radili imao je nekoliko memcachiranih poslužitelja na hostovima (ne virtualnim strojevima), od kojih je svaki obrađivao 50K+ kratkotrajnih veza u sekundi.
Eksperimentirali su s konfiguracijom conntrack, povećavajući veličinu tablice i smanjujući vrijeme praćenja, ali konfiguracija je bila nepouzdana, potrošnja RAM-a se znatno povećala, što je predstavljalo problem (reda veličine GBytes!), a veze su bile tako kratke da conntrack nije stvoriti svoju uobičajenu prednost performansi (smanjena potrošnja procesora ili latencija paketa).
Okrenuli su se Calicu kao alternativi. Calico mrežna pravila omogućuju vam da ne koristite conntrack za određene vrste prometa (pomoću opcije pravila doNotTrack). To im je dalo razinu performansi koja im je bila potrebna, plus dodatnu razinu sigurnosti koju pruža Calico.
Do koje duljine ćete morati prijeći da biste zaobišli conntrack?
- Mrežna pravila o ne-praćenju općenito bi trebala biti simetrična. U slučaju pružatelja usluga SaaS: njihove su se aplikacije izvodile unutar zaštićene zone i stoga su, koristeći mrežna pravila, mogli staviti na bijeli promet promet iz drugih specifičnih aplikacija kojima je dopušten pristup memcached-u.
- Politika ne-praćenja ne uzima u obzir smjer veze. Dakle, ako je memcached poslužitelj hakiran, teoretski se možete pokušati povezati s bilo kojim od memcached klijenata, sve dok koristi ispravan izvorni port. Međutim, ako ste ispravno definirali mrežnu politiku za svoje memcachirane klijente, tada će ti pokušaji povezivanja i dalje biti odbijeni na strani klijenta.
- Politika ne-praćenja primjenjuje se na svaki paket, za razliku od normalnih politika koje se primjenjuju samo na prvi paket u toku. To 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 uravnotežen smanjenjem potrošnje resursa za conntrack obradu. Na primjer, u slučaju SaaS pružatelja usluga, broj paketa za svaku vezu bio je vrlo malen, tako da je dodatna potrošnja CPU-a prilikom primjene politika na svaki paket bila opravdana.
Počnimo s testiranjem
Izveli smo test na jednom modulu s memcachiranim poslužiteljem i više memcachiranih klijentskih modula koji rade na udaljenim čvorovima kako bismo mogli pokrenuti vrlo velik broj veza u sekundi. Poslužitelj s predmemoriranom jedinicom poslužitelja imao je 8 jezgri i 512k unosa u conntrack tablici (standardna konfigurirana veličina tablice za glavno računalo).
Mjerili smo razliku u izvedbi između: bez mrežne politike; s redovitom Calico policom; i Calico pravilo o ne-praćenju.
Za prvi test postavili smo broj veza na 4.000 u sekundi, kako bismo se mogli usredotočiti na razliku u potrošnji CPU-a. Nije bilo značajnih razlika između pravila bez pravila i uobičajenih pravila, ali ne prati povećanu potrošnju CPU-a za oko 20%:
U drugom testu pokrenuli smo onoliko veza koliko su naši klijenti mogli generirati i izmjerili maksimalni broj veza u sekundi koje naš memcached poslužitelj može obraditi. Kao što se i očekivalo, slučajevi "bez pravila" i "uobičajena pravila" dosegnuli su ograničenje praćenja od preko 4,000 veza u sekundi (512k / 120s = 4,369 veza/s). Uz politiku ne-praćenja, naši su klijenti 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 ti brojevi već dovoljni da ilustriraju poantu ovog članka!
Zaključak
Conntrack je važna značajka kernela. Savršeno radi svoj posao. Često ga koriste ključne komponente sustava. Međutim, u nekim specifičnim scenarijima, zagušenje zbog conntrack-a nadmašuje normalne prednosti koje pruža. U ovom scenariju, Calico mrežna pravila mogu se 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!
Također pročitajte ostale članke na našem blogu:
Izvor: www.habr.com