VPN پر Docker کنٹینر تک رسائی نہیں؟ سب نیٹ کا موازنہ کریں

Docker ایک سب نیٹ دیتا ہے جس پر VPN بھی دعویٰ کرتا ہے۔ دونوں پتہ منصوبے موازنہ کریں، پھر ایسی مرمت چنیں جو دوبارہ جڑنے پر بھی قائم رہے۔

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

ترتیب بدلنے سے پہلے راستہ پڑھیں

اُس نیٹ ورک سے شروع کریں جو Docker نے واقعی بنایا۔ IPAM بلاک پتہ منصوبہ ہے، اور سب نیٹ وہ سطر ہے جو اہم ہے:

docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]

Compose بطور ڈیفالٹ ہر نئے منصوبے کو /16 مختص کرتا ہے، اس لیے دو سروسز 65,536 پتوں کی حد میں رہ سکتی ہیں۔ یہی چوڑائی اس بات کی وجہ ہے کہ اوورلیپ عام ہیں: بے ترتیب چنا گیا /16 اتنا بڑا ہوتا ہے کہ اُس سائٹ کو نگل جائے جہاں آپ سرنگ کے ذریعے پہنچتے ہیں، اور کسی کو تب تک پتہ نہیں چلتا جب تک سرنگ اوپر نہ آئے۔

پھر ایک کنٹینر پتے کے لیے راستے کے انتخاب کا موازنہ کریں — ایک بار سرنگ بند ہونے پر اور ایک بار کھلی ہونے پر:

ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1

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

/16 ٹکراؤ آسانی سے کیوں ہوتا ہے

Docker پل نیٹ ورک نجی تالابوں سے لیتا ہے، اور ڈیفالٹ تالاب 172.16.0.0/12 بلاک سے /16 ٹکڑوں میں آتا ہے۔ کارپوریٹ نیٹ ورک اکثر وہی نجی جگہ استعمال کرتے ہیں، اور ریموٹ رسائی VPN وہ پری فکس ہر جڑنے والے کلائنٹ کی طرف دھکیلتا ہے۔ جب دونوں فریق سمجھیں کہ 172.18.0.0/16 اُن کا ہے، تو ایک روٹنگ جدول میں دو متضاد دعوے ہوتے ہیں۔

فاتح کا فیصلہ پری فکس کی لمبائی کرتی ہے، راستوں کی ترتیب نہیں۔ 10.0.0.0/8 دھکیلنے والی سرنگ 172.18.0.0/16 کے پل راستے کو نہیں ہراتی، کیونکہ /8 کم مخصوص ہے۔ 172.18.0.0/16 یا اُس کے اندر 172.18.5.0/24 دھکیلنے والی سرنگ ہرا دیتی ہے۔ اسی لیے ایک لیپ ٹاپ دفتر کے نیٹ ورک پر چلتا ہے اور اُسی VPN کے ساتھ ہوٹل کے Wi-Fi پر ناکام ہوتا ہے: کلائنٹ کو مختلف پری فکس ملتے ہیں۔

وہی جدول دوسری سمت بھی چلاتی ہے۔ 10.8.4.20 پر اندرونی ہوسٹ درکار کنٹینر پیکٹ اپنے پل گیٹ وے کو بھیجتا ہے، اور پھر ہوسٹ اُسے سرنگ میں روٹ کرتا ہے۔ وہ راستہ عام طور پر چلتا ہے کیونکہ ہوسٹ NAT کرتا ہے، مگر یہ ناکام ہوتا ہے جب کارپوریٹ فریق صرف لیپ ٹاپ کا VPN پتہ قبول کرے، یا جب ریورس پاتھ فلٹرنگ غیر متناسب جواب گرا دے۔

تین مرمتوں کا موازنہ کریں

نکلنے کے صرف تین راستے ہیں، اور وہ اس میں مختلف ہیں کہ کس کی منظوری ضروری ہے اور ایک کو لاگو کرتے وقت کیا ٹوٹتا ہے۔

RepairWho owns itWhat it costs
Renumber the container networkYouRecreates the network, restarts services, invalidates literal addresses in configs and scripts
Exclude your range from the tunnelNetwork teamChanges what every laptop sees, needs a change request and a client profile update
Reach the service through a published portYou and the clientOne port only, no direct container-to-container routing across the tunnel

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

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

