Urmărirea conexiunii („conntrack”) este o caracteristică de bază a stivei de rețea a nucleului Linux. Permite nucleului să țină evidența tuturor conexiunilor sau fluxurilor de rețea logice și, prin urmare, să identifice toate pachetele care alcătuiesc fiecare flux, astfel încât să poată fi procesate împreună secvenţial.
Conntrack este o caracteristică importantă a nucleului care este utilizată în unele cazuri de bază:
- NAT se bazează pe informațiile de la conntrack, astfel încât să poată trata toate pachetele din același flux în mod egal. De exemplu, atunci când un pod accesează un serviciu Kubernetes, echilibratorul de încărcare kube-proxy utilizează NAT pentru a direcționa traficul către un anumit pod din cluster. Conntrack înregistrează că, pentru o anumită conexiune, toate pachetele către serviciul IP trebuie trimise la același pod și că pachetele returnate de podul backend trebuie să fie NAT înapoi la podul de la care a venit cererea.
- Firewall-urile cu stat, cum ar fi Calico, se bazează pe informații de la connecttrack la traficul „răspuns” pe lista albă. Acest lucru vă permite să scrieți o politică de rețea care spune „permiteți podului meu să se conecteze la orice adresă IP de la distanță” fără a fi nevoie să scrieți o politică pentru a permite în mod explicit traficul de răspuns. (Fără aceasta, ar trebui să adăugați regula mult mai puțin sigură „permite pachete în podul meu de la orice IP”.)
În plus, conntrack îmbunătățește de obicei performanța sistemului (prin reducerea consumului CPU și a latenței pachetelor), deoarece doar primul pachet dintr-un flux
trebuie să treacă prin întreaga stivă de rețea pentru a determina ce să facă cu ea. Vezi postarea "" pentru a vedea un exemplu de cum funcționează.
Cu toate acestea, conttrack are limitările sale...
Deci unde a mers totul prost?
Tabelul conntrack are o dimensiune maximă configurabilă și, dacă se umple, conexiunile încep de obicei să fie respinse sau abandonate. Există suficient spațiu liber în tabel pentru a gestiona traficul majorității aplicațiilor, iar acest lucru nu va deveni niciodată o problemă. Cu toate acestea, există câteva scenarii în care ați putea dori să luați în considerare utilizarea tabelului conttrack:
- Cel mai evident caz este dacă serverul dumneavoastră gestionează un număr extrem de mare de conexiuni active simultan. De exemplu, dacă tabelul dvs. de conntrack este configurat pentru 128k intrări, dar aveți >128k conexiuni simultane, cu siguranță veți întâlni o problemă!
- Un caz puțin mai puțin evident: dacă serverul dumneavoastră procesează un număr foarte mare de conexiuni pe secundă. Chiar dacă conexiunile sunt de scurtă durată, acestea continuă să fie monitorizate de Linux pentru o anumită perioadă de timp (120 de secunde în mod implicit). De exemplu, dacă tabelul conntrack este configurat pentru 128k intrări și încercați să gestionați 1100 conexiuni pe secundă, acestea vor depăși dimensiunea tabelului conntrack, chiar dacă conexiunile sunt de foarte scurtă durată (128k/120s = 1092 conexiuni/ s).
Există mai multe tipuri de nișă de aplicații care se încadrează în aceste categorii. În plus, dacă aveți o mulțime de actori răi, completarea tabelului conntrack al serverului dvs. cu multe conexiuni pe jumătate deschise ar putea fi folosită ca parte a unui atac de refuz de serviciu (DOS). În ambele cazuri, conntrack poate deveni un blocaj limitativ în sistemul dumneavoastră. În unele cazuri, ajustarea parametrilor tabelului conntrack poate fi suficientă pentru a vă satisface nevoile - prin creșterea dimensiunii sau reducerea timpului de expirare a conntrack (dar dacă o faceți greșit, veți avea multe probleme). În alte cazuri, va fi necesar să ocoliți conntrack pentru trafic agresiv.
Exemplu real
Să dăm un exemplu specific: un furnizor SaaS mare cu care am lucrat avea un număr de servere memcache pe gazde (nu mașini virtuale), fiecare dintre ele procesând peste 50 conexiuni pe termen scurt pe secundă.
Au experimentat configurația conntrack, mărind dimensiunile tabelelor și reducând timpul de urmărire, dar configurația a fost nesigură, consumul de RAM a crescut semnificativ, ceea ce a fost o problemă (de ordinul GBytes!), iar conexiunile au fost atât de scurte încât conntrack nu a făcut-o. creați beneficiul său obișnuit de performanță (procesor cu consum redus sau latență de pachete).
Au apelat la Calico ca alternativă. Politicile de rețea Calico vă permit să nu utilizați conntrack pentru anumite tipuri de trafic (folosind opțiunea de politică doNotTrack). Acest lucru le-a oferit nivelul de performanță de care aveau nevoie, plus nivelul suplimentar de securitate oferit de Calico.
La ce lungimi va trebui să mergi pentru a ocoli conttrack?
- Politicile de rețea de nu urmărire ar trebui să fie, în general, simetrice. În cazul furnizorului SaaS: aplicațiile lor rulau într-o zonă protejată și, prin urmare, folosind politica de rețea, puteau lista albă traficul de la alte aplicații specifice cărora li sa permis accesul la memcached.
- Politica do-not-track nu ține cont de direcția conexiunii. Astfel, dacă serverul memcached este piratat, teoretic puteți încerca să vă conectați la oricare dintre clienții memcached, atâta timp cât folosește portul sursă corect. Cu toate acestea, dacă ați definit corect politica de rețea pentru clienții dvs. memcache, atunci aceste încercări de conectare vor fi în continuare respinse din partea clientului.
- Politica de nu urmărire este aplicată fiecărui pachet, spre deosebire de politicile normale, care sunt aplicate numai primului pachet dintr-un flux. Acest lucru poate crește consumul CPU per pachet, deoarece politica trebuie aplicată pentru fiecare pachet. Dar pentru conexiunile de scurtă durată, această cheltuială este echilibrată de reducerea consumului de resurse pentru procesarea conntrack. De exemplu, în cazul unui furnizor SaaS, numărul de pachete pentru fiecare conexiune a fost foarte mic, astfel încât consumul suplimentar de CPU la aplicarea politicilor fiecărui pachet era justificat.
Să începem testarea
Am rulat testul pe un singur pod cu un server memcached și mai multe pod-uri client memcache care rulează pe noduri la distanță, astfel încât să putem rula un număr foarte mare de conexiuni pe secundă. Serverul cu podul serverului memcached avea 8 nuclee și 512k intrări în tabelul conntrack (dimensiunea tabelului configurat standard pentru gazdă).
Am măsurat diferența de performanță între: fără politică de rețea; cu politica obișnuită Calico; și politica Calico de nu urmărire.
Pentru primul test, am setat numărul de conexiuni la 4.000 pe secundă, astfel încât să ne putem concentra pe diferența de consum al procesorului. Nu au existat diferențe semnificative între nicio politică și politica obișnuită, dar consumul de CPU a crescut cu aproximativ 20%:
În al doilea test, am lansat atâtea conexiuni câte au putut clienții noștri să genereze și am măsurat numărul maxim de conexiuni pe secundă pe care serverul nostru memcache le-ar putea gestiona. Așa cum era de așteptat, cazurile „fără politică” și „politică regulată” au atins ambele limita de conntrack de peste 4,000 de conexiuni pe secundă (512k / 120s = 4,369 conexiuni/s). Cu o politică de nu urmărire, clienții noștri au trimis fără probleme 60,000 de conexiuni pe secundă. Suntem siguri că am putea crește acest număr adăugând mai mulți clienți, dar credem că aceste cifre sunt deja suficiente pentru a ilustra ideea acestui articol!
Concluzie
Conntrack este o caracteristică importantă a nucleului. Își face treaba perfect. Este adesea folosit de componentele cheie ale sistemului. Cu toate acestea, în unele scenarii specifice, aglomerația datorată conntrack depășește beneficiile normale pe care le oferă. În acest scenariu, politicile de rețea Calico pot fi utilizate pentru a dezactiva selectiv utilizarea conttrack în timp ce crește securitatea rețelei. Pentru restul traficului, contrack continuă să fie prietenul tău!
Citiți și alte articole de pe blogul nostru:
Sursa: www.habr.com