Kubernetes میں OpenVPN پوڈ کچھ آگے نہیں بھیجتا؟ ip_forward چیک کریں

کلائنٹ VPN پوڈ کو پنگ کرتے ہیں اور اس سے آگے کچھ نہیں۔ namespace میں فارورڈنگ بند ہے، اور درستگی کو admission، ری اسٹارٹ اور واپسی کے راستے سے گزرنا ہوگا۔

آپ کا لیپ ٹاپ سبز سرنگ دکھاتا ہے، کلائنٹ لاگ بتاتا ہے کہ راستے پش کیے گئے، اور جواب دینے والا واحد پتہ VPN سرور کا اپنا سرنگ IP ہے۔ اس سے آگے پنگ آپ جو بھی نشانہ بنائیں مر جاتے ہیں، خواہ وہ ClusterIP ہو، دوسرے پوڈ کا پتہ ہو یا کوئی عوامی ہوسٹ نام۔ یہ امتزاج مبہم نہیں، تشخیصی ہے: ڈی کیپسولیشن کام کرتی ہے، اور دوسری ہاپ نہیں۔

مجھے یہ ایک Debian نوڈ پر ملا جو chart کے ذریعے نصب شدہ OpenVPN امیج چلا رہا تھا، اور سرنگ آسان حصہ تھی۔ کلائنٹ نے 10.8.0.x لیز لی، 10.8.0.1 نے جواب دیا، اور 10.96.0.10، کلسٹر DNS سروس، وقت ختم ہو گئی۔ سرور لاگ میں کچھ بھی بیمار دکھائی نہیں دیا، اور اسی وجہ سے لوگ ان iptables قواعد کو دوبارہ لکھنے لگتے ہیں جنہیں کبھی چھونے کی ضرورت نہ تھی۔

VPN پوڈ ایک روٹر ہے، اور یہ صاف کہنا چاہیے۔ خفیہ کردہ پیکٹ آتے ہیں، پوڈ کے اپنے نیٹ ورک namespace میں کھلتے ہیں، اور پھر کسی دوسرے انٹرفیس سے باہر جانا ہوتا ہے۔ Linux اس دوسرے قدم سے انکار کرتا ہے جب تک اسی namespace کے اندر فارورڈنگ فعال نہ ہو۔

کلائنٹ کیا پا سکتا ہے اور کیا نہیں

جواب دینے والا پتہ سرنگ کے آخری سرے کا ہے، اور VPN عمل اسے مقامی طور پر رکھتا ہے، اس لیے فارورڈنگ بالکل شامل نہیں۔ باقی سب، بشمول دوسرا پوڈ، سروس کا VIP یا انٹرنیٹ، کے لیے کرنل کو پیکٹ tun0 سے eth0 تک منتقل کرنا ہوتا ہے۔ جب وہ منتقلی مسترد ہوتی ہے، علامت مستردی نہیں بلکہ یکساں خاموشی ہے، کیونکہ سرنگ کے نیچے واپس کوئی ICMP خرابی پیدا نہیں ہوتی۔ آپ کو ٹائم آؤٹ ملتے ہیں، ناقابل رسائی پیغامات نہیں، اور یہی اشارہ ہے کہ کوئی بھی روٹنگ نہیں کر رہا۔

دو منٹ کی درجہ بندی تہہ کو تنگ کرتی ہے۔ اگر DNS نام ناکام ہوں جبکہ سروس IP پر خام پنگ کامیاب ہوں، مسئلہ فارورڈنگ میں نہیں، DNS پلمبنگ میں ہے۔ اگر پیئر پتے سے آگے ہر منزل وقت ختم کرے، ننگے IP سمیت، تو namespace سے شروع کریں۔

namespace کے اندر کی ترتیب پڑھیں

ہر پوڈ کو اپنا نیٹ ورک namespace ملتا ہے، اور net.ipv4.ip_forward فی namespace sysctl ہے۔ نوڈ پر اسے بدلنا کنٹینر کے بارے میں کچھ نہیں بتاتا، اور یہ غلط مشین پر دوپہر گزارنے کا قابل اعتماد طریقہ ہے۔

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

صفر تشخیص کی تصدیق کرتا ہے۔ قدر نوڈ کی رن ٹائم ترتیب سے بھی ورثے میں نہیں ملتی: کنٹینر بننے کے ہر موقع پر یہ امیج کے ڈیفالٹ سے شروع ہوتی ہے۔ اس لیے kubectl exec ... sysctl -w سے ہاتھ سے لگائی گئی درستگی اگلی ری اسٹارٹ پر غائب ہو جاتی ہے اور وقفے وقفے سے نظر آنے والی خرابی کے طور پر واپس آتی ہے۔

اسے فعال کرنا تاکہ manifest اسے رکھے