جان بوجھ کر ایک حد مقرر کریں

ایک منصوبے کے لیے، compose فائل میں سب نیٹ کا اعلان کریں تاکہ منصوبہ مشترکہ تالاب سے لینا بند کرے:

networks:
  default:
    ipam:
      config:
        - subnet: 10.201.7.0/24

وہ حد اُس رجسٹر سے لیں جو آپ کی ٹیم رکھتی ہے، نہ کہ اُس مثال سے جو تلاش کے دوران ملی۔ اِسے VPN کے دھکیلے گئے پری فکس، لوگوں کے گھریلو LAN اور اسی ہوسٹ کے دیگر کنٹینر نیٹ ورکس کے خلاف جانچیں۔ پھر دوبارہ تشکیل کی منصوبہ بندی کریں، کیونکہ موجودہ نیٹ ورک اپنا پرانا سب نیٹ رکھتا ہے: docker compose down، پھر up -d۔ docker network rm انکار کرتا ہے جب تک اینڈ پوائنٹس منسلک ہوں، اور فائل میں کوئی بھی ipv4_address اندراج نئی حد کے اندر ہونا چاہیے۔

اُن نیٹ ورکس کے لیے جو Docker خود بناتا ہے، /etc/docker/daemon.json میں ڈیمون تالاب مقرر کریں:

{
  "default-address-pools": [
    { "base": "10.201.0.0/16", "size": 24 },
    { "base": "10.202.0.0/16", "size": 24 }
  ]
}

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

Linux پل اور Docker Desktop مختلف طریقے سے ناکام ہوتے ہیں

Linux ہوسٹ پر، کنٹینرز ہوسٹ کے نام کی جگہ میں پلوں پر بیٹھتے ہیں۔ سب کچھ ایک ہی جدول طے کرتی ہے، اس لیے اوپر کا موازنہ ہی پوری کہانی ہے: پل کا راستہ پڑھیں، سرنگ کا راستہ پڑھیں، اور دیکھیں کہ اصل کنٹینر پتے کے لیے کون جیتتا ہے۔

Docker Desktop کنٹینرز کو اپنے NAT والی VM کے پیچھے رکھتا ہے۔ ہوسٹ کو کنٹینر پتے تک کوئی راستہ نہیں ہوتا؛ وہ سروس تک شائع شدہ پورٹ کے ذریعے پہنچتا ہے، عام طور پر 127.0.0.1 سے بندھی۔ اس لیے VPN کلائنٹ کسی بھی سب نیٹ اوورلیپ کے بغیر سروس توڑ سکتا ہے: یا VM کی اندرونی حد کے لیے راستہ نصب کر کے، یا سرنگ جڑی ہونے کے دوران loopback ٹریفک روک کر۔ اگر ہوسٹ پر ip route get بتائے کہ کنٹینر پتے کے لیے کوئی راستہ نہیں، تو یہ متوقع ہے، خرابی نہیں۔

عملی نتیجہ یہ ہے کہ آپ پہلے کہاں دیکھتے ہیں۔ Linux پر، روٹنگ جدول سے شروع کریں۔ Desktop پر، شائع شدہ پورٹ اور VPN کلائنٹ کے فائر وال قواعد سے شروع کریں، پھر دیکھیں کہ VM کا اندرونی سب نیٹ سرنگ کے دھکیلے گئے کسی چیز سے ٹکراتا ہے یا نہیں۔

سرنگ کھلی رکھ کر تصدیق کریں

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

  1. کنٹینر کے اصل پتے کے ساتھ ہوسٹ سے ip route get۔
  2. کسی دوسرے کنٹینر سے درخواست، تاکہ ثابت ہو کہ سروس خود صحت مند ہے۔
  3. سرنگ کھلی ہونے پر کلائنٹ سے curl -sv http://127.0.0.1:8080/، پھر LAN کی مشین سے کنٹینر پتے تک traceroute -n۔
  4. اگر درخواست ہوسٹ تک پہنچے مگر جواب غائب ہو جائے تو sysctl net.ipv4.conf.all.rp_filter۔

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

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