بود OpenVPN في Kubernetes لا يمرر شيئًا؟ تحقق من ip_forward

يعرض حاسوبك نفقًا أخضر، ويقول سجل العميل إن المسارات دُفعت، والعنوان الوحيد الذي يستجيب هو عنوان IP للنفق الخاص بخادم الـVPN نفسه. لا تصل أي ping بعده مهما كان هدفها، سواء أكان ClusterIP أو عنوان بود آخر أو اسم مضيف عام. هذه التركيبة تشخيصية لا غامضة: إزالة التغليف تعمل، والقفزة الثانية لا تعمل.

واجهت هذا على عقدة Debian تشغّل صورة OpenVPN مثبّتة عبر chart، وكان النفق الجزء السهل. أخذ العميل إيجارًا 10.8.0.x، واستجاب 10.8.0.1، بينما انتهى 10.96.0.10، خدمة DNS العنقودية، بمهلة. لم يبدُ شيء في سجل الخادم معتلًا، ولهذا بالضبط يبدأ الناس في إعادة كتابة قواعد iptables لم يحتاجوها يومًا.

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

ما يستطيع العميل الوصول إليه وما لا يستطيع

العنوان الذي يستجيب ينتمي إلى نقطة نهاية النفق، وعملية الـVPN تملكه محليًا، لذا لا تشارك إعادة التوجيه فيه إطلاقًا. كل ما عداه، بما في ذلك بود آخر أو VIP لخدمة أو الإنترنت، يحتاج إلى النواة لنقل حزمة من tun0 إلى eth0. وعندما يُرفض هذا النقل، يكون العرَض صمتًا موحّدًا لا رفضًا، لأن لا شيء يولّد خطأ ICMP عائدًا في النفق. تحصل على مهل، لا على رسائل عدم إمكانية الوصول، وهذا هو الدليل على أن لا أحد يوجّه إطلاقًا.

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

اقرأ الإعداد داخل مساحة الأسماء

يحصل كل بود على مساحة أسماء شبكة خاصة به، و net.ipv4.ip_forward هو sysctl لكل مساحة أسماء. تغييره على العقدة لا يخبرك شيئًا عن الحاوية، وهو طريقة موثوقة لقضاء أصيل في الجهاز الخطأ.

kubectl exec -it deploy/openvpn -- sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 0

الصفر يؤكد التشخيص. القيمة لا تُورَّث من تهيئة وقت تشغيل العقدة أيضًا: بل تبدأ من الافتراضي في الصورة كل مرة تُنشأ فيها حاوية. لذلك يختفي الإصلاح المطبّق يدويًا باستخدام kubectl exec ... sysctl -w عند إعادة التشغيل التالية ويعود كعيب يبدو متقطعًا.

تفعيله كي يحتفظ به البيان

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

initContainers:
- name: enable-forwarding
  image: busybox:1.36
  command: ["sysctl", "-w", "net.ipv4.ip_forward=1"]
  securityContext:
    privileged: true

سطر privileged: true هو ما يعترض عليه المراجعون، وهم محقون. كتابة sysctl تحتاج إما امتيازًا أو قدرة ضيقة النطاق، وعنقود يعمل بمعيار Pod Security المقيّد قد يرفض حاوية init مميزة رفضًا قاطعًا. إذا رفض القبول البود، تعرف ذلك عند الإنشاء، وهو على الأقل صادق وسهل القراءة.

البديل الأنظف هو قائمة securityContext.sysctls على مستوى البود، التي تتيح لـkubelet تطبيق sysctls محددة النطاق دون منح امتياز لأي حاوية. وهي تغطي فقط الأسماء في قائمة العنقود المسموح بها. وهل net.ipv4.ip_forward في تلك القائمة يعتمد على كيفية تهيئة kubelet، والبود الذي يطلب sysctl خارجها يُرفض عند القبول أو يعلق في CreateContainerConfigError بينما يُعاد محاولة الصندوق. تحقق من القائمة المسموح بها قبل أن تفترض أن الحقل معطوب.

قبل أن تبني أيًا من المقاربتين يدويًا، انظر إن كان chart يعرض المفتاح أصلًا، غالبًا كشيء مثل ipForwardInitContainer: true. استخدام قيمة chart يبقي ملف التجاوز صغيرًا وينجو من الترقية التالية، وهو ما لا تفعله تعديلات Deployment المرقّعة يدويًا.

النصف الثاني: مسار العودة والسياسة

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

تقع السياسة فوق ذلك. تُقيَّم كائنات NetworkPolicy وقواعد جدار الحماية السحابي مقابل عنوان المصدر الذي تحمله الحزمة بعد الترجمة، لذا قد تتوقف قاعدة مكتوبة لبركة العملاء عن المطابقة بهدوء بمجرد تفعيل إخفاء الهوية.

عندما يحتاج العملاء إلى الوصول فقط إلى الخدمات داخل العنقود، فإن إنهاء الـVPN عند VIP الخدمة تصميم أصغر من التوجيه إلى شبكة البودات. كما يبقي بركة العملاء خارج جدول توجيه CNI تمامًا.

عزل القفزة الفاشلة عن العميل

اعمل من الداخل إلى الخارج وتوقف عند أول خطوة صامتة. ابدأ بنظير الـVPN، ثم جرّب عنوان بود ما، ثم VIP خدمة، وبعد ذلك فقط وجهة عامة. كل نجاح يحرّك الحدود قفزة واحدة، وكل فشل يسمّي الطبقة التي تستحق الفحص. بعد أي طرح، ادخل ونفّذ واقرأ sysctl مجددًا، لأن البود المستبدل يبدأ من افتراضي الصورة، والإصلاح الذي لم يكن في البيان قط قد ذهب بالفعل.

توثيق Kubernetes حول استخدام sysctls في عنقود يسرد الأسماء التي يمكن ضبطها عبر سياق أمان البود، وهو أول مكان تنظر فيه عندما يرفض القبول التغيير.