🛋️ 😎 🍨 قنصل + iptables =: 3 🥦 🕵🏻 👩🏽‍🎤

في عام 2010 ، كان لدى Wargaming 50 خادمًا ونموذج شبكة بسيط: الواجهة الخلفية والواجهة الأمامية وجدار الحماية. ازداد عدد الخوادم ، وأصبح النموذج أكثر تعقيدًا: شبكات VLAN المرحلية والمعزولة مع ACLs ، ثم شبكات VPN مع VRF ، VLANs مع ACLs إلى L2 ، VRFs من ACLs إلى L3. رأس الغزل؟ المزيد سيكون أكثر متعة.

عندما بدأت الخوادم في العمل 16000 بدون دموع مع العديد من الأجزاء غير المتجانسة ، أصبح من المستحيل. لذلك ، توصلوا إلى حل مختلف. أخذنا مجموعة Netfilter ، وأضفنا القنصل إليها كمصدر للبيانات ، وحصلنا على جدار حماية موزع بشكل سريع. استبدلوا ACL على الموجهات واستخدموا كجدار حماية خارجي وداخلي. لإدارة الأدوات الديناميكية ، قمنا بتطوير نظام BEFW ، الذي تم استخدامه في كل مكان: من التحكم في وصول المستخدم إلى شبكة البقالة إلى عزل أجزاء الشبكة عن بعضها البعض.

كيف يعمل كل هذا ولماذا يجب أن تلقي نظرة فاحصة على هذا النظام ، كما يقول إيفان أغاركوف (اضطراب) - رئيس مجموعة أمن البنية التحتية لوحدة الصيانة في مركز تطوير شركة مينسك. إيفان هو معجب في SELinux ، ويحب بيرل ، ويكتب الرمز. بصفته رئيسًا لمجموعة IB ، يعمل بانتظام مع السجلات والنسخ الاحتياطية والبحث والتطوير لحماية Wargaming من المتسللين وضمان تشغيل جميع خوادم الألعاب في الشركة.

مرجع التاريخ

قبل أن أقول كيف قمنا بذلك ، سأخبرك كيف توصلنا إلى هذا ولماذا كانت هناك حاجة إليه. للقيام بذلك ، نحن ننقل منذ 9 سنوات: 2010 ، ظهر فقط عالم الدبابات. كان لدى Wargaming حوالي 50 خادمًا.

الرسم البياني لنمو خوادم الشركة.

كان لدينا نموذج شبكة. لهذا الوقت كان مثاليا.

نموذج الشبكة في عام 2010.

في الواجهة الأمامية هناك أشخاص أشرار يريدون كسرنا ، ولكن هناك جدار حماية فيه. لا يوجد جدار حماية على الواجهة الخلفية ، ولكن هناك 50 خادمًا ، ونحن نعرفهم جميعًا. كل شيء يعمل بشكل جيد.

لمدة 4 سنوات ، نما أسطول الخادم 100 مرة ، حتى 5000. ظهرت أولى الشبكات المعزولة - المراحل: لا يمكنها الدخول في الإنتاج ، وغالبًا ما تدور الأشياء التي يمكن أن تكون خطرة هناك.

نموذج الشبكة في عام 2014.

باستخدام القصور الذاتي ، استخدمنا جميع قطع الحديد نفسها ، وتم تنفيذ جميع الأعمال على شبكات VLAN المعزولة: تتم كتابة ACLs إلى VLAN التي تسمح أو تمنع أي اتصال.

في عام 2016 ، بلغ عدد الخوادم 8000. استوعبت Wargaming استوديوهات أخرى ، ظهرت شبكات تابعة إضافية. يبدو أنها ملكنا ، ولكن ليس تمامًا: غالبًا لا تعمل VLAN للشركاء ، عليك استخدام VPN مع VRF ، يصبح العزل أكثر تعقيدًا. نما خليط من عزلات ACL.

نموذج الشبكة في عام 2016.

وبحلول عام 2018 ، نما أسطول السيارات إلى 16000. كان هناك 6 قطاعات ، ولم نحسب الباقي ، بما في ذلك الأجزاء المغلقة ، حيث تم تخزين البيانات المالية. هناك شبكات حاويات (Kubernetes) و DevOps والشبكات السحابية المتصلة عبر VPN ، على سبيل المثال ، من IVS. كان هناك الكثير من القواعد - يؤلم.

نموذج الشبكة وطرق العزل في 2018.

