🥇Када Линук цоннтрацк више није ваш пријатељ

Праћење везе („цоннтрацк“) је основна карактеристика мрежног стека Линук кернела. Омогућава кернелу да прати све логичке мрежне везе или токове и на тај начин идентификује све пакете који чине сваки ток тако да се могу обрадити заједно узастопно.

Цоннтрацк је важна карактеристика кернела која се користи у неким основним случајевима:

НАТ се ослања на информације из цоннтрацк-а тако да може једнако третирати све пакете из истог тока. На пример, када под приступи Кубернетес услузи, кубе-прокси балансатор оптерећења користи НАТ да усмери саобраћај на одређени под у оквиру кластера. Цоннтрацк бележи да за дату везу, сви пакети ИП сервису морају да буду послати у исти под, и да пакети које враћа бацкенд под морају бити НАТ враћени у модул из којег је стигао захтев.
Заштитни зидови са статусом, као што је Цалицо, ослањају се на информације од саобраћаја „одговора“ на повезивању до беле листе. Ово вам омогућава да напишете мрежну политику која каже „дозволи мојој подлози да се повеже са било којом удаљеном ИП адресом“ без потребе да пишете политику која ће експлицитно дозволити саобраћај одговора. (Без овога, морали бисте да додате много мање безбедно правило „дозволи пакете у мој под са било које ИП адресе“.)

Поред тога, цоннтрацк обично побољшава перформансе система (смањењем потрошње ЦПУ-а и кашњења пакета) јер само први пакет у стриму
мора проћи кроз цео мрежни стог да би одредио шта да ради са њим. Погледајте пост "Поређење кубе-прокси режима“ да видите пример како ово функционише.

Међутим, цоннтрацк има своја ограничења...

Па где је све пошло наопако?

Цоннтрацк табела има конфигурабилну максималну величину, а ако се напуни, везе обично почињу да се одбијају или прекидају. У табели има довољно слободног простора за руковање саобраћајем већине апликација и то никада неће постати проблем. Међутим, постоји неколико сценарија у којима бисте могли да размислите о коришћењу табеле цоннтрацк:

Најочигледнији случај је ако ваш сервер управља изузетно великим бројем истовремено активних веза. На пример, ако је ваша цоннтрацк табела конфигурисана за 128к уноса, али имате >128к истовремених веза, сигурно ћете наићи на проблем!
Мало мање очигледан случај: ако ваш сервер обрађује веома велики број веза у секунди. Чак и ако су везе краткотрајне, Линук их и даље надгледа неко време (подразумевано 120 секунди). На пример, ако је ваша цоннтрацк табела конфигурисана за 128к уноса и покушавате да обрађујете 1100 веза у секунди, оне ће премашити величину табеле цоннтрацк, чак и ако су везе веома кратког века (128к/120с = 1092 везе/ с).

Постоји неколико нишних типова апликација које спадају у ове категорије. Поред тога, ако имате много лоших актера, попуњавање табеле цоннтрацк вашег сервера са пуно полуотворених веза може се користити као део напада ускраћивања услуге (ДОС). У оба случаја, цоннтрацк може постати ограничавајуће уско грло у вашем систему. У неким случајевима, прилагођавање параметара табеле цоннтрацк може бити довољно да задовољи ваше потребе – повећањем величине или смањењем временског ограничења цоннтрацк (али ако то урадите погрешно, наићи ћете на много проблема). У другим случајевима биће неопходно заобићи коннтрацк за агресиван саобраћај.

Прави пример

Хајде да дамо конкретан пример: један велики СааС провајдер са којим смо радили имао је велики број сервера са мемкеширањем на хостовима (не виртуелним машинама), од којих је сваки обрађивао 50К+ краткорочних веза у секунди.

Експериментисали су са конфигурацијом цоннтрацк-а, повећавајући величину табеле и смањујући време праћења, али конфигурација је била непоуздана, потрошња РАМ-а се значајно повећала, што је представљало проблем (реда од ГБите-а!), а везе су биле толико кратке да цоннтрацк није створи своју уобичајену предност перформанси (смањена потрошња ЦПУ-а или кашњење пакета).

Окренули су се Калико као алтернативи. Мрежне политике Цалицо вам омогућавају да не користите цоннтрацк за одређене типове саобраћаја (користећи опцију политике доНотТрацк). Ово им је дало ниво перформанси који им је био потребан, плус додатни ниво сигурности који је обезбедио Цалицо.

На које дужине ћете морати да идете да бисте заобишли колосек?

Не-праћење мрежне политике генерално треба да буду симетричне. У случају СааС провајдера: њихове апликације су радиле унутар заштићене зоне и стога су, користећи мрежну политику, могли на белу листу саобраћаја из других специфичних апликација којима је био дозвољен приступ мемцацхед-у.
Политика не прати не узима у обзир правац везе. Стога, ако је мемцацхед сервер хакован, теоретски можете покушати да се повежете са било којим од мемцацхед клијената, све док користи исправан изворни порт. Међутим, ако сте исправно дефинисали мрежну политику за своје мемцацхед клијенте, онда ће ови покушаји повезивања и даље бити одбијени на страни клијента.
Политика не прати се примењује на сваки пакет, за разлику од нормалних смерница, које се примењују само на први пакет у току. Ово може повећати потрошњу ЦПУ-а по пакету јер се политика мора применити за сваки пакет. Али за краткотрајне везе, овај трошак је балансиран смањењем потрошње ресурса за обраду цоннтрацк-а. На пример, у случају СааС провајдера, број пакета за сваку везу је био веома мали, тако да је додатна потрошња ЦПУ-а при примени смерница на сваки пакет била оправдана.

Почнимо са тестирањем

Извршили смо тест на једном модулу са сервером мемкешираним и више мемкешираних клијентских модула који раде на удаљеним чворовима како бисмо могли да покренемо веома велики број веза у секунди. Сервер са мемцацхед серверском подршком је имао 8 језгара и 512к уноса у цоннтрацк табели (стандардна конфигурисана величина табеле за хост).
Измерили смо разлику у перформансама између: нема мрежне политике; са редовном политиком Калико; и Калико не прати политику.

За први тест смо поставили број конекција на 4.000 у секунди, како бисмо могли да се фокусирамо на разлику у потрошњи процесора. Није било значајних разлика између политике без политике и регуларне политике, али не пратите повећану потрошњу процесора за око 20%:

У другом тесту, покренули смо онолико конекција колико су наши клијенти могли да генеришу и измерили максималан број конекција у секунди који је наш мемкеш сервер могао да обради. Као што се и очекивало, случајеви „без политике“ и случајеви „редовне политике“ достигли су границу везе од преко 4,000 веза у секунди (512к / 120с = 4,369 веза/с). Уз политику „не прати“, наши клијенти су слали 60,000 веза у секунди без икаквих проблема. Сигурни смо да бисмо могли да повећамо овај број додавањем више клијената, али сматрамо да су ови бројеви већ довољни да илуструју поенту овог чланка!

Закључак

Цоннтрацк је важна карактеристика кернела. Свој посао ради савршено. Често га користе кључне компоненте система. Међутим, у неким специфичним сценаријима, загушење због цоннтрацк-а надмашује нормалне предности које пружа. У овом сценарију, Цалицо мрежне политике се могу користити за селективно онемогућавање коришћења цоннтрацк-а уз повећање безбедности мреже. За сав други саобраћај, цоннтрацк је и даље ваш пријатељ!

Прочитајте и друге чланке на нашем блогу:

Извор: ввв.хабр.цом

Када Линук цоннтрацк више није ваш пријатељ