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

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

لن أخوض في التفاصيل حول تثبيت وتكوين MetalLB لأنني أفترض أن لديك بالفعل بعض الخبرة. أقترح البدء فورًا في العمل ، أي تكوين التوجيه. إذن لدينا أربع حالات:

الحالة 1: عندما يكون الإعداد غير مطلوب

لنأخذ حالة بسيطة.

تكوين التوجيه الإضافي غير مطلوب عندما تكون العناوين الصادرة عن MetalLB في نفس الشبكة الفرعية مثل عناوين العقد الخاصة بك.

على سبيل المثال لديك شبكة فرعية 192.168.1.0/24، لديها جهاز توجيه 192.168.1.1، وتحصل العقد الخاصة بك على العناوين: 192.168.1.10-30، ثم بالنسبة لـ MetalLB يمكنك ضبط النطاق 192.168.1.100-120 وتأكد من أنها ستعمل بدون أي تكوين إضافي.

لماذا هذا؟ نظرًا لأن العقد الخاصة بك قد تم تكوين مسارات لها بالفعل:

# ip route
default via 192.168.1.1 dev eth0 onlink 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

والعناوين من نفس الغضب ستعيد استخدامها دون أي إيماءات إضافية.

الحالة 2: عند الحاجة إلى تخصيص إضافي

يجب عليك إعداد مسارات إضافية عندما لا تحتوي العقد الخاصة بك على عنوان IP مهيأ أو مسار للشبكة الفرعية التي تعالج مشكلات MetalLB لها.

سأشرح أكثر من ذلك بقليل. عندما تُرجع MetalLB عنوانًا ، يمكن مقارنة ذلك بإسناد بسيط للنموذج:

ip addr add 10.9.8.7/32 dev lo

انتبه على:

• a) يتم تعيين العنوان ببادئة /32 أي أن الطريق إلى الشبكة الفرعية لن تتم إضافته تلقائيًا (إنه مجرد عنوان)
• b) يتم تعيين العنوان لأي واجهة عقدة (على سبيل المثال ، الاسترجاع). من الجدير بالذكر هنا خصائص مكدس شبكات Linux. بغض النظر عن الواجهة التي تضيف عنوانًا إليها ، ستقوم النواة دائمًا بمعالجة طلبات arp وإرسال ردود ARP لأي منها ، ويعتبر هذا السلوك صحيحًا ، علاوة على ذلك ، يُستخدم على نطاق واسع في بيئة ديناميكية مثل Kubernetes.

يمكن تكوين هذا السلوك ، على سبيل المثال من خلال تمكين صارم arp:

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

في هذه الحالة ، لن يتم إرسال ردود arp إلا إذا كانت الواجهة تحتوي صراحةً على عنوان IP محدد. هذا الإعداد مطلوب إذا كنت تخطط لاستخدام MetalLB وكان وكيل kube يعمل في وضع IPVS.

ومع ذلك ، لا يستخدم MetalLB النواة لمعالجة طلبات arp ، ولكنه يفعل ذلك بنفسه في مساحة المستخدم ، لذلك لن يؤثر هذا الخيار على MetalLB.

دعنا نعود إلى مهمتنا. إذا كان مسار العناوين التي تم إصدارها غير موجود على العقد الخاصة بك ، فقم بإضافته مسبقًا إلى جميع العقد:

ip route add 10.9.8.0/24 dev eth1

الحالة 3: عندما تحتاج إلى التوجيه المستند إلى المصدر

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

على سبيل المثال ، لديك كل نفس الشبكة الفرعية 192.168.1.0/24 مخصصة لعقدك ، لكنك تريد إعطاء عناوين خارجية باستخدام MetalLB. افترض أن لديك عناوين متعددة من شبكة فرعية 1.2.3.0/24 موجودة في VLAN 100 وتريد استخدامها للوصول إلى خدمات Kubernetes من الخارج.

عند الاتصال 1.2.3.4 سوف تقدم طلبات من شبكة فرعية مختلفة عن 1.2.3.0/24 ونتوقع ردا. العقدة الحالية هي العقدة الرئيسية للعنوان الذي قدمته MetalLB 1.2.3.4، سوف تتلقى حزمة من جهاز التوجيه 1.2.3.1، ولكن الإجابة عن ذلك يجب بالضرورة أن تسير بنفس الطريق ، من خلال 1.2.3.1.