پائیدار آپشن ایک init کنٹینر ہے جو اسی پوڈ سینڈ باکس میں چلتا ہے اور VPN کنٹینر شروع ہونے سے پہلے قدر لکھتا ہے۔ پوڈ میں کنٹینر ایک نیٹ ورک namespace شیئر کرتے ہیں، اس لیے ترتیب مرکزی کنٹینر میں منتقل ہو جاتی ہے۔

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

وہی privileged: true وہ سطر ہے جس پر جائزہ لینے والے اعتراض کرتے ہیں، اور وہ درست ہیں۔ sysctl لکھنے کے لیے یا تو استحقاق چاہیے یا تنگ دائرے کی صلاحیت، اور محدود Pod Security Standard چلانے والا کلسٹر مراعات یافتہ init کنٹینر کو یکسر مسترد کر سکتا ہے۔ اگر admission پوڈ مسترد کرے، تو آپ کو بناتے وقت پتہ چلتا ہے، جو کم از کم دیانت دار اور پڑھنے میں آسان ہے۔

زیادہ صاف متبادل پوڈ سطح کی securityContext.sysctls فہرست ہے، جو kubelet کو کسی بھی کنٹینر کو استحقاق دیے بغیر namespace والی sysctl لاگو کرنے دیتی ہے۔ یہ صرف کلسٹر کی اجازت فہرست کے ناموں کا احاطہ کرتی ہے۔ net.ipv4.ip_forward اس فہرست میں ہے یا نہیں یہ اس پر منحصر ہے کہ kubelet کیسے ترتیب دیا گیا، اور اس سے باہر sysctl مانگنے والا پوڈ admission میں مسترد ہوتا ہے یا سینڈ باکس دوبارہ آزمانے کے دوران CreateContainerConfigError میں پھنس جاتا ہے۔ فیلڈ ٹوٹا ہوا ماننے سے پہلے اجازت فہرست چیک کریں۔

دونوں میں سے کوئی طریقہ ہاتھ سے بنانے سے پہلے دیکھیں کہ chart پہلے ہی سوئچ ظاہر کرتا ہے یا نہیں، اکثر ipForwardInitContainer: true جیسی کسی چیز کے طور پر۔ chart کی قدر استعمال کرنے سے آپ کی override فائل چھوٹی رہتی ہے اور اگلی اپ گریڈ تک چلتی ہے، جو ہاتھ سے پیچ کی گئی Deployment تبدیلیاں نہیں کرتیں۔

دوسرا نصف: واپسی کا راستہ اور پالیسی

فارورڈنگ فعال ہونا ضروری ہے، کافی نہیں۔ اگر کلائنٹ ایسا نجی پول استعمال کریں جس کے لیے کلسٹر نیٹ ورک کا کوئی راستہ نہیں، تو جوابات سرنگ میں واپس راستہ نہیں ڈھونڈ پاتے، اور پوڈ کو وہ ٹریفک اپنی منزل کی طرف ماسک کرنا پڑتا ہے۔

پالیسی اس پر بیٹھتی ہے۔ NetworkPolicy اشیاء اور کلاؤڈ فائر وال قواعد اس ماخذ پتے کے خلاف جانچے جاتے ہیں جو پیکٹ ترجمے کے بعد اٹھاتا ہے، اس لیے کلائنٹ پول کے لیے لکھا گیا قاعدہ ماسکنگ فعال ہونے پر خاموشی سے مماثلت کھو سکتا ہے۔

جب کلائنٹ کو صرف کلسٹر کے اندر کی خدمات تک پہنچنا ہو، تو VPN کو سروس کے VIP پر ختم کرنا پوڈ نیٹ ورک میں روٹ کرنے سے چھوٹا ڈیزائن ہے۔ یہ کلائنٹ پول کو CNI کی روٹنگ ٹیبل سے مکمل طور پر باہر رکھتا ہے۔

ناکام ہاپ کو کلائنٹ سے الگ کرنا

باہر کی طرف کام کریں اور پہلے خاموش قدم پر رکیں۔ VPN پیئر سے شروع کریں، پھر کسی پوڈ کا پتہ آزمائیں، پھر سروس VIP، اور اس کے بعد ہی کوئی عوامی منزل۔ ہر کامیابی حد کو ایک ہاپ آگے بڑھاتی ہے، اور ہر ناکامی اس تہہ کا نام لیتی ہے جو دیکھنے کے لائق ہے۔ کسی بھی رول آؤٹ کے بعد exec کر کے اندر جائیں اور sysctl دوبارہ پڑھیں، کیونکہ بدلا گیا پوڈ امیج کے ڈیفالٹ سے شروع ہوتا ہے اور وہ درستگی جو کبھی manifest میں نہ تھی پہلے ہی جا چکی ہے۔

Kubernetes کی دستاویز کلسٹر میں sysctl کے استعمال پر بتاتی ہے کہ کون سے نام پوڈ سیکیورٹی سیاق کے ذریعے سیٹ کیے جا سکتے ہیں، اور admission کے تبدیلی کو مسترد کرنے پر سب سے پہلے وہیں دیکھنا چاہیے۔

متعلقہ مضامین