للعزل استخدمنا: VLAN مع ACL على L2 ، VRF مع ACL على L3 ، VPN وأكثر من ذلك بكثير. كثير جدا.

مشاكل

يعيش الجميع مع ACLs و VLANs. ما هو الخطأ بشكل عام؟ هارولد ، يخفي الألم ، سيجيب على هذا السؤال.

كانت هناك العديد من المشاكل ، ولكن كانت هناك خمس مشاكل ضخمة.

زيادات السعر الهندسي للقواعد الجديدة . تمت إضافة كل قاعدة جديدة لفترة أطول من القاعدة السابقة ، لأنه كان عليك أولاً معرفة ما إذا كانت هناك بالفعل قاعدة من هذا القبيل.
لا يوجد جدار حماية داخل الأجزاء . تم فصل الشرائح بطريقة أو بأخرى عن بعضها البعض ، ولا توجد بالفعل موارد كافية في الداخل.
تم تطبيق القواعد لفترة طويلة. تسليم مشغلي القاعدة المحلية يمكن أن يكتب في ساعة واحدة. استغرق العالمية عدة أيام.
صعوبات في تدقيق القواعد . بتعبير أدق ، لم يكن ذلك ممكناً. تمت كتابة القواعد الأولى في عام 2010 ، ولم يعد معظم مؤلفيها يعملون لدى الشركة.
مستوى منخفض من السيطرة على البنية التحتية . هذه هي المشكلة الرئيسية - لم نكن نعرف جيدًا ما الذي يحدث معنا.

هذا ما بدا عليه مهندس الشبكة في عام 2018 عندما سمع: "نحتاج إلى المزيد من قوائم ACL".

حلول

في بداية عام 2018 ، تقرر القيام بشيء حيال ذلك.

سعر التكامل في تزايد مستمر. كانت نقطة البداية هي أن مراكز البيانات الكبيرة لم تعد تدعم شبكات VLAN و ACL المعزولة ، لأن الذاكرة على الأجهزة نفدت.

الحل: إزالة العامل البشري وأتمتة توفير الوصول إلى الحد الأقصى.

تنطبق قواعد جديدة لفترة طويلة. الحل: تسريع تطبيق القواعد ، وجعلها موزعة ومتوازية. للقيام بذلك ، تحتاج إلى نظام موزع بحيث يتم تسليم القواعد من تلقاء نفسها ، دون rsync أو SFTP لكل ألف نظام.

عدم وجود جدار حماية داخل الأجزاء.بدأ جدار الحماية داخل الأجزاء بالتوجه إلينا عندما ظهرت خدمات مختلفة داخل نفس الشبكة. الحل: استخدم جدار حماية يستند إلى المضيف. تقريبا في كل مكان لدينا لينكس ، و iptables في كل مكان ، هذه ليست مشكلة.

صعوبات في تدقيق القواعد. الحل: احتفظ بجميع القواعد في مكان واحد للمراجعة والإدارة ، حتى نتمكن من تدقيق كل شيء.

مستوى منخفض من السيطرة على البنية التحتية. الحل: جرد جميع الخدمات والوصول بينها.

هذه عملية إدارية أكثر من كونها عملية فنية. في بعض الأحيان يكون لدينا 200-300 إصدار جديد في الأسبوع ، خاصةً خلال العروض الترويجية وفي أيام العطلات. ومع ذلك ، هذا فقط لفريق واحد من DevOps. مع العديد من الإصدارات ، من المستحيل معرفة نوع المنافذ ، IP ، التكامل المطلوب. لذلك ، احتجنا إلى مديري خدمة مدربين تدريباً خاصاً والذين أجروا مقابلات مع الفرق: "ما هو موجود ولماذا رفعته؟"

بعد كل ما أطلقناه ، بدأ مهندس الشبكة في عام 2019 في الظهور بهذا الشكل.

قنصل

قررنا أن نضع كل شيء وجدناه بمساعدة مديري الخدمات في القنصل ومن هناك سنكتب قواعد iptables.

كيف قررنا القيام بذلك؟

نقوم بجمع جميع الخدمات والشبكات والمستخدمين.
دعونا نجعل قواعد iptables قائمة عليها.
التحكم الآلي.
...
الربح.

القنصل ليس API بعيد ، يمكنه العمل على كل عقدة والكتابة إلى iptables. يبقى فقط أن يأتي مع الضوابط التلقائية التي ستنظف الفائض ، وسيتم حل معظم المشاكل! سننهي الباقي في العملية.

