OpenVPN يرسل خادم DNS لكن Linux يتجاهله

خادم DNS المُرسَل موجود في السجل، والنفق قائم، والأسماء الداخلية ما زالت تفشل. لا شيء معطوب في الإرسال نفسه؛ الإعداد وصل وتوقف عند ذلك. خيار DNS مُرسَل هو رسالة إلى العميل، وليس توجيهاً إلى مُحلِّل نظام التشغيل، والتسليم بينهما هو حيث تنتهي معظم هذه الحالات. خمسة فحوص، بالترتيب، تكشف التسليم الذي لم يحدث.

الفحص الأول: كيف يبدأ الاتصال

مالك الاتصال يحدد من يستطيع تطبيق إعدادات المُحلِّل. أمر openvpn المباشر من صدفة لا يملك إلا عمليته الخاصة، بينما وحدة systemd أو NetworkManager أو عميل من بائع لكل منها طريقته في نشر DNS. اقرأ قائمة العمليات واسم الوحدة قبل افتراض أي منها.

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

اكتب المالك قبل المتابعة. كل فحص لاحق يعتمد عليه.

الفحص الثاني: ماذا يحمل رابط المُحلِّل فعلاً

على مضيف systemd-resolved، يسرد resolvectl status كل رابط مع خوادمه ونطاقاته. اعثر على رابط النفق واقرأ مدخلاته، ولا تفترض أن الواجهة تُسمى tun0، لأن الترقيم يتبع ترتيب الإنشاء. إذا غاب العنوان المُرسَل من الرابط، فقد فشل التسليم لا الاستعلام.

إذا كان العنوان موجوداً، فالسؤال التالي هو أي النطاقات يدّعيها ذلك الرابط. الرابط بلا قائمة نطاقات لا يجيب إلا عن الأسماء التي يُسأل عنها مباشرة، وهذا نادراً ما تريده نشرة split-DNS. العنوان وحده ضروري لكنه غير كافٍ.

قارن اسم الرابط في مخرجات المُحلِّل باسم الواجهة في سجل VPN قبل استنتاج أي شيء. عدم التطابق هناك يعني عادة أن سطر السجل جاء من عملية أخرى.

الفحص الثالث: هل تختار مساحة الأسماء ذلك الرابط

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

افحص إسناد النطاق، لا عنوان الخادم فقط. النطاق المكتوب كـ ~corp.example هو نطاق توجيه، والمدّة تغيّر طريقة مطابقة الاسم.

إذا كان للتطبيق مُحلِّل خاص به، فاختبر بالآلية نفسها التي يستخدمها لا بأداة النظام. أداة استعلام تتجاوز مُحلِّل النظام ستنجح بغض النظر عن حالة الرابط.

الفحص الرابع: مالك واحد، لا اثنان

إذا كان NetworkManager يدير VPN وحالة المُحلِّل بالفعل، فإن إضافة سكربت خطاف غير ذي صلة تخلق كاتبين متنافسين. الخطاف الذي يوفره الحزمة لـ systemd-resolved تكامل مدعوم، ويتوقع دورة حياة محددة: script-security 2، ومسار up، ثم up-restart، ومسار down، ثم down-pre. تلك الخيارات تجعل التسجيل والإزالة يحدثان في اللحظات الصحيحة بدلاً من الاتصال الأول فقط.

استخدم المسار المثبَّت من الحزمة لا مساراً توضيحياً منسوخاً من دليل. الأذونات مهمة أيضاً، لأن الخطاف يعمل بعد إسقاط الامتيازات.

تعديل سكربت مُحلِّل التوزيعة لتغيير هدف مخرجاته يسجّل حلاً مؤقتاً لمضيف واحد. إنه ليس إصلاحاً عاماً.

الفحص الخامس: النتيجة نفسها بعد إعادة الاتصال

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

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