Ryšio sekimas („conntrack“) yra pagrindinė „Linux“ branduolio tinklo dėklo funkcija. Tai leidžia branduoliui sekti visus loginius tinklo ryšius arba srautus ir taip identifikuoti visus paketus, sudarančius kiekvieną srautą, kad juos būtų galima apdoroti kartu nuosekliai.
Conntrack yra svarbi branduolio funkcija, kuri naudojama kai kuriais pagrindiniais atvejais:
- NAT remiasi informacija iš conntrack, todėl gali vienodai apdoroti visus paketus iš to paties srauto. Pavyzdžiui, kai grupė pasiekia Kubernetes paslaugą, kube tarpinio serverio apkrovos balansavimo priemonė naudoja NAT, kad nukreiptų srautą į konkrečią grupę klasterio viduje. Conntrack įrašo, kad tam tikram ryšiui visi IP paslaugos paketai turi būti siunčiami į tą patį bloką, o paketai, kuriuos grąžino užpakalinės programos, turi būti NAT grąžinti į podėlį, iš kurio buvo gauta užklausa.
- Būseną palaikančios ugniasienės, pvz., Calico, remiasi informacija iš prisijungimo takelio į baltojo sąrašo „atsakymo“ srautą. Tai leidžia jums parašyti tinklo politiką, kuri sako „leisti mano podeliui prisijungti prie bet kurio nuotolinio IP adreso“, nereikalaujant rašyti politikos, leidžiančios aiškiai leisti atsako srautą. (Be to turėtumėte pridėti daug mažiau saugią taisyklę „leisti paketus į mano bloką iš bet kurio IP“.)
Be to, conntrack paprastai pagerina sistemos našumą (sumažindama procesoriaus suvartojimą ir paketų delsą), nes sraute yra tik pirmasis paketas.
turi pereiti visą tinklo krūvą, kad nustatytų, ką su juo daryti. Žiūrėti įrašą "“ norėdami pamatyti pavyzdį, kaip tai veikia.
Tačiau conntrack turi savo apribojimus...
Tai kur viskas suklydo?
Conntrack lentelė turi konfigūruojamą maksimalų dydį, o jei ji užsipildo, ryšiai dažniausiai pradedami atmesti arba nutraukti. Lentelėje yra pakankamai laisvos vietos daugumos programų srautui apdoroti, ir tai niekada netaps problema. Tačiau yra keli scenarijai, pagal kuriuos galbūt norėsite naudoti conntrack lentelę:
- Akivaizdžiausias atvejis yra tada, kai jūsų serveris tvarko labai daug vienu metu veikiančių jungčių. Pavyzdžiui, jei jūsų conntrack lentelė sukonfigūruota 128 128 įrašų, bet turite > XNUMX XNUMX lygiagrečių ryšių, tikrai susidursite su problema!
- Šiek tiek mažiau akivaizdus atvejis: jei jūsų serveris apdoroja labai daug ryšių per sekundę. Net jei ryšiai yra trumpalaikiai, „Linux“ juos ir toliau stebi tam tikrą laiką (pagal nutylėjimą 120 s). Pavyzdžiui, jei jūsų prisijungimo lentelė sukonfigūruota 128 1100 įrašų ir bandote apdoroti 128 120 jungčių per sekundę, jie viršys conntrack lentelės dydį, net jei ryšiai bus labai trumpalaikiai (1092 XNUMX / XNUMX s = XNUMX XNUMX jungtys per sekundę ).
Yra keletas nišinių programų, kurios patenka į šias kategorijas. Be to, jei turite daug blogų veikėjų, serverio prisijungimo lentelės užpildymas daugybe pusiau atvirų jungčių gali būti naudojama kaip paslaugų atsisakymo (DOS) atakos dalis. Abiem atvejais conntrack gali tapti ribojančia sistemos kliūtimi. Kai kuriais atvejais gali pakakti koreguoti conntrack lentelės parametrus, kad atitiktų jūsų poreikius – padidinus dydį arba sumažinus conntrack skirtąjį laiką (tačiau jei tai padarysite neteisingai, susidursite su daugybe problemų). Kitais atvejais agresyviam eismui reikės aplenkti kontraktą.
Tikras pavyzdys
Pateiksime konkretų pavyzdį: vienas didelis SaaS teikėjas, su kuriuo dirbome, turėjo daugybę atmintyje išsaugotų serverių pagrindiniuose kompiuteriuose (ne virtualiose mašinose), kurių kiekvienas apdorodavo 50 tūkst.+ trumpalaikių jungčių per sekundę.
Jie eksperimentavo su conntrack konfigūracija, didindami lentelių dydį ir sumažindami sekimo laiką, tačiau konfigūracija buvo nepatikima, RAM suvartojimas žymiai padidėjo, o tai buvo problema (gigabaitų eilės!), o ryšiai buvo tokie trumpi, kad conntrack neveikė. sukurti savo įprastą našumo naudą (mažesnis procesoriaus ar paketo delsos suvartojimas).
Jie kreipėsi į Calico kaip alternatyvą. „Calico“ tinklo taisyklės leidžia nenaudoti „conntrack“ tam tikro tipo srautui (naudojant „doNotTrack“ politikos parinktį). Tai suteikė jiems reikalingą našumo lygį ir papildomą Calico teikiamą saugumo lygį.
Kokią atkarpą turėsite nueiti, kad apeitumėte conntrack?
- Tinklo nesekimo politika paprastai turėtų būti simetriška. „SaaS“ teikėjo atveju: jų programos veikė apsaugotoje zonoje, todėl naudodamos tinklo politiką jos galėjo įtraukti srautą iš kitų konkrečių programų, kurioms buvo leista prieiti prie atminties talpyklos.
- Taikant nesekimo politiką neatsižvelgiama į ryšio kryptį. Taigi, jei į atmintyje įrašytą serverį buvo įsilaužta, teoriškai galite bandyti prisijungti prie bet kurio atmintyje išsaugoto kliento, jei jis naudoja teisingą šaltinio prievadą. Tačiau jei teisingai apibrėžėte tinklo politiką savo atmintinėje išsaugotiems klientams, šie bandymai prisijungti vis tiek bus atmesti kliento pusėje.
- Nesekimo politika taikoma kiekvienam paketui, o ne įprastai strategijai, kuri taikoma tik pirmajam srauto paketui. Tai gali padidinti procesoriaus suvartojimą vienam paketui, nes politika turi būti taikoma kiekvienam paketui. Tačiau trumpalaikiams ryšiams šias išlaidas atsveria sumažėjęs resursų sunaudojimas ryšio apdorojimui. Pavyzdžiui, SaaS teikėjo atveju kiekvieno ryšio paketų skaičius buvo labai mažas, todėl papildomas procesoriaus sunaudojimas taikant politiką kiekvienam paketui buvo pagrįstas.
Pradėkime bandymus
Testą atlikome vienoje talpykloje su talpykloje išsaugotu serveriu ir keliomis atmintinėje saugomomis klientų grupėmis, veikiančiomis nuotoliniuose mazguose, kad galėtume paleisti labai daug jungčių per sekundę. Serveris su atmintyje išsaugotu serverio bloku turėjo 8 branduolius ir 512 XNUMX įrašų conntrack lentelėje (standartinis sukonfigūruotas pagrindinio kompiuterio lentelės dydis).
Išmatavome našumo skirtumą tarp: nėra tinklo politikos; su įprasta Calico politika; ir Calico nesekimo politika.
Pirmojo bandymo metu jungčių skaičių nustatėme iki 4.000 per sekundę, kad galėtume sutelkti dėmesį į procesoriaus suvartojimo skirtumą. Nebuvo jokių reikšmingų skirtumų tarp politikos nebuvimo ir įprastos politikos, bet nesekti padidėjusį procesoriaus suvartojimą maždaug 20 %:
Antrojo bandymo metu paleidome tiek jungčių, kiek galėjo sukurti mūsų klientai, ir išmatavome maksimalų jungčių skaičių per sekundę, kurį galėjo apdoroti atmintyje išsaugotas serveris. Kaip ir tikėtasi, „be politikos“ ir „įprastos politikos“ atvejai pasiekė daugiau nei 4,000 512 prisijungimų per sekundę ribą (120 4,369 / 60,000 s = XNUMX XNUMX prisijungimai per sekundę). Taikydami nesekimo politiką mūsų klientai be problemų išsiuntė XNUMX XNUMX prisijungimų per sekundę. Esame tikri, kad galėtume padidinti šį skaičių pridėję daugiau klientų, bet manome, kad šių skaičių jau pakanka, kad paaiškintume šio straipsnio esmę!
išvada
Conntrack yra svarbi branduolio funkcija. Jis puikiai atlieka savo darbą. Jį dažnai naudoja pagrindiniai sistemos komponentai. Tačiau kai kuriais konkrečiais scenarijais spūstys dėl susisiekimo nusveria įprastą jo teikiamą naudą. Pagal šį scenarijų Calico tinklo strategijas galima naudoti norint pasirinktinai išjungti conntrack naudojimą, tuo pačiu padidinant tinklo saugumą. Visam kitam srautui conntrack ir toliau yra jūsų draugas!
Taip pat skaitykite kitus mūsų tinklaraščio straipsnius:
Šaltinis: www.habr.com