لماذا القنصل؟

راسخ. في 2014-2015 ، استخدمناه كخلفية لـ Vault ، حيث نقوم بتخزين كلمات المرور.

لا تفقد البيانات . أثناء الاستخدام ، لم يفقد القنصل البيانات في أي حادث. هذا هو إضافة ضخمة لنظام إدارة جدار الحماية.

تسرع اتصالات P2P من انتشار التغيير . مع P2P ، تأتي جميع التغييرات بسرعة ، لا حاجة للانتظار لساعات.

مريحة REST API. لقد اعتبرنا أيضًا Apache ZooKeeper ، ولكن ليس لديه REST API ، سيكون عليك وضع العكازات.

يعمل كمخزن مفاتيح (KV) ، ودليل (اكتشاف الخدمة) . يمكنك تخزين الخدمات والكتالوجات ومراكز البيانات على الفور. هذا ليس مناسبًا لنا فقط ، ولكن أيضًا للفرق المجاورة ، لأنه عند بناء خدمة عالمية ، نفكر بشكل كبير.

مكتوب في Go ، وهو جزء من مكدس Wargaming. نحن نحب هذه اللغة ، ولدينا العديد من مطوري Go.

نظام ACL قوي. في القنصل ، يمكنك استخدام قوائم ACL لإدارة من وماذا تكتب. نحن نضمن أن قواعد جدار الحماية لن تتداخل مع أي شيء آخر ولن تكون لدينا مشاكل في ذلك.

لكن القنصل له عيوبه.

لا يتم القياس داخل مركز البيانات ، إذا لم يكن لديك إصدار الأعمال. يتم تحجيمها فقط من قبل الاتحاد.
يعتمد بشكل كبير على جودة الشبكة وتحميل الخادم. لن يعمل القنصل بشكل طبيعي كخادم على خادم مشغول إذا كان هناك أي تأخيرات في الشبكة ، على سبيل المثال ، سرعة غير متساوية. ويرجع ذلك إلى اتصالات P2P وتحديث نماذج التوزيع.
صعوبات مع مراقبة إمكانية الوصول . في وضع القنصل يمكن القول أن كل شيء على ما يرام ، لكنه مات منذ فترة طويلة.

قمنا بحل معظم هذه المشاكل أثناء عمل القنصل ، لذلك اخترناها. لدى الشركة خطط لخلفية بديلة ، لكننا تعلمنا كيفية التعامل مع المشاكل وما زلنا نعيش مع القنصل.

كيف يعمل القنصل

في مركز البيانات الشرطية ، نقوم بتثبيت خوادم - من ثلاثة إلى خمسة. لن يعمل خادم أو خادمان: لن يتمكنوا من تنظيم النصاب القانوني وتحديد من هو على صواب ، ومن على خطأ ، عندما لا تتطابق البيانات. أكثر من خمسة لا معنى له ، سينخفض الأداء.

يتصل العملاء بأي ترتيب بالخوادم: نفس الوكلاء ، فقط بعلامة server = false.

بعد ذلك ، يتلقى العملاء قائمة باتصالات P2P وإنشاء اتصالات فيما بينهم.

على المستوى العالمي ، نحن نربط العديد من مراكز البيانات. كما أنها تربط P2P وتتواصل.

عندما نريد جمع البيانات من مركز بيانات آخر ، ينتقل الطلب من خادم إلى خادم. يسمى هذا المخطط بروتوكول Serf . تم تطوير بروتوكول Serf ، مثل القنصل ، من قبل HashiCorp.

بعض الحقائق الهامة عن القنصل

القنصل لديه وثائق تصف عمله. سأقدم فقط الحقائق المختارة التي تستحق المعرفة.

خوادم القنصل تختار الأساتذة من بين الناخبين . يحدد القنصل المعالج من قائمة الخوادم لكل مركز بيانات ، وتذهب جميع الطلبات إليه فقط ، بغض النظر عن عدد الخوادم. لا يؤدي تعليق المعالج إلى إعادة الانتخاب. إذا لم يتم تحديد المعالج ، فلن يتم تقديم الطلبات من قبل أي شخص.

هل تريد التحجيم الأفقي؟ آسف لكن لا.

