VPN کنٹینر میں DNAT: INPUT نہیں، فارورڈنگ

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

ترجمے کے بعد پیکٹ کا پیچھا کریں

10.90.0.0/24 کا کلائنٹ پول اور 10.90.0.1 کا ٹنل پتہ لیں۔ ایک پل پر دو کنٹینر ہیں: 192.0.2.2 VPN چلاتا ہے اور 192.0.2.3 ایپلیکیشن چلاتا ہے۔ ایک کلائنٹ 10.90.0.1:8080 سے جڑتا ہے، اور VPN کنٹینر کے نام کی جگہ میں DNAT اصول اسے ایپلیکیشن کے اصل پتے اور پورٹ پر دوبارہ لکھتا ہے۔ پھر کوئی راستہ پیکٹ کو پل کے پار بھیجتا ہے۔ یہ پتے مثال کے طور پر ہیں، تعیناتی کی ترکیب نہیں۔

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

اجازت فارورڈ راستے کی ہے

VPN کنٹینر کو IP فارورڈنگ اور کلائنٹ پول، ایپلیکیشن کے پتے اور مطلوبہ پورٹ تک محدود فارورڈنگ فیصلہ درکار ہے۔ قائم شدہ جوابات کو اپنی اجازت چاہیے۔ اصل ٹنل پتے سے ملنے والا اصول DNAT کے بعد نہیں ملے گا، کیونکہ منزل پہلے ہی بدل چکی ہے۔ INPUT اجازت ایسی ٹریفک کے لیے غلط ہک ہے جو اب اس میزبان کو مخاطب نہیں۔

دائرہ تنگ رکھیں: ایک ماخذ کی حد، ایک منزل، ایک سروس۔ کھلا فارورڈنگ اصول لکھنا آسان اور بعد میں اس کا دفاع بہت مشکل ہے۔

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Docker کی زنجیریں آپ کے کنٹینر کی زنجیریں نہیں

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

Docker فائر وال حوالہ ان زنجیروں اور DNAT کے بعد ملنے کی وضاحت کرتا ہے۔ Docker کے فائر وال انتظام کو بند کر کے یا ہر زنجیر کو کھلا بنا کر غائب منظوری درست نہ کریں، کیونکہ اس سے وہ حد ہٹ جاتی ہے جو آپ استعمال کرنا چاہتے ہیں۔

واپسی کے راستے کو سوچا سمجھا انتخاب بنائیں

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

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

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