🥇Когато Linux conntrack вече не е ваш приятел

Проследяването на връзката („conntrack“) е основна характеристика на мрежовия стек на ядрото на Linux. Тя позволява на ядрото да следи всички логически мрежови връзки или потоци и по този начин да идентифицира всички пакети, които съставят всеки поток, така че да могат да бъдат обработени заедно последователно.

Conntrack е важна функция на ядрото, която се използва в някои основни случаи:

NAT разчита на информация от conntrack, така че да може да третира еднакво всички пакети от един и същ поток. Например, когато pod има достъп до услуга на Kubernetes, kube-proxy load balancer използва NAT, за да насочи трафик към конкретен pod в рамките на клъстера. Conntrack записва, че за дадена връзка всички пакети към IP услугата трябва да бъдат изпратени до един и същ pod и че пакетите, върнати от backend pod, трябва да бъдат NATed обратно към pod, от който е дошла заявката.
Защитните стени с контрол на състоянието, като Calico, разчитат на информация от connecttrack за трафик на „отговор“ в белия списък. Това ви позволява да напишете мрежова политика, която казва „разрешете на моя модул да се свърже с всеки отдалечен IP адрес“, без да се налага да пишете политика за изрично разрешаване на трафик на отговор. (Без това ще трябва да добавите много по-малко сигурното правило „разрешаване на пакети към моя под от всеки IP“.)

Освен това conntrack обикновено подобрява производителността на системата (чрез намаляване на потреблението на процесора и латентността на пакетите), тъй като само първият пакет в потока
трябва да премине през целия мрежов стек, за да определи какво да прави с него. Вижте публикацията "Сравнение на kube-прокси режими", за да видите пример как работи това.

Conntrack обаче има своите ограничения...

И така, къде се обърка всичко?

Таблицата conntrack има конфигурируем максимален размер и ако се напълни, връзките обикновено започват да се отхвърлят или прекъсват. В таблицата има достатъчно свободно място за обработка на трафика на повечето приложения и това никога няма да се превърне в проблем. Има обаче няколко сценария, в които може да искате да обмислите използването на таблицата conntrack:

Най-очевидният случай е, ако сървърът ви обработва изключително голям брой едновременно активни връзки. Например, ако вашата conntrack таблица е конфигурирана за 128k записа, но имате >128k едновременни връзки, със сигурност ще се натъкнете на проблем!
Малко по-малко очевиден случай: ако вашият сървър обработва много голям брой връзки в секунда. Дори ако връзките са краткотрайни, те продължават да се наблюдават от Linux за известен период от време (120s по подразбиране). Например, ако вашата таблица conntrack е конфигурирана за 128k записи и се опитвате да обработите 1100 връзки в секунда, те ще надвишат размера на таблицата conntrack, дори ако връзките са много краткотрайни (128k/120s = 1092 връзки/ с).

Има няколко нишови типа приложения, които попадат в тези категории. Освен това, ако имате много лоши участници, попълването на таблицата conntrack на вашия сървър с много полуотворени връзки може да се използва като част от атака за отказ на услуга (DOS). И в двата случая conntrack може да се превърне в ограничаващо тясно място във вашата система. В някои случаи коригирането на параметрите на таблицата conntrack може да е достатъчно, за да отговори на вашите нужди - чрез увеличаване на размера или намаляване на времето за изчакване на conntrack (но ако го направите погрешно, ще се натъкнете на много проблеми). За други случаи ще е необходимо да се заобиколи conntrack за агресивен трафик.

Реален пример

Нека дадем конкретен пример: един голям доставчик на SaaS, с който работихме, имаше няколко memcached сървъра на хостове (не виртуални машини), всеки от които обработваше 50K+ краткосрочни връзки в секунда.

Те експериментираха с конфигурацията conntrack, увеличавайки размерите на таблиците и намалявайки времето за проследяване, но конфигурацията беше ненадеждна, консумацията на RAM се увеличи значително, което беше проблем (от порядъка на GBytes!), а връзките бяха толкова къси, че conntrack не създаде обичайната си полза от производителността (намалена консумация на CPU или латентност на пакети).

Те се обърнаха към Calico като алтернатива. Мрежовите правила на Calico ви позволяват да не използвате conntrack за определени типове трафик (използвайки опцията на правилата doNotTrack). Това им даде нивото на производителност, от което се нуждаеха, плюс допълнителното ниво на сигурност, осигурено от Calico.

Какви дължини ще трябва да изминете, за да заобиколите conntrack?

Мрежовите политики за не-проследяване обикновено трябва да са симетрични. В случая на доставчика на SaaS: техните приложения работеха в защитената зона и следователно, използвайки мрежова политика, те можеха да поставят в белия списък трафика от други конкретни приложения, на които беше разрешен достъп до memcached.
Политиката за не-проследяване не взема предвид посоката на връзката. По този начин, ако memcached сървърът е хакнат, теоретично можете да опитате да се свържете с който и да е от memcached клиентите, стига да използва правилния изходен порт. Въпреки това, ако сте дефинирали правилно мрежовата политика за вашите memcached клиенти, тогава тези опити за свързване пак ще бъдат отхвърлени от страна на клиента.
Политиката за непроследяване се прилага към всеки пакет, за разлика от нормалните политики, които се прилагат само към първия пакет в потока. Това може да увеличи потреблението на процесора за пакет, тъй като политиката трябва да се прилага за всеки пакет. Но за краткотрайни връзки този разход се балансира от намаляването на потреблението на ресурси за обработка на conntrack. Например, в случай на SaaS доставчик, броят на пакетите за всяка връзка беше много малък, така че допълнителната консумация на процесор при прилагане на политики към всеки пакет беше оправдана.

Да започнем тестването

Проведохме теста на един pod с memcached сървър и множество memcached клиентски pods, работещи на отдалечени възли, така че да можем да изпълняваме много голям брой връзки в секунда. Сървърът с memcached server pod имаше 8 ядра и 512k записа в conntrack таблицата (стандартно конфигурирания размер на таблицата за хоста).
Измерихме разликата в производителността между: липса на мрежова политика; с редовна полица Calico; и политика за не-проследяване на Calico.

За първия тест зададохме броя на връзките на 4.000 в секунда, за да можем да се съсредоточим върху разликата в консумацията на процесора. Нямаше значителни разлики между липсата на политика и обикновената политика, но не-проследявайте увеличеното потребление на процесора с около 20%:

Във втория тест стартирахме толкова връзки, колкото нашите клиенти могат да генерират, и измерихме максималния брой връзки в секунда, които нашият memcached сървър може да обработи. Както се очакваше, случаите „без политика“ и „обикновена политика“ достигнаха лимита на conntrack от над 4,000 връзки в секунда (512k / 120s = 4,369 връзки/s). С политика без проследяване, нашите клиенти изпратиха 60,000 XNUMX връзки в секунда без никакви проблеми. Сигурни сме, че бихме могли да увеличим този брой, като добавим повече клиенти, но смятаме, че тези числа вече са достатъчни, за да илюстрират смисъла на тази статия!

Заключение

Conntrack е важна функция на ядрото. Той си върши работата перфектно. Често се използва от ключови системни компоненти. Въпреки това, в някои специфични сценарии, задръстванията, дължащи се на conntrack, превишават нормалните предимства, които предоставя. В този сценарий мрежовите политики на Calico могат да се използват за селективно деактивиране на използването на conntrack, като същевременно се повишава мрежовата сигурност. За целия останал трафик conntrack продължава да бъде ваш приятел!

Прочетете и други статии в нашия блог:

Източник: www.habr.com

Когато Linux conntrack вече не е ваш приятел