ينتقل طلب إلى مركز بيانات آخر من رئيسي إلى رئيسي ، بغض النظر عن الخادم الذي وصل إليه. يتلقى السيد المحدد 100 ٪ من الحمل ، باستثناء الحمل على الطلبات المستقبلية. تحتوي جميع خوادم مركز البيانات على نسخة محدثة من البيانات ، ولكن هناك إجابة واحدة فقط.

الطريقة الوحيدة لتغيير الحجم هي تمكين الوضع الذي لا معنى له على العميل.

في الوضع القديم ، يمكنك الرد دون اكتمال النصاب. هذا وضع نرفض فيه تناسق البيانات ، لكننا نقرأ أسرع قليلاً من المعتاد ويستجيب أي خادم. وبطبيعة الحال ، يتم التسجيل فقط من خلال المعلم.

لا يقوم القنصل بنسخ البيانات بين مراكز البيانات . عند جمع الاتحاد ، سيكون لكل خادم البيانات الخاصة به فقط. بالنسبة للآخرين ، يتحول دائمًا إلى شخص آخر.

إن العمليات الذرية غير مضمونة خارج المعاملة . تذكر أنه ليس فقط يمكنك تغيير شيء ما. إذا كنت ترغب في ذلك بشكل مختلف ، قم بإجراء معاملة بقفل.

عمليات الحظر لا تضمن الحظر . ينتقل الطلب من رئيسي إلى رئيسي ، وليس بشكل مباشر ، لذلك ليس هناك ما يضمن أن القفل سيعمل عند القفل ، على سبيل المثال ، في مركز بيانات آخر.

لا تضمن قوائم التحكم في الوصول (ACL) الوصول أيضًا (في كثير من الحالات) . قد لا تعمل قائمة التحكم بالوصول (ACL) لأنها مخزنة في مركز بيانات واحد للاتحاد - في مركز بيانات قائمة التحكم بالوصول (DC الأساسي). إذا لم يجيب DC عليك ، فلن تعمل ACL.

سيعمل معالج تحويم على تجميد الاتحاد بالكامل . على سبيل المثال ، يوجد في الاتحاد 10 مراكز بيانات ، وفي واحد هناك شبكة سيئة ، وسقوط رئيسي واحد. كل من يتواصل معه عالق في دائرة: يتم تقديم طلب ، ولا توجد إجابة عليه ، ويعلق الخيط. لن يكون من الممكن معرفة متى سيحدث هذا ، فقط في ساعة أو ساعتين سوف يسقط الاتحاد بأكمله. لا يمكنك فعل أي شيء حيال ذلك.

تتم معالجة الحالة والنصاب القانوني والانتخابات في خيط منفصل. لن يتم إعادة التحديد ، ولن تظهر الحالة أي شيء. أنت تعتقد أن لديك قنصل حي ، تسأل ، ولا يحدث شيء - لا توجد إجابة. علاوة على ذلك ، تظهر الحالة أن كل شيء على ما يرام.

واجهنا هذه المشكلة ، كان علينا إعادة بناء أجزاء معينة من مراكز البيانات لتجنبها.

لا تحتوي نسخة الأعمال من Consul Enterprise على بعض العوائق أعلاه . لديها العديد من الوظائف المفيدة: التصويت والتوزيع والتحجيم. هناك "واحد فقط" واحد - نظام الترخيص لنظام موزع مكلف للغاية.

الإختراق مدى الحياة: rm -rf /var/lib/consul- علاج لجميع أمراض العامل. إذا لم ينجح شيء بالنسبة لك ، فما عليك سوى حذف بياناتك وتنزيل البيانات من النسخة. على الأرجح ، سوف يعمل القنصل.

Befw

الآن دعونا نتحدث عن ما أضفناه إلى القنصل.

BEFW - مختصر ل سرير و الكلية الاسترالية E الثانية وF غضب وW الإطلاق. كان من الضروري تسمية المنتج بطريقة أو بأخرى عندما قمت بإنشاء المستودع من أجل وضع تعهدات الاختبار الأولى فيه. يبقى هذا الاسم.

قوالب القواعد

القواعد مكتوبة في صيغة iptables.

-N BEFW
-P إسقاط الإدخال
-A INPUT -m state - حالة ذات صلة ، تم تأسيسها -ج قبول
-A INPUT -i lo -j ACCEPT
-A INPUT -j BEFW

نحن جميعا الذهاب الى سلسلة BEFW، باستثناء ESTABLISHED، RELATEDوالمضيف المحلي. القالب يمكن أن يكون أي شيء ، هذا مجرد مثال.

