Docker کنٹینر VPN کے پیچھے موجود ہوسٹس تک کیوں نہیں پہنچتا

کارپوریٹ VPN کے پیچھے کسی چیز تک نہ پہنچنے والا کنٹینر عام طور پر سرنگ سے مختلف نیٹ ورک نام فضا میں رہتا ہے۔ ہوسٹ کلائنٹ کے راستے، DNS سرورز اور فائر وال کے نشانات ہوسٹ کے اسٹیک کے ہیں؛ برج نیٹ ورک کنٹینر کا اپنا اسٹیک ہوتا ہے۔ یہی ایک حقیقت پلیٹ فارم ٹیم تک پہنچنے والی زیادہ تر رپورٹوں کی وضاحت کرتی ہے، اور یہی وجہ ہے کہ «VPN خراب ہے» اور «Docker VPN کو بائی پاس کرتا ہے» دونوں ایک ہی وقت میں غلط ہو سکتے ہیں۔ ایک علامت کے پیچھے دو بالکل مختلف ترتیبیں چھپی ہوئی ہیں، اس لیے کوئی بھی ترتیب بدلنے سے پہلے طے کریں کہ آپ کے پاس کون سی ہے۔

پتہ لگائیں کہ سرنگ کس کی نام فضا کی ہے

macOS یا Windows کے لیے Docker Desktop پر کنٹینر Linux ورچوئل مشین کے اندر چلتے ہیں۔ ڈیسک ٹاپ پر نصب VPN کلائنٹ ڈیسک ٹاپ آپریٹنگ سسٹم میں سرنگ بناتا ہے، اور ورچوئل مشین اسے کبھی نہیں دیکھتی۔ کوئی کنٹینر ترتیب اسے ٹھیک نہیں کرتی، کیونکہ کنٹینر کو جس انٹرفیس کی ضرورت ہوگی وہ اس کی نیٹ ورک نام فضا میں بالکل موجود نہیں۔

Linux ہوسٹ پر سرنگ ہوسٹ کی نام فضا میں رہتی ہے، اور برج کنٹینر عام طور پر باہر جاتے وقت ماخذ NAT لگا کر ہوسٹ کی روٹنگ جدول کے ذریعے اس تک پہنچتے ہیں۔ جب وہ راستہ ناکام ہوتا ہے، تو وجہ عام طور پر غائب راستہ نہیں، بلکہ فارورڈنگ پالیسی، ریورس پاتھ فلٹرنگ یا ایک دوسرے پر چڑھا ہوا سب نیٹ ہوتا ہے۔ آگے پڑھنے سے پہلے تصدیق کریں کہ آپ دو دنیاؤں میں سے کس میں ہیں:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

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

ہوسٹ نیٹ ورکنگ ایک امتحان ہے، ڈیزائن نہیں

کنٹینر کو ہوسٹ نیٹ ورکنگ کے ساتھ چلانا، جسے Docker ہوسٹ نیٹ ورک نام فضا کے اشتراک کے طور پر دستاویز کرتا ہے, اسے سرنگ کا انٹرفیس اور اس کے راستے براہ راست وراثت میں دیتا ہے۔ اگر وہی درخواست پھر کامیاب ہو، تو راستہ نظریہ تصدیق شدہ ہے اور ناکامی نام فضا کی تنہائی ہے، اسناد، DNS یا رسائی کا قاعدہ نہیں۔

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

اسے تشخیص کے طور پر رکھیں۔ ہوسٹ نیٹ ورکنگ پورٹ کی اشاعت اور کنٹینر سے آپ کی مطلوبہ تنہائی کا بڑا حصہ چھوڑ دیتی ہے، اور Docker Desktop پر «host» کا مطلب ورچوئل مشین ہے، ڈیسک ٹاپ نہیں، اس لیے وہاں کی کامیابی یا ناکامی آپ کو گمراہ کر سکتی ہے اگر آپ بھول جائیں کہ کس ہوسٹ سے مخاطب تھے۔

tun ڈیوائس اور اس کے ساتھ آنے والے مراعات

کنٹینر کے اندر VPN کلائنٹ کو سرنگ ڈیوائس اور اسے ترتیب دینے کی اجازت چاہیے۔ عام شارٹ کٹ --privileged ہے، جو ہر ڈیوائس دیتا ہے اور پورے کنٹینر میں سیکیورٹی پالیسی نرم کرتا ہے۔ یہ اس کام کی ضرورت سے کہیں زیادہ ہے، اور جائزے میں اسے درست ثابت کرنا مشکل ہے۔

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

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

اس ڈیزائن کا مطلب یہ بھی ہے کہ کلائنٹ ہر کنٹینر کے لیے چلتا ہے۔ یہ درست جواب ہے جب ہر ورک لوڈ کو اپنی سرنگ چاہیے، اور غلط جواب جب آپ صرف ہوسٹ کی سرنگ نظر آنا چاہتے تھے، جسے پلیٹ فارم ٹیم نے شاید فرض کیا کہ آپ کر رہے ہیں۔

برج NAT وہ ماخذ بدلتا ہے جو VPN دیکھتا ہے

ڈیفالٹ برج کے ساتھ کنٹینر کی باہر جانے والی ٹریفک ہوسٹ کے پتے میں ترجمہ ہوتی ہے۔ اس لیے VPN کے پیچھے کارپوریٹ فریق کنٹینر کا نہیں، ہوسٹ کی سرنگ کا پتہ دیکھتا ہے، ماخذ کے لحاظ سے رسائی کے قواعد ایسے برتاؤ کرتے ہیں جیسے درخواست ہوسٹ نے بھیجی ہو، اور دو کنٹینر VPN سرور کے لیے ناقابلِ امتیاز ہو جاتے ہیں۔

macvlan یا ipvlan اس کے بجائے کنٹینر کو LAN پتہ دیتا ہے، جو LAN کی دریافت میں مدد کرتا ہے اور کنٹینر کو حصے پر ہم منصب دکھاتا ہے۔ یہ ہوسٹ کی سرنگ کو مکمل طور پر بائی پاس بھی کرتا ہے، اس لیے ایسا کنٹینر صرف-VPN سابقوں تک نہیں پہنچے گا جب تک VPN اس LAN سے بھی قابلِ رسائی نہ ہو۔

دونوں شکلیں جائز ہیں؛ وہ مختلف تقاضوں کا جواب دیتی ہیں۔ اگر تقاضا ہے «اس کنٹینر کو صرف-VPN سروس تک پہنچنا چاہیے»، تو آپ ہوسٹ کے ذریعے روٹنگ اور کنٹینر کے اندر سرنگ ختم کرنے کے درمیان انتخاب کرتے ہیں۔ یہ انتخاب تعیناتی سے پہلے لکھیں، پہلی ناکام درخواست کے بعد نہیں۔ آپ جو بھی چنیں، دور کے سرے کو نظر آنے والا ماخذ پتہ درج کریں، کیونکہ اس کے رسائی قواعد اور اس کے لاگز وہی دکھائیں گے۔ جو ڈیزائن وہ پتہ نہیں بتا سکتا وہ مکمل نہیں۔

DNS ڈیمن کی پیروی کرتا ہے، سرنگ کی نہیں

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

سروس کے لیے حل کنندہ واضح طور پر مقرر کریں، یا اسے سرنگ کے ذریعے قابلِ رسائی داخلی حل کنندہ کی طرف اشارہ کریں۔ جو کنٹینر نجی نام کو عوامی پتے میں حل کرتا ہے وہ عام طور پر عوامی حل کنندہ استعمال کرتا ہے، ٹوٹے راستے سے نہیں گزرتا، اور اصلاح compose فائل یا ڈیمن ترتیب میں ہے۔

یہی استدلال باہر جانے والے پتے کے سوال پر بھی لاگو ہوتا ہے۔ اگر ہر کنٹینر کو مختلف VPN پتے سے نظر آنا چاہیے، تو ایک ہوسٹ سرنگ یہ فراہم نہیں کر سکتی کیونکہ NAT انہیں ایک ماخذ میں سمیٹ دیتا ہے۔ قابلِ عمل شکلیں ہر کنٹینر کی نام فضا میں کلائنٹ یا سرنگ کا مالک اور اپنا اسٹیک بانٹنے والا سائیڈ کار ہیں، اور دونوں یہ بدلتے ہیں کہ ایپلیکیشن کو کیسے مخاطب کیا جاتا ہے۔

ٹکٹ بند کرنے سے پہلے چیک لسٹ: سرنگ کی مالک نام فضا کی شناخت کریں، ہوسٹ نیٹ ورکنگ سے راستہ ثابت کریں، صرف ضروری tun ڈیوائس نقشہ کریں، NAT کے بعد ماخذ پتہ یاد رکھیں، حل کنندہ واضح طور پر مقرر کریں اور فی کنٹینر باہر جانے والے پتوں کو جھنڈا نہیں، معماری فیصلہ سمجھیں۔