OpenVPN Access Server: أعد تشغيل الخدمة أم طبّق الإعداد

يُلصق أمران لما يبدو أنه المهمة نفسها على OpenVPN Access Server، لكنهما يفعلان شيئين مختلفين. يوقف systemctl restart openvpnas المنتج بأكمله ثم يعيد تشغيله. أما sacli start فيرفع الخدمات الداخلية التي تقرأ الإعداد الذي غيرته للتو. والاختيار بينهما ليس مسألة ذوق: فهو يعتمد على ما تقوله وثائق الإعداد نفسه، وعلى ما إذا كانت جلستك تمر عبر الخادم الذي أنت على وشك إعادة تشغيله، وعلى ما إذا كنت تنظر إلى المنتج الصحيح اصلا.

طبقتان، خدمة واحدة

يعمل Access Server كوحدة systemd واحدة، openvpnas، وتشرف تلك الخدمة على الخدمات الداخلية خلف واجهة الويب ومستمعي VPN. و sacli هو واجهة سطر الأوامر إلى التثبيت نفسه، في /usr/local/openvpn_as/scripts/sacli، ويمكنه بدء تلك المكونات الداخلية وإيقافها والاستعلام عنها دون استبدال الوحدة.

لهذا يوجد الأمران. إعادة تشغيل الخدمة تعيد تنفيذ كل شيء، بما في ذلك العملية التي تنهي أنفاق العملاء. أما sacli start فيطلب من الخدمة العاملة اصلا أن ترفع مكوناتها كي تقرأ الإعداد الجديد، وهذا ما تتطلبه معظم تغييرات الخصائص فعلا.

الشرط الأول: ماذا تقول وثائق الإعداد

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

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

الشرط الثاني: هل جلستك داخل النفق

إذا كنت تدير Access Server عبر الـ VPN التي يوفرها، فإن إعادة التشغيل تقطع الاتصال الذي يحمل shell الخاص بك. وقد يكتمل الأمر بعد موت جلستك، فلا تعرف إن كان قد نجح. و sacli start قد يقطع الجلسة لحظيا للسبب نفسه عندما يتعامل المكون الذي يعاد تشغيله مع حركة مرورك.

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

الشرط الثالث: هل هذا المنتج هو ما تظنه

Access Server ليس OpenVPN Community. تثبيت المجتمع يشغل وحدات مثل openvpn@server أو openvpn-client@profile، والإعداد في /etc/openvpn، ولا وجود لـ sacli هناك. وإعادة تشغيل كل وحدة تحمل openvpn في اسمها على مضيف مشترك هي الطريقة التي تسقط بها أنفاق غير مترابطة معا.

تعرف قبل أن تلمس أي شيء: يجيب systemctl status openvpnas --no-pager عما إذا كان Access Server هو ما يعمل، ويسرد sacli status مكوناته الداخلية، ويسرد systemctl list-units --type=service الوحدات التي تحتوي أسماؤها على openvpn. وإذا أظهر الأمر الأخير وحدات بأسماء ملفات تعريف، فأنت على منتج المجتمع ولا ينطبق عليك بقية هذا.

طبقه ثم تحقق بما يتجاوز active

الوحدة التي تعلن active لديها عملية تعمل، وهذا ليس نفس مسار مصادقة يعمل. بعد خطوة التطبيق، تحقق من sacli status للمكونات التي توقعت إعادة تشغيلها، وتأكد من أن القيمة خزنت عبر sacli ConfigQuery، ثم نفذ عملية دخول عميل واحدة محدودة بحساب اختبار.

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

يعد درس إدارة الخدمات من المورد مرجعا للعمليات التي تنتمي إلى sacli، ويستحق فتحه قبل أن تقرر أن إعادة التشغيل هي الخيار الآمن.

القرار في تمريرة واحدة

اتبع هذه الأسطر الأربعة وتوقف عند أول سطر ينطبق:

• صفحة الإعداد تذكر sacli start، أو أنك نفذت ConfigPut للتو: استخدم sacli start.
• الصفحة تتطلب إعادة تشغيل، أو أن التغيير يمس المستمعين لا الخصائص: استخدم systemctl restart openvpnas.
• يصل shell الخاص بك عبر هذا الخادم: رتب الوصول إلى وحدة التحكم أولا، ثم نفذ الأمر الذي اختاره السطران أعلاه.
• التحقق: sacli status، و ConfigQuery للقيمة، ودخول واحد، ومورد خاص واحد. حالة الخدمة وحدها ليست خط النهاية.

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