ما فائدة BEFW؟

خدمات

لدينا خدمة ، لديها دائما منفذ ، العقدة التي تعمل عليها. من عقدة لدينا ، يمكننا أن نسأل الوكيل محليًا ونكتشف أن لدينا نوعًا من الخدمة. يمكنك أيضًا وضع العلامات.

تتحول أي خدمة قيد التشغيل ومسجلة لدى القنصل إلى قاعدة iptables. لدينا SSH - منفذ مفتوح 22. نص bash بسيط: curl و iptables ، لا شيء آخر مطلوب.

الزبائن

كيفية فتح الوصول ليس للجميع ولكن بشكل انتقائي؟ باسم الخدمة ، أضف قوائم IP إلى مستودع KV.

على سبيل المثال ، نريد أن يتمكن الجميع من الشبكة العاشرة من الوصول إلى خدمة SSH_TCP_22. هل تريد إضافة حقل TTL صغير واحد؟ والآن لدينا أذونات مؤقتة ، على سبيل المثال ، ليوم واحد.

يصل

نحن نربط الخدمات والعملاء: لدينا خدمة لكل تخزين KV جاهز. الآن نعطي الوصول ليس للجميع ، ولكن بشكل انتقائي.

مجموعات

إذا قمنا في كل مرة بكتابة آلاف عناوين IP للوصول ، فسنتعب. دعونا نخرج مجموعات - مجموعة فرعية منفصلة في KV. سنطلق عليه الاسم المستعار (أو المجموعات) وسنقوم بتخزين المجموعات هناك وفقًا للمبدأ نفسه.

الاتصال: الآن يمكننا فتح SSH ليس بشكل خاص على P2P ، ولكن على مجموعة كاملة أو عدة مجموعات. وبالمثل ، هناك TTL - يمكنك الإضافة إلى المجموعة وإزالتها من المجموعة مؤقتًا.

دمج

مشكلتنا هي العامل البشري والأتمتة. حتى الآن قمنا بحلها بهذه الطريقة.

نحن نعمل مع Puppet ، وننقل كل ما يتعلق بالنظام (رمز التطبيق) إليه. يخزن Puppetdb (PostgreSQL العادي) قائمة بالخدمات التي تعمل هناك ، ويمكنك العثور عليها حسب نوع المورد. هناك يمكنك أن تجد من يذهب إلى أين. لدينا أيضًا طلب سحب ونظام طلب دمج لهذا.

لقد كتبنا befw-sync ، وهو أبسط حل يساعد على نقل البيانات. أولاً ، تذهب مزامنة ملفات تعريف الارتباط إلى puppetdb. تم تكوين HTTP API هناك: نسأل عن الخدمات التي نقدمها ، وما الذي يجب القيام به. ثم يقدمون طلبًا إلى القنصل.

هل هناك تكامل؟ نعم: لقد كتبوا القواعد وسمحوا بقبول طلب السحب. هل تحتاج إلى منفذ أو إضافة مضيف إلى مجموعة ما؟ سحب الطلب ، مراجعة - لا مزيد من "البحث عن 200 ACL أخرى ومحاولة القيام بشيء حيال ذلك."

الاقوي

يستغرق ping Localhost مع سلسلة قواعد فارغة 0.075 مللي ثانية.

أضف 10000 iptables لهذه السلسلة. ونتيجة لذلك ، ستزداد ping بمقدار 5 مرات: iptables خطي تمامًا ، ومعالجة كل عنوان تستغرق بعض الوقت.

بالنسبة للجدار الناري ، الذي نرحل فيه آلاف ACLs ، لدينا العديد من القواعد ، وهذا يؤدي إلى تأخير. بالنسبة لبروتوكولات الألعاب ، هذا أمر سيئ.

ولكن إذا وضعنا 10000 عنوان في ipset ، فسوف ينخفض.

النقطة هي أن "O" (تعقيد الخوارزمية) لـ ipset هو دائمًا 1 ، بغض النظر عن عدد القواعد الموجودة. صحيح ، هناك قيود - لا يمكن أن يكون هناك أكثر من 65535 قاعدة. في الوقت الحالي ، نحن نعيش مع هذا: يمكنك دمجها ، وتوسيعها ، وإنشاء مجموعتين في واحدة.

تخزين

الاستمرار المنطقي لعملية التكرار هو تخزين معلومات العملاء للخدمة في ipset.

