ip netns exec اور DNS: نام نام کی جگہ کے اندر کیوں ناکام ہوتے ہیں

ایک حکم VPN نام کی جگہ کے اندر 10.8.0.5 تک بغیر کسی شکایت کے پہنچتا ہے، اور وہی حکم اسی لمحے ناکام ہو جاتا ہے جب وہ میزبان کا نام استعمال کرتا ہے۔ نام کی جگہ کے اپنے انٹرفیس، راستے اور ساکٹ ہوتے ہیں؛ اس کی اپنی حل کنندہ فائل نہیں ہوتی۔ اگر کوئی وہاں ایک نہ رکھے، تو اندر کا عمل میزبان کی /etc/resolv.conf پڑھتا ہے اور ایسے سرور سے پوچھتا ہے جو اس نیٹ ورک اسٹیک سے ناقابل رسائی ہو سکتا ہے۔

یہ روٹنگ کا نہیں، فائل کے انتخاب کا مسئلہ ہے، اور اسی لیے عددی منزل اب بھی کام کرتی ہے۔

وہ حل کنندہ منظر دیکھیں جو عمل کو واقعی ملتا ہے

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

ip netns add سے بنائی گئی نام کی جگہ کے لیے صرف پڑھنے کی جانچ مختصر ہے:

ip netns exec vpn cat /etc/resolv.conf

غور کریں کہ نتیجہ قابل رسائی پتہ، کوئی loopback اسٹب، یا مختلف رسائی والی جگہ کی طرف اشارہ کرنے والا علامتی لنک بتاتا ہے یا نہیں۔

exec مددگار دراصل کیا ماؤنٹ کرتا ہے

ip-netns ٹول ہر نام کی جگہ کی ترتیب /etc/netns/NAME/ کے تحت دستاویز کرتا ہے۔ جب یہ کوئی عمل شروع کرتا ہے، مددگار ایک ماؤنٹ نام کی جگہ بناتا ہے اور ان فائلوں کو ان کے معمول کے راستوں پر bind-mount کرتا ہے، تاکہ عمل کو نام کی جگہ کے لیے مخصوص نقل نظر آئے۔ یہ اسی مخصوص لانچر کی سہولت ہے۔ کسی اور راستے سے، مثلاً unshare یا کنٹینر رن ٹائم کے ذریعے، نیٹ ورک نام کی جگہ میں داخل ہونا اسے خودکار طور پر دہراتا نہیں۔

یہاں جال loopback حل کنندہ ہے: 127.0.0.53 کا مطلب نام کی جگہ کا اپنا loopback ہے، میزبان کا اسٹب نہیں۔ جو اسٹب صرف میزبان کی نام کی جگہ میں سنتا ہے وہ نئی میں خدمت نہیں بنتا۔

ایسا حل کنندہ چنیں جہاں تک نام کی جگہ پہنچ سکے

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

اپنا حل کنندہ رکھنے والی ایپلیکیشنز، مثلاً DNS over HTTPS استعمال کرنے والی، فائل کو مکمل نظر انداز کر سکتی ہیں۔ اگر ٹول کی اپنی DNS ترتیب ہو، تو resolv.conf بدلنے سے اس پر اثر نہیں پڑے گا، اور نام کی جگہ کبھی مسئلہ نہیں تھی۔

فائل صحیح جگہ لکھیں

/etc/netns/NAME/resolv.conf کے تحت نام کی جگہ کی مخصوص فائل بنائیں اور لانچر کو اسے پیش کرنے دیں۔ اسے کم سے کم رکھیں: ایک یا دو قابل رسائی سرور اور کام کے لیے درکار تلاش کے ڈومین۔ عمل کے ایک گروہ کے لیے سوچا گیا منظر درست کرنے کے لیے میزبان کی تیار کردہ حل کنندہ فائل میں ترمیم نہ کریں، کیونکہ اس سے مشین کی ہر ایپلیکیشن بدل جاتی ہے۔ اگر میزبان حل کنندہ مینیجر استعمال کرتا ہے، تو اس سے لڑنے کے بجائے اسی مینیجر کے ذریعے نام کی جگہ کا راستہ ترتیب دیں۔

فائل کا مواد رن بک میں درج کریں۔ ورنہ اگلا شخص میزبان کا حل کنندہ جانچے گا، کام کرتا جواب دیکھے گا اور نتیجہ نکالے گا کہ نام کی جگہ ٹھیک ہے۔

پورا راستہ دوبارہ جانچیں

نام کی جگہ کے اندر عددی پتہ، اندرونی نام اور عوامی نام کے ساتھ جانچ کریں۔ یہ ترتیب رسائی کو حل سے الگ کرتی ہے اور اندرونی زون کو عوامی زون سے الگ کرتی ہے۔ پھر نام کی جگہ دوبارہ بنائیں اور دہرائیں، کیونکہ صرف چلتے ہوئے نمونے میں موجود فائل اس کے ساتھ غائب ہو جاتی ہے۔

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