Docker: ایک کنٹینر کو VPN کے ذریعے چلائیں اور دوسرے کو براہِ راست رکھیں
ٹنل کو اس کا اپنا کنٹینر دیں، صرف ان سروسز کو جو اس کی ضرورت رکھتی ہیں وہ نیم اسپیس بانٹنے دیں، پھر مالک کے بعد آنے والی چیزوں کا حساب رکھیں: پورٹس، localhost، DNS.
ایک ہوسٹ، دو ورک لوڈز اور ایک تقاضا جو انہیں الگ کرتا ہے: ایک ڈاؤن لوڈ کلائنٹ جسے تجارتی VPN سے باہر آنا ہے، اور ایک انتظامی انٹرفیس جسے ہوسٹ کا کنکشن استعمال کرتے رہنا ہے۔ ہوسٹ پر VPN کلائنٹ انسٹال کرنا تقاضا فوراً پورا نہیں کرتا، کیونکہ پھر دونوں ورک لوڈز ایک ہی اخراج بانٹتے ہیں۔ جو نمونہ واقعی کام کرتا ہے وہ یہ ہے کہ ٹنل کو اس کے اپنے کنٹینر میں منتقل کیا جائے اور صرف ان ورک لوڈز کو اجازت دی جائے جنہیں اس کی ضرورت ہے اس کنٹینر کے نیٹ ورک نیم اسپیس میں شامل ہونے کی۔ باقی سب معمول کا Docker راستہ رکھتا ہے، اور آگے آنے والی تفصیلات اس بات کے نتائج ہیں کہ نیم اسپیس کس کی ملکیت ہے۔
مشترکہ نیم اسپیس قواعد کیوں بدلتا ہے
دوسرے کے نیم اسپیس میں شامل ہونے والا کنٹینر اپنا نیٹ ورک اسٹیک نہیں پاتا۔ وہ اسی انٹرفیس، اسی روٹنگ جدول اور اسی loopback کو دیکھتا ہے جو اس کنٹینر کا ہے جس میں وہ شامل ہوا، اور اسی لیے یہ نمونہ مفید ہے: ورک لوڈ عام طور پر حل کر کے جڑتا ہے، اور نیچے کا ٹنل اطلاق کو بتائے بغیر ٹریفک پکڑ لیتا ہے۔ قیمت یہ ہے کہ ہر نیٹ ورک سے متعلق سیٹنگ کا اب ایک ہی مالک ہے، اور شامل ہونے والا کنٹینر وہ نہیں ہے۔
یہ ملکیت کا قاعدہ بیشتر کنفیگریشن سوالات کا جواب ان کے پوچھے جانے سے پہلے دے دیتا ہے۔ اگر سیٹنگ نیٹ ورک اسٹیک میں رہتی ہے تو وہ سائیڈ کار کی ہے۔ اگر وہ عمل کی وضاحت کرتی ہے تو وہ ورک لوڈ کے ساتھ رہتی ہے۔
loopback وہ حصہ ہے جو لوگوں کو حیران کرتا ہے۔ شامل ہونے والے کنٹینر کے اندر، localhost سائیڈ کار کے loopback پر حل ہوتا ہے، اپنے کسی نجی پر نہیں، اس لیے 127.0.0.1 پر بندھ کر علیحدگی کی توقع رکھنے والی سروس اب وہ پتہ ٹنل کنٹینر کے ساتھ بانٹتی ہے۔
پورٹس اس کنٹینر پر شائع کریں جو نیم اسپیس کا مالک ہے
پورٹ میپنگ نیم اسپیس کے مالک کی ہے، چاہے سننے والا عمل دوسرے کنٹینر میں چل رہا ہو۔ میپنگ سائیڈ کار پر اعلان کریں، اور ورک لوڈ اپنی عمل کی کنفیگریشن کو اچھوتا رکھے۔ شامل ہونے والی سروس پر میپنگ اثر انداز نہیں ہو سکتی، چاہے انجن اسے رد کرے یا کنٹینر کے شروع ہونے کے طریقے کے مطابق خاموشی سے نظرانداز کرے، اور اسی لیے ایک لمحہ پہلے قابلِ رسائی انٹرفیس نمونہ لاگو ہوتے ہی غائب ہو جاتا ہے۔
services:
gluetun:
image: qmcgaw/gluetun
cap_add: [NET_ADMIN]
ports: ["8080:8080"]
client-vpn:
image: example/client
network_mode: "service:gluetun"
client-direct:
image: example/client
ports: ["8081:8080"]اس بلاک کو تین سروسز کے بجائے تین فیصلے سمجھیں۔ سائیڈ کار ٹنل اور شائع شدہ پورٹ کی مالک ہے؛ شامل ہونے والا کلائنٹ کوئی نیٹ ورک اعلان نہیں کرتا؛ براہِ راست کلائنٹ ڈیفالٹ نیٹ ورک پر اپنی میپنگ رکھتا ہے۔ صلاحیت NET_ADMIN ہی سائیڈ کار کو انٹرفیس بنانے اور راستے بدلنے دیتی ہے، اور یہی وجہ ہے کہ اس کنٹینر کو ان ورک لوڈز سے زیادہ مراعات درکار ہیں جن کی وہ خدمت کرتا ہے۔
براہِ راست رہنے والی سروس اپنا نیٹ ورک رکھتی ہے
جس ورک لوڈ کو ٹنل سے نہیں گزرنا چاہیے وہ ڈیفالٹ پل یا اپنا صارف کی جانب سے متعین نیٹ ورک اپنے شائع شدہ پورٹ اور اپنے اخراج کے ساتھ رکھتا ہے۔ دو کنٹینرز کے نام سے بات کر سکنے کے لیے اسے سائیڈ کار کے نیٹ ورک سے جوڑنے کا لالچ ہوتا ہے، مگر وہی ایک قدم اس کی ٹریفک کو خاموشی سے ٹنل میں منتقل کر دیتا ہے۔ اگر انہیں ایک دوسرے تک پہنچنا ہے تو الگ صارف متعین نیٹ ورک بنائیں، دونوں کو اس سے جوڑیں، اور سائیڈ کار کو باہر جانے کا واحد راستہ رہنے دیں۔
دو سوالات الگ رکھیں: کون سے کنٹینرز ایک دوسرے تک پہنچ سکتے ہیں، اور کون کہاں سے باہر جاتا ہے۔ انہیں ملانا ہی اس ڈیزائن کے دوبارہ پورے ہوسٹ پر محیط VPN بننے کا عام ترین طریقہ ہے۔
پہلے گھنٹے کے لیے ناکامیوں کا میٹرکس
زیادہ تر پہلی کوششیں چار طریقوں میں سے کسی ایک سے ناکام ہوتی ہیں، اور ہر ایک کی وجہ الگ ہے۔ انہیں اسی ترتیب سے جانچیں، کیونکہ پہلے دو تقریباً ہر رپورٹ کی وضاحت کرتے ہیں۔
| Symptom | Likely cause |
|---|---|
| Web UI unreachable after the change | Port mapping declared on the joining container instead of the sidecar |
| Both containers show the provider's exit address | The direct service was attached to the sidecar network |
| Internal names stop resolving | Resolver settings live on the host, not in the shared namespace |
| Health check fails but the app works | The check probes localhost, which now means the sidecar |
چوتھی سطر وہی ہے جسے لوگ غلطی سے ایپلیکیشن کی خرابی سمجھتے ہیں۔ ورک لوڈ کے اپنے loopback کے خلاف لکھی گئی جانچ اب ٹنل کنٹینر کو جانچ رہی ہے، اس لیے وہ یا ناکام ہوتی ہے یا بالکل غلط سروس کی اطلاع دیتی ہے۔
جب ایک ہی ہوسٹ نام کو ٹنل کی ضرورت ہو
کبھی کبھی پورا ٹنل زیادہ ہوتا ہے: ایک اندرونی نام کو کارپوریٹ VPN سے گزرنا ہوتا ہے جبکہ مقامی ساکٹ یا ڈسپلے کنکشن چلتا رہتا ہے۔ کنٹینر کے اندر پورا ٹنل اس راستے اور ہوسٹ کو مخاطب ہر چیز کو توڑ دیتا ہے، اس لیے صرف ضروری سابقہ کو روٹ کریں۔ کلائنٹ کے گرد تقسیم شدہ روٹنگ ریپر یہ کرتا ہے، نامزد ہوسٹ کو ٹنل سے بھیجتا ہے اور باقی سب کے لیے سابقہ راستہ اچھوتا چھوڑ دیتا ہے۔
یہ تب چنیں جب آپ کو صرف ایک سروس تک پہنچنا ہو اور کنٹینر کی ساری ٹریفک منتقل کرنے کی کوشش نہ کر رہے ہوں۔ یہ سائیڈ کار سے مختلف آلہ ہے اور مختلف سوال کا جواب دیتا ہے۔
تصدیق کریں، پھر اسے دوبارہ شروع ہونے پر قائم رہنے والا بنائیں
ہر کنٹینر سے پوچھیں کہ وہ کس پتے سے آتا دکھتا ہے۔ ٹنل والے کو فراہم کنندہ کا پتہ چھاپنا چاہیے اور براہِ راست والے کو ہوسٹ کا اخراج۔ یکساں جوابات کا مطلب ہے کہ براہِ راست سروس نے غلط نیم اسپیس ورثے میں پائی ہے یا ہوسٹ سطح کا VPN اب بھی سب کچھ پکڑ رہا ہے، اور وہ دو اصلاحات مختلف ہیں۔ ہر compose ترمیم کے بعد جانچ دوبارہ چلائیں، کیونکہ ایک نقل شدہ سروس بلاک مسئلہ واپس لانے کے لیے کافی ہے۔
تین چیزیں بعد میں ٹوٹنے کی عادت رکھتی ہیں۔ DNS نیم اسپیس کے مالک کی پیروی کرتا ہے، اس لیے حل کنندہ اور تلاش ڈومین کی سیٹنگز ہوسٹ پر نہیں بلکہ سائیڈ کار پر ہونی چاہئیں۔ پورٹ فارورڈنگ والا VPN دوبارہ جڑنے پر اپنا سننے والا پورٹ بدلتا ہے، اس لیے فراہم کنندہ کا فارورڈ شدہ پورٹ اور کنٹینر کی جانب سننے والا پورٹ کلائنٹ کنفیگریشن یا پورٹ میپنگ میں واپس لکھنا پڑتا ہے، عام طور پر ایک چھوٹے اپ ڈیٹر کے ذریعے جو فراہم کنندہ کا API پڑھتا ہے۔ اور localhost کے خلاف لکھی گئی کوئی بھی جانچ اب ورک لوڈ کے بجائے ٹنل کنٹینر سے پوچھتی ہے۔
نمونہ لکھ لیں، جس میں یہ بھی شامل ہو کہ کون سا کنٹینر نیم اسپیس رکھتا ہے اور کون سے پورٹس اس کے ہیں۔ اگلا شخص ایک سروس شامل کرے گا، غلط بلاک نقل کرے گا اور اس مضمون کی پہلی ناکامی دہرائے گا۔