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

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

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

NAT разчита на информация от conntrack, така че може да обработва единкратно всички пакети от един поток. Например, когато pod се свързва със service Kubernetes, балансировчикът на натоварване kube-proxy използва NAT, за да насочи трафика към конкретен pod в кластера. Conntrack записва, че за определено съединение всички пакети към IP адрес на service трябва да се изпращат в един и същ pod, а пакетите, връщани от pod-a на backend, трябва да бъдат насочвани обратно към pod-а, от който е дошъл запитването.
Firewall-ове с проследяване на състоянието, като Calico, разчитат на информация от conntrack, за да добавят „отговорен“ трафик в белия списък. Това ви позволява да напишете мрежова политика, която казва: „Позволете на моят pod да се свързва с всеки отдалечен IP адрес“ без да е необходимо да пишете политика за явно разрешаване на отговорния трафик. (Без това, вие ще трябва да добавите значително по-малко безопасно правило „да разрешавате пакети в моя pod от всеки IP“.)

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

Въпреки това, conntrack има своите ограничения...

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

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

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

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

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

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

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

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

На какво ще се наложи да се прибегне, за да се заобиколи conntrack?

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

Да преминем към тестовете

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

За първия тест зададохме брой на свързванията до 4000 в секунда, така че можехме да се фокусираме върху разликата в потреблението на CPU. Не намерихме съществени различия между отсъствието на политика и стандартната политика, но do-not-track увеличи потреблението на CPU с около 20%.

Във втория тест стартирахме толкова свързвания, колкото можеха да генерират нашите клиенти, и измерихме максималното количество свързвания в секунда, което нашият memcached-сервер можеше да обработи. Както очаквахме, в случая на "без политики" и "стандартна политика" и двата достигнаха лимита на conntrack от над 4000 свързвания в секунда (512k / 120s = 4369 свързвания/с). С политиката do-not-track нашите клиенти изпращаха 60000 свързвания в секунда без никакви проблеми. Убедени сме, че можехме да увеличим това число, свързвайки повече клиенти, но смятаме, че тези цифри са достатъчни, за да илюстрират посланието на тази статия!

Заключение

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