ڈیو کنٹینر VPN-صرف ہوسٹ تک نہیں پہنچ پا رہا: کہاں دیکھیں

نجی API آپ کے ڈیسک ٹاپ براؤزر میں کھلتا ہے اور ڈیولپمنٹ کنٹینر میں ناکام ہو جاتا ہے۔ یہ تضاد نہیں ہے، اور یہ شاذ و نادر ہی خود VPN ہوتا ہے۔ براؤزر کی درخواست اور ناکام درخواست مختلف عملوں نے، مختلف resolver، proxy اور راستوں کے ساتھ، اور اکثر بالکل مختلف نیٹ ورک نیم اسپیس سے بھیجی۔ "میرے لیپ ٹاپ پر" کا مطلب Windows ہوسٹ، ایک WSL ڈسٹری بیوشن، Docker Desktop کی ورچوئل مشین اور اُس VM کے اندر موجود کنٹینر، یعنی چار سیاق و سباق ہو سکتے ہیں جن میں سے ہر ایک ایک ہی ہوسٹ نام کا مختلف جواب دے سکتا ہے۔ ایک بھی سیٹنگ کو چھونے سے پہلے معلوم کریں کہ ناکام ہونے والا عمل کون سا استعمال کر رہا ہے۔

سیٹنگ بدلنے سے پہلے عمل کا پتہ لگائیں

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

docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route

Windows پر، wsl -l -v بتاتا ہے کہ ڈسٹری بیوشن WSL 2 کے تحت چل رہی ہے یا نہیں، جو اسے اپنے الگ ورچوئل سوئچ کے پیچھے رکھتا ہے۔ یہی تفصیل طے کرتی ہے کہ کنٹینر ہوسٹ کی روٹنگ ٹیبل شیئر کرتا ہے یا ایسے NAT کے پیچھے بیٹھا ہے جسے ہوسٹ تک پہنچنے کے لیے فارورڈ شدہ پورٹ یا ہوسٹ نام درکار ہے۔

ایک درخواست کو مستقل رکھیں اور موازنہ کریں

نجی ہوسٹ پر ایک بے ضرر اینڈ پوائنٹ منتخب کریں اور ہر موازنے کے لیے وہی استعمال کریں: براؤزر سے، ہوسٹ ٹرمینل سے، WSL ڈسٹری بیوشن سے اور کنٹینر کے اندر سے۔ ہر کوشش کے لیے چار چیزیں ریکارڈ کریں: حل شدہ پتہ، آیا proxy استعمال ہوا، ناکامی کی قسم اور گزرا ہوا وقت۔ نام کی تلاش، کنکشن قائم ہونا، TLS کی توثیق اور HTTP اسٹیٹس چار مختلف مسائل ہیں، اور انہیں "یہ کام نہیں کرتا" میں ملا دینا ایک صبح ضائع کر دیتا ہے۔

موازنہ اُسی کنٹینر کے اندر چلائیں جو ناکام ہو رہا ہے، ٹائم آؤٹ کے ساتھ تاکہ خاموش فائر وال ٹرمینل کو منٹوں تک نہ روکے۔ نیا کنٹینر انجن کا نیٹ ورک سیاق و سباق دوبارہ پیدا کرتا ہے مگر ایپلیکیشن کنٹینر کی نیم اسپیس، proxy متغیرات یا resolver نہیں، اسی لیے اصل کنٹینر میں docker exec ہی مستند جانچ ہے اور سائیڈ کار صرف یہ الگ کرنے کا طریقہ ہے کہ فرق انجن میں ہے یا کنٹینر میں:

docker exec -it app /bin/sh -c "getent hosts api.internal; curl -v --max-time 8 https://api.internal/ 2>&1 | tail -20"
docker run --rm --network container:app curlimages/curl:latest -sv --max-time 8 https://api.internal/ 2>&1 | tail -20