الآن لدينا نفس SSH ، ولا نكتب 100 IP على الفور ، لكننا قمنا بتعيين اسم ipset للتواصل معه ، والقاعدة التالية DROP. يمكنك إعادة القاعدة "من ليس هنا ، هذا هو DROP" ، ولكن بشكل أكثر وضوحًا.

الآن لدينا قواعد ومجموعات. وتتمثل المهمة الرئيسية في إنشاء مجموعة قبل كتابة القاعدة ، لأن خلاف ذلك لن يكتب iptables القاعدة.

مخطط عام

في شكل رسم بياني ، كل ما قلته يبدو هكذا.

التزم بالدمى ، يتم إرسال كل شيء إلى المضيف ، الخدمات موجودة ، ipset موجود ، وأي شخص غير مسجل هناك غير مسموح به.

السماح والرفض

لإنقاذ العالم بسرعة أو إيقاف شخص ما بسرعة ، في بداية جميع السلاسل قمنا بعمل مجموعتين: rules_allowو rules_deny. كيف تعمل؟

على سبيل المثال ، يُنشئ شخص لديه برامج تتبُّع حملًا على الويب. في السابق ، كان من الضروري العثور على IP الخاص به من خلال السجلات ، وإحالته إلى مهندسي الشبكات حتى يتمكنوا من العثور على مصدر حركة المرور وحظره. الآن تبدو مختلفة.

نحن نشحن إلى القنصل ، ننتظر 2.5 ثانية ، والانتهاء من ذلك. نظرًا لأن القنصل يوزع بسرعة من خلال P2P ، فإنه يعمل في كل مكان وفي أي مكان في العالم.

بمجرد أن توقفت تمامًا عن WOT تمامًا ، ارتكبت خطأً بجدار الحماية. rules_allow- هذا هو تأميننا ضد مثل هذه الحالات. إذا أخطأنا بجدار الحماية في مكان ما ، فقد تم حظر شيء ما في مكان ما ، يمكننا دائمًا إرسال شرط مشروط 0.0/0لرفع كل شيء بسرعة. ثم سنقوم بإصلاح كل شيء بأيدينا.

مجموعات أخرى

يمكنك إضافة أي مجموعات أخرى في الفضاء $IPSETS$ .

لماذا؟ في بعض الأحيان يحتاج شخص ما إلى مجموعة ipset ، على سبيل المثال ، لمضاهاة قطع جزء من المجموعة. يمكن لأي شخص إحضار أي مجموعات ، الاتصال بها وسيتم أخذها من القنصل. في نفس الوقت ، يمكن للمجموعات المشاركة في قواعد iptables وأن تكون مثل فريق NOOP: سيتم دعم الاتساق من خلال البرنامج الخفي.

المستخدمون

كان الأمر على هذا النحو: مستخدم متصل بشبكة وتلقى المعلمات من خلال مجال. حتى الجيل التالي من جدران الحماية ، لم تتمكن Cisco من معرفة مكان المستخدم وأين عنوان IP. لذلك ، تم منح الوصول فقط من خلال أجهزة اسم المضيف.

ماذا فعلنا؟ مثبتة في وقت تلقي العنوان. عادة ما يكون dot1x أو Wi-Fi أو VPN - كل شيء يمر عبر RADIUS. لكل مستخدم ، أنشئ مجموعة حسب اسم المستخدم وضع عنوان IP به TTL ، وهو ما يعادل dhcp.lease - بمجرد انتهاء صلاحيته ، ستختفي القاعدة.

الآن يمكننا فتح الوصول إلى الخدمات ، وكذلك إلى مجموعات أخرى ، بواسطة اسم المستخدم. تخلصنا من الألم مع اسم المضيف عندما تغيروا ، وأخرجنا العبء من مهندسي الشبكة لأنهم لم يعودوا بحاجة إلى Cisco. الآن ، يصف المهندسون أنفسهم الوصول إلى خوادمهم.

عازلة

في موازاة ذلك ، بدأنا في تفكيك العزل. قام مديرو الخدمات بجرد ، وقمنا بتحليل جميع شبكاتنا. نحن نحللها في نفس المجموعات ، وعلى الخوادم الضرورية تمت إضافة المجموعات ، على سبيل المثال ، لرفضها. الآن نفس العزلة المرحلية تدخل في القواعد - الإنتاج في الإنتاج ، ولكن ليس في الإنتاج نفسه.

