OpenVPN عند بدء التشغيل على Ubuntu: NetworkManager أم systemd؟

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

كل شيء آخر، من تثبيت المسارات إلى سلوك إعادة الاتصال، يتبع ذلك القرار الأول.

حلقة المفاتيح هي الفرق الذي لا يذكره أحد

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

تتجنب نسخة systemd تلك المشكلة بقراءة ملف بيانات اعتماد من القرص، ما يجعل الملف هو الشيء الذي تحميه. chmod 400 مع الملكية لـ root هو الحد الأدنى، وينبغي أن يبقى الملف خارج النسخ الاحتياطية وقوالب الصور التي لا تتحكم بها.

ربط VPN باتصال ليس ضمانًا للإقلاع

في nm-connection-editor، اختر الاتصال السلكي أو اللاسلكي بدلًا من VPN، وافتح تبويب General، وفعّل خيار الاتصال بـ VPN تلقائيًا وسمِّ ملف التعريف. بعدها تُنشّط NetworkManager الـ VPN كاتصال ثانوي عندما يصل الاتصال الأساسي إلى حالة متصلة. هذا اعتماد وليس قاعدة جدار ناري. لا تزال الحزم قادرة على الخروج خلال الثواني قبل ارتفاع النفق، والسر المخزَّن الذي يفشل في الفتح يترك الجهاز متصلًا بالإنترنت دونه.

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

تحتاج نسخة systemd إلى اسم ملف مطابق

ضع ملف التعريف في دليل العميل الذي يتوقعه الحزمة، مثل /etc/openvpn/client/office.conf، وأشر من داخله إلى ملف بيانات الاعتماد بـ auth-user-pass office.cred. اسم النسخة هو اسم الملف دون اللاحقة، لذا يقرأ openvpn-client@office الملف office.conf. مكّنها بـ sudo systemctl enable --now openvpn-client@office وأكّد المطابقة بـ systemctl cat openvpn-client@office بدلًا من الثقة بمثال من مدونة.

تُحل المسارات داخل ملف التعريف نسبةً إلى دليل عمل الوحدة، لا إلى ملف التعريف نفسه، لذا قد يفشل سطر ca أو auth-user-pass النسبي عند الإقلاع بينما يعمل عند اختباره يدويًا. استخدم مسارات مطلقة لكل ما يجب أن تجده الوحدة. ثم اقرأ journalctl -u openvpn-client@office -b بعد إقلاع حقيقي؛ فالوحدة التي تعلن نشاطها دون نفق تذكر عادة ملفًا مفقودًا في ذلك السجل.

تشحن الحزم الأقدم اسم قالب مختلف، لذا يحسم systemctl list-unit-files 'openvpn*' أيها موجود على هذا المضيف.

سلوك إعادة الاتصال قرار منفصل

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

الإيقاف حرفي بالقدر نفسه: sudo systemctl disable --now openvpn-client@office يوقف النسخة الجارية ويزيل رابط الإقلاع. التعطيل وحده يترك النفق يعمل حتى إعادة التشغيل التالية، وهذا يفاجئ كل من يختبر بتعطيله ويراقب بقاء الواجهة قائمة.

أعد التشغيل، ثم تحقق من أربعة أمور بالترتيب

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

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

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