Kubernetes میں VPN کلائنٹ کا IP: اسے محفوظ رکھیں یا SNAT کریں؟
Kubernetes میں VPN کلائنٹ کے اصل پتے اور سورس NAT کے درمیان تین شرائط کی بنیاد پر انتخاب کریں، پھر واپسی راستہ اور pods کی تبدیلی کی جانچ کریں۔
کہیں ٹنل اور backend کے درمیان کلائنٹ کا پتہ یا تو زندہ رہتا ہے یا بدل دیا جاتا ہے، اور دونوں نتائج قابلِ دفاع ہیں۔ انتخاب وصول کرنے والی سروس کے مالک کا ہے، نہ کہ اس کا جس نے CNI نصب کیا۔ جب فی کلائنٹ اجازت، کوٹے یا آڈٹ ریکارڈ اہم ہوں تو پتے کو ہر قدم سے گزرنا ہوگا۔ جب مشترکہ انتساب قابلِ قبول ہو تو سورس NAT ایک روٹنگ مسئلہ ختم کر دیتا ہے جسے ورنہ آپ ہمیشہ برقرار رکھتے۔
پتہ درحقیقت کہاں غائب ہوتا ہے
دور دراز کلائنٹ کا پیکٹ VPN pod تک ٹنل رینج کے اندر اندرونی ماخذ کے ساتھ پہنچتا ہے، مثلاً 10.90.0.42۔ جب pod اس پیکٹ کو ClusterIP یا pod کے IP کی طرف آگے بھیجتا ہے تو تین مختلف میکانزم ماخذ کو دوبارہ لکھ سکتے ہیں۔ نوڈ کی CNI masquerade قاعدہ اس ٹریفک کو ڈھانپتا ہے جو pod کلسٹر CIDR سے باہر بھیجتا ہے۔ منزل نوڈ پر kube-proxy کا conntrack اندراج خود Service چھلانگ کو ڈھانپتا ہے۔ جو پراکسی کنکشن ختم کرتا ہے وہ پیکٹ آگے نہیں بھیجتا، لہٰذا آخر میں جو ماخذ آپ دیکھتے ہیں وہ پراکسی کا ہے۔
ان میں سے ہر ایک مختلف پرت میں رہتا ہے، اسی لیے ایک Service فیلڈ تقریباً کبھی پورا راستہ درست نہیں کرتا۔
VPN کے عوامی Service پر externalTrafficPolicy صرف بیرونی کنکشن کا فیصلہ کرتا ہے: Local دور دراز پتہ اس نوڈ پر رکھتا ہے جس نے اسے وصول کیا، جبکہ Cluster kube-proxy کو اجازت دیتا ہے کہ پیکٹ کسی دوسرے نوڈ کو دے اور وہاں masquerade کرے۔ یہ ترتیب اس Listener کو کنٹرول کرتی ہے جس سے آپ کے کلائنٹ جڑتے ہیں۔ یہ اس ڈکرپٹ شدہ پیکٹ کے بارے میں کچھ نہیں کہتی جو آپ کا VPN عمل بعد میں کلسٹر میں بھیجتا ہے۔
تین شرائط جو بحث کو طے کرتی ہیں
میں ہر بار یہی تین سوالات اسی ترتیب سے پوچھتا ہوں جب یہ معاملہ آتا ہے، کیونکہ پہلا عموماً بحث ختم کر دیتا ہے۔ ان کے جواب مخصوص ورک لوڈ کے لیے دیں، پورے کلسٹر کے لیے نہیں۔ ایک ہی کمپنی کے دو کلسٹر مختلف جوابات پر پہنچ سکتے ہیں اور دونوں درست ہو سکتے ہیں۔
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
اگر backend پہلے سوال کا جواب ہاں اور دوسرے کا نہیں دے تو آپ کے پاس نیٹ ورک کا کام ہے، manifest میں ترمیم نہیں۔ اگر تیسری سطر پراکسی کہے تو پتہ کبھی زندہ نہ رہتا، اور اس کے برعکس دعویٰ ایک ہفتے کی پیکٹ گرفتاری کا خرچ ہے۔
preserve موڈ نیٹ ورک سے کیا مانگتا ہے
ماخذ محفوظ رکھنے کا مطلب ہے کہ منزل نوڈ کو ٹریفک ایک فعال VPN گیٹ وے کے ذریعے 10.90.0.42 پر واپس بھیجنا ہوگا۔ VPN پول کلسٹر CIDR نہیں ہے، اس لیے کوئی CNI اسے آپ کے لیے بطور ڈیفالٹ روٹ نہیں کرتا۔ آپ خود راستہ شامل کرتے ہیں اور پھر یقینی بناتے ہیں کہ گیٹ وے کا وہ اینڈ پوائنٹ جس کی طرف یہ اشارہ کرتا ہے دوبارہ شیڈولنگ سے بچ جائے۔
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2وہ اگلی چھلانگ pod کا پتہ ہے، اور pod کے پتے حرکت کرتے ہیں۔ راستہ کسی Service VIP یا نوڈ کے ایسے پتے کی طرف موڑیں جو اپنی جگہ رہے، یا مان لیں کہ ہر بے دخلی کے بعد آپ گیٹ وے کے پیچھے بھاگیں گے۔ الٹے راستے کی فلٹرنگ دوسرا جال ہے: سخت موڈ ایسے پیکٹ گرا دیتا ہے جن کا واپسی راستہ اس انٹرفیس سے نہیں ملتا جس پر وہ آئے، اور یہ بالکل محفوظ VPN بہاؤ کی شکل ہے۔
ڈھیلا توثیق اکثر کام کرنے والے واپسی راستے اور ان جوابات کے درمیان فرق ہوتی ہے جو backend چھوڑنے کے بعد غائب ہو جاتے ہیں۔ VPN نوڈ پر masquerade قواعد کو بھی ٹنل رینج نکالنا ہوگا، ورنہ آگے بھیجا گیا پیکٹ pod کے پتے کے ساتھ نکلے گا، چاہے آپ نے کوئی بھی راستہ بنایا ہو۔ اس استثنا کو iptables کو ہاتھ سے ایڈٹ کرنے کے بجائے خود CNI کی ترتیب میں ظاہر کریں، کیونکہ ایجنٹ دوبارہ شروع ہونے پر اپنی زنجیریں دوبارہ لکھتا ہے اور آپ کا ہاتھ سے لکھا اصول ٹھیک اگلی اپ گریڈ تک رہتا ہے۔
NetworkPolicy رسائی کنٹرول ہے، روٹنگ نہیں۔ کسی پالیسی کو سخت کرنا کبھی وہ پتہ بحال نہیں کرے گا جسے masquerade پہلے ہی بدل چکا ہے۔
SNAT کتنا مہنگا ہے، اور اسے کیسے لکھیں
کلسٹر کی طرف سورس NAT سستا ڈیزائن ہے، اور یہ غلطی نہیں۔ backend VPN pod یا نوڈ کا پتہ دیکھتا ہے، لاگ ایک دوسرے سے متفق ہوتے ہیں، اور کوئی واپسی راستہ موجود ہونا ضروری نہیں۔ آپ جو کھوتے ہیں وہ نیٹ ورک کی سطح پر دو کلائنٹس میں تمیز کرنے کی صلاحیت ہے، اس لیے کوٹے، پابندیاں اور آڈٹ نشانات کہیں اور سے آنے چاہئیں۔
عام طور پر وہ کہیں اور ایپلیکیشن ہے: سیشن ٹوکن، دستخط شدہ ہیڈر، یا PROXY پروٹوکول کی سطر جو آپ کے زیرِ کنٹرول پراکسی لکھتا ہے۔ یہ وصول کنندہ کو ایسی شناخت دیتے ہیں جس پر وہ صرف اس وقت بھروسا کر سکتا ہے جب پراکسی راستے میں ہو اور ہیڈر کلائنٹ کی طرف سے مقرر نہ کیا جا سکے۔ runbook میں واضح کریں کہ کون سی لاگو ہوتی ہے، کیونکہ اگلا انجینئر فرض کرے گا کہ لاگ میں درج پتہ کلائنٹ ہے۔ ایسا نہیں ہے، اور ایک واقعہ اس مفروضے کو مہنگا بنانے کے لیے کافی ہے۔
یہ تبادلہ تب تک ایماندار رہتا ہے جب تک لکھا رہے۔
وہ جانچیں جو کام کرنے والے راستے کو خوش قسمت راستے سے الگ کرتی ہیں
تازہ کنکشن سے جانچیں، کیش شدہ سے نہیں، اور دونوں سمتوں میں جانچیں۔ کئی خرابیاں صرف اس لیے وقفے وقفے سے لگتی ہیں کہ نئے بہاؤ دوبارہ لکھا گیا راستہ لیتے ہیں۔
ایک مجاز درخواست کے دوران tuple تین مقامات پر پکڑیں: ڈکرپشن کے فوراً بعد، VPN pod کے اخراجی انٹرفیس پر، اور backend پر۔ اگر ماخذ دوسری اور تیسری گرفت کے درمیان بدلے تو وجہ pod سے نیچے ہے۔ اگر دوسری سے پہلے بدلے تو خود pod ترجمہ کر رہا ہے۔
پھر VPN pod حذف کریں اور دوبارہ شیڈولنگ کے دوران جانچ دہرائیں۔ محفوظ راستہ جو بے دخلی پر ٹوٹ جائے نامکمل ہے، اور وہ NAT قاعدہ بھی جو ایسے پتے سے بندھا ہو جو اب موجود نہیں۔ آخر میں ایسے ماخذ سے ایک درخواست بھیجیں جس کے رد ہونے کی توقع ہے اور تصدیق کریں کہ رد پالیسی سے آتا ہے، کسی غائب راستے سے نہیں۔