OpenVPN لا يبدأ: اقرأ السطر الأول، لا الإعدادات

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

ثلاثة أوامر للقراءة فقط توصلك إلى هناك: journalctl -u openvpn@server -b --no-pager أولاً، ثم systemctl status openvpn@server ثانياً، و ss -lunp لمنافذ UDP المستمعة وأصحابها.

السطر الأول يحدد الفرع

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

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

من أيضاً يحتجز المنفذ 1194

السبب عادةً ليس خادماً ثانياً نصبه أحدهم عمداً. توقّع عميلاً بدأ يدوياً ولا يزال حياً في طرفية أخرى، أو ملف تعريف ثانياً صادف أنه اختار المنفذ نفسه، أو حزمة مورّد يحتفظ نفقها الخاص بالمنفذ 1194. يظهر مالك المقبس في ss -lunp؛ مُرّر ذلك المعرّف PID إلى systemctl status لتعرف إن كانت وحدة مسؤولة. أنزله عبر مسار التحكم الخاص به بدلاً من إشارة.

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

وحدات متبقية بعد الإزالة

الإزالة تحذف الملفات التنفيذية؛ أما ملفات الوحدات المكتوبة يدوياً، وعادةً تحت /etc/systemd/system، فتبقى بعدها. عندئذٍ تعيد Systemd محاولة وحدة تشير إلى مسار لم يبق موجوداً، والرسالة تتعلق بذلك الملف المفقود لا بإزالة الأمس. يعرض systemctl status مسار شظية الوحدة قرب الأعلى، لذا تحقّق منه بـ dpkg -S قبل حذف أي شيء. بعد زوال اليتيم، يمسح systemctl daemon-reload و systemctl reset-failed الحالة؛ وإلا ورثتها كل فحوص الحالة اللاحقة.

حين يجيب which openvpn بشيء تحت /usr/local، فالملف التنفيذي المستخدم جاء من مثبّت مورّد لا من apt. مثل هذا المثبّت يجلب عادةً مستمعَه الخاص ومدخل إقلاعه الخاص ومجلد إعداداته الخاص، لذا فإن حذف الأمر الظاهر يترك المقبس محتجزاً.

أزله بالطريقة التي توثّقها الجهة المورّدة، وأكّد أن المنفذ حرّ بـ ss -lunp، وأضف عميل التوزيعة فقط إن كنت بحاجة إليه.

اضبط الحالة قبل إعادة المحاولة

امسح الحالة الفاشلة قبل استخلاص استنتاجات منها: systemctl reset-failed يزيل العدادات، ثم يبلّغ systemctl status عن حالة الوحدة الحالية لا عن تاريخها. ابدأها مرة واحدة واقرأ سجل تلك الحالة نفسه بدلاً من الحالة المجمّعة للجهاز. وحدة تبلّغ عن نشاط بينما النفق لا يحمل شيئاً مشكلة منفصلة، وهي أكثر شيوعاً بكثير. يُدمج الاثنان في تقارير الأخطاء لأن كليهما ينتهي بقول المستخدم إن الـ VPN لا يعمل.

سجّل الفرع الذي سلكته: تعارض منافذ، أو ملف تنفيذي مفقود، أو إعدادات مفقودة. المرة القادمة سيكون التعرف عليه أسرع.