لماذا أنشأناها؟
لفترة طويلة ، استخدمنا في Rambler Group بنية شبكة مركز بيانات ثلاثية المستويات ، حيث يعيش كل مشروع أو مكون بنية تحتية في شبكة محلية ظاهرية مخصصة. مرت جميع حركات المرور - بين شبكات vlans وبين مراكز البيانات - عبر معدات على مستوى الحافة.
تعد أجهزة Edge أجهزة توجيه باهظة الثمن قادرة على أداء العديد من الوظائف المختلفة ، وبالتالي فإن المنافذ الموجودة عليها باهظة الثمن أيضًا. بمرور الوقت ، نمت حركة المرور الأفقية (من آلة إلى آلة - على سبيل المثال ، نسخ قاعدة البيانات ، والطلبات إلى مختلف الخدمات ، وما إلى ذلك) ، وفي مرحلة ما ظهرت مشكلة استخدام المنفذ على أجهزة التوجيه الحدودية.
إحدى الوظائف الرئيسية لهذه الأجهزة هي تصفية حركة المرور. نتيجة لذلك ، أصبح من الصعب أيضًا إدارة قائمة التحكم بالوصول (ACL): كان عليك القيام بكل شيء يدويًا ، بالإضافة إلى أن تنفيذ المهمة من قبل القسم المجاور استغرق أيضًا وقتًا. تم قضاء وقت إضافي في تكوين المنافذ على مستوى الوصول. كان من الضروري تنفيذ ليس فقط الإجراءات اليدوية لنفس شهادات عدم الممانعة ، ولكن أيضًا لتحديد المشكلات الأمنية المحتملة ، نظرًا لأن المضيفين يغيرون مواقعهم ، على التوالي ، يمكنهم الوصول غير المشروع إلى شبكات vlans الخاصة بأشخاص آخرين.
حان الوقت لتغيير شيء ما ، وشبكات Clos أو ، كما يطلق عليها أيضًا ، جاءت مصانع IP للإنقاذ.
على الرغم من التشابه الخارجي ، فإن الاختلاف الأساسي بين هذه البنية والسابقة هو أن كل جهاز ، بما في ذلك طبقة الأوراق ، يعمل كجهاز توجيه ، والبوابة الافتراضية للخادم هي Top-of-Rack. وبالتالي ، يمكن الآن المرور الأفقي بين أي مضيفين من مختلف المشاريع عبر طبقة العمود الفقري ، وليس عبر الحافة.
بالإضافة إلى ذلك ، على نفس مستوى العمود الفقري ، يمكننا توصيل مراكز البيانات ببعضها البعض ، ولا توجد الآن أكثر من أربعة أجهزة شبكة على المسار بين أي خادمين. المعدات المتطورة في هذه البنية مطلوبة فقط لتوصيل مشغلي الاتصالات وتسمح فقط بالمرور الرأسي (من وإلى الإنترنت).
الميزة الرئيسية لشبكة Klose هي أنها تفتقر إلى مكان يمكنك من خلاله تصفية حركة المرور بين المضيفين. لذلك ، يجب تنفيذ هذه الوظيفة مباشرة على الخادم. جدار الحماية المركزي هو برنامج يقوم بتصفية حركة المرور على المضيف نفسه الذي يتلقى حركة المرور.
المتطلبات
تم تحديد الحاجة إلى تنفيذ جدار حماية مركزي من خلال عدة عوامل في وقت واحد:
- المستهلكين النهائيين و
- البنية التحتية الحالية.
لذلك كانت متطلبات التطبيق كالتالي:
- يجب أن يكون جدار الحماية قادرًا على العمل وإنشاء قواعد على الأجهزة المضيفة والظاهرية. علاوة على ذلك ، يجب ألا تختلف قائمة القواعد عن البيئة التي يعمل فيها جدار الحماية. أي أن القواعد متطابقة.
- . , – ssh, ( Prometheus), .
- , -.
- , – .
- .
- : « , ».
تعد سحابة Rambler Group ديناميكية تمامًا: يتم إنشاء الأجهزة الافتراضية وإزالتها وتثبيت الخوادم وتفكيكها. لذلك ، نحن لا نستخدم الوصول من نقطة إلى نقطة ؛ بنيتنا التحتية لديها مفهوم "المجموعة المضيفة".
Hostgroup هو عبارة عن ترميز لمجموعة من الخوادم التي تصف دورها بشكل فريد. على سبيل المثال news-prod-coolstream-blue.
يؤدي هذا إلى مطلب آخر: يجب على المستخدمين العمل مع كيانات عالية المستوى - مجموعات مضيفة ومشاريع وما إلى ذلك.
الفكرة والتنفيذ
Tulling
جدار الحماية المركزي هو شيء كبير ومعقد يتطلب تكوين الوكيل. يمكن أن يستغرق العثور على المشكلات أكثر من خمس دقائق ، لذلك ظهرت أداة مع الوكيل والخادم ، والتي تخبر المستخدم إذا تم تكوين الوكيل بشكل صحيح وما يحتاج إلى الإصلاح. على سبيل المثال ، من المتطلبات المهمة للمضيف وجود سجل DNS في مجموعة المضيف أو PTR. ستخبرك الأداة بكل هذا وأكثر ( يتم وصف وظائفها أدناه ).
جدار حماية موحد
نحاول الالتزام بالمبدأ التالي: يجب أن يكون التطبيق الذي يقوم بتكوين جدار الحماية على المضيف هو الوحيد من أجل عدم الحصول على "قواعد وامضة". بمعنى ، إذا كان الخادم يحتوي بالفعل على أداة التخصيص الخاصة به (على سبيل المثال ، إذا تم تكوين القواعد بواسطة وكيل آخر) ، فإن تطبيقنا لا ينتمي هناك. حسنًا ، الشرط المعاكس يعمل أيضًا: إذا كان هناك وكيل جدار الحماية الخاص بنا ، فعندئذ فقط هو من يضع القواعد - وهنا مبدأ التحكم الكامل.
جدار الحماية ليس iptables
كما تعلم ، iptables هو مجرد أداة سطر أوامر للعمل مع netfilter. لنقل جدار الحماية إلى منصات مختلفة (Windows ، وأنظمة BSD) ، يعمل الوكيل والخادم مع النموذج الخاص بهما. المزيد عن هذا قليلاً أدناه ، في قسم "الهندسة المعمارية" .
لا يحاول الوكيل حل الأخطاء المنطقية
كما هو مذكور أعلاه ، لا يتخذ الوكيل أي قرارات. إذا كنت تريد إغلاق المنفذ 443 ، الذي يعمل عليه خادم HTTP بالفعل ، فلا مشكلة ، قم بإغلاقه!
هندسة معمارية
من الصعب التوصل إلى شيء جديد في بنية مثل هذا التطبيق.
- لدينا وكيل ، يقوم بتكوين القواعد على المضيف.
- لدينا خادم ، يعطي قواعد محددة من قبل المستخدم.
- لدينا مكتبة وأدوات.
- لدينا محلل عالي المستوى - يقوم بتغيير عناوين IP إلى مجموعات مضيفة / مشاريع والعكس صحيح. المزيد عن كل هذا أدناه .
تمتلك Rambler Group العديد من المضيفين وحتى المزيد من الأجهزة الافتراضية ، وكلهم ، بطريقة أو بأخرى ، ينتمون إلى كيان ما:
- VLAN
- شبكة الاتصال
- مشروع
- المجموعة المضيفة.
يصف الأخير انتماء المضيف إلى المشروع ودوره. على سبيل المثال ، news-prod-backend-api ، حيث: news - project؛ همز - حسده ، في هذه الحالة هو الإنتاج ؛ الخلفية - الدور api هي علامة مخصصة تعسفية.
يعمل Resolver Firewall على الشبكة و / أو طبقة النقل ، والمجموعات المضيفة والمشاريع عبارة عن كيانات عالية المستوى. لذلك ، من أجل "تكوين صداقات" وفهم من يملك المضيف (أو الجهاز الظاهري) ، تحتاج إلى الحصول على قائمة بالعناوين - أطلقنا على هذا المكون اسم "High Level Resolver". إنه يغير الأسماء عالية المستوى إلى مجموعة من العناوين (من حيث وحدة الحل "مضمنة") ، وعلى العكس من ذلك ، عنوان لاسم الكيان ("يحتوي على").
Library - Core
لتوحيد بعض المكونات وتوحيدها ، ظهرت مكتبة تسمى أيضًا Core. إنه نموذج بيانات به وحدات تحكم وطرق عرض خاصة به تسمح لك بتعبئته وقراءته. يعمل هذا الأسلوب على تبسيط الكود من جانب الخادم وكود الوكيل إلى حد كبير ، ويساعد أيضًا في مقارنة القواعد الحالية على المضيف بالقواعد المستلمة من الخادم.
لدينا عدة مصادر لملء النموذج:
- ملفات القواعد (نوعان مختلفان: مبسط ووصف القاعدة بالكامل)
- القواعد الواردة من الخادم
- القواعد المتلقاة من المضيف نفسه.
العامل
الوكيل ليس ارتباطًا عبر iptables ، ولكنه تطبيق مستقل يعمل باستخدام غلاف فوق مكتبات C libiptc، libxtables. لا يتخذ الوكيل نفسه أي قرارات ، ولكنه يقوم فقط بتكوين القواعد على المضيف.
دور الوكيل ضئيل للغاية: اقرأ ملفات القواعد (بما في ذلك الملفات الافتراضية) ، واحصل على البيانات من الخادم (إذا تم تكوينه للتشغيل عن بُعد) ، ودمج القواعد في مجموعة واحدة ، وتحقق مما إذا كانت تختلف عن الحالة السابقة ، وإذا كانت مختلفة ، يتم تطبيقها.
دور مهم آخر للوكيل هو عدم تحويل المضيف إلى قرع أثناء التثبيت الأولي أو عند تلقي استجابة غير صالحة من الخادم. لتجنب ذلك ، نوفر مجموعة من القواعد في الحزمة افتراضيًا ، مثل ssh ومراقبة الوصول وما إلى ذلك. إذا تلقى وكيل جدار الحماية رمز استجابة بخلاف رمز الاستجابة رقم 200 ، فلن يحاول الوكيل تنفيذ أي إجراء وسيغادر الحالة السابقة. لكنه لا يحمي من الأخطاء المنطقية ، إذا رفضت الوصول إلى المنافذ 80 ، 443 ، فسيظل الوكيل يقوم بعمله ، حتى عندما تعمل خدمة الويب على المضيف.
تم تصميم
Tulza Tulza لمديري النظام والمطورين الذين يقومون بصيانة المشروع. الهدف بسيط للغاية: بنقرة واحدة ، احصل على جميع البيانات حول عمل الوكيل. الأداة قادرة على إخبارك بما يلي:
- هو البرنامج الخفي للوكيل قيد التشغيل
- هل هناك سجل PTR للمضيف
- .
هذه المعلومات كافية لتشخيص المشاكل في مرحلة مبكرة.
الخادم
الخادم هو تطبيق + قاعدة بيانات. يتم تنفيذ كل منطق العمل من قبله. من الميزات المهمة للخادم أنه لا يخزن عناوين IP. يعمل الخادم فقط مع كائنات المستوى الأعلى - أسماء مجموعة المضيفين والمشروع وما إلى ذلك.
القواعد في القاعدة هي كما يلي: الإجراء: قبول Src: project-B ، project-C Dst: Project-B Proto: tcp Ports: 80، 443.
كيف يفهم الخادم القواعد التي يجب تقديمها ولمن؟ ويترتب على المتطلبات أن القواعد يجب أن تكون متطابقة بغض النظر عن مكان تشغيل الوكيل ، سواء كان مضيفًا أو جهازًا افتراضيًا.
يأتي طلب الوكيل دائمًا إلى الخادم بقيمة واحدة - عنوان IP. من المهم أن تتذكر أن كل وكيل يسأل عن القواعد لنفسه ، أي أنه الوجهة.
لسهولة فهم عملية الخادم ، ضع في اعتبارك عملية الحصول على قواعد المضيف التي تنتمي إلى المشروع.
يأتي دور المحلل أولاً. وتتمثل مهمتها في تغيير عنوان IP إلى اسم المضيف ، ثم معرفة الكيان الذي يحتوي عليه هذا المضيف. يستجيب HL-Resolver للخادم الذي يحتويه المضيف في المشروع A. يشير HL-Resolver إلى Datasource (الذي لم نذكره من قبل). مصدر البيانات هو نوع من قاعدة معارف الشركة حول الخوادم والمشاريع والمجموعات المضيفة وما إلى ذلك.
بعد ذلك ، يبحث الخادم عن جميع قواعد المشروع مع الوجهة = اسم المشروع. نظرًا لأننا لا تحتوي على عناوين في قاعدة البيانات ، فنحن بحاجة إلى إعادة تسمية أسماء المشروع إلى أسماء مضيفة ، ثم إلى عناوين ، بحيث يتم إرسال الطلب مرة أخرى إلى مصدر البيانات من خلال المحلل. يقوم HL-Resoler بإرجاع قائمة بالعناوين ، وبعد ذلك يتلقى الوكيل قائمة جاهزة من القواعد.
إذا كانت وجهتنا عبارة عن مضيف به أجهزة افتراضية ، فسيتم تنفيذ نفس البرنامج النصي ليس فقط للمضيف ، ولكن أيضًا لكل جهاز افتراضي عليه.
يوجد أدناه رسم تخطيطي يوضح حالة بسيطة: يتلقى مضيف (جهاز أو جهاز افتراضي) قواعد المضيف في Project-A.
إطلاق
ليس من الصعب تخمين أن وجود إدارة جدار حماية مركزية ، يمكنك أيضًا كسر كل شيء مركزيًا. لذلك ، يتم تنفيذ إصدارات العامل والخادم على مراحل.
للخادم - اختبار Blue-Green + A / B يعتبر
Blue-Green استراتيجية نشر تتضمن مجموعتين مضيفتين. ويتم التبديل في أجزاء 1،3،5،10 ... 100٪. لذلك ، إذا كانت هناك مشاكل في الإصدار الجديد ، فلن يعاني سوى جزء صغير من الخدمات.
بالنسبة للوكيل ، فإن Canary
Canary (أو نشر الكناري) يشبه إلى حد ما اختبار A / B. نقوم بتحديث بعض الوكلاء فقط ونلقي نظرة على المقاييس. إذا كان كل شيء على ما يرام ، فإننا نأخذ قطعة أخرى أكبر وهكذا حتى 100٪.
خاتمة
نتيجة لذلك ، قمنا بعمل خدمة ذاتية لمهندسي النظام ، والتي تتيح لك إدارة الوصول إلى الشبكة من نقطة واحدة. وهكذا فإننا:
- HTTP-API
- .