Windows کنٹینرز اور VPN: مقامی نیٹ ورکنگ کیوں ٹوٹتی ہے
Windows کنٹینر میزبان کی روٹنگ ٹیبل استعمال کرتا ہے، اسی لیے مقامی ذیلی نیٹ کو بلاک کرنے والا VPN کنٹینر کا سابقہ بھی ساتھ لے جاتا ہے۔ Linux موڈ دوسرا راستہ اختیار کرتا ہے۔
ایک ہی لیپ ٹاپ پر، ایک VPN کلائنٹ منسلک ہونے کی حالت میں، Linux کنٹینر آپس میں بات کرتے رہتے ہیں اور Windows کنٹینر رک جاتے ہیں۔ بدلنے والی چیز امیج نہیں؛ پیکٹ میزبان تک جو راستہ لیتے ہیں وہ ہے۔ ڈیفالٹ نیٹ ورک پر Windows کنٹینر میزبان کی روٹنگ ٹیبل اور ترجمہ ادھار لیتے ہیں، اس لیے میزبان کی روٹنگ بدلنے والی پالیسی اُنہیں بھی بدل دیتی ہے۔ کچھ بھی دوبارہ انسٹال کرنے سے پہلے روٹ تلاش سے اس کی تصدیق کریں۔
Windows کنٹینر کے پیکٹ میزبان میں کہاں داخل ہوتے ہیں
ڈیفالٹ nat نیٹ ورک کا کنٹینر Host Networking Service کے سابقے سے پتہ حاصل کرتا ہے، عام طور پر 172.16.0.0/12 کے اندر کہیں، اور مجازی اڈاپٹر کے ذریعے میزبان تک پہنچتا ہے۔ میزبان اُس سابقے کا راستہ رکھتا ہے اور ٹریفک کو اُس اڈاپٹر کی طرف منتقل کرتا ہے جو اس وقت فعال ہے۔ اُس راستے کے درمیان کوئی الگ مجازی مشین نہیں ہے۔
یہی ڈیزائن خرابی کو مشینی بناتا ہے۔ جب کنٹینر پیکٹ بھیجتا ہے تو میزبان کنٹینر سابقے کے لیے روٹ تلاش کرتا ہے۔ جو راستہ جیتتا ہے پیکٹ وہیں جاتا ہے، اور کنٹینر کا اس میں کوئی رائے نہیں۔
VPN کلائنٹ اُس راستے پر کیا بدلتا ہے
کارپوریٹ کلائنٹ اکثر بہت سے راستے اور ایک فلٹر نصب کرتا ہے جو ٹنل فعال رہنے کے دوران مقامی ذیلی نیٹ تک رسائی سے انکار کرتا ہے۔ مقصد دفاعی ہے: متاثرہ مقامی نیٹ ورک محفوظ مشین تک نہیں پہنچنا چاہیے۔ ضمنی اثر یہ ہے کہ میزبان کا راستہ کنٹینر سابقے تک اب مقامی NAT نیٹ ورک نہیں ہے۔
اس کے بجائے تلاش ٹنل سے مطابقت رکھتی ہے اور پیکٹ اُس گیٹ وے کے حوالے کر دیا جاتا ہے جس نے اُس کنٹینر پتے کا کبھی نام نہیں سنا۔ Ping ناکام ہوتا ہے، ایپلیکیشن کا وقت ختم ہو جاتا ہے، اور VPN آئیکن چمکتے ہوئے کنٹینر ٹوٹا ہوا دکھائی دیتا ہے۔ منسلک حالت میں میزبان کی ٹیبل دیکھیں اور حریف راستہ نظر آتا ہے۔
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
Linux کنٹینر مختلف رویہ کیوں رکھتے ہیں
Linux انجن کنٹینر ہلکی مجازی مشین کے اندر چلاتا ہے، اور اُس مشین سے باہر جانے والے کنکشن کنٹینر کی جانب سے میزبان طرف کے پراکسی کے ذریعے کھولے جاتے ہیں۔ ساکٹ میزبان شروع کرتا ہے، اس لیے کنٹینر سابقے کے بارے میں VPN کا قاعدہ اُس پر اسی طرح لاگو نہیں ہوتا، اور کام کا بوجھ نیٹ ورک تک پہنچتا رہتا ہے۔
یہی فرق یہ بھی بتاتا ہے کہ Linux کی ترکیبیں کیوں منتقل نہیں ہوتیں۔ جس Linux کنٹینر کو اپنی ٹنل درکار ہو اُسے TUN ڈیوائس اور NET_ADMIN صلاحیت دی جاتی ہے۔ Windows کنٹینر کسی انٹرفیس کو ڈیوائس کے طور پر ظاہر نہیں کرتے، اس لیے اُس نمونے کا اُس طرف کوئی متبادل نہیں۔
راستہ ثابت کریں، پھر ڈیزائن منتخب کریں
شواہد میزبان سے جمع کریں، کنٹینر سے نہیں، کیونکہ تلاش میزبان کرتا ہے:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"VPN منسلک ہونے سے پہلے ایک بار اور بعد میں ایک بار روٹ آؤٹ پٹ چلائیں۔ اگر دوسرے آؤٹ پٹ میں کنٹینر سابقہ ٹنل اڈاپٹر کی طرف اشارہ کرے تو تشخیص مکمل ہے اور کنٹینر دوبارہ شروع کرنے سے مدد نہیں ملے گی۔
پہلا آپشن پالیسی کا فیصلہ ہے: نیٹ ورک کے مالک سے پوچھیں کہ کیا اس ڈیوائس کے لیے مقامی LAN رسائی کی اجازت دی جا سکتی ہے۔ کئی کارپوریٹ کلائنٹ اسے سیٹنگ کے طور پر دیتے ہیں، لیکن یہ جان بوجھ کر بنائی گئی حد کو کمزور کرتا ہے۔ اسے مالک اور جائزے کی تاریخ کے ساتھ دستاویزی استثنا کے طور پر مانگیں۔ ہر ڈیوائس کے لیے وہ ٹوگل جس کی طرف کوئی واپس نہیں آتا، وہی راستہ ہے جس سے دفاعی پالیسی خاموشی سے غائب ہو جاتی ہے۔
جہاں پالیسی کو قائم رہنا ہے وہاں راستے سے لڑنے کے بجائے کام کا بوجھ منتقل کریں۔ واضح ذیلی نیٹ اور گیٹ وے والا شفاف نیٹ ورک کنٹینر کو مقامی لنک پر رکھتا ہے، Linux کا بوجھ VM پراکسی کے پیچھے چلتا ہے، اور اپنے کلائنٹ کے ساتھ الگ مجازی مشین اپنی پالیسی برقرار رکھتی ہے۔ ایک جان بوجھ کر منتخب کریں اور کنٹینر کے اندر سے جانچیں، کیونکہ صارف کی درخواست وہیں پیدا ہوتی ہے۔