لماذا يعمل تحليل DNS على المضيف لكنه يفشل داخل حاوية؟

قد يعمل DNS على المضيف بينما يفشل DNS داخل الحاوية، لأن الحاوية تستخدم مسارًا مختلفًا للمحلّل أو مساحة أسماء مختلفة أو مسارًا مختلفًا عبر جدار الحماية أو حالة مختلفة لإعادة توجيه Docker.

على خادم منزلي، قد يستعلم المضيف مباشرةً من موجّه أو Pi-hole أو محلّل VPN، بينما ترسل حاوية على شبكة الجسر الطلبات عبر المحلّل المضمّن في Docker أو عبر ملف resolv.conf منسوخ. أسرع طريقة للتشخيص هي اختبار عنوان IP أولًا، ثم الاستعلام عن كل محلّل بشكل صريح من داخل الحاوية المتأثرة، حتى لا يُخلط بين فشل DNS وفشل الاتصال الخارجي العام.

افصل فشل DNS عن فشل الشبكة العام

من داخل الحاوية المتأثرة، اختبر عنوان IP خارجيًا معروفًا وعنوان IP لخادم DNS المقصود قبل اختبار أي اسم مضيف. سجّل المسارات وفقدان الحزم وما إذا كان الوصول إلى المنفذين 53 عبر TCP وUDP ممكنًا.

توضح حالة حاوية Manjaro الفرع المعاكس: فقد فشل المرور المباشر عبر IP أيضًا، مما أثبت أن المشكلة أوسع من DNS. يمنع اختبار الاتصال المباشر عبر IP تغييرات المحلّل من إخفاء خلل في الجسر أو NAT أو مسار جدار الحماية.

إذا فشل الاتصال عبر IP، فأصلح شبكة الحاوية أولًا. وإذا عمل IP لكن فشلت الأسماء، فتابع فحص إعداد المحلّل ومسار الاستعلام.

افحص إعداد المحلّل داخل الحاوية

اقرأ /etc/resolv.conf داخل الحاوية وقارنه بالمضيف. لاحظ عناوين خوادم الأسماء ونطاقات البحث والخيارات ووضع الشبكة وما إذا كان الملف يتغير بعد إعادة الإنشاء.

أفادت حالة في OpenMediaVault بفشل استعلامات الحاوية عبر محلّل Docker المضمّن 127.0.0.11 بعد تحديث وقت التشغيل. ويمكن أن يختلف مسار المحلّل المضمّن هذا عن استعلام المضيف الناجح.

لا تعدّل الملف المُنشأ تلقائيًا بشكل دائم داخل حاوية قيد التشغيل. ضع خوادم DNS ونطاقات البحث المقصودة في إعدادات Compose أو المنصة حتى تبقى بعد إعادة الإنشاء.

استعلم من DNS الخاص بـ Docker ومن المحلّل الرئيسي بشكل منفصل

نفّذ الاستعلام نفسه مقابل المحلّل المضمّن في Docker، والموجّه أو خادم DNS المحلي، ومحلّل خارجي معروف حيثما تسمح السياسة. قارن بين انتهاء المهلة والرفض وNXDOMAIN والعنوان المُعاد.

تتبعت حالة في مجتمع TrueNAS فشل DNS داخل الحاوية إلى ملف وصول في الموجّه كان يحظر الطلبات، رغم أن حركة مرور المضيف الأخرى كانت تعمل. وكانت الملاحظة الحاسمة هي حظر DNS لمسار الحاوية، لا اسم مضيف غير صالح.

إذا نجحت الاستعلامات المباشرة إلى المحلّل الرئيسي لكن فشل المحلّل المضمّن، فأعد تشغيل حالة محلّل Docker وشبكته أو أصلحها. وإذا انتهت مهلة جميع خوادم DNS، فتحقق من توجيه المنفذ 53 وجدار الحماية وVPN وحركة الردود.

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

تحقق من حلقات DNS المحلية والإجابات الداخلية الخاطئة

حدّد ما إذا كانت الحاوية تحاول الاستعلام من خدمة DNS على المضيف نفسه أو من حاوية أخرى أو من اسم مضيف يُعاد حله عبر الوكيل العكسي. التقط الإجابة بدلًا من افتراض أن كل استعلام ناجح صحيح.

وجدت حالة في مجتمع Traefik أن إحدى الحاويات أعادت حل نطاق مخصص إلى نفسها بدلًا من النظير المقصود. وقد اجتازت إجابة DNS الخاطئة من جانب الحاوية اختبار الحل الأساسي، لكنها عطلت اتصال واجهة API.

استخدم أسماء الخدمات لحركة المرور بين الحاويات على الشبكة نفسها، واستخدم DNS المنقسم لأسماء المضيفين العامة فقط عندما يكون مسار العودة مقصودًا. تجنب المسارات الالتفافية التي ترسل الحاوية عبر الوكيل العام للوصول إلى تبعية محلية، ما لم يُختبر هذا المسار صراحةً.

تحقق من ردود UDP وNAT وعزل الشبكة

التقط حركة المرور على المنفذ 53 في واجهة الحاوية وجسر المضيف. تأكد من خروج الاستعلام ووصوله إلى المحلّل وعودة الرد من العنوان الذي يتوقعه العميل.

وثّق مستخدمو Pi-hole حالات انتهت فيها مهلة استعلامات الحاويات الموجودة على المضيف نفسه، لأن الردود عادت من مصدر مُترجم غير متوقع. ويميز مصدر رد DNS غير المتوقع مشكلة مسار الرد عن المحلّل الصامت.

إذا عبر الطلب والرد شبكات Docker مختلفة، فأضف الشبكة المشتركة أو المسار الصحيح بدلًا من نقل كل خدمة إلى شبكة المضيف. تحقق من مناطق جدار الحماية وسياسات VPN التي قد تتعامل مع شبكات الجسر الفرعية بشكل مختلف عن عنوان المضيف.

أعد إنشاء حالة الشبكة وأثبت نجاح الإصلاح

بعد تصحيح المحلّل أو جدار الحماية أو تعريف الشبكة، أعد إنشاء حاوية اختبار واحدة على الشبكة المقصودة، ثم كرر اختبارات IP والمحلّل المباشر والمحلّل المضمّن واسم الخدمة والاسم العام.

يوفر دليل ZimaSpace حول فصل أعطال العنوان عن أعطال الاسم حدًا تشخيصيًا موازيًا من جانب المضيف.

لا تُحل المشكلة إلا عندما يصمد إعداد DNS بعد إعادة الإنشاء وإعادة التشغيل، وتعيد أسماء الخدمات الداخلية والأسماء العامة المسموح بها العناوين المقصودة، وتنجح حركة مرور التطبيق عبر مسار الشبكة نفسه. وإذا عاد الفشل فقط بعد تحديث Docker، فاحتفظ بالإصدار وسجلات البرنامج الخدمي لتحديد حدود التراجع في وقت التشغيل.