Ühenduse jälgimine ("conntrack") on Linuxi kerneli võrgupinu põhifunktsioon. See võimaldab kernelil jälgida kõiki loogilisi võrguühendusi või voogusid ja tuvastada seeläbi kõik paketid, mis moodustavad iga voo, et neid saaks järjestikku koos töödelda.
Conntrack on oluline kerneli funktsioon, mida kasutatakse mõnel põhijuhul:
- NAT tugineb conntracki teabele, et saaks käsitleda kõiki samast voost pärit pakette võrdselt. Näiteks kui kaust pääseb juurde Kubernetese teenusele, kasutab kube-puhverserveri koormuse tasakaalustaja NAT-i, et suunata liiklus klastrisse konkreetsesse podi. Conntrack registreerib, et antud ühenduse jaoks tuleb kõik IP-teenuse paketid saata samasse kausta ja et taustamooduli poolt tagastatud paketid tuleb NAT-ida tagasi podisse, kust päring tuli.
- Olekupõhised tulemüürid, nagu Calico, toetuvad teabele, mis pärineb ühendustrackist, et lisada liikluse valgesse nimekirja. See võimaldab teil kirjutada võrgupoliitika, mis ütleb: "Luba mu podil ühenduda mis tahes kaug-IP-aadressiga", ilma et peaksite kirjutama poliitikat, mis lubaks selgesõnaliselt vastuse liiklust. (Ilma selleta peaksite lisama palju vähem turvalise reegli "lubake pakette minu kausta mis tahes IP-st".)
Lisaks parandab conntrack tavaliselt süsteemi jõudlust (vähendades CPU tarbimist ja paketi latentsust), kuna voos on ainult esimene pakett
peab läbima kogu võrgupinu, et teha kindlaks, mida sellega teha. Vaata postitust "", et näha selle toimimise näidet.
Conntrackil on aga oma piirangud...
Niisiis, kus see kõik valesti läks?
Conntrack-tabelil on seadistatav maksimaalne suurus ja kui see saab täis, hakatakse ühendusi tavaliselt tagasi lükkama või katkestama. Tabelis on enamiku rakenduste liikluse haldamiseks piisavalt vaba ruumi ja see ei muutu kunagi probleemiks. Siiski on mõned stsenaariumid, mille puhul võiksite kaaluda conntrack-tabeli kasutamist.
- Kõige ilmsem juhtum on see, kui teie server käsitleb äärmiselt suurt hulka samaaegselt aktiivseid ühendusi. Näiteks kui teie conntrack-tabel on konfigureeritud 128 128 kirje jaoks, kuid teil on > XNUMX XNUMX samaaegseid ühendusi, tekib kindlasti probleem!
- Veidi vähem ilmne juhtum: kui teie server töötleb sekundis väga palju ühendusi. Isegi kui ühendused on lühiajalised, jätkab Linux nende jälgimist mõnda aega (vaikimisi 120 sekundit). Näiteks kui teie conntrack-tabel on konfigureeritud 128 1100 kirje jaoks ja proovite käsitleda 128 ühendust sekundis, siis need ületavad conntrack-tabeli suurust isegi siis, kui ühendused on väga lühiajalised (120k/1092s = XNUMX ühendust/ s).
Nendesse kategooriatesse kuuluvad mitut tüüpi rakendusi. Lisaks, kui teil on palju halbu tegijaid, võib teenuse keelamise (DOS) rünnaku osana kasutada oma serveri kontaktitabeli täitmist paljude pooleldi avatud ühendustega. Mõlemal juhul võib conntrack saada teie süsteemis piiravaks kitsaskohaks. Mõnel juhul võib teie vajaduste rahuldamiseks piisata conntrack-tabeli parameetrite kohandamisest – suurendades suurust või vähendades conntrack-i ajalõpusid (aga kui teete seda valesti, on teil palju probleeme). Muudel juhtudel on vaja agressiivse liikluse korral conntrackist mööda minna.
Tõeline näide
Toome konkreetse näite: ühel suurel SaaS-i pakkujal, kellega me koostööd tegime, oli hostidel (mitte virtuaalmasinatel) mitu vahemällu salvestatud servereid, millest igaüks töötles 50 XNUMX+ lühiajalist ühendust sekundis.
Nad katsetasid conntracki konfiguratsiooni, suurendades tabelite suurust ja vähendades jälgimisaega, kuid konfiguratsioon oli ebausaldusväärne, RAM-i tarbimine suurenes oluliselt, mis oli probleem (suurusjärgus GBbytes!) ja ühendused olid nii lühikesed, et conntrack ei toiminud. luua oma tavapärane jõudluskasu (väiksem tarbimine CPU või paketi latentsus).
Nad pöördusid alternatiivina Calico poole. Calico võrgueeskirjad võimaldavad teil teatud tüüpi liikluse jaoks conntracki mitte kasutada (kasutades poliitikavalikut doNotTracki). See andis neile vajaliku jõudluse ja Calico pakutava täiendava turvataseme.
Kui kaua peate läbima, et conntrackist mööda minna?
- Ära jälgi võrgupoliitikad peaksid üldiselt olema sümmeetrilised. SaaS-i pakkuja puhul: nende rakendused töötasid kaitstud tsoonis ja seetõttu said nad võrgupoliitikat kasutades lisada liikluse lubatud loendisse teistest konkreetsetest rakendustest, millel oli juurdepääs memcached'ile.
- Ära jälgi poliitika ei võta arvesse ühenduse suunda. Seega, kui vahemällu salvestatud server on häkitud, võite teoreetiliselt proovida ühendust luua mis tahes vahemällu salvestatud kliendiga, kui see kasutab õiget lähteporti. Kui aga olete oma vahemällu salvestatud klientide jaoks võrgupoliitika õigesti määratlenud, lükatakse need ühenduskatsed kliendi poolel siiski tagasi.
- Mittejälgimise poliitikat rakendatakse igale paketile, erinevalt tavalistest poliitikatest, mida rakendatakse ainult voo esimesele paketile. See võib suurendada protsessori tarbimist paketi kohta, kuna poliitikat tuleb rakendada iga paketi jaoks. Kuid lühiajaliste ühenduste puhul tasakaalustab seda kulutust ressursside tarbimise vähenemine ühenduse töötlemiseks. Näiteks SaaS-i pakkuja puhul oli pakettide arv iga ühenduse jaoks väga väike, seega oli igale paketile poliitikate rakendamisel lisaprotsessorikulu õigustatud.
Alustame testimisega
Teostasime testi ühes puhverserveris ja mitmes kaugsõlmedes töötava vahemällu salvestatud kliendipodi abil, et saaksime sekundis käivitada väga suure arvu ühendusi. Vahemällu salvestatud serverihoidikuga serveril oli 8 tuuma ja 512 XNUMX kirjet conntracki tabelis (hosti standardne konfigureeritud tabeli suurus).
Mõõtsime jõudluse erinevust järgmiste vahel: võrgupoliitika puudub; tavalise Calico poliitikaga; ja Calico mittejälgimise poliitika.
Esimese testi jaoks määrasime ühenduste arvuks 4.000 sekundis, et saaksime keskenduda protsessori tarbimise erinevusele. Poliitika puudumise ja tavalise poliitika vahel ei olnud olulisi erinevusi, kuid ära jälgi suurenenud protsessori tarbimist umbes 20% võrra:
Teises testis käivitasime nii palju ühendusi, kui meie kliendid suutsid luua, ja mõõtsime maksimaalset ühenduste arvu sekundis, millega meie vahemällu salvestatud server hakkama sai. Ootuspäraselt saavutasid nii poliitika puudumise kui ka tavapoliitika juhtumid üle 4,000 ühenduse sekundis (512 120 / 4,369 s = 60,000 XNUMX ühendust/s). Ära jälgi poliitikaga saatsid meie kliendid probleemideta XNUMX XNUMX ühendust sekundis. Oleme kindlad, et saaksime seda arvu suurendada, lisades rohkem kliente, kuid leiame, et need arvud on juba piisavad, et illustreerida selle artikli mõtet!
Järeldus
Conntrack on oluline kerneli funktsioon. Ta teeb oma tööd suurepäraselt. Seda kasutavad sageli süsteemi peamised komponendid. Mõne konkreetse stsenaariumi korral kaalub kokkutõmbumisest tingitud ummikud siiski üles selle tavapärase kasu. Selle stsenaariumi korral saab Calico võrgupoliitikaid kasutada conntracki kasutamise valikuliseks keelamiseks, suurendades samal ajal võrgu turvalisust. Kogu muu liikluse jaoks on conntrack jätkuvalt teie sõber!
Loe ka teisi meie ajaveebi artikleid:
Allikas: www.habr.com