Docker پورٹ کی اشاعت بمقابلہ VPN: جواب کہاں جاتا ہے

مکمل ٹنل والا VPN اوپر آنے کے بعد بھی میزبان SSH کا جواب دیتا رہتا ہے، جبکہ اسی مشین پر Docker سے شائع شدہ سروس خاموش ہو جاتی ہے۔ سننے والے میں کوئی خرابی نہیں: کنٹینر چل رہا ہے، پورٹ میپنگ موجود ہے، اور پیکٹ پہنچتا ہے۔ کنٹینر صحت مند ہے اور درخواست واقعی اس تک پہنچتی ہے۔ فرق یہ ہے کہ Linux اپنا راستہ چنتے وقت جواب کہاں سے شروع ہوتا ہے، اور یہی فرق طے کرتا ہے کہ نیچے دیے گئے دو ڈیزائنوں میں سے آپ کو کون سا چاہیے۔

ٹوپل کا تعاقب منزل NAT کے ذریعے کریں

ایک میزبان لیں 192.0.2.10 پر، جو TCP 2222 کو 172.30.240.5:22 پر موجود کنٹینر تک شائع کرتا ہے۔ 198.51.100.25 سے آنے والی درخواست کنٹینر تک پہنچنے سے پہلے ترجمہ ہوتی ہے، اور کنٹینر اپنی ہی حیثیت میں جواب دیتا ہے۔

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

میزبان کے راستے کے فیصلے پر جواب اب بھی کنٹینر کا ماخذ پتہ رکھتا ہے۔ ریورس ترجمہ بعد میں شائع شدہ ٹوپل بحال کرتا ہے، اسی لیے پیکٹ ٹھیک اسی لمحے غلط دکھتا ہے جب راستہ چنا جاتا ہے۔

صرف میزبان کے لیے بنایا گیا اصول اسے کیوں چھوڑ دیتا ہے

ایسا اصول جو WAN جدول صرف 192.0.2.10 سے آنے والے پیکٹوں کے لیے چنتا ہے، میزبان کے اپنے ڈیمنز کو محیط کرتا ہے اور اس آگے بھیجے گئے جواب کو بالکل چھوڑ دیتا ہے۔ جواب پر ماخذ پتہ 172.30.240.5 ہے، میزبان نہیں۔

ضرورت سے زیادہ اصلاح یہ ہے کہ کنٹینر سے سب کچھ WAN کے ذریعے روٹ کیا جائے، جو کنٹینر کے غیر متعلقہ باہر جانے والے کنکشنز کو بھی VPN سے مستثنیٰ کر دیتا ہے۔ یہ مانگی گئی پالیسی سے مختلف ہے، اور عام طور پر بعد میں کسی کو حیران کرتا ہے۔

DNAT کے بعد مماثلت ایک اور ہک ہے

Docker کی فائر وال دستاویز بیان کرتی ہے کہ عام صارف فلٹرنگ DNAT کے بعد کا منزل دیکھتی ہے, اس لیے عام اصول میں شائع شدہ پورٹ 2222 کی مماثلت کنٹینر پورٹ 22 کی مماثلت کے برابر نہیں۔ اگر اصل ٹوپل اہم ہے تو یہ اندازہ لگانے کے بجائے کہ کون سا پورٹ نظر آتا ہے، معاونت شدہ اصل منزل کا طریقہ کار استعمال کریں۔

یہ ہک الجھن ایسے اصول بناتی ہے جو درست دکھتے ہیں اور کبھی مماثل نہیں ہوتے۔ پالیسی دوبارہ لکھنے سے پہلے خود اصول پر کاؤنٹر دیکھیں۔ صفر ہٹ والا اصول آپ کو بتاتا ہے کہ اس کا جائزہ ایسی جگہ ہو رہا ہے جہاں پیکٹ کبھی نہیں پہنچتا۔

ڈیزائن A: فیصلہ کنکشن کی حالت کے طور پر لے جائیں

کنکشن مارک داخلی فیصلہ ترجمے کے پار لے جا سکتا ہے، لیکن اہم راستے کی تلاش سے پہلے اسے پیکٹ پر بحال کرنا ہوتا ہے۔ مراحل یہ ہیں:

1. ایسا مارک فیلڈ اور اصول ترجیح مختص کریں جو Docker، VPN یا کسی اور پالیسی مالک سے متصادم نہ ہوں۔
2. صرف مطلوبہ نئی WAN کنکشن کی شناخت DNAT سے پہلے کے اس مقام پر کریں جہاں کنکشن ٹریکنگ دستیاب ہو۔
3. اصل درخواست کو خود WAN جدول میں دھکیلے بغیر فیصلہ کنکشن مارک پر درج کریں۔
4. جواب کی سمت میں، روٹنگ سے پہلے صرف اپنے مارک بٹس پیکٹ پر بحال کریں۔
5. مکمل WAN جدول اتنا جلدی چنیں کہ VPN اصول پہلے جیت نہ سکے۔

اس جدول کو حقیقی منسلک راستے اور گیٹ وے درکار ہیں۔ راستہ نہ ہونے پر متعین رویہ بھی درکار ہے۔ ٹنل میں خاموشی سے گر جانا بدترین نتیجہ ہے، کیونکہ ترتیب اب بھی کام کرتی دکھتی ہے۔ اس کے بجائے بند حالت میں ناکام ہوں اور اسے لاگ کریں۔

ڈیزائن B: میزبان پر ختم کریں

کنٹینر کے سامنے TCP پراکسی یا ریورس پراکسی جیسا جان بوجھ کر ترتیب دیا گیا میزبان طرفہ فرنٹ اینڈ، جواب کو میزبان کے پتے سے پیدا ہوتا رکھتا ہے۔ پھر میزبان کے لیے لکھے گئے اصول توقع کے مطابق برتاؤ کرتے ہیں، اور کنٹینر اپنے نجی نیٹ ورک پر ہی رہتا ہے۔

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

تبدیلی کی تصدیق کریں، نیت کی نہیں

عوامی طرف سے نئی مجاز کنکشن کھولیں اور تصدیق کریں کہ جواب مطلوبہ انٹرفیس سے باہر جاتا ہے۔ پھر دیکھیں کہ کنٹینر کی شروع کردہ غیر متعلقہ درخواست اب بھی VPN کی پیروی کرتی ہے۔

ایک اصول جانچنے کے لیے مشین کا کنکشن جدول فلش نہ کریں: موجودہ اندراجات اپنی پرانی میپنگ رکھتے ہیں، اور فلش میزبان پر باقی سب کچھ توڑ دیتا ہے۔ پورٹ شائع کرنا رسائی کی صلاحیت متعین کرتا ہے۔ یہ جواب کا راستہ متعین نہیں کرتا۔ منتخب ڈیزائن اس کے جدول ناموں کے ساتھ لکھ لیں، تاکہ کسی واقعے کے دوران اگلے شخص کو اسے دوبارہ دریافت نہ کرنا پڑے۔