نظرًا لأن العقدة لديها بالفعل بوابة افتراضية تم تكوينها 192.168.1.1، ثم بشكل افتراضي ستذهب الإجابة إليه ، وليس إلى 1.2.3.1من خلالها تلقينا الطرد.

كيف تتعامل مع هذا الوضع؟

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

ip link add link eth0 name eth0.100 type vlan id 100
ip link set eth0.100 up

ثم أضف المسارات:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

انتبه إلى المسارات التي نضيفها إلى جدول توجيه منفصل 100 سيحتوي فقط على المسارين اللازمين لإرسال حزمة استجابة عبر البوابة 1.2.3.1خلف الواجهة eth0.100.

نحتاج الآن إلى إضافة قاعدة بسيطة:

ip rule add from 1.2.3.0/24 lookup 100

التي تقول صراحة: إذا كان عنوان المصدر للحزمة موجودًا 1.2.3.0/24، فأنت بحاجة إلى استخدام جدول التوجيه 100. في ذلك ، وصفنا بالفعل الطريق الذي سيرسله من خلاله 1.2.3.1

الحالة 4: عندما تحتاج إلى توجيه قائم على السياسة

هيكل الشبكة هو نفسه كما في المثال السابق ، ولكن لنفترض أنك تريد أيضًا أن تكون قادرًا على الوصول إلى العناوين الخارجية للمجموعة 1.2.3.0/24 من القرون الخاصة بك:

تكمن الخصوصية في حقيقة أنه عند الوصول إلى أي عنوان في 1.2.3.0/24، حزمة الاستجابة تضرب العقدة ولها عنوان المصدر في النطاق 1.2.3.0/24 سيتم إرساله بإخلاص إلى eth0.100، لكننا نريد من Kubernetes إعادة توجيهه إلى أول Pod ، والذي أنشأ الطلب الأصلي.

لم يكن حل هذه المشكلة سهلاً ، لكنه أصبح ممكنًا بفضل التوجيه المستند إلى السياسة:

لفهم العملية بشكل أفضل ، سأقدم مخطط كتلة netfilter:

لتبدأ ، كما في المثال السابق ، دعنا ننشئ جدول توجيه إضافي:

ip route add 1.2.3.0/24 dev eth0.100 table 100
ip route add default via 1.2.3.1 table 100

الآن دعنا نضيف بعض القواعد إلى iptables:

iptables -t mangle -A PREROUTING -i eth0.100 -j CONNMARK --set-mark 0x100
iptables -t mangle -A PREROUTING  -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j RETURN
iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark

ستحدد هذه القواعد الاتصالات الواردة لكل واجهة eth0.100، وضع علامات على جميع الحزم مع العلامة 0x100، سيتم استخدام نفس العلامة أيضًا لتمييز الاستجابات ضمن نفس الاتصال.

الآن يمكننا إضافة قاعدة توجيه:

ip rule add from 1.2.3.0/24 fwmark 0x100 lookup 100

وهذا يعني أن جميع الحزم التي لها عنوان مصدر 1.2.3.0/24 والعلامة 0x100 يجب أن يتم توجيهها باستخدام جدول 100.

وبالتالي ، فإن الحزم الأخرى المستلمة على واجهة مختلفة لا تندرج تحت هذه القاعدة ، والتي ستسمح بتوجيهها بواسطة أدوات Kubernetes القياسية.

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

المشكلة هي أنه في حالتنا لن يعمل بشكل صحيح ، لكن يمكننا إيقاف تشغيله:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0.100/rp_filter

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

من أجل عدم تقييد عامل التصفية تمامًا ، يمكننا استخدام تنفيذ rp_filter لـ netfilter. باستخدام rpfilter كوحدة iptables ، يمكنك إعداد قواعد مرنة تمامًا ، على سبيل المثال:

iptables -t raw -A PREROUTING -i eth0.100 -d 1.2.3.0/24 -j RETURN
iptables -t raw -A PREROUTING -i eth0.100 -m rpfilter --invert -j DROP

قم بتمكين rp_filter على الواجهة eth0.100 لجميع العناوين باستثناء 1.2.3.0/24.

المصدر: www.habr.com