DNS الخاص بـ OpenVPN يبقى بعد SIGKILL: تحقّق من المالك أولًا

يتوقف DNS عن العمل بعد قتل عميل OpenVPN، وأول ما يتبادر إلى الذهن هو إعادة كتابة /etc/resolv.conf. هذا التعديل قد يُعطّل مُحلِّلًا يعمل بينما تكون الحالة المتقادمة الحقيقية في مكان آخر. والسؤال الذي يجب حسمه أولًا هو من يملك إعدادات DNS التي ثبّتها النفق، وهل كان الخروج الذي تجاوز التنظيف مهمًا فعلًا.

ثلاثة شروط تحدّد الإصلاح: الإشارة التي أنهت العملية، ومكوّن المُحلِّل الذي تلقّى الإعدادات، وهل وصلة النفق ما زالت موجودة. أجب عنها بهذا الترتيب، وسيأتي الإصلاح عادةً دون المساس بأي ملف عام.

حدّد نوع الخروج الذي وقع

في إصدار Community OpenVPN، تُعدّ SIGINT وSIGTERM طلبَي خروج سلسين. أما SIGKILL فلا يمكن التقاطها: لا يمكن حجبها أو معالجتها، لذا لا تحصل أي روتين إغلاق على فرصة للعمل. الضغط العادي على Ctrl+C في طرفية أمامية يولّد SIGINT، بينما المُشرف الذي يتوقف عن الانتظار يتصاعد عادةً إلى SIGKILL. الفرق مهم لأن الحالة الثانية وحدها تضمن أن الخطافات تم تجاوزها.

التشغيل داخل screen أو tmux لا يغيّر الإشارة التي يرسلها Ctrl+C. تحقّق مما تلقّته العملية فعلًا بدلًا مما تفعله الطرفية عادةً.

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

حدّد من يملك المُحلِّل

systemd-resolved وسكربت على نمط resolvconf وإعادة كتابة ملف بسيط هي ثلاثة مالكين مختلفين. الأول يحتفظ بإعدادات الوصلة في الذاكرة ويُسقطها عند اختفاء الواجهة. الثاني يحتفظ بسجلات تبقى حتى يزيلها شيء ما. والثالث يكتب ملفًا ويترك الاستعادة لمن كتبه.

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

قد يملك VPN مُدار عبر NetworkManager تغييرات المُحلِّل بالفعل. وإضافة مساعد ثانٍ فوقه تخلق مالكين يتنافسان على الوصلة نفسها، وتعود حالة الخاسر عند إعادة الاتصال التالية. فإن كان مدير هو المسؤول، أصلح الإعداد في المدير لا في سكربت.

ما الذي يستطيعه خطاف down وما لا يستطيعه

يعمل سكربت down بعد إغلاق جهاز TUN/TAP. وإضافة down-pre تقلب هذا الترتيب وتُشغّل السكربت بينما الجهاز ما زال موجودًا، وهو ما تحتاجه المساعدات التي تتطلب الوصلة الحيّة.

لا يجعل أي من التوجيهين خطافًا يعمل بعد SIGKILL. كما لا تُستعاد الصلاحيات بـ down-pre: فإذا انتقل الخادم إلى user أو group أو دخل إلى chroot، يعمل الخطاف بما يتركه له ذلك من وصول. وقد يفشل خطاف مُستدعى مع ذلك في تحديث المُحلِّل. ويغطي مرجع OpenVPN الإشارات ودورة حياة الاستدعاء.

افحص خطأ الخطاف نفسه إلى جانب حالة خروج العملية. فالتنظيف الغائب والتنظيف الفاشل يبدوان متطابقين في المُحلِّل ومختلفين في السجلات.

افحص الحالة التي تبقى فعلًا

على نظام يستخدم systemd-resolved، يُظهر resolvectl status أي وصلة ما زالت تحمل خوادم DNS الخاصة بالـ VPN أو نطاقات التوجيه. قد تنتمي تلك الوصلة إلى اتصال زال، أو إلى نفق آخر ما زال قائمًا.

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

استعد دون سرقة وصلة أخرى

عندما تكون إعدادات الوصلة مسؤوليتك، يأخذ resolvectl revert اسم الوصلة ويمسح إعداد DNS في وقت التشغيل لتلك الواجهة. وهو إجراء في وقت التشغيل لا تعديل في ملف تعريف، لذا يبقى إعداد الاتصال الدائم دون مساس. وقد تسمّي وصلة خاطئة فتمسح DNS لنفق يعمل، ولهذا يأتي الاسم من خرج الحالة.

تأكّد من أن /etc/resolv.conf رابط رمزي مُدار قبل تحريره، ثم أوقف العميل عادةً مرة أخرى وانظر إلى DNS مجددًا. وإن نظّف التوقف الثاني، فالمشكلة الأسبق كانت الخروج القسري لا الإعداد.