فشل تحميل CIFS عبر VPN بسبب ترتيب nsswitch

النفق قائم. يرد خادم الملفات على ping بالعنوان. ثم يجلس mount.cifs مع اسم المضيف فترة ثم يبلّغ أن المضيف غير قابل للوصول، فتبدأ في إعادة بناء ملف تعريف VPN لم يكن المشكلة أبدًا. على Linux يحل glibc الاسم قبل أن توجد أي حزمة SMB، وقد ينهي الترتيب في ذلك المحلّل البحث قبل أن يُسأل DNS إطلاقًا. هذا هو المسار الذي أتبعه، بدءًا من الأمر الذي فشل لا من العميل.

اقرأ الفشل في المكان الصحيح

أداتان تسلكان مسارين مختلفين إلى الاسم نفسه، ومقارنتهما تكلّف أمرًا واحدًا. getent يمشي في مكدس خدمة الأسماء المهيّأ؛ وhost وdig يستدعيان DNS مباشرة ويتجاهلان ذلك المكدس. إذا أعاد الاستدعاء المباشر عنوانًا وأعاد getent لا شيء، فخادم DNS قابل للوصول وإعداد المحلّل عندك هو الذي يفشل.

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

الأمر الثالث هو الحاسم: يفرض مصدر DNS ويتجاوز بقية المكدس. وعندما ينجح ذلك ويفشل getent العادي، تكون قد أثبتت أن الترتيب هو العيب، لا النفق ولا الخادم.

سطر hosts تسلسل يتوقف مبكرًا

يقرأ محلّل glibc الملف /etc/nsswitch.conf ويمشي في مدخل hosts: من اليسار إلى اليمين. توزيعات كثيرة تشحن سطرًا يأتي فيه بحث multicast أولًا مع إجراء عودة مبكر مرتبط به. الإجراء ليس زينة: عندما يجيب mDNS بـ “not found”، ينهي [NOTFOUND=return] البحث كله، فلا يُرسل اسم الشركة أبدًا إلى المحلّل الذي دفع به VPN. لا شيء يسجّل ذلك، لأنه لم تُرسل أي استعلام ليرفضه المحلّل. لهذا يبدو التحميل كأنه معلّق ثم يبلّغ أن المضيف غير قابل للوصول.

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

قدّم DNS قبل إجراء العودة المبكر بدلًا من حذف mDNS، وغيّر ذلك عبر إدارة الإعدادات. التعديل اليدوي يبقى حتى بناء الصورة التالي، ثم تصل التذكرة نفسها من جهاز آخر لا يتذكر الإصلاح.

المحلّل ليس نطاق بحث

يحتاج الحل أيضًا إلى أن يُجرَّب الاسم. الاسم غير المؤهل مثل fileserver لا يصبح fileserver.corp.example إلا عندما يُربط نطاق بحث بالواجهة التي تحمل الاستعلام. VPN يدفع خادم DNS دون قائمة بحث ينتج انقسامًا محددًا جدًا: الاسم المؤهل بالكامل يُحلّ وكل اسم قصير يفشل.

اختبر الصيغتين قبل تعديل ملف التعريف، لأن الفشلين يشيران في اتجاهين مختلفين. على مضيف systemd-resolved يملك رابط النفق خوادمه ونطاقات التوجيه الخاصة به، فاقرأ الرابط لا الملف العام.

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

إذا نُسب الاستعلام إلى رابط لا يحمل النفق، فنطاق التوجيه مفقود رغم وجود عنوان DNS. تلك مشكلة سياسة في إعداد resolved، لا مشكلة توجيه في النفق.

الحاويات تحمل نسختها من الجواب

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

افحص داخل الحاوية قبل أن تلوم الصورة. أمران يعيدان التشخيص كله في ثوانٍ، والثاني يثبت أي محلّل أجاب فعلًا.

عندئذٍ فقط انظر إلى المشاركة والمرشّح

بعد أن يُحلّ الاسم، تكون الأعطال المتبقية شبكية عادية. يحتاج SMB إلى TCP 445 نحو الخادم، وتصفح قائمة مجموعة عمل يعتمد على خدمات أسماء لا يمرّرها النفق على الأرجح. اعمل بالاسم المضيف بدلًا من انتظار امتلاء قائمة، ودع العميل يخبرك بأي مرحلة وصل. الاتصال المرفوض والمهلة الصامتة جديران بالفصل أيضًا، لأن الأول يعني عادة أن شيئًا أجاب والثاني يعني أن لا شيء أجاب.

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

العنوان المحلول مع رفض المنفذ 445 أو انتهاء مهلته مشكلة جدار حماية أو مستمع على الجهة الأخرى. الاسم غير المحلول هو مشكلة المحلّل. والتحميل الذي يصادق لكنه يعيد أخطاء صلاحيات ليس هذا ولا ذاك، فلا تُعِد فتح سؤال الشبكة بعد أن تُقام الجلسة.

اجعل الاستنتاج بضيق الأدلة. عندما يعمل العنوان ولا يعمل الاسم، فالنفق يؤدي عمله والإصلاح موقعه ترتيب المحلّل أو نطاق البحث أو إعداد الحاوية نفسه.