في عام 2010 الشركة كان هناك 50 خادمًا ونموذج شبكة بسيط: الواجهة الخلفية والواجهة الأمامية وجدار الحماية. زاد عدد الخوادم، وأصبح النموذج أكثر تعقيدًا: التدريج، وشبكات VLAN المعزولة مع قوائم ACL، ثم شبكات VPN مع VRFs، وشبكات VLAN مع قوائم ACL على L2، وVRFs مع قوائم ACL على L3. الرأس يدور؟ وسوف يكون أكثر متعة في وقت لاحق.
عندما كان هناك 16 خادم، أصبح من المستحيل العمل بدون تمزق مع العديد من القطاعات غير المتجانسة. لذلك توصلنا إلى حل آخر. لقد أخذنا مكدس Netfilter، وأضفنا Consul إليه كمصدر بيانات، وحصلنا على جدار حماية سريع التوزيع. لقد استبدلوا قوائم ACL على أجهزة التوجيه واستخدموها كجدار حماية خارجي وداخلي. لإدارة الأداة ديناميكيًا، قمنا بتطوير نظام BEFW، والذي تم استخدامه في كل مكان: بدءًا من إدارة وصول المستخدم إلى شبكة المنتج وحتى عزل أجزاء الشبكة عن بعضها البعض.
سيخبرك كيف يعمل كل شيء ولماذا يجب عليك إلقاء نظرة فاحصة على هذا النظام. إيفان أجاركوف () - رئيس مجموعة أمن البنية التحتية بقسم الصيانة بمركز التطوير في مينسك التابع للشركة. إيفان من محبي SELinux، ويحب لغة Perl، ويكتب الأكواد البرمجية. بصفته رئيسًا لمجموعة أمن المعلومات، فهو يعمل بانتظام مع السجلات والنسخ الاحتياطية والبحث والتطوير لحماية Wargaming من المتسللين وضمان تشغيل جميع خوادم الألعاب في الشركة.
المعلومات التاريخية
قبل أن أخبرك كيف فعلنا ذلك، سأخبرك كيف وصلنا إلى هذا في المقام الأول ولماذا كانت هناك حاجة إليه. للقيام بذلك، دعونا نعود 9 سنوات إلى الوراء: عام 2010، ظهر عالم الدبابات للتو. كان لدى Wargaming ما يقرب من 50 خادمًا.
مخطط نمو خادم الشركة.
كان لدينا نموذج الشبكة. في ذلك الوقت كان الأمثل.
نموذج الشبكة في عام 2010.
هناك أشرار في الواجهة الأمامية يريدون كسرنا، لكن لديها جدار حماية. لا يوجد جدار حماية على الواجهة الخلفية، ولكن هناك 50 خادمًا، ونحن نعرفهم جميعًا. كل شيء يعمل بشكل جيد.
في 4 سنوات، نما أسطول الخوادم 100 مرة، ليصل إلى 5000. ظهرت الشبكات المعزولة الأولى - التدريج: لم يتمكنوا من الذهاب إلى الإنتاج، وغالبًا ما كانت هناك أشياء تعمل هناك والتي يمكن أن تكون خطيرة.
نموذج الشبكة في عام 2014.
بسبب القصور الذاتي، استخدمنا نفس قطع الأجهزة، وتم تنفيذ كل العمل على شبكات محلية ظاهرية معزولة: تتم كتابة قوائم ACL على شبكات VLAN، والتي تسمح أو ترفض نوعًا ما من الاتصال.
وفي عام 2016، وصل عدد الخوادم إلى 8000. واستوعبت شركة Wargaming استوديوهات أخرى، وظهرت شبكات تابعة إضافية. يبدو أنها ملكنا، ولكن ليس تمامًا: غالبًا ما لا تعمل شبكة VLAN مع الشركاء، ويجب عليك استخدام VPN مع VRF، ويصبح العزل أكثر تعقيدًا. نما خليط العزل ACL.
نموذج الشبكة في عام 2016.
ومع بداية عام 2018، ارتفع أسطول الآلات إلى 16 ألفاً، وكان هناك 000 شرائح، ولم نحسب الباقي، بما في ذلك المغلقة التي تم تخزين البيانات المالية فيها. ظهرت شبكات الحاويات (Kubernetes)، وDevOps، والشبكات السحابية المتصلة عبر VPN، على سبيل المثال، من IVS. كان هناك الكثير من القواعد - كان الأمر مؤلمًا.
نموذج الشبكة وطرق العزل في عام 2018.
للعزل استخدمنا: VLAN مع ACL على L2، VRF مع ACL على L3، VPN وأكثر من ذلك بكثير. أكثر مما ينبغي.
مشاكل
الجميع يعيش مع ACL وVLAN. ما هو الخطأ؟ هذا السؤال سوف يجيب عليه هارولد، ويخفي الألم.
كانت هناك مشاكل كثيرة، ولكن كانت هناك خمس مشاكل ضخمة.
- زيادة الأسعار الهندسية للقواعد الجديدة. استغرقت إضافة كل قاعدة جديدة وقتًا أطول من القاعدة السابقة، لأنه كان من الضروري أولاً معرفة ما إذا كانت هناك مثل هذه القاعدة بالفعل.
- لا يوجد جدار حماية داخل القطاعات. تم فصل الأجزاء بطريقة ما عن بعضها البعض، ولم تكن هناك موارد كافية بالداخل.
- تم تطبيق القواعد لفترة طويلة. يمكن للمشغلين كتابة قاعدة محلية واحدة يدويًا خلال ساعة. استغرق الأمر العالمي عدة أيام.
- صعوبات في قواعد التدقيق. بتعبير أدق، لم يكن ذلك ممكنا. تمت كتابة القواعد الأولى في عام 2010، ولم يعد معظم مؤلفيها يعملون في الشركة.
- انخفاض مستوى السيطرة على البنية التحتية. هذه هي المشكلة الرئيسية، فنحن لم نكن نعرف جيدًا ما الذي يحدث في بلدنا.
هذا ما بدا عليه مهندس الشبكات في عام 2018 عندما سمع: "بحاجة إلى مزيد من ACL".
حلول
في بداية عام 2018، تقرر القيام بشيء حيال ذلك.
سعر التكامل ينمو باستمرار. كانت نقطة البداية هي أن مراكز البيانات الكبيرة توقفت عن دعم شبكات VLAN وقوائم ACL المعزولة بسبب نفاد ذاكرة الأجهزة.
الحل: أزلنا العامل البشري وقمنا بأتمتة توفير الوصول إلى الحد الأقصى.
ويستغرق تطبيق القواعد الجديدة وقتا طويلا. الحل: تسريع تطبيق القواعد وجعلها موزعة ومتوازية. وهذا يتطلب نظامًا موزعًا بحيث يتم تسليم القواعد بنفسها، بدون rsync أو SFTP إلى ألف نظام.
لا يوجد جدار حماية داخل القطاعات. بدأ وصول جدار الحماية ضمن المقاطع إلينا عندما ظهرت خدمات مختلفة داخل نفس الشبكة. الحل: استخدم جدار الحماية على مستوى المضيف - جدران الحماية المستندة إلى المضيف. في كل مكان تقريبًا لدينا Linux، وفي كل مكان لدينا iptables، فهذه ليست مشكلة.
صعوبات في قواعد التدقيق. الحل: احتفظ بجميع القواعد في مكان واحد للمراجعة والإدارة، حتى نتمكن من تدقيق كل شيء.
انخفاض مستوى السيطرة على البنية التحتية. الحل: قم بجرد كافة الخدمات وإمكانية الوصول فيما بينها.
وهذه عملية إدارية أكثر منها تقنية. في بعض الأحيان يكون لدينا ما بين 200 إلى 300 إصدار جديد أسبوعيًا، خاصة أثناء العروض الترويجية والعطلات. علاوة على ذلك، هذا مخصص لفريق واحد فقط من DevOps لدينا. مع وجود العديد من الإصدارات، من المستحيل معرفة ما هي المنافذ وعناوين IP وعمليات التكامل المطلوبة. لذلك، كنا بحاجة إلى مديري خدمات مدربين تدريباً خاصاً الذين سألوا الفرق: "ما هو الموجود على أي حال ولماذا طرحتموه؟"
بعد كل ما أطلقناه، بدأ مهندس الشبكات في عام 2019 يبدو بهذا الشكل.
قنصل
قررنا أن نضع كل ما وجدناه بمساعدة مديري الخدمة في القنصل ومن هناك سنكتب قواعد iptables.
كيف قررنا أن نفعل هذا؟
- سنقوم بجمع كافة الخدمات والشبكات والمستخدمين.
- لنقم بإنشاء قواعد iptables بناءً عليها.
- نحن أتمتة التحكم.
- ....
- ربح.
Consul ليس واجهة برمجة تطبيقات بعيدة، ويمكن تشغيله على كل عقدة والكتابة إلى iptables. كل ما تبقى هو التوصل إلى أدوات تحكم تلقائية من شأنها تنظيف الأشياء غير الضرورية، وسيتم حل معظم المشاكل! سنعمل على الباقي بينما نمضي.
لماذا القنصل؟
لقد أثبتت نفسها بشكل جيد. في الفترة 2014-15، استخدمناه كواجهة خلفية لـ Vault، حيث نقوم بتخزين كلمات المرور.
لا يفقد البيانات. خلال فترة الاستخدام، لم يفقد القنصل أي بيانات خلال حادث واحد. هذه إضافة كبيرة لنظام إدارة جدار الحماية.
تعمل اتصالات P2P على تسريع انتشار التغيير. مع P2P، تأتي جميع التغييرات بسرعة، فلا داعي للانتظار لساعات.
واجهة برمجة تطبيقات REST مريحة. لقد أخذنا بعين الاعتبار أيضًا Apache ZooKeeper، لكنه لا يحتوي على REST API، لذا سيتعين عليك تثبيت العكازات.
يعمل بمثابة Key Vault (KV) ودليل (اكتشاف الخدمة). يمكنك تخزين الخدمات والكتالوجات ومراكز البيانات في وقت واحد. وهذا أمر مناسب ليس لنا فحسب، بل أيضًا للفرق المجاورة، لأننا عند بناء خدمة عالمية، نفكر بشكل كبير.
مكتوب بلغة Go، وهو جزء من حزمة Wargaming. نحن نحب هذه اللغة، ولدينا العديد من مطوري Go.
نظام ACL قوي. في Consul، يمكنك استخدام قوائم ACL للتحكم في من يكتب ماذا. نحن نضمن أن قواعد جدار الحماية لن تتداخل مع أي شيء آخر ولن نواجه مشاكل في ذلك.
ولكن القنصل أيضا له عيوبه.
- لا يمكن التوسع داخل مركز البيانات إلا إذا كان لديك إصدار أعمال. إنه قابل للتطوير فقط من خلال الاتحاد.
- يعتمد بشكل كبير على جودة تحميل الشبكة والخادم. لن يعمل Consul بشكل صحيح كخادم على خادم مشغول إذا كان هناك أي تأخير في الشبكة، على سبيل المثال، سرعة متفاوتة. ويرجع ذلك إلى اتصالات P2P ونماذج التوزيع المحدثة.
- صعوبة مراقبة التوفر. في وضع القنصل يمكنه أن يقول أن كل شيء على ما يرام، لكنه توفي منذ وقت طويل.
لقد قمنا بحل معظم هذه المشكلات أثناء استخدام Consul، ولهذا اخترناه. لدى الشركة خطط لواجهة خلفية بديلة، لكننا تعلمنا كيفية التعامل مع المشكلات ونعيش حاليًا مع Consul.
طريقة عمل القنصل
سنقوم بتثبيت ثلاثة إلى خمسة خوادم في مركز بيانات مشروط. لن يعمل خادم أو خادمان: لن يتمكنوا من تنظيم النصاب القانوني وتحديد من هو على حق ومن هو على خطأ عندما لا تتطابق البيانات. أكثر من خمسة لا معنى له، وسوف تنخفض الإنتاجية.
يتصل العملاء بالخوادم بأي ترتيب: نفس الوكلاء، فقط بالعلامة server = false.
بعد ذلك، يتلقى العملاء قائمة باتصالات P2P ويقومون ببناء اتصالات فيما بينهم.
على المستوى العالمي، نقوم بربط العديد من مراكز البيانات. يقومون أيضًا بتوصيل P2P والتواصل.
عندما نريد استرداد البيانات من مركز بيانات آخر، ينتقل الطلب من خادم إلى خادم. ويسمى هذا المخطط بروتوكول الأقنان. تم تطوير بروتوكول Serf، مثل Consul، بواسطة HashiCorp.
بعض الحقائق الهامة عن القنصل
القنصل لديه وثائق تصف كيفية عمله. سأقدم فقط الحقائق المختارة التي تستحق المعرفة.
يقوم خوادم القنصل باختيار سيد من بين الناخبين. يقوم القنصل باختيار سيد من قائمة الخوادم لكل مركز بيانات، وجميع الطلبات تذهب إليه فقط، بغض النظر عن عدد الخوادم. تجميد الماجستير لا يؤدي إلى إعادة انتخابه. إذا لم يتم تحديد السيد، فلن تتم تلبية الطلبات من قبل أي شخص.
هل تريد القياس الأفقي؟ آسف، لا.
ينتقل الطلب إلى مركز بيانات آخر من مركز بيانات رئيسي إلى مركز بيانات رئيسي، بغض النظر عن الخادم الذي جاء إليه. يتلقى السيد المحدد 100% من الحمل، باستثناء التحميل على الطلبات المعاد توجيهها. تحتوي جميع الخوادم الموجودة في مركز البيانات على نسخة محدثة من البيانات، ولكن يستجيب واحد فقط.
الطريقة الوحيدة للقياس هي تمكين الوضع القديم على العميل.
في الوضع القديم، يمكنك الاستجابة دون اكتمال النصاب القانوني. هذا هو الوضع الذي نتخلى فيه عن اتساق البيانات، ولكن نقرأ بشكل أسرع قليلاً من المعتاد، ويستجيب أي خادم. وبطبيعة الحال، التسجيل فقط من خلال السيد.
القنصل لا ينسخ البيانات بين مراكز البيانات. عندما يتم تجميع الاتحاد، سيكون لكل خادم بياناته الخاصة فقط. بالنسبة للآخرين، فهو يلجأ دائمًا إلى شخص آخر.
لا يتم ضمان ذرية العمليات خارج المعاملة. تذكر أنك لست الوحيد الذي يستطيع تغيير الأشياء. إذا كنت تريد ذلك بشكل مختلف، فقم بإجراء معاملة باستخدام القفل.
عمليات الحظر لا تضمن القفل. ينتقل الطلب من رئيسي إلى رئيسي، وليس بشكل مباشر، لذلك ليس هناك ضمان بأن الحظر سيعمل عندما تقوم بالحظر، على سبيل المثال، في مركز بيانات آخر.
ACL أيضًا لا تضمن الوصول (في كثير من الحالات). قد لا تعمل قائمة التحكم بالوصول (ACL) لأنها مخزنة في مركز بيانات اتحادي واحد - في مركز بيانات قائمة التحكم بالوصول (ACL) (DC الأساسي). إذا لم يجيبك DC، فلن تعمل قائمة التحكم بالوصول (ACL).
سيد واحد متجمد سوف يتسبب في تجميد الاتحاد بأكمله. على سبيل المثال، يوجد 10 مراكز بيانات في الاتحاد، وأحدها لديه شبكة سيئة، وفشل مركز واحد. كل من يتواصل معه سيبقى عالقًا في دائرة: هناك طلب ولا إجابة له والخيط يتجمد. لا توجد طريقة لمعرفة متى سيحدث هذا، ففي غضون ساعة أو ساعتين فقط سيسقط الاتحاد بأكمله. لا يوجد شيء يمكنك القيام به حيال ذلك.
تتم معالجة الحالة والنصاب القانوني والانتخابات من خلال موضوع منفصل. لن تتم إعادة الانتخاب، ولن تظهر الحالة أي شيء. تعتقد أن لديك قنصلًا حيًا، تسأل، ولا يحدث شيء - لا توجد إجابة. وفي الوقت نفسه، تظهر الحالة أن كل شيء على ما يرام.
لقد واجهنا هذه المشكلة واضطررنا إلى إعادة بناء أجزاء معينة من مراكز البيانات لتجنبها.
لا تحتوي النسخة التجارية من Consul Enterprise على بعض العيوب المذكورة أعلاه. وله العديد من الوظائف المفيدة: اختيار الناخبين، والتوزيع، والقياس. لا يوجد سوى "لكن" واحد - نظام الترخيص للنظام الموزع مكلف للغاية.
اختراق الحياة: rm -rf /var/lib/consul - علاج لجميع أمراض الوكيل. إذا لم ينجح شيء ما بالنسبة لك، فما عليك سوى حذف بياناتك وتنزيل البيانات من نسخة. على الأرجح، سيعمل القنصل.
BEFW
الآن دعونا نتحدث عن ما أضفناه إلى القنصل.
هو اختصار ل BACKEndFغضبWالجميع. اضطررت إلى تسمية المنتج بطريقة ما عندما قمت بإنشاء المستودع من أجل وضع أول التزام بالاختبار فيه. ويبقى هذا الاسم.
قوالب القواعد
القواعد مكتوبة في بناء جملة iptables.
- -ن قبل ذلك
- -P انخفاض الإدخال
- -حالة الإدخال -m - الحالة ذات الصلة، المنشأة -j قبول
- -A المدخلات -i lo -j قبول
- -إدخال -j BEFW
كل شيء يدخل في سلسلة BEFW، باستثناء ESTABLISHED, RELATED والمضيف المحلي. القالب يمكن أن يكون أي شيء، وهذا مجرد مثال.
كيف يكون BEFW مفيدًا؟
الخدمات
لدينا خدمة، ولها دائمًا منفذ، وعقدة تعمل عليها. من عقدتنا، يمكننا أن نسأل الوكيل محليًا ونكتشف أن لدينا نوعًا من الخدمة. يمكنك أيضًا وضع العلامات.
أي خدمة يتم تشغيلها وتسجيلها لدى Consul تتحول إلى قاعدة iptables. لدينا SSH - منفذ مفتوح 22. نص Bash بسيط: حليقة وiptables، ليست هناك حاجة إلى أي شيء آخر.
الزبائن
كيفية فتح الوصول ليس للجميع، ولكن بشكل انتقائي؟ إضافة قوائم IP إلى مساحة تخزين KV حسب اسم الخدمة.
على سبيل المثال، نريد أن يتمكن كل شخص على الشبكة العاشرة من الوصول إلى خدمة SSH_TCP_22. هل ترغب في إضافة حقل TTL صغير واحد؟ والآن لدينا تصاريح مؤقتة، على سبيل المثال، ليوم واحد.
الوصول
نحن نربط الخدمات بالعملاء: لدينا خدمة، وتخزين KV جاهز لكل منهم. الآن نحن نمنح الوصول ليس للجميع، ولكن بشكل انتقائي.
مجموعة
إذا كتبنا آلاف عناوين IP للوصول إليها في كل مرة، فسوف نتعب. دعونا نتوصل إلى مجموعات - مجموعة فرعية منفصلة في KV. دعنا نسميها الاسم المستعار (أو المجموعات) ونخزن المجموعات هناك وفقًا لنفس المبدأ.
دعونا نتواصل: الآن يمكننا فتح SSH ليس خصيصًا لـ P2P، ولكن لمجموعة كاملة أو عدة مجموعات. وبنفس الطريقة، هناك TTL - يمكنك الإضافة إلى مجموعة والإزالة منها مؤقتًا.
التكامل
مشكلتنا هي العامل البشري والأتمتة. حتى الآن قمنا بحلها بهذه الطريقة.
نحن نعمل مع Puppet، وننقل لهم كل ما يتعلق بالنظام (رمز التطبيق). يقوم Puppetdb (PostgreSQL العادي) بتخزين قائمة بالخدمات التي تعمل هناك، ويمكن العثور عليها حسب نوع المورد. هناك يمكنك معرفة من يتقدم وأين. لدينا أيضًا نظام طلب سحب ودمج لهذا الغرض.
لقد كتبنا befw-sync، وهو حل بسيط يساعد في نقل البيانات. أولاً، يتم الوصول إلى ملفات تعريف الارتباط الخاصة بالمزامنة عن طريق puppetdb. تم تكوين واجهة برمجة تطبيقات HTTP هناك: نطلب ما هي الخدمات المتوفرة لدينا وما يجب القيام به. ثم يقدمون طلبًا إلى القنصل.
هل هناك تكامل؟ نعم: لقد كتبوا القواعد وسمحوا بقبول طلبات السحب. هل تحتاج إلى منفذ معين أو إضافة مضيف إلى مجموعة ما؟ طلب السحب والمراجعة - لا مزيد من "ابحث عن 200 قائمة أخرى من قوائم ACL وحاول أن تفعل شيئًا حيال ذلك."
الأمثل
يستغرق تنفيذ الأمر Pinging للمضيف المحلي بسلسلة قواعد فارغة 0,075 مللي ثانية.
دعونا نضيف 10 عنوان iptables إلى هذه السلسلة. ونتيجة لذلك، سيزيد اختبار الاتصال 000 مرات: iptables خطي تمامًا، وتستغرق معالجة كل عنوان بعض الوقت.
بالنسبة لجدار الحماية حيث نقوم بترحيل الآلاف من قوائم ACL، لدينا الكثير من القواعد، وهذا يؤدي إلى زمن الاستجابة. هذا أمر سيء بالنسبة لبروتوكولات الألعاب.
ولكن إذا وضعنا 10 عنوان في ipset سوف ينخفض الأمر ping أيضًا.
النقطة المهمة هي أن "O" (تعقيد الخوارزمية) لـ ipset يساوي دائمًا 1، بغض النظر عن عدد القواعد الموجودة. صحيح أن هناك قيودًا - لا يمكن أن يكون هناك أكثر من 65535 قاعدة، في الوقت الحالي نحن نعيش مع هذا: يمكنك دمجها وتوسيعها وإنشاء اثنين من ipsets في واحد.
تخزين
الاستمرار المنطقي لعملية التكرار هو تخزين معلومات حول عملاء الخدمة في ipset.
الآن لدينا نفس SSH، ولا نكتب 100 IP مرة واحدة، ولكن نحدد اسم ipset الذي نحتاج إلى التواصل معه، والقاعدة التالية DROP. ويمكن تحويلها إلى قاعدة واحدة "من ليس هنا، يسقط"، لكنها أكثر وضوحا.
الآن لدينا القواعد والمجموعات. المهمة الرئيسية هي إنشاء مجموعة قبل كتابة القاعدة، وإلا فلن يكتب iptables القاعدة.
مخطط عام
في شكل رسم تخطيطي، كل ما قلته يبدو هكذا.
نحن نلتزم بـ Puppet، يتم إرسال كل شيء إلى المضيف، الخدمات هنا، ipset هناك، ولا يسمح لأي شخص غير مسجل هناك.
السماح والرفض
لإنقاذ العالم بسرعة أو تعطيل شخص ما بسرعة، في بداية كل السلاسل قمنا بعمل مجموعتين من ipsets: rules_allow и rules_deny. كيف تعمل؟
على سبيل المثال، يقوم شخص ما بإنشاء تحميل على الويب الخاص بنا باستخدام الروبوتات. في السابق، كان عليك العثور على عنوان IP الخاص به من السجلات، ونقله إلى مهندسي الشبكات، حتى يتمكنوا من العثور على مصدر حركة المرور وحظره. يبدو مختلفا الآن.
نرسلها إلى القنصل، ننتظر 2,5 ثانية، ويتم ذلك. وبما أن Consul يوزع بسرعة من خلال P2P، فهو يعمل في كل مكان وفي أي جزء من العالم.
بمجرد أن توقفت بطريقة أو بأخرى عن WOT تمامًا بسبب خطأ في جدار الحماية. rules_allow - هذا هو تأميننا ضد مثل هذه الحالات. إذا ارتكبنا خطأ في مكان ما مع جدار الحماية، فسيتم حظر شيء ما في مكان ما، يمكننا دائما إرسال شرطي 0.0/0لالتقاط كل شيء بسرعة. في وقت لاحق سوف نقوم بإصلاح كل شيء باليد.
مجموعات أخرى
يمكنك إضافة أي مجموعات أخرى في الفضاء $IPSETS$.
لماذا؟ في بعض الأحيان يحتاج شخص ما إلى ipset، على سبيل المثال، لمحاكاة إيقاف تشغيل جزء ما من المجموعة. يمكن لأي شخص إحضار أي مجموعات وتسميتها، وسيتم استلامها من القنصل. في الوقت نفسه، يمكن للمجموعات إما المشاركة في قواعد iptables أو العمل كفريق NOOP: سيتم الحفاظ على الاتساق من قبل البرنامج الخفي.
الأعضاء
في السابق، كان الأمر على هذا النحو: كان المستخدم متصلاً بالشبكة ويتلقى المعلمات من خلال المجال. قبل ظهور الجيل الجديد من جدران الحماية، لم تكن شركة Cisco تعرف كيفية فهم مكان وجود المستخدم ومكان عنوان IP. ولذلك، تم منح الوصول فقط من خلال اسم المضيف للجهاز.
ماذا فعلنا؟ لقد تعثرنا في اللحظة التي تلقينا فيها العنوان. عادةً ما يكون هذا هو dot1x أو Wi-Fi أو VPN - كل شيء يمر عبر RADIUS. لكل مستخدم، نقوم بإنشاء مجموعة حسب اسم المستخدم ونضع فيها عنوان IP مع TTL يساوي dhcp.lease الخاص به - بمجرد انتهاء صلاحيته، ستختفي القاعدة.
الآن يمكننا فتح الوصول إلى الخدمات، مثل المجموعات الأخرى، عن طريق اسم المستخدم. لقد خففنا عناء أسماء المضيفين عند تغييرها، وخففنا العبء عن مهندسي الشبكات لأنهم لم يعودوا بحاجة إلى Cisco. الآن يقوم المهندسون أنفسهم بتسجيل الوصول على خوادمهم.
العزل
في نفس الوقت بدأنا في تفكيك العزل. قام مديرو الخدمة بجرد، وقمنا بتحليل جميع شبكاتنا. دعونا نقسمهم إلى نفس المجموعات، وعلى الخوادم الضرورية، تمت إضافة المجموعات، على سبيل المثال، للرفض. الآن نفس العزلة المرحلية تنتهي برفض قواعد الإنتاج، ولكن ليس في الإنتاج نفسه.
يعمل المخطط بسرعة وبساطة: نقوم بإزالة كافة قوائم ACL من الخوادم، وتفريغ الأجهزة، وتقليل عدد شبكات VLAN المعزولة.
مراقبة النزاهة
في السابق، كان لدينا مشغل خاص للإبلاغ عندما يقوم شخص ما بتغيير قاعدة جدار الحماية يدويًا. كنت أكتب كتابًا ضخمًا للتحقق من قواعد جدار الحماية، كان الأمر صعبًا. يتم الآن التحكم في النزاهة بواسطة BEFW. إنه يضمن بحماس أن القواعد التي يضعها لا تتغير. إذا قام شخص ما بتغيير قواعد جدار الحماية، فسوف يتغير كل شيء مرة أخرى. "لقد قمت بسرعة بإعداد وكيل حتى أتمكن من العمل من المنزل" - لم يعد هناك المزيد من هذه الخيارات.
يتحكم BEFW في ipset من الخدمات ويدرج في befw.conf، قواعد الخدمات في سلسلة BEFW. لكنها لا تراقب السلاسل والقواعد الأخرى وغيرها من ipsets.
الحماية من الأعطال
يقوم BEFW دائمًا بتخزين آخر حالة جيدة معروفة مباشرة في البنية الثنائيةstate.bin. إذا حدث خطأ ما، فإنه يعود دائمًا إلى ملف الحالة هذا.bin.
هذا تأمين ضد عملية القنصل غير المستقرة، عندما لا يرسل بيانات أو يرتكب شخص ما خطأ ويستخدم قواعد لا يمكن تطبيقها. لضمان عدم تركنا بدون جدار حماية، سيعود BEFW إلى أحدث حالة في حالة حدوث خطأ في أي مرحلة.
في المواقف الحرجة، يعد هذا ضمانًا بأننا سنظل مع جدار حماية فعال. نفتح جميع الشبكات الرمادية على أمل أن يأتي المسؤول ويصلحها. يومًا ما سأضع هذا في التكوينات، لكن الآن لدينا فقط ثلاث شبكات رمادية: 10/8 و172/12 و192.168/16. داخل قنصلنا، هذه ميزة مهمة تساعدنا على التطوير بشكل أكبر.
العرض التوضيحي: خلال التقرير، يوضح إيفان الوضع التجريبي لـ BEFW. من الأسهل مشاهدة المظاهرة . كود المصدر التجريبي متاح .
المزالق
سأخبرك عن الأخطاء التي واجهناها.
ipset إضافة مجموعة 0.0.0.0/0. ماذا يحدث إذا قمت بإضافة 0.0.0.0/0 إلى ipset؟ هل سيتم إضافة كافة عناوين 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=other. كما قلت، نعتقد أننا نطلب بعض البيانات، لكننا إما سنحصل على بيانات أو خطأ. يمكننا القيام بذلك عبر القنصل محليًا، ولكن في هذه الحالة سيتم تجميد كليهما.
عميل القنصل المحلي عبارة عن غلاف عبر HTTP API. لكنه يتوقف فقط ولا يستجيب لـ Ctrl+C أو Ctrl+Z أو أي شيء آخر kill -9 في وحدة التحكم التالية. لقد واجهنا هذا عندما كنا نبني مجموعة كبيرة. ولكن ليس لدينا حل حتى الآن، ونحن نستعد لإصلاح هذا الخطأ في Consul.
قائد القنصل لا يستجيب. سيدنا في مركز البيانات لا يستجيب، نعتقد: "ربما ستعمل خوارزمية إعادة التحديد الآن؟"
لا، لن ينجح الأمر، ولن تظهر المراقبة أي شيء: سيقول القنصل أن هناك مؤشر التزام، وتم العثور على قائد، وكل شيء على ما يرام.
كيف نتعامل مع هذا الأمر؟ service consul restart في كرون كل ساعة. إذا كان لديك 50 خادمًا، فلا مشكلة كبيرة. عندما يكون هناك 16 منهم، سوف تفهم كيف يعمل.
اختتام
ونتيجة لذلك، حصلنا على المزايا التالية:
- تغطية 100% لجميع أجهزة Linux.
- السرعة.
- أتمتة.
- لقد حررنا مهندسي الأجهزة والشبكات من العبودية.
- ظهرت إمكانيات التكامل التي لا حدود لها تقريبًا: حتى مع Kubernetes، وحتى مع Ansible، وحتى مع Python.
سلبيات: القنصل الذي علينا الآن أن نعيش معه، وتكلفة الخطأ الباهظة للغاية. على سبيل المثال، مرة واحدة في الساعة 6 مساء (وقت الذروة في روسيا) قمت بتحرير شيء ما في قوائم الشبكات. كنا نقوم فقط ببناء العزل في BEFW في ذلك الوقت. لقد ارتكبت خطأ في مكان ما، يبدو أنني أشرت إلى القناع الخطأ، لكن كل شيء سقط في ثانيتين. تضيء شاشة المراقبة، ويأتي الشخص المناوب مسرعًا: "لدينا كل شيء!" تحول لون رئيس القسم إلى اللون الرمادي عندما شرح لرجال الأعمال سبب حدوث ذلك.
تكلفة الخطأ مرتفعة للغاية لدرجة أننا توصلنا إلى إجراءات وقائية معقدة خاصة بنا. إذا قمت بتنفيذ ذلك على موقع إنتاج كبير، فلن تحتاج إلى إعطاء رمز مميز رئيسي عبر Consul للجميع. وهذا سوف ينتهي بشكل سيء.
من حيث التكلفة. لقد كتبت رمزًا لمدة 400 ساعة فقط. يقضي فريقي المكون من 4 أشخاص 10 ساعات شهريًا في تقديم الدعم للجميع. بالمقارنة بسعر أي جدار حماية من الجيل الجديد، فهو مجاني.
الخطط. تتمثل الخطة طويلة المدى في إيجاد وسائل نقل بديلة لتحل محل القنصل أو مكملة له. ربما سيكون كافكا أو شيء من هذا القبيل. ولكن في السنوات القادمة سوف نعيش في القنصل.
خطط فورية: التكامل مع Fail2ban، مع المراقبة، مع nftables، وربما مع توزيعات أخرى، ومقاييس، ومراقبة متقدمة، وتحسين. دعم Kubernetes موجود أيضًا في مكان ما في الخطط، لأن لدينا الآن العديد من المجموعات والرغبة.
المزيد من الخطط:
- البحث عن الحالات الشاذة في حركة المرور.
- إدارة خريطة الشبكة؛
- دعم كوبيرنيتيس.
- تجميع الحزم لجميع الأنظمة؛
- واجهة مستخدم الويب.
نحن نعمل باستمرار على توسيع التكوين وزيادة المقاييس والتحسين.
انضم إلى المشروع. اتضح أن المشروع رائع، ولكن لسوء الحظ، لا يزال مشروعًا لشخص واحد. تعال إلى وحاول القيام بشيء ما: الالتزام، الاختبار، اقتراح شيء ما، تقديم تقييمك.
وفي هذه الأثناء نحن نستعد ل ، والذي سيعقد يومي 6 و 7 أبريل في سانت بطرسبرغ، ونحن ندعو مطوري الأنظمة عالية التحميل . المتحدثون ذوو الخبرة يعرفون بالفعل ما يجب عليهم فعله، ولكن بالنسبة لأولئك الجدد في التحدث، نوصي على الأقل . المشاركة في المؤتمر كمتحدث له عدد من المزايا. يمكنك قراءة أي منها، على سبيل المثال، في النهاية .
المصدر: www.habr.com