alpine کی بنیادی امیج میں busybox ہے اور curl نہیں، اور یہی ایسی تفصیل ہے جو کاپی شدہ تشخیصی بلاک کو ناکام کر دیتی ہے: ایسی امیج منتخب کریں جس میں کلائنٹ ہو، یا اسی رن کے اندر اسے شامل کریں۔ غیر متعلقہ عوامی سائٹس سے موازنہ کچھ الگ نہیں کرتا۔ اگر https://example.com کنٹینر سے کام کرتا ہے تو آپ نے صرف یہ جانا کہ کنٹینر کو انٹرنیٹ رسائی ہے اور اس بارے میں کچھ نہیں کہ وہ ٹنل کے ذریعے نجی پتہ تک پہنچ سکتا ہے یا نہیں۔ اسی طرح نیا ٹرمینل کھولنا صرف یہ ثابت کرتا ہے کہ نیا ٹرمینل کام کرتا ہے، یہ نہیں کہ وہ ناکام ایپلیکیشن کے ساتھ کوئی رن ٹائم شیئر کرتا ہے۔

Docker Desktop VPN کے ساتھ کام کر سکتا ہے

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

جو اب بھی اہم ہے وہ استعمال شدہ backend، کلائنٹ کی اسپلٹ ٹنل پالیسی، اور وہ resolver ترتیب ہے جو VM کو ملی۔ ایسا VPN کلائنٹ جو راستے نصب کرتا ہے مگر DNS نہیں، یا ایسا DNS سرور دھکیلتا ہے جس تک VM نہیں پہنچ سکتا، ہوسٹ کے کام کرنے کے دوران کنٹینر کے اندر نام کی تلاش کی ناکامی پیدا کرتا ہے، کیونکہ ہوسٹ کے پاس اضافی resolver یا محفوظ شدہ جواب ہوتا ہے۔ یہ کنٹینر کے لباس میں resolver کا مسئلہ ہے۔ یہ آپ کی ہر VPN دوبارہ کنکشن کے باوجود برقرار رہتا ہے، کیونکہ ٹنل پہلے ہی وہ ٹریفک لے رہی ہے جو آپ نے اسے لے جانے کو کہا تھا۔

پتوں کا اوورلیپ اور MTU مختلف ناکامیاں ہیں

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

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40

دوسری MTU کا مسئلہ ہے۔ اگر کنکشن قائم ہو جائے اور TLS مکمل ہو جائے مگر بڑے جوابات رک جائیں تو آپ کا مسئلہ پیکٹ کے سائز کا ہے، اجازت کا نہیں، اور DNS ریکارڈ بدلنا اسے کبھی ٹھیک نہیں کرے گا۔ کچھ بھی بدلنے سے پہلے چھوٹی اور بڑی درخواست سے جانچیں اور دونوں نتائج ریکارڈ کریں۔

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

proxy کی ترتیب فی عمل ہے، فی مشین نہیں

کنٹینر کے اندر، localhost اُسی کنٹینر کے اپنے نیٹ ورک سیاق و سباق کا نام ہے، اس لیے ہوسٹ پر چلنے والا proxy وہاں اُس نام سے قابلِ رسائی نہیں۔ Docker Desktop ہوسٹ تک رسائی کے لیے host.docker.internal فراہم کرتا ہے، اور Linux پر آپ اسے --add-host=host.docker.internal:host-gateway کے ساتھ واضح طور پر شامل کرتے ہیں۔ بہرحال، وہ نام آپ کو ہوسٹ تک راستہ دیتا ہے؛ یہ proxy سروس پیدا نہیں کرتا اور نہ آپ کو اسے استعمال کرنے کا اختیار دیتا ہے۔

اصل ماحول کے لیے فراہم کردہ proxy پتہ اور پورٹ استعمال کریں، اور دیکھیں کہ اسے کون پڑھ رہا ہے۔ انٹرایکٹو شیل میں ایکسپورٹ کیے گئے متغیرات ہر ایڈیٹر ایکسٹینشن، لینگویج سرور، بلڈ ٹول اور بیک گراؤنڈ ڈیمون کو خود بخود کنفیگر نہیں کرتے۔ اہم وہ عمل ہے جس نے ناکام درخواست بھیجی، اس لیے اُس کے ماحول کا معائنہ کریں، اپنے ٹرمینل کے ماحول کا نہیں۔

آخر میں، حل کو خود وضاحت کرنے دیں۔ مفید حل اُس حد کا نام لیتا ہے جو غلط تھی، وہ سیٹنگ جو اسے بدلی، اور اُن عملوں کا مجموعہ جن پر اب یہ اثر ڈالتا ہے۔ VPN، ایڈیٹر اور انجن کو باری باری ری اسٹارٹ کرنا علامت بدل سکتا ہے، مگر ایسا کچھ پیچھے نہیں چھوڑتا جسے اگلا شخص استعمال کر سکے۔