يعد تتبع الاتصال ("conntrack") ميزة أساسية في حزمة شبكات Linux kernel. فهو يسمح للنواة بتتبع جميع اتصالات الشبكة المنطقية أو التدفقات وبالتالي تحديد جميع الحزم التي تشكل كل تدفق بحيث يمكن معالجتها معًا بشكل تسلسلي.
تعد Conntrack إحدى ميزات kernel المهمة التي يتم استخدامها في بعض الحالات الأساسية:
- يعتمد NAT على المعلومات الواردة من conntrack حتى يتمكن من التعامل مع جميع الحزم من نفس الدفق بالتساوي. على سبيل المثال، عندما تصل حجرة إلى خدمة Kubernetes، يستخدم موازن التحميل kube-proxy NAT لتوجيه حركة المرور إلى حجرة معينة داخل المجموعة. يسجل Conntrack أنه بالنسبة لاتصال معين، يجب إرسال جميع الحزم إلى خدمة IP إلى نفس الحاوية، ويجب أن يتم إعادة الحزم التي تم إرجاعها بواسطة حاوية الواجهة الخلفية إلى الحالة التي جاء منها الطلب.
- تعتمد جدران الحماية ذات الحالة الخاصة، مثل Calico، على المعلومات الواردة من مسار الاتصال إلى حركة مرور "الاستجابة" في القائمة البيضاء. يتيح لك هذا كتابة سياسة شبكة تقول "السماح لجهازي بالاتصال بأي عنوان IP بعيد" دون الحاجة إلى كتابة سياسة للسماح بشكل صريح بحركة الاستجابة. (بدون هذا، سيتعين عليك إضافة قاعدة "السماح بالحزم إلى حجرتي من أي IP" الأقل أمانًا.)
بالإضافة إلى ذلك، يعمل conntrack عادةً على تحسين أداء النظام (عن طريق تقليل استهلاك وحدة المعالجة المركزية وزمن وصول الحزمة) منذ الحزمة الأولى فقط في الدفق
يجب أن تمر عبر مكدس الشبكة بالكامل لتحديد ما يجب فعله به. شاهد المنشور ""لرؤية مثال على كيفية عمل ذلك.
ومع ذلك، conntrack له حدوده ...
إذن أين حدث كل هذا الخطأ؟
يحتوي جدول conntrack على الحد الأقصى للحجم القابل للتكوين، وإذا امتلأ، عادةً ما يتم رفض الاتصالات أو إسقاطها. توجد مساحة خالية كافية في الجدول للتعامل مع حركة مرور معظم التطبيقات، ولن يمثل هذا مشكلة أبدًا. ومع ذلك، هناك بعض السيناريوهات التي قد ترغب في التفكير في استخدام جدول conntrack فيها:
- الحالة الأكثر وضوحًا هي إذا كان الخادم الخاص بك يتعامل مع عدد كبير جدًا من الاتصالات النشطة المتزامنة. على سبيل المثال، إذا تم تكوين جدول conntrack الخاص بك لعدد 128 ألف إدخال، ولكن لديك أكثر من 128 ألف اتصال متزامن، فمن المؤكد أنك ستواجه مشكلة!
- حالة أقل وضوحًا: إذا كان خادمك يعالج عددًا كبيرًا جدًا من الاتصالات في الثانية. حتى لو كانت الاتصالات قصيرة العمر، فستستمر مراقبتها بواسطة Linux لفترة معينة من الوقت (120 ثانية افتراضيًا). على سبيل المثال، إذا تم تكوين جدول conntrack الخاص بك لإدخالات تبلغ 128 كيلو بايت وكنت تحاول التعامل مع 1100 اتصال في الثانية، فسوف تتجاوز حجم جدول conntrack، حتى إذا كانت الاتصالات قصيرة العمر للغاية (128 كيلو بايت/120 ثانية = 1092 اتصالاً/ س).
هناك عدة أنواع متخصصة من التطبيقات التي تندرج ضمن هذه الفئات. بالإضافة إلى ذلك، إذا كان لديك الكثير من العناصر السيئة، فقد يتم استخدام ملء جدول اتصال الخادم الخاص بك بالعديد من الاتصالات نصف المفتوحة كجزء من هجوم رفض الخدمة (DOS). في كلتا الحالتين، يمكن أن يصبح conntrack عنق الزجاجة المحدود في نظامك. في بعض الحالات، قد يكون ضبط معلمات جدول conntrack كافيًا لتلبية احتياجاتك - عن طريق زيادة الحجم أو تقليل مهلات conntrack (ولكن إذا قمت بذلك بشكل خاطئ، فسوف تواجه الكثير من المشاكل). وفي حالات أخرى، سيكون من الضروري تجاوز conntrack لحركة المرور العدوانية.
مثال حقيقي
لنعطي مثالًا محددًا: كان لدى أحد موفري SaaS الكبار الذين عملنا معهم عددًا من الخوادم المخزنة مؤقتًا على المضيفين (وليس الأجهزة الافتراضية)، كل منها يعالج أكثر من 50 ألف اتصال قصير المدى في الثانية.
لقد جربوا تكوين conntrack، وزيادة أحجام الجدول وتقليل وقت التتبع، لكن التكوين كان غير موثوق به، وزاد استهلاك ذاكرة الوصول العشوائي بشكل كبير، وهو ما كان يمثل مشكلة (حسب ترتيب الجيجابايت!)، وكانت الاتصالات قصيرة جدًا لدرجة أن conntrack لم يقم بذلك. إنشاء فائدة الأداء المعتادة (تقليل استهلاك وحدة المعالجة المركزية أو زمن وصول الحزمة).
كبديل، لجأوا إلى كاليكو. تسمح لك سياسات شبكة Calico بعدم استخدام conntrack لأنواع معينة من حركة المرور (باستخدام خيار سياسة doNotTrack). وقد منحهم هذا مستوى الأداء الذي يحتاجونه، بالإضافة إلى مستوى الأمان الإضافي الذي توفره شركة Calico.
ما هي الأطوال التي سيتعين عليك الذهاب إليها لتجاوز conntrack؟
- يجب أن تكون سياسات شبكة عدم التتبع متماثلة بشكل عام. في حالة موفر SaaS: تم تشغيل تطبيقاته داخل منطقة محمية، وبالتالي، باستخدام سياسة الشبكة، يمكنهم إدراج حركة المرور من تطبيقات محددة أخرى تم السماح لها بالوصول إلى memcached في القائمة البيضاء.
- لا تأخذ سياسة عدم التتبع في الاعتبار اتجاه الاتصال. وبالتالي، إذا تم اختراق خادم memcached، يمكنك نظريًا محاولة الاتصال بأي من عملاء memcached، طالما أنه يستخدم منفذ المصدر الصحيح. ومع ذلك، إذا قمت بتحديد سياسة الشبكة لعملاء memcached بشكل صحيح، فستظل محاولات الاتصال هذه مرفوضة من جانب العميل.
- يتم تطبيق سياسة عدم التتبع على كل حزمة، على عكس السياسات العادية، التي يتم تطبيقها فقط على الحزمة الأولى في التدفق. يمكن أن يؤدي هذا إلى زيادة استهلاك وحدة المعالجة المركزية لكل حزمة لأنه يجب تطبيق السياسة على كل حزمة. ولكن بالنسبة للاتصالات قصيرة العمر، تتم موازنة هذه النفقات من خلال تقليل استهلاك الموارد لمعالجة الاتصال. على سبيل المثال، في حالة موفر SaaS، كان عدد الحزم لكل اتصال صغيرًا جدًا، لذلك تم تبرير استهلاك وحدة المعالجة المركزية الإضافية عند تطبيق السياسات على كل حزمة.
لنبدأ الاختبار
لقد أجرينا الاختبار على حجرة واحدة مع خادم memcached والعديد من حجرات العميل المخزنة مؤقتًا التي تعمل على العقد البعيدة حتى نتمكن من تشغيل عدد كبير جدًا من الاتصالات في الثانية. يحتوي الخادم الذي يحتوي على حاوية خادم memcached على 8 مراكز و512 ألف إدخال في جدول conntrack (حجم الجدول القياسي الذي تم تكوينه للمضيف).
قمنا بقياس فرق الأداء بين: عدم وجود سياسة للشبكة؛ مع سياسة كاليكو العادية؛ وسياسة كاليكو لعدم التتبع.
بالنسبة للاختبار الأول، قمنا بتعيين عدد الاتصالات على 4.000 اتصال في الثانية، حتى نتمكن من التركيز على الفرق في استهلاك وحدة المعالجة المركزية. لم تكن هناك اختلافات كبيرة بين عدم وجود سياسة والسياسة العادية، ولكن لا تتبع زيادة استهلاك وحدة المعالجة المركزية بحوالي 20%:
في الاختبار الثاني، قمنا بإطلاق أكبر عدد ممكن من الاتصالات التي يمكن لعملائنا إنشاؤها وقياس الحد الأقصى لعدد الاتصالات في الثانية التي يمكن لخادم memcached التعامل معها. كما هو متوقع، وصلت كل من حالتي "لا توجد سياسة" و"السياسة العادية" إلى حد الاتصال الذي يزيد عن 4,000 اتصال في الثانية (512 كيلو / 120 ثانية = 4,369 اتصالاً/ثانية). مع سياسة عدم التتبع، أرسل عملاؤنا 60,000 اتصال في الثانية دون أي مشاكل. نحن على يقين من أنه يمكننا زيادة هذا العدد عن طريق إضافة المزيد من العملاء، ولكننا نشعر أن هذه الأرقام كافية بالفعل لتوضيح الهدف من هذه المقالة!
اختتام
Conntrack هي ميزة مهمة للنواة. يقوم بعمله على أكمل وجه. وغالبا ما يتم استخدامه من قبل مكونات النظام الرئيسية. ومع ذلك، في بعض السيناريوهات المحددة، يفوق الازدحام الناتج عن conntrack الفوائد العادية التي يوفرها. في هذا السيناريو، يمكن استخدام سياسات شبكة Calico لتعطيل استخدام conntrack بشكل انتقائي مع زيادة أمان الشبكة. بالنسبة لجميع حركة المرور الأخرى، يستمر conntrack في كونه صديقك!
اقرأ أيضًا مقالات أخرى على مدونتنا:
المصدر: www.habr.com