🥇Когато Linux conntrack вече не е ваш партньор

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

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

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

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

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

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

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

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

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

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

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

Те експериментираха с конфигурацията на conntrack, увеличаваха размерите на таблиците и намаляваха времето за проследяване, но конфигурацията беше ненадеждна, значително се увеличи консумацията на RAM, което беше проблем (порядъка на GB!), а връзките бяха толкова кратки, че 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 на memcached-сървъра имаше 8 ядра и 512k записа в conntrack таблицата (стандартно настроен размер на таблицата за хост).
Измервахме разликата в производителността между: без мрежова политика; с обикновена политика на Calico; и с политика на Calico do-not-track.

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

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

Заключение

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