Docker کے پورٹ کی اشاعت اور VPN کے ماخذ: دو مطابقات جو آپ سے چھوٹ جاتی ہیں

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

افسانہ: VPN سرور کو اجازت دیں اور کام تمام

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

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

ماخذ: کلائنٹ کا ذخیرہ یا ترجمہ شدہ گیٹ وے

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

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

پورٹ: DNAT اس عدد کو بدلتا ہے جس سے آپ میل کراتے ہیں

Docker iptables کے ساتھ عام Linux برج اشاعت میں، میزبان کی 8443 سے کنٹینر پورٹ 443 تک میپنگ فارورڈنگ فلٹر چلنے سے پہلے ترجمہ ہو جاتی ہے۔ پیکٹ فلٹر تک منزل پورٹ 443 کے ساتھ پہنچتا ہے۔ اس موقع پر 8443 سے میل کھانے والا قاعدہ کبھی فعال نہیں ہوتا، اگرچہ کلائنٹ نے 8443 لکھا تھا۔

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

فیصلہ کریں کہ کون سا عدد ارادہ ظاہر کرتا ہے۔ جب قاعدہ کنٹینر کے اندر کی خدمت کی حفاظت کرے تو DNAT کے بعد کنٹینر پورٹ سے میل کرائیں۔ جب قاعدہ بتانا ہو کہ کلائنٹ نے کیا مانگا، تو conntrack اختیار کے ساتھ اصل منزل سے میل کرائیں، اور اس کے ساتھ آنے والی اضافی میل کی لاگت اور قواعد کی ترتیب کی احتیاط قبول کریں۔

زنجیر: DOCKER-USER، INPUT نہیں

Docker کا iptables رہنما صارف کی فارورڈنگ پالیسی کو DOCKER-USER زنجیر میں رکھتا ہے، جس کا جائزہ Docker کے اپنے فارورڈنگ قواعد سے پہلے لیا جاتا ہے۔ میزبان خدمت سے INPUT زنجیر میں نقل کیا گیا قاعدہ میزبان کی طرف مخاطب ٹریفک چھانتا ہے، کنٹینر کی طرف فارورڈ ہونے والی ٹریفک نہیں۔ یہ غلطی ایسا قاعدہ بناتی ہے جو درست دکھائی دیتا ہے اور کنٹینر کے راستے پر کوئی اثر نہیں ڈالتا۔

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

نئے رابطوں سے تصدیق کریں

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

ان جانچوں کے پیچھے زنجیروں کی ترتیب اور پورٹ ترجمانی کا رویہ Docker کا iptables رہنما میں درج ہے۔ کوئی ترکیب نقل کرنے سے پہلے اسے پڑھیں، اور تصدیق کریں کہ نصب شدہ Docker کون سا backend استعمال کرتا ہے، کیونکہ nftables backend پالیسی کو مختلف طریقے سے یکجا کرتا ہے۔