Адсочванне злучэнняў ("conntrack") з'яўляецца асноўнай функцыяй сеткавага стэка ядра Linux. Яна дазваляе ядру адсочваць усе лагічныя сеткавыя злучэнні ці струмені і тым самым ідэнтыфікаваць усе пакеты, якія складаюць кожны струмень, каб іх можна было паслядоўна апрацоўваць разам.
Conntrack - гэта важная функцыя ядра, якая выкарыстоўваецца ў некаторых асноўных выпадках:
- NAT абапіраецца на інфармацыю ад сonntrack, таму ён можа аднолькава апрацоўваць усе пакеты з аднаго патоку. Напрыклад, калі pod звяртаецца да service Kubernetes, балансавальнік нагрузкі kube-proxy выкарыстоўвае NAT для накіравання трафіку на канкрэтны pod ўнутры кластара. Conntrack запісвае, што для вызначанага злучэння ўсе пакеты да IP service павінны адпраўляцца ў адзін і той жа pod, і што пакеты, якія вяртаюцца pod'ом бэкенда, павінны быць накіраваны NAT-ом зваротна ў pod з якога прыйшоў запыт.
- Firewall'ы з адсочваннем стану, такія як Calico, абапіраюцца на інфармацыю ад сonntrack, каб дадаваць "зваротны" трафік у белы спіс. Гэта дазваляе вам напісаць сеткавую палітыку, якая кажа: "дазволіць майму pod'у падлучацца да любога выдаленага IP-адрасу" без неабходнасці пісаць палітыку для відавочнага дазволу зваротнага трафіку. (Без гэтага вам давялося б дадаць значна менш бяспечнае правіла "дазваляць пакеты ў мой pod з любога IP".)
Акрамя таго, conntrack звычайна падвышае прадукцыйнасць сістэмы (зніжаючы спажыванне працэсарнага часу і час затрымак пакетаў), паколькі толькі першы пакет у струмені
павінен прайсці поўную апрацоўку стэка сеткі, каб вызначыць, што з ім рабіць. Глядзіце пост «», каб убачыць прыклад таго, як гэта працуе.
Тым не менш, у 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, павялічвалі памеры табліц і скарачалі час адсочвання, але канфігурацыя была ненадзейнай, значна павялічылася спажыванне АЗП, што было праблемай (парадку ГБайтаў!), а злучэнні былі настолькі кароткімі што conntrack не ствараў свайго звычайнага выйгрышу ў прадукцыйнасці (памяншэнне ЦП або затрымак пакетаў).
У якасці альтэрнатывы яны звярнуліся да 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'om 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 працягвае быць вашым таварышам!
Таксама чытайце іншыя артыкулы ў нашым блогу:
Крыніца: habr.com