Docker کنٹینرز VPN کے DNS حل کنندہ کو نظر انداز کیوں کرتے ہیں

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

ایک ہی مشین پر حل کنندہ کے دو منظر

Linux پر، Docker بنتے وقت ہر کنٹینر کو میزبان کی حل کنندہ ترتیب کی ایک نقل دیتا ہے، loopback پتے چھانٹ دیتا ہے، اور 127.0.0.11 پر ایک ایمبیڈڈ DNS سرور چلاتا ہے جو سوالات باہر بھیجتا ہے۔ کنٹینر شروع ہونے کے بعد /etc/resolv.conf دوبارہ لکھنے والا VPN کلائنٹ اس کے اندر کچھ نہیں بدلتا۔ کنٹینر کو دوبارہ شروع کرنا صرف اسی صورت میں مدد کرتا ہے جب اس لمحے میزبان حل کنندہ اتفاقاً درست ہو۔

macOS یا Windows پر Docker Desktop ایک تہہ مزید شامل کرتا ہے، کیونکہ ڈیمن ورچوئل مشین میں رہتا ہے۔ میزبان کا VPN حل کنندہ اس VM کو کبھی نظر نہ آئے، اس لیے دوبارہ شروع کرنے سے کچھ بھی نہیں بدلتا۔ حل منتخب کرنے سے پہلے دونوں منظر موازنہ کریں: میزبان کی حل کنندگان کی فہرست کے ساتھ docker exec mycontainer cat /etc/resolv.conf۔

جب میزبان اندرونی حل کنندہ درج کرتا ہے اور کنٹینر عوامی حل کنندہ درج کرتا ہے تو وہ عوامی نام حل کرے گا اور اندرونی ناموں پر ناکام ہوگا۔ یہی تقسیم اس مسئلے کا دستخط ہے۔

آپشن A: ہر کنٹینر کے لیے ٹنل حل کنندہ بھیجنا

Docker فی کنٹینر DNS ترتیبات قبول کرتا ہے، اور یہی سب سے چھوٹی کام کرنے والی تبدیلی ہے۔ پہلے VPN کے حل کنندہ پتے پڑھیں: macOS پر scutil --dns، Linux پر resolvectl status یا خود کلائنٹ کی حالت کی آؤٹ پٹ۔ پھر ان کے ساتھ کنٹینر شروع کریں، مثلاً docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage۔ Compose میں وہی ترتیب سروس کے نیچے فہرست ہے، جہاں یہ کسی کے شیل تاریخچے کے بجائے ورژن کنٹرول میں رہتی ہے۔

/etc/docker/daemon.json میں dns ارے ہر نئی کنٹینر پر لاگو ہوتی ہے، جو زیادہ صاف لگتا ہے اور نہیں ہے۔ یہ تب بھی لاگو ہوتی ہے جب ٹنل بند ہو، اور تب صرف VPN سے قابل رسائی حل کنندہ عام امیج کھینچنے کو توڑ دیتا ہے۔ فی کنٹینر ترتیبات کی توجیہ اور واپسی دونوں آسان ہیں۔

آپشن B: کنٹینر کو میزبان نیٹ ورک بانٹنے دینا

میزبان نیٹ ورکنگ نقل کو مکمل طور پر نظر انداز کرتی ہے، کیونکہ کنٹینر میزبان کا حل کنندہ اور میزبان کی ٹنل استعمال کرتا ہے۔ یہ وہ نیٹ ورک تنہائی بھی ہٹا دیتی ہے جو آپ غالباً چاہتے تھے، اور Docker Desktop کے تحت یکساں برتاؤ نہیں کرتی۔ Linux پر اندرونی نام حل کرنے والے ایک بار کے اوزار کے لیے یہ عملی انتخاب ہے۔

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

دونوں آپشن کیا درست نہیں کرتے

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

خود حل کنندہ کو ڈی بگ کرنے سے پہلے Docker نیٹ ورک کا ذیلی نیٹ VPN ذیلی نیٹ کے سامنے جانچیں۔ اوورلیپ ایسی ناکامی پیدا کرتا ہے جو بالکل خراب DNS سرور جیسی دکھتی ہے۔

کنٹینر کے اندر تصدیق کریں

براؤزر یا زبان کے رن ٹائم کے بجائے کنٹینر کے اندر getent hosts db.internal سے جانچیں، کیونکہ وہ اپنی DNS پالیسی اور اپنی کیشنگ لاگو کرتے ہیں۔ اگر getent نام حل کرے اور ایپلیکیشن پھر بھی ناکام ہو، تو حل کنندہ اب درست ہے اور باقی مسئلہ ایپلیکیشن کی سطح کا ہے۔ اگر وہ حل نہ کرے، تو DNS مرحلہ مکمل نہیں ہوا۔

DNS ترتیبات بدلنے کے بعد کنٹینر دوبارہ بنائیں۔ چلتے کنٹینر کے اندر /etc/resolv.conf کی تدوین اس کے ساتھ غائب ہو جاتی ہے اور ترتیب کے مسئلے کو عین اتنی دیر چھپاتی ہے جتنی دیر میں کوئی اسے دوبارہ شروع کرتا ہے۔