OpenVPN لا يبدأ دون رسالة خطأ؟ راجع السجل

يعود الأمر، وتظهر الخدمة على أنها فاشلة، ولا يصل إلى الطرفية أي شيء يشبه التفسير. هذا الصمت هو العَرَض الذي يصفه الناس بـ«OpenVPN لا يبدأ»، وهو لا يعني تقريباً أبداً أن البرنامج مات دون أن يقول شيئاً. بل يعني أن الرسالة ذهبت إلى قناة لم تكن تقرؤها، أو أن ما شغّلته لم يكن ما أعددته. ويمكن تشخيص الحالتين في أقل من دقيقة بمجرد أن تتوقف عن اعتبار الملف الشخصي هو المشتبه به.

أربعة أماكن تستقبل المخرجات: سجل الوحدة، الملحق الذي يملك الاتصال، والطرف الآخر من النفق، وملف تنفيذي مختلف عن الذي تظنه قيد التشغيل. لكلٍّ منها فحصه الخاص.

الصمت يعني أنك لم تكن تراقب القناة الصحيحة

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

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

أضف systemctl show -p Result -p ExecMainStatus openvpn-client@office للتمييز بين خروج نظيف وإشارة. الحالة 1 مع Result=exit-code قرار من البرنامج؛ Result=signal أو مهلة زمنية تشير إلى البيئة بدلاً من ذلك، ولن يغيّر أي قدر من تحرير الملف الشخصي ذلك. سجّل القيمتين قبل إعادة تشغيل أي شيء، لأن إعادة التشغيل تمحو الحالة العابرة التي أنتجتهما.

اسم النسخة جزء من المسار

وحدة القالب المحزَّمة لا تأخذ مسار ملف. بل تأخذ اسم نسخة، ويُضاف ذلك الاسم إلى دليل للعثور على الملف الشخصي: office يُحَلّ إلى /etc/openvpn/client/office.conf في حزمة Debian وUbuntu. ملف يسمى office-v2.conf بدأ باسم @office، لا يُقرأ أبداً، وتخرج الوحدة بهدوء لأنه من وجهة نظرها لم يكن هناك ما تفعله. يختلف دليل البحث بين وضع العميل ووضع الخادم، لذا يشير الخطأ نفسه إلى مكان آخر تماماً عند تبديل القوالب.

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

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

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

عندما يملك الملحق النفق، لا ترى الطرفية شيئاً

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

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

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

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

ملفان تنفيذيان، مسار PATH واحد

بناء يدوي مثبَّت تحت /usr/local يفوز عند الاستدعاء من صدفة، لأن /usr/local/sbin يسبق /usr/sbin في PATH الافتراضي في Ubuntu. الوحدة لا تستخدم PATH الخاص بك؛ بل تشغّل المسار المطلق المكتوب في ExecStart. لذا قد تكون النسخة التي تعمل في طرفيتك والنسخة التي تفشل كخدمة برنامجين مختلفين حقاً.

قارن الاثنين قبل إعادة بناء أي شيء. الأمر الثالث هو الذي يحسم الحجة.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

ثمة فرق بيئي آخر يختبئ في المكان نفسه. الوحدة المحزَّمة تعتمد على دليل وقت تشغيل تحت /run الذي ينشئه systemd لها؛ وحدة بديلة مكتوبة يدوياً تُغفل ذلك الإعداد قد تفشل قبل أن تفتح ملفاً واحداً، ويبدو الفشل كرفض عام دون أي رسالة من OpenVPN.

أعطال لا يستطيع العميل الإبلاغ عنها

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

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

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