Þegar Linux conntrack er ekki lengur vinur þinn

Þegar Linux conntrack er ekki lengur vinur þinn

Tengimæling („conntrack“) er kjarnaeiginleiki Linux kjarnanetsstafla. Það gerir kjarnanum kleift að halda utan um allar rökréttar nettengingar eða flæði og auðkenna þar með alla pakka sem mynda hvert flæði svo hægt sé að vinna þá saman í röð.

Conntrack er mikilvægur kjarnaeiginleiki sem er notaður í sumum grunntilfellum:

  • NAT byggir á upplýsingum frá conntrack svo það geti meðhöndlað alla pakka úr sama straumi jafnt. Til dæmis, þegar hlað hefur aðgang að Kubernetes þjónustu, notar kube-proxy hleðslujafnari NAT til að beina umferð að tilteknu hólf innan klasans. Conntrack skráir að fyrir tiltekna tengingu verða allir pakkar til IP þjónustunnar að vera sendir á sama pod og að pakkar sem bakenda pod skilar verða að vera NATed aftur í pod sem beiðnin kom frá.
  • Yfirlitslegir eldveggir eins og Calico treysta á upplýsingar frá tengibraut til „viðbragðs“ umferðar á hvítlista. Þetta gerir þér kleift að skrifa netstefnu sem segir "leyfðu podnum mínum að tengjast hvaða ytri IP tölu sem er" án þess að þurfa að skrifa stefnu til að leyfa beinlínis svarumferð. (Án þessa þyrftirðu að bæta við miklu óöruggari reglunni „leyfa pakka í pod minn frá hvaða IP sem er“.)

Að auki bætir conntrack venjulega afköst kerfisins (með því að draga úr örgjörvanotkun og pakkaleynd) þar sem aðeins fyrsti pakkinn í straumi
verður að fara í gegnum allan netstaflann til að ákvarða hvað á að gera við það. Sjá færsluna "Samanburður á kube-proxy stillingum“ til að sjá dæmi um hvernig það virkar.

Hins vegar hefur conntrack sínar takmarkanir...

Svo hvar fór allt úrskeiðis?

Conntrack taflan hefur stillanlega hámarksstærð og ef hún verður full byrja tengingar venjulega að hafna eða sleppa. Það er nóg pláss í töflunni til að takast á við umferð flestra forrita og þetta mun aldrei verða vandamál. Hins vegar eru nokkrar aðstæður þar sem þú gætir viljað íhuga að nota conntrack töfluna:

  • Augljósasta tilvikið er ef þjónninn þinn sér um mjög mikinn fjölda virkra samtímis tenginga. Til dæmis, ef conntrack taflan þín er stillt fyrir 128k færslur, en þú ert með >128k samhliða tengingar, muntu örugglega lenda í vandræðum!
  • Örlítið minna augljóst tilvik: ef þjónninn þinn vinnur mjög mikinn fjölda tenginga á sekúndu. Jafnvel þó að tengingarnar séu stuttar, þá er áfram fylgst með þeim af Linux í nokkurn tíma (120s sjálfgefið). Til dæmis, ef conntrack taflan þín er stillt fyrir 128k færslur og þú ert að reyna að höndla 1100 tengingar á sekúndu, munu þær fara yfir stærð conntrack töflunnar, jafnvel þótt tengingarnar séu mjög stuttar (128k/120s = 1092 tengingar/ s).

Það eru nokkrar sessgerðir af forritum sem falla í þessa flokka. Að auki, ef þú ert með marga slæma leikara, gæti það verið notað sem hluti af þjónustuneitunarárás (DOS) að fylla samtengingartöflu netþjónsins þíns með fullt af hálfopnum tengingum. Í báðum tilfellum getur conntrack orðið takmarkandi flöskuháls í kerfinu þínu. Í sumum tilfellum getur verið nóg að stilla færibreytur conntrack töflunnar til að mæta þörfum þínum - með því að auka stærðina eða draga úr tímamörkum conntrack (en ef þú gerir það rangt muntu lenda í miklum vandræðum). Í öðrum tilvikum verður nauðsynlegt að fara framhjá tengingu fyrir árásargjarn umferð.

Raunverulegt dæmi

Við skulum gefa sérstakt dæmi: einn stór SaaS-veita sem við unnum með var með fjölda minnismiðlara á vélum (ekki sýndarvélar), sem hver um sig vann 50K+ skammtímatengingar á sekúndu.

Þeir gerðu tilraunir með uppsetningu conntrack, stækkuðu töflustærðir og minnkuðu mælingartíma, en uppsetningin var óáreiðanleg, vinnsluminni neyslan jókst verulega, sem var vandamál (af stærðargráðunni GBytes!), og tengingarnar voru svo stuttar að conntrack gerði það ekki skapa venjulegan árangursávinning (minni neyslu CPU eða pakkaleynd).

Þeir sneru sér að Calico sem valkost. Calico netstefnur leyfa þér að nota ekki conntrack fyrir ákveðnar tegundir umferðar (með því að nota doNotTrack stefnumöguleikann). Þetta gaf þeim þá frammistöðu sem þeir þurftu, auk aukins öryggisstigs sem Calico veitti.

Hvaða lengd þarftu að fara í til að komast framhjá tengingu?

  • Reglur um að fylgjast ekki með netkerfi ættu almennt að vera samhverfar. Í tilviki SaaS-veitunnar: forritin þeirra keyrðu innan verndaðs svæðis og þess vegna, með netstefnu, gátu þau hvítlistað umferð frá öðrum sérstökum forritum sem fengu aðgang að memcached.
  • Ekki-fylgja stefnan tekur ekki mið af stefnu tengingarinnar. Þannig að ef brotist er inn á memcached þjóninn, geturðu fræðilega reynt að tengjast einhverjum af memcached viðskiptavinunum, svo framarlega sem hann notar rétta upprunatengi. Hins vegar, ef þú hefur rétt skilgreint netstefnuna fyrir memcached viðskiptavini þína, þá verður þessum tengingartilraunum samt hafnað á biðlarahlið.
  • Reglan um að rekja ekki er notuð á alla pakka, öfugt við venjulegar reglur, sem eru aðeins notaðar á fyrsta pakkann í flæði. Þetta getur aukið örgjörvanotkun á hvern pakka vegna þess að stefnan verður að vera notuð fyrir hvern pakka. En fyrir skammtímatengingar er þessi kostnaður jafnaður með lækkun á auðlindanotkun fyrir samtengingarvinnslu. Til dæmis, þegar um SaaS þjónustuaðila er að ræða, var fjöldi pakka fyrir hverja tengingu mjög lítill, þannig að viðbótar CPU neysla þegar reglum var beitt á hvern pakka var réttlætanleg.

Við skulum byrja að prófa

Við keyrðum prófið á einum pod með memcached miðlara og mörgum memcached client pods sem keyrðu á ytri hnútum þannig að við gætum keyrt mjög mikinn fjölda tenginga á sekúndu. Miðlarinn með memcached server pod var með 8 kjarna og 512k færslur í conntrack töflunni (venjuleg stillt töflustærð fyrir gestgjafann).
Við mældum frammistöðumuninn á milli: engin netstefna; með reglulegri Calico stefnu; og Calico ekki fylgja stefnu.

Fyrir fyrstu prófunina settum við fjölda tenginga á 4.000 á sekúndu, svo við gætum einbeitt okkur að muninum á örgjörvanotkun. Enginn marktækur munur var á milli engrar stefnu og reglulegrar stefnu, en ekki fylgjast með aukinni örgjörvanotkun um um 20%:

Þegar Linux conntrack er ekki lengur vinur þinn

Í seinni prófinu ræstum við eins margar tengingar og viðskiptavinir okkar gátu búið til og mældum hámarksfjölda tenginga á sekúndu sem memcached þjónninn okkar gæti séð um. Eins og búist var við náðu „engin stefna“ og „venjuleg stefna“ tilvikin bæði tengimörkum yfir 4,000 tengingar á sekúndu (512k / 120s = 4,369 tengingar/s). Með reglum um að fylgjast ekki með sendu viðskiptavinir okkar 60,000 tengingar á sekúndu án nokkurra vandræða. Við erum viss um að við gætum aukið þennan fjölda með því að bæta við fleiri viðskiptavinum, en okkur finnst þessar tölur nú þegar nægja til að sýna tilgang þessarar greinar!

Þegar Linux conntrack er ekki lengur vinur þinn

Ályktun

Conntrack er mikilvægur kjarnaeiginleiki. Hann skilar starfi sínu fullkomlega. Það er oft notað af lykilkerfishlutum. Hins vegar, í sumum sérstökum tilfellum, vegur þrengslin vegna tengingar þyngra en eðlilegur ávinningur sem það veitir. Í þessari atburðarás er hægt að nota Calico netstefnur til að slökkva á vali á notkun conntrack en auka netöryggi. Fyrir alla aðra umferð heldur conntrack áfram að vera vinur þinn!

Lestu einnig aðrar greinar á blogginu okkar:

Heimild: www.habr.com

Bæta við athugasemd