Ulanishni kuzatish (“conntrack”) Linux yadrosi tarmoq stekining asosiy xususiyati hisoblanadi. Bu yadroga barcha mantiqiy tarmoq ulanishlari yoki oqimlarini kuzatib borish va shu bilan har bir oqimni tashkil etuvchi barcha paketlarni aniqlab olish imkonini beradi, shunda ular ketma-ket qayta ishlanishi mumkin.
Conntrack ba'zi asosiy holatlarda ishlatiladigan muhim yadro xususiyatidir:
- NAT konntrack ma'lumotlariga tayanadi, shuning uchun u bir xil oqimdagi barcha paketlarni teng ko'rib chiqishi mumkin. Misol uchun, pod Kubernetes xizmatiga kirganda, kub-proksi yuk balanslagichi trafikni klaster ichidagi ma'lum bir podkaga yo'naltirish uchun NAT-dan foydalanadi. Conntrack ma'lum bir ulanish uchun IP xizmatiga barcha paketlar bir xil podga yuborilishi kerakligini va backend pod orqali qaytarilgan paketlar so'rov kelgan podkaga NATlangan bo'lishi kerakligini yozadi.
- Calico kabi statistik xavfsizlik devorlari ulanish yo'lidan oq ro'yxatdagi "javob" trafigiga qadar bo'lgan ma'lumotlarga tayanadi. Bu sizga javob trafigiga aniq ruxsat berish siyosatini yozmasdan turib "mening podkastim istalgan masofaviy IP manzilga ulanishiga ruxsat berish" degan tarmoq siyosatini yozish imkonini beradi. (Bunday bo'lmasa, siz xavfsizroq bo'lgan "har qanday IP-dan mening podkastimga paketlarga ruxsat berish" qoidasini qo'shishingiz kerak bo'ladi.)
Bundan tashqari, conntrack odatda tizim ish faoliyatini yaxshilaydi (protsessor sarfini va paketlarning kechikishini kamaytirish orqali), chunki oqimdagi faqat birinchi paket.
u bilan nima qilishni aniqlash uchun butun tarmoq stekidan o'tishi kerak. Xabarga qarang ""uning qanday ishlashiga misolni ko'rish uchun.
Biroq, conntrack o'z cheklovlariga ega ...
Xo'sh, hammasi qayerda noto'g'ri ketdi?
Conntrack jadvali sozlanishi mumkin bo'lgan maksimal o'lchamga ega va agar u to'la bo'lsa, ulanishlar odatda rad etila boshlaydi yoki o'chiriladi. Ko'pgina ilovalar trafigini boshqarish uchun jadvalda etarli bo'sh joy mavjud va bu hech qachon muammoga aylanmaydi. Biroq, ulanish jadvalidan foydalanishni ko'rib chiqishingiz mumkin bo'lgan bir nechta stsenariylar mavjud:
- Eng aniq holat, agar sizning serveringiz bir vaqtning o'zida juda ko'p sonli faol ulanishlarni ishlatsa. Misol uchun, agar sizning ulanish jadvalingiz 128k yozuvlar uchun sozlangan bo'lsa, lekin siz>128k bir vaqtda ulanishga ega bo'lsangiz, siz albatta muammoga duch kelasiz!
- Bir oz kamroq aniq holat: agar sizning serveringiz soniyada juda ko'p ulanishlarni qayta ishlasa. Ulanishlar qisqa muddatli bo'lsa ham, ular Linux tomonidan ma'lum vaqt davomida kuzatilishida davom etadi (sukut bo'yicha 120 soniya). Misol uchun, agar sizning ulanish jadvalingiz 128k yozuvlar uchun sozlangan bo'lsa va siz soniyasiga 1100 ta ulanishni boshqarishga harakat qilmoqchi bo'lsangiz, ulanishlar juda qisqa muddatli bo'lsa ham (128k/120s = 1092 ulanish/) ular ulanish jadvali hajmidan oshib ketadi. s).
Ushbu toifalarga kiruvchi bir nechta turdagi ilovalar mavjud. Bundan tashqari, agar sizda juda ko'p yomon aktyorlar bo'lsa, serveringizning ulanish jadvalini ko'plab yarim ochiq ulanishlar bilan to'ldirish xizmatni rad etish (DOS) hujumining bir qismi sifatida ishlatilishi mumkin. Ikkala holatda ham, ulanish tizimi tizimingizda cheklovchi darboğazga aylanishi mumkin. Ba'zi hollarda, ulanish jadvali parametrlarini sozlash sizning ehtiyojlaringizni qondirish uchun etarli bo'lishi mumkin - hajmini oshirish yoki ulanish vaqtini qisqartirish (lekin buni noto'g'ri qilsangiz, juda ko'p muammolarga duch kelasiz). Boshqa hollarda, tajovuzkor trafik uchun konntrackni chetlab o'tish kerak bo'ladi.
Haqiqiy misol
Aniq bir misol keltiraylik: biz ishlagan yirik SaaS provayderi hostlarda (virtual mashinalarda emas) bir qancha memkeshlangan serverlarga ega edi, ularning har biri soniyasiga 50K+ qisqa muddatli ulanishlarni qayta ishlagan.
Ular jadval o'lchamlarini oshirib, kuzatuv vaqtini qisqartirgan holda conntrack konfiguratsiyasi bilan tajriba o'tkazdilar, ammo konfiguratsiya ishonchsiz edi, operativ xotira iste'moli sezilarli darajada oshdi, bu muammo edi (Gbayt tartibida!) va ulanishlar shunchalik qisqa ediki, konntrack bajarilmadi. uning odatdagi ishlash foydasini yaratish (kamaytirilgan iste'mol CPU yoki paketli kechikish).
Ular muqobil sifatida Calicoga murojaat qilishdi. Calico tarmoq siyosatlari sizga ma'lum trafik turlari uchun (doNotTrack siyosati opsiyasi yordamida) conntrack-dan foydalanmaslikka imkon beradi. Bu ularga kerakli ishlash darajasini va Calico tomonidan taqdim etilgan qo'shimcha xavfsizlik darajasini berdi.
Bog'lanishni chetlab o'tish uchun qancha masofani bosib o'tishingiz kerak?
- Tarmoqni kuzatmaslik qoidalari odatda simmetrik bo'lishi kerak. SaaS provayderi misolida: ularning ilovalari himoyalangan zona ichida ishlaydi va shuning uchun tarmoq siyosatidan foydalanib, ular memcached-ga kirishga ruxsat berilgan boshqa maxsus ilovalardan trafikni oq ro'yxatga olishlari mumkin edi.
- Do-not-track siyosati ulanish yo'nalishini hisobga olmaydi. Shunday qilib, agar memkeshlangan server buzilgan bo'lsa, siz nazariy jihatdan memkeshlangan har qanday mijozga ulanishga harakat qilishingiz mumkin, agar u to'g'ri manba portidan foydalansa. Biroq, agar siz memcachlangan mijozlaringiz uchun tarmoq siyosatini to'g'ri belgilagan bo'lsangiz, u holda bu ulanish urinishlari mijoz tomonidan rad etiladi.
- Kuzatmaslik siyosati faqat oqimdagi birinchi paketga qo'llaniladigan oddiy siyosatlardan farqli o'laroq, har bir paketga qo'llaniladi. Bu har bir paket uchun protsessor sarfini oshirishi mumkin, chunki siyosat har bir paket uchun qo'llanilishi kerak. Ammo qisqa muddatli ulanishlar uchun bu xarajat aloqani qayta ishlash uchun resurslarni sarflashni kamaytirish bilan muvozanatlanadi. Misol uchun, SaaS provayderida har bir ulanish uchun paketlar soni juda kichik edi, shuning uchun har bir paketga siyosatni qo'llashda qo'shimcha CPU iste'moli oqlandi.
Sinovni boshlaylik
Biz sinovni memkeshlangan server va masofaviy tugunlarda ishlaydigan bir nechta memkeshli mijoz podkastlari bilan bitta podda o'tkazdik, shunda biz soniyada juda ko'p ulanishlarni amalga oshirishimiz mumkin edi. Memkeshlangan server podasi bo'lgan serverda 8 yadro va ulanish jadvalida 512 ming yozuv mavjud edi (xost uchun standart tuzilgan jadval o'lchami).
Biz ishlash farqini o'lchadik: tarmoq siyosati yo'q; muntazam Calico siyosati bilan; va Calico do-not-track siyosati.
Birinchi sinov uchun biz ulanishlar sonini soniyasiga 4.000 ga o'rnatdik, shuning uchun biz CPU iste'molidagi farqga e'tibor qaratishimiz mumkin. Hech qanday siyosat va oddiy siyosat o'rtasida sezilarli farqlar yo'q edi, lekin kuzatmang - protsessor sarfini taxminan 20% ga oshiring:
Ikkinchi sinovda biz mijozlarimiz yaratishi mumkin bo'lgan ko'plab ulanishlarni ishga tushirdik va memkeshlangan serverimiz bajara oladigan soniyada maksimal ulanishlar sonini o'lchadik. Kutilganidek, “siyosat yo‘q” va “muntazam siyosat” holatlari sekundiga 4,000 dan ortiq ulanish chegarasiga yetdi (512k/120s = 4,369 ulanish/s). Kuzatmang siyosati bilan mijozlarimiz soniyasiga 60,000 XNUMX ta ulanishni hech qanday muammosiz jo‘natishdi. Ishonchimiz komilki, koʻproq mijozlarni qoʻshish orqali bu sonni oshirishimiz mumkin, ammo bu raqamlar ushbu maqolaning mohiyatini tushuntirish uchun yetarli deb hisoblaymiz!
xulosa
Conntrack muhim yadro xususiyatidir. U o'z ishini mukammal bajaradi. U ko'pincha asosiy tizim komponentlari tomonidan qo'llaniladi. Biroq, ayrim o'ziga xos stsenariylarda, ulanish tufayli kelib chiqadigan tiqilinch u taqdim etadigan oddiy foydadan ustun turadi. Ushbu stsenariyda Calico tarmoq siyosati tarmoq xavfsizligini oshirishda ulanishdan foydalanishni tanlab o'chirish uchun ishlatilishi mumkin. Boshqa barcha trafik uchun conntrack sizning do'stingiz bo'lib qoladi!
Shuningdek, bizning blogimizdagi boshqa maqolalarni o'qing:
Manba: www.habr.com