يعمل النظام بسرعة وببساطة: قم بإزالة جميع قوائم التحكم في الوصول من الخوادم وإلغاء تحميل الأجهزة وتقليل عدد شبكات VLAN المعزولة.

مراقبة النزاهة

في السابق ، كان يعمل مشغل خاص بالنسبة لنا ، والذي أبلغ عندما قام شخص ما بتغيير قاعدة جدار الحماية بأيديهم. لقد كتبت مدقق قواعد جدار حماية ضخم ، كان صعبًا. تتحكم النزاهة الآن في BEFW. يتأكد بحماسة أن القواعد التي يضعها لا تتغير. إذا قام شخص ما بتغيير قواعد جدار الحماية ، فسوف يعيد كل شيء. "لقد رفعت وكيلًا سريعًا هنا للعمل من المنزل" - لم يعد هناك مثل هذه الخيارات.

يتحكم BEFW في مجموعة الرموز من الخدمات والقائمة في befw.conf ، قواعد الخدمة في سلسلة BEFW. ولكن لا يتبع سلاسل وقواعد أخرى و ipset أخرى.

الحماية من الحوادث

يحفظ BEFW دائمًا آخر حالة ناجحة مباشرةً في البنية الثنائية لـ state.bin. إذا حدث خطأ ما ، فسيتم إرجاعه دائمًا إلى هذه الحالة. bin.

هذا هو تأمين القنصل غير المستقر عندما لم يرسل بيانات أو ارتكب شخص خطأ واستخدم قواعد لا يمكن تطبيقها. حتى لا نترك بدون جدار حماية ، ستعود BEFW إلى الحالة الأخيرة إذا حدث خطأ في مرحلة ما.

في المواقف الحرجة ، هذا ضمان بأننا سنبقى مع جدار حماية يعمل. نفتح جميع الشبكات الرمادية على أمل أن يأتي المشرف ويصلحها. في يوم من الأيام ، سأخرجها في التهيئة ، ولكن الآن لدينا فقط ثلاث شبكات رمادية: 10/8 و 172/12 و 192.168 / 16. كجزء من القنصل الخاص بنا ، هذه ميزة مهمة تساعد على التطوير بشكل أكبر.

: - BEFW. . GitHub.

سأخبرك عن الأخطاء التي واجهناها.

إضافة مجموعة ipset 0.0.0.0/0. ماذا يحدث إذا أضفت إلى ipset 0.0.0.0/0؟ هل ستتم إضافة جميع عناوين IP؟ هل سيتم فتح الوصول إلى الإنترنت؟

لا ، نحصل على خطأ يكلفنا ساعتين من التوقف. علاوة على ذلك ، لم يعمل الخطأ منذ عام 2016 ، فهو يقع في RedHat Bugzilla تحت الرقم # 1297092 ، لكننا وجدناه عن طريق الصدفة - من تقرير المطور.

الآن BEFW لديه قاعدة صارمة ، والتي 0.0.0.0/0تتحول إلى عنوانين: 0.0.0.0/1و 128.0.0.0/1.

مجموعة استعادة ipset <ملف. ماذا تفعل ipset عندما تقول ذلك restore؟ هل تعتقد أنها تعمل مثل iptables؟ هل تريد استعادة البيانات؟

لا شيء من هذا القبيل - يقوم بدمج ، ولا تختفي العناوين القديمة ، ولا تغلق الوصول.

وجدنا خطأ عندما اختبرنا العزلة. الآن هناك نظام معقد إلى حد ما - بدلاً من restoreتنفيذه create temp، ثم restore flush tempو restore temp. في نهاية المبادلة: للذرية ، لأنه إذا نفذت لأول مرة flushوفي تلك اللحظة وصلت بعض الحزمة ، سيتم تجاهلها وسيحدث خطأ ما. لذلك ، هناك القليل من السحر الأسود.

consul kv get -datacenter = أخرى. كما قلت ، نعتقد أننا نطلب بعض البيانات ، لكننا سنحصل على بيانات أو خطأ. يمكننا القيام بذلك من خلال القنصل محليًا ، ولكن في هذه الحالة سيتوقف أحدهما والآخر.

عميل القنصل المحلي هو مجمّع فوق HTTP API. لكنها معلقة فقط ولا تجيب على Ctrl + C أو Ctrl + Z ، مهما كانت ، فقطkill -9في وحدة التحكم المجاورة. لقد صادفنا هذا عندما كنا نبني مجموعة كبيرة. لكن لا يوجد لدينا حل حتى الآن ، نحن نستعد لتصحيح هذا الخطأ في القنصل.

زعيم القنصل لا يستجيب. لا يستجيب سيدنا في مركز البيانات ، نعتقد: "ربما ، ستعمل خوارزمية إعادة الاختيار الآن؟"

لا ، لن يعمل ، ولن تظهر المراقبة أي شيء: سيقول القنصل أن هناك مؤشر التزام ، وقد تم العثور على قائد ، وكل شيء على ما يرام.

كيف نحارب هذا؟ service consul restartفي كرون كل ساعة. إذا كان لديك 50 خادمًا - فلا توجد مشكلة. عندما يكون هناك 16000 ، سوف تفهم كيف يعمل.

استنتاج

ونتيجة لذلك ، حصلنا على المزايا التالية:

تغطية 100٪ لجميع أجهزة Linux.
سرعة.
التشغيل الآلي
مهندسو الحديد والشبكات المحررين من العبودية.
هناك فرص تكامل تكاد لا تنتهي: حتى مع Kubernetes ، حتى مع Ansible ، حتى مع Python.

السلبيات : القنصل ، الذي نعيش معه الآن ، وسعر خطأ مرتفع جدًا. كمثال ، مرة واحدة في الساعة 6 مساءً (وقت الذروة في روسيا) ، حكمت شيئًا ما على قوائم الشبكات. كنا نبني العزل في BEFW في ذلك الوقت. كنت مخطئا في مكان ما ، على ما يبدو ، أشرت إلى القناع الخطأ ، لكن كل شيء سقط في ثانيتين. المراقبة تضيء ، يأتي الضابط المناوب: "كل شيء يقع معنا!" تحول رئيس القسم إلى اللون الرمادي عندما شرح للأعمال لماذا حدث ذلك.

سعر الخطأ مرتفع جدًا لدرجة أننا توصلنا إلى إجراءات الوقاية المعقدة الخاصة بنا. إذا قمت بتطبيقه على إنتاج كبير ، فلن تحتاج إلى إعطاء رمز رئيسي على القنصل للجميع. ستنتهي بشدة.

كلفة.لقد كتبت الرمز لمدة 400 ساعة فقط. لدعم فريقي المكون من 4 أشخاص يقضي 10 ساعات في الشهر على الإطلاق. مقارنة بسعر أي جدار حماية من الجيل الجديد ، فهو مجاني.

الخطط. الخطة طويلة المدى هي البحث عن وسائل نقل بديلة مقابل القنصل أو بالإضافة إليه. ربما يكون كافكا أو شيء من هذا القبيل. ولكن في السنوات القادمة سنعيش في القنصل.

الخطط الفورية: التكامل مع Fail2ban ، مع المراقبة ، مع nftables ، ربما مع توزيعات أخرى ، المقاييس ، المراقبة المتقدمة ، التحسين. دعم Kubernetes موجود أيضًا في مكان ما في الخطط ، لأنه لدينا الآن العديد من المجموعات والرغبات.

آخر الخطط:

البحث عن الشذوذ المروري ؛
إدارة خريطة الشبكة ؛
دعم Kubernetes ؛
تجميع الحزم لجميع الأنظمة ؛
واجهة مستخدم الويب

نحن نعمل باستمرار على توسيع التكوين وزيادة المقاييس والتحسين.

انضم إلى المشروع. تبين أن المشروع رائع ، ولكن للأسف ، لا يزال هذا المشروع مشروعًا لشخص واحد. تعال إلى GitHub وحاول القيام بشيء: الالتزام ، الاختبار ، عرض شيء ما ، إعطاء تقييمك.

في هذه الأثناء ، نحن نستعد لـ Saint HighLoad ++ ، الذي سيعقد يومي 6 و 7 أبريل في سان بطرسبرغ ، وندعو مطوري الأنظمة عالية التحميل للتقدم بطلب للحصول على تقرير . يعرف المتحدثون ذوو الخبرة بالفعل ما يجب القيام به ، ونوصي بأن يحاول الوافدون الجدد على الخطابات على الأقل . المشاركة في المؤتمر كمتحدث لها مزايا عديدة. والتي يمكنك قراءتها ، على سبيل المثال ، في نهاية هذه المقالة .

قنصل + iptables =: 3