هل يظل OpenVPN يدفع مسارات قديمة؟ افحص ما حمّله فعلاً

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

المقارنة أدناه تسير من العملية إلى الخارج، لأن العملية هي المرجع الوحيد في تحديد الملف النافذ.

الملف الذي عدّلته والملف الذي تقرأه العملية

ابدأ بالوحدة وسطر الأوامر الذي أنتجته. على مضيف يعمل بـ systemd، يطبع systemctl cat openvpn@server سطر ExecStart، ووحدة النسخة تستنبط عادةً مسار إعداداتها من اسم النسخة، لذا فالعملية الخفية التي تبدأ باسم openvpn@office تقرأ ملفاً مختلفاً عن تلك التي تبدأ باسم openvpn@server. قارن ذلك بوسائط argv للعملية الجارية. وتضيف أداة إدارة الإعدادات طريقة أخرى لضياع التغيير: يمكنها كتابة ملف صحيح في موضع لا تذكره الوحدة أبداً، فيبدو نشر ناجح كأنه بلا أثر.

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

ما يدفعه الخادم وما يثبّته العميل

على المسار المدفوع أن يعبر مرشّحين. على الخادم يجب أن يكون داخل الإعدادات المحمّلة، لا في كتلة معلّقة ولا في ملف خاص بعميل لا يطابق اسمه. وعلى العميل يجب أن يكون pull مفعّلاً، وألا يكون أي pull-filter يتخلّص من الخيار. اتصل بمستوى verbosity 4 واقرأ الخيارات المدفوعة التي يبلّغ عنها العميل: فإن ظهر المسار في تلك القائمة، فقد أدى الخادم واجبه والعميل هو الذي يختار عدم تثبيته.

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

البادئة المدفوعة ومسار العودة مشكلتان مختلفتان

العميل الذي يتجاهل redirect-gateway عن قصد ليحتفظ بمساره المحلي إلى الإنترنت ينشئ فجوة ثانية لا علاقة لها بالأولى. تستطيع مجسّات الخادم بلوغ عنوان النفق، لكن الأجوبة لا تصل أبداً، لأن الردّ الموجّه إلى عنوان IP للنفق على الخادم يمرّ عبر البوابة الافتراضية العادية للعميل. وليس مسار الشبكة الفرعية المدفوع هو المتّهم هنا؛ الغائب هو مسار يعيد حركة مرور شبكة النفق الخاصة بالخادم إلى جهاز النفق.

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

قارن الجدولين على الطرفين

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

احتفظ بثلاثة معرّفات معاً: مسار الإعدادات، واسم الوحدة أو النسخة، وهوية العميل التي اختبرت بها.

هذه الثلاثة تحوّل الحادثة التالية إلى فحص من خمس دقائق بدل تحقيق متكرر، وهي ما يحتاجه زميلك حين يصبح النفق مشكلة شخص آخر.

مشكلة المسار التي تصمد أمام إعادة التشغيل ليست في الغالب مشكلة توجيه أصلاً؛ فالخلل يقع في مكان أعلى من الجدول الذي تواصل قراءته.