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

Следењето конекција („conntrack“) е основна карактеристика на мрежниот оџак на кернелот Linux. Тоа му овозможува на кернелот да ги следи сите логички мрежни врски или текови и на тој начин да ги идентификува сите пакети што го сочинуваат секој проток, така што тие можат да се обработуваат заедно последователно.

Conntrack е важна карактеристика на кернелот што се користи во некои основни случаи:

NAT се потпира на информации од conntrack за да може подеднакво да ги третира сите пакети од истиот тек. На пример, кога pod пристапува до услугата Kubernetes, балансерот на оптоварување на kube-proxy користи NAT за да го насочи сообраќајот кон одредена подлога во кластерот. Conntrack евидентира дека за дадена врска, сите пакети до услугата IP мора да се испратат до истиот под, и дека пакетите вратени од подлогата за заднина мора да бидат NATE вратени назад во подлогата од која дојде барањето.
Заштитните ѕидови со стабилна состојба, како што е Calico, се потпираат на информации од сообраќајот за „одговор“ на конектираната патека до белата листа. Ова ви овозможува да напишете мрежна политика која вели „дозволи мојот pod да се поврзе со која било оддалечена IP адреса“ без да мора да пишувате политика за експлицитно да дозволите сообраќај за одговор. (Без ова, ќе треба да го додадете многу помалку безбедното правило „дозволи пакети во мојот pod од која било IP адреса“.)

Дополнително, conntrack обично ги подобрува перформансите на системот (со намалување на потрошувачката на процесорот и доцнењето на пакетите) бидејќи само првиот пакет во преносот
мора да помине низ целиот мрежен стек за да одреди што да прави со него. Погледнете ја објавата“Споредба на кубе-прокси режими“ за да видите пример за тоа како функционира ова.

Сепак, contrack има свои ограничувања...

Значи, каде сето тоа тргна наопаку?

Табелата за conntrack има максимална големина што може да се конфигурира и ако се наполни, врските обично почнуваат да се одбиваат или испуштаат. Има доволно слободен простор во табелата за да се справи со сообраќајот на повеќето апликации и тоа никогаш нема да стане проблем. Сепак, постојат неколку сценарија во кои можеби ќе сакате да размислите за користење на табелата за контрола:

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

Постојат неколку ниши типови на апликации кои спаѓаат во овие категории. Дополнително, ако имате многу лоши актери, пополнувањето на контролната табела на вашиот сервер со многу полуотворени врски може да се користи како дел од нападот за одбивање на услугата (DOS). Во двата случаи, conntrack може да стане ограничувачко тесно грло во вашиот систем. Во некои случаи, прилагодувањето на параметрите на табелата за контрола може да биде доволно за да се задоволат вашите потреби - со зголемување на големината или намалување на временските рокови за контрак (но ако го направите погрешно, ќе наидете на многу проблеми). За други случаи ќе биде неопходно да се заобиколи контролата за агресивен сообраќај.

Вистински пример

Да дадеме конкретен пример: еден голем SaaS провајдер со кој работевме имаше голем број мемкеширани сервери на хостови (не виртуелни машини), од кои секоја обработуваше 50K+ краткорочни врски во секунда.

Тие експериментираа со конфигурацијата на conntrack, зголемувајќи ја големината на табелите и намалувајќи го времето за следење, но конфигурацијата беше несигурна, потрошувачката на RAM меморија значително се зголеми, што беше проблем (по редослед на GBytes!), а врските беа толку кратки што conntrack не создадете ја неговата вообичаена придобивка за перформанси (намалена потрошувачка на процесорот или доцнењето на пакетите).

Тие се свртеа кон Калико како алтернатива. Мрежните политики на Calico ви дозволуваат да не користите conntrack за одредени видови сообраќај (користејќи ја опцијата за политика doNotTrack). Ова им го даде нивото на изведба што им беше потребно, плус дополнителното ниво на безбедност обезбедено од Calico.

На која должина ќе треба да одите за да ја заобиколите контролата?

Мрежните политики „Не следете“ генерално треба да бидат симетрични. Во случајот на давателот на SaaS: нивните апликации работеа во заштитената зона и затоа, користејќи мрежна политика, тие можеа да го стават во бела листа на сообраќај од други специфични апликации на кои им беше дозволен пристап до мемкешираните.
Политиката за да не се следи не ја зема предвид насоката на врската. Така, ако мемкешираниот сервер е хакиран, теоретски може да се обидете да се поврзете со кој било од мемкешираните клиенти, сè додека ја користи точната изворна порта. Меѓутоа, ако правилно сте ја дефинирале мрежната политика за вашите мемкеширани клиенти, тогаш овие обиди за поврзување сепак ќе бидат одбиени од страната на клиентот.
Политиката за да не се следи се применува на секој пакет, наспроти нормалните политики, кои се применуваат само на првиот пакет во протокот. Ова може да ја зголеми потрошувачката на процесорот по пакет бидејќи политиката мора да се примени за секој пакет. Но, за краткотрајните врски, овој трошок се балансира со намалувањето на потрошувачката на ресурси за обработка на контрак. На пример, во случај на провајдер на SaaS, бројот на пакети за секоја врска беше многу мал, така што дополнителната потрошувачка на процесорот при примена на политики за секој пакет беше оправдана.

Ајде да започнеме со тестирање

Тестот го извршивме на еден pod со мемкеширан сервер и повеќе мемкеширани клиентски подлоги кои работат на оддалечени јазли за да можеме да извршиме многу голем број врски во секунда. Серверот со мемкешираната серверска подлога имаше 8 јадра и 512 илјади записи во табелата за контрола (стандардна конфигурирана големина на табелата за домаќинот).
Ја измеривме разликата во перформансите помеѓу: нема мрежна политика; со редовна политика на Калико; и политиката на Calico да не се следи.

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

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

Заклучок

Conntrack е важна карактеристика на кернелот. Совршено си ја врши работата. Често се користи од клучните компоненти на системот. Меѓутоа, во некои специфични сценарија, метежот поради контролата ги надминува нормалните придобивки што ги обезбедува. Во ова сценарио, мрежните политики на Calico може да се користат за селективно оневозможување на употребата на contrack додека се зголемува безбедноста на мрежата. За целиот друг сообраќај, Conntrack продолжува да биде ваш пријател!

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

Извор: www.habr.com

Кога Linux contrack веќе не е ваш пријател