ردیابی اتصال ("conntrack") یکی از ویژگی های اصلی پشته شبکه هسته لینوکس است. این به هسته اجازه می دهد تا تمام اتصالات یا جریان های شبکه منطقی را ردیابی کند و در نتیجه تمام بسته هایی را که هر جریان را تشکیل می دهند شناسایی کند تا بتوان آنها را به صورت متوالی با هم پردازش کرد.
Conntrack یک ویژگی مهم هسته است که در برخی موارد اساسی استفاده می شود:
- NAT به اطلاعات از conntrack متکی است بنابراین می تواند با تمام بسته های یک جریان به طور یکسان رفتار کند. به عنوان مثال، هنگامی که یک پاد به یک سرویس Kubernetes دسترسی پیدا می کند، متعادل کننده بار پراکسی kube از NAT برای هدایت ترافیک به یک پاد خاص در داخل خوشه استفاده می کند. Conntrack ثبت می کند که برای یک اتصال معین، تمام بسته های سرویس IP باید به همان pod ارسال شوند و بسته های بازگردانده شده توسط غلاف backend باید به غلافی که درخواست از آنجا آمده است NAT داده شوند.
- فایروال های حالت دار مانند Calico به اطلاعات مربوط به ترافیک "پاسخ" در لیست سفید تکیه می کنند. این به شما امکان می‌دهد یک خط‌مشی شبکه بنویسید که می‌گوید «به غلاف من اجازه داده شود به هر آدرس IP راه دور متصل شود» بدون نیاز به نوشتن خط‌مشی برای اجازه دادن به ترافیک پاسخ به صراحت. (بدون این، شما باید قانون بسیار کمتر ایمن "اجازه دادن بسته ها به غلاف من از هر IP" را اضافه کنید.)
علاوه بر این، conntrack معمولاً عملکرد سیستم را بهبود می بخشد (با کاهش مصرف CPU و تأخیر بسته ها) زیرا تنها اولین بسته در یک جریان است.
باید از کل پشته شبکه عبور کند تا مشخص شود با آن چه باید کرد. پست را ببینید"" برای دیدن نمونه ای از نحوه کار.
با این حال، contrack محدودیت های خود را دارد ...
پس کجا همه چیز اشتباه شد؟
جدول conntrack دارای حداکثر اندازه قابل تنظیم است و اگر پر شود، اتصالات معمولاً شروع به رد یا حذف می کنند. فضای خالی کافی در جدول برای مدیریت ترافیک اکثر برنامه ها وجود دارد و این هرگز مشکل ساز نخواهد شد. با این حال، چند سناریو وجود دارد که در آنها ممکن است بخواهید از جدول conntrack استفاده کنید:
- واضح ترین مورد این است که سرور شما تعداد بسیار زیادی اتصال فعال همزمان را مدیریت کند. به عنوان مثال، اگر جدول conntrack شما برای ورودی های 128k پیکربندی شده است، اما شما بیش از 128k اتصالات همزمان دارید، مطمئناً با مشکل مواجه خواهید شد!
- یک مورد کمتر آشکار: اگر سرور شما تعداد بسیار زیادی اتصال در ثانیه را پردازش می کند. حتی اگر اتصالات کوتاه مدت باشند، برای مدتی (به طور پیش فرض 120 ثانیه) توسط لینوکس نظارت می شوند. به عنوان مثال، اگر جدول conntrack شما برای ورودی های 128k پیکربندی شده است و شما سعی می کنید 1100 اتصال در ثانیه را مدیریت کنید، اندازه آنها از جدول conntrack بیشتر خواهد شد، حتی اگر اتصالات بسیار کوتاه مدت باشند (128k/120s = 1092 اتصال/ s).
انواع مختلفی از برنامه ها وجود دارد که در این دسته بندی ها قرار می گیرند. علاوه بر این، اگر بازیگران بد زیادی دارید، پر کردن جدول کنتراک سرور خود با تعداد زیادی اتصال نیمه باز می تواند به عنوان بخشی از حمله انکار سرویس (DOS) استفاده شود. در هر دو مورد، conntrack می تواند به یک گلوگاه محدود کننده در سیستم شما تبدیل شود. در برخی موارد، تنظیم پارامترهای جدول conntrack ممکن است برای برآورده کردن نیازهای شما کافی باشد - با افزایش اندازه یا کاهش زمان های conntrack (اما اگر این کار را اشتباه انجام دهید، با مشکلات زیادی مواجه خواهید شد). برای موارد دیگر لازم است که برای ترافیک تهاجمی، از contrack عبور کنید.
مثال واقعی
بیایید یک مثال خاص ارائه دهیم: یکی از ارائه دهندگان بزرگ SaaS که با آن کار کردیم، تعدادی سرور حافظه پنهان روی هاست ها (نه ماشین های مجازی) داشت که هر کدام 50 هزار اتصال کوتاه مدت در ثانیه پردازش می کردند.
آنها با پیکربندی conntrack آزمایش کردند، اندازه جدول را افزایش دادند و زمان ردیابی را کاهش دادند، اما پیکربندی غیرقابل اعتماد بود، مصرف RAM به طور قابل توجهی افزایش یافت که یک مشکل بود (به ترتیب گیگابایت!)، و اتصالات آنقدر کوتاه بودند که conntrack انجام نشد. مزیت عملکرد معمول خود را ایجاد کند (کاهش مصرف CPU یا تأخیر بسته).
آنها به عنوان جایگزین به Calico روی آوردند. خط مشی های شبکه Calico به شما این امکان را می دهد که از conntrack برای انواع خاصی از ترافیک استفاده نکنید (با استفاده از گزینه سیاست doNotTrack). این به آنها سطح عملکرد مورد نیاز، به علاوه سطح امنیتی اضافی ارائه شده توسط Calico را به آنها داد.
برای دور زدن conntrack چه مسیرهایی باید طی کنید؟
- خط‌مشی‌های شبکه ردیابی نشود معمولاً باید متقارن باشند. در مورد ارائه‌دهنده SaaS: برنامه‌های آنها در داخل منطقه محافظت شده اجرا می‌شد و بنابراین، با استفاده از خط‌مشی شبکه، می‌توانستند ترافیک سایر برنامه‌های خاص را که اجازه دسترسی به memcached را داشتند، در لیست سفید قرار دهند.
- خط مشی عدم پیگیری جهت اتصال را در نظر نمی گیرد. بنابراین، اگر سرور memcached هک شده باشد، می‌توانید از نظر تئوری سعی کنید به هر یک از کلاینت‌های memcached متصل شوید، تا زمانی که از پورت منبع صحیح استفاده کند. با این حال، اگر خط مشی شبکه را برای کلاینت های حافظه پنهان خود به درستی تعریف کرده باشید، این تلاش ها برای اتصال همچنان در سمت سرویس گیرنده رد می شوند.
- خط مشی do-not-track برای هر بسته اعمال می شود، برخلاف سیاست های معمولی که فقط برای اولین بسته در جریان اعمال می شود. این می تواند مصرف CPU را در هر بسته افزایش دهد زیرا این خط مشی باید برای هر بسته اعمال شود. اما برای اتصالات کوتاه مدت، این هزینه با کاهش مصرف منابع برای پردازش contrack متعادل می شود. به عنوان مثال، در مورد یک ارائه دهنده SaaS، تعداد بسته ها برای هر اتصال بسیار کم بود، بنابراین مصرف اضافی CPU هنگام اعمال سیاست ها برای هر بسته توجیه می شد.
بیایید تست را شروع کنیم
ما آزمایش را روی یک پاد واحد با یک سرور memcached و چندین غلاف سرویس گیرنده memcached که روی گره‌های راه دور اجرا می‌شوند، اجرا کردیم تا بتوانیم تعداد بسیار زیادی اتصال در ثانیه را اجرا کنیم. سرور با غلاف سرور memcached دارای 8 هسته و 512 هزار ورودی در جدول conntrack (اندازه جدول پیکربندی استاندارد برای میزبان) بود.
ما تفاوت عملکرد بین: بدون سیاست شبکه; با خط مشی منظم Calico؛ و خط مشی ردیابی نکردن Calico.
برای آزمایش اول، تعداد اتصالات را روی 4.000 در ثانیه قرار دادیم، بنابراین می‌توانیم روی تفاوت مصرف CPU تمرکز کنیم. هیچ تفاوت قابل توجهی بین سیاست بدون خط مشی و خط مشی معمولی وجود نداشت، اما ردیابی نکردن مصرف CPU را حدود 20 درصد افزایش داد:
در آزمایش دوم، ما هر تعداد اتصال را که مشتریانمان می توانستند ایجاد کنند، راه اندازی کردیم و حداکثر تعداد اتصالاتی را که سرور memcached ما می توانست انجام دهد، اندازه گیری کردیم. همانطور که انتظار می رفت، موارد "بدون خط مشی" و "خط مشی منظم" هر دو به حد مجاز بیش از 4,000 اتصال در ثانیه رسیدند (512k / 120s = 4,369 اتصال در ثانیه). با سیاست عدم پیگیری، مشتریان ما 60,000 اتصال در ثانیه بدون هیچ مشکلی ارسال کردند. ما مطمئن هستیم که می‌توانیم این تعداد را با اضافه کردن مشتریان بیشتر افزایش دهیم، اما احساس می‌کنیم این اعداد از قبل برای نشان دادن نکته این مقاله کافی هستند!
نتیجه
Conntrack یک ویژگی مهم هسته است. او کارش را عالی انجام می دهد. اغلب توسط اجزای کلیدی سیستم استفاده می شود. با این حال، در برخی از سناریوهای خاص، ازدحام ناشی از کنتراک بیشتر از مزایای عادی آن است. در این سناریو، از سیاست های شبکه Calico می توان برای غیرفعال کردن انتخابی استفاده از conntrack و در عین حال افزایش امنیت شبکه استفاده کرد. برای تمام ترافیک های دیگر، conntrack همچنان دوست شماست!
همچنین سایر مقالات وبلاگ ما را بخوانید:
منبع: www.habr.com