ip netns exec وDNS: لماذا تفشل الأسماء داخل فضاء الأسماء
لفضاء الأسماء واجهاته ومساره الخاصة، وليس له ملف مُحلِّل خاص به. تحقّق من أي ملف resolv.conf تراه العملية المُطلقة ومن أين جاء ذلك الملف.
يصل أمر إلى 10.8.0.5 داخل فضاء أسماء VPN دون أي شكوى، ويفشل الأمر نفسه في اللحظة التي يستخدم فيها اسم مضيف. لفضاء الأسماء واجهاته ومساره ومقابسه الخاصة؛ لكن ليس له ملف محلل خاص به. وما لم يضع شيء ما ملفًا هناك، فإن العملية بالداخل تقرأ ملف /etc/resolv.conf الخاص بالمضيف وتطلب من خادم قد لا يكون قابلًا للوصول من مكدس الشبكة ذلك.
هذه مشكلة في اختيار الملف وليست مشكلة توجيه، ولهذا السبب تحديدًا تظل الوجهة الرقمية تعمل.
تحقّق من رؤية المحلّل التي تحصل عليها العملية فعليًا
لا تفترض أن الصدفة التي استخدمتها تعادل العملية التي تُنقّحها. فقد يدخل تطبيق رسومي، أو وحدة systemd، أو حاوية، كلٌّ منها سياق تحميل أو شبكة مختلفًا. شغّل الاستعلام عبر مسار الإطلاق نفسه، واطبع ملف المحلّل من داخله.
بالنسبة لفضاء أسماء أُنشئ باستخدام ip netns add، يكون فحص القراءة فقط قصيرًا:
ip netns exec vpn cat /etc/resolv.confلاحظ ما إذا كانت النتيجة تسمّي عنوانًا قابلًا للوصول، أو كعب حجب loopback، أو رابطًا رمزيًا يشير إلى مكان بقابلية وصول مختلفة.
ما يُحمّله مساعد exec فعليًا
توثّق أداة ip-netns إعدادات كل فضاء أسماء تحت /etc/netns/NAME/. وعندما تُطلق عملية، ينشئ المساعد فضاء تحميل ويُحمّل تلك الملفات فوق مساراتها المعتادة، فترى العملية النسخة الخاصة بفضاء الأسماء. هذه ميزة مريحة لهذا المُطلق بعينه. أما دخول فضاء أسماء شبكة عبر مسار آخر، مثل unshare أو وقت تشغيل حاوية، فلا يعيد إنتاج ذلك تلقائيًا.
محلّل loopback هو الفخ هنا: 127.0.0.53 يعني loopback الخاص بفضاء الأسماء، لا كعب المضيف. والكعب الذي يستمع في فضاء أسماء المضيف فقط لا يصبح خدمة في الفضاء الجديد.
اختر محلّلًا يستطيع فضاء الأسماء الوصول إليه
أي خادم يسمّيه الملف يظل بحاجة إلى مسار من فضاء الأسماء ذلك. يمكن للمحلّل العام أن يجيب عن الأسماء العامة ويظل يفشل مع منطقة داخلية، لأن الخدمة الخاصة لا تُوصل إلا عبر النفق. افحص المسار في الوقت نفسه الذي تفحص فيه العنوان، لا بعد أن يكون الاستعلام قد فشل بالفعل.
قد تتجاهل التطبيقات التي لديها محلّل خاص بها، مثل تطبيق يستخدم DNS عبر HTTPS، هذا الملف تمامًا. وإذا كانت الأداة تملك إعداد DNS خاصًا بها، فلن يؤثر تغيير resolv.conf فيها، ولم يكن فضاء الأسماء هو المشكلة أصلًا.
اكتب الملف في المكان الصحيح
أنشئ الملف الخاص بفضاء الأسماء تحت /etc/netns/NAME/resolv.conf ودع المُطلق يعرضه. أبقِه بسيطًا: خادم أو خادمان قابلان للوصول، ونطاقات البحث التي تحتاجها المهمة. لا تُعدّل ملف المحلّل المُولَّد للمضيف لإصلاح رؤية مخصّصة لمجموعة عمليات واحدة، لأن ذلك يغيّر كل تطبيق على الجهاز. وإذا كان المضيف يستخدم مدير محلّل، فاضبط مسار فضاء الأسماء عبر ذلك المدير بدلًا من مصارعته.
سجّل محتوى الملف في دليل التشغيل. وإلا فإن الشخص التالي سيختبر محلّل المضيف، ويرى إجابة تعمل، ويستنتج أن فضاء الأسماء سليم.
أعد اختبار المسار كله
اختبر داخل فضاء الأسماء بعنوان رقمي، واسم داخلي، واسم عام. هذا التسلسل يفصل قابلية الوصول عن التحليل، ويفصل المناطق الداخلية عن العامة. ثم أعد إنشاء فضاء الأسماء وكرّر، لأن ملفًا موجودًا في نسخة قيد التشغيل فقط يزول معها.
تأكّد من أن العملية، لا الصدفة، هي التي تتلقّى الملف. فالاستعلام الذي ينجح من صدفة تفاعلية ويفشل من خدمة هو نتيجة تتعلق بسياق التحميل، ويستحق أن يُكتب قبل الحادث التالي بدلًا من إعادة اكتشافه من الصفر.