كيفية تشغيل OpenConnect في الخلفية بعد تسجيل الدخول التفاعلي

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

تأكد مما تطلبه البوابة عند تسجيل الدخول

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

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

شغّل الجلسة الأولى في المقدمة واقرأ الخرج

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

ثم أعد نفس الاستدعاء مع وضع الخلفية وملف PID مضافاً، مثلاً openconnect --background --pid-file /run/openconnect.pid vpn.example.net، مع إبقاء خيارات البروتوكول والمصادقة التي تتطلبها بوابتك على السطر نفسه. يصف دليل OpenConnect هذا الخيار بأنه استمرار في الخلفية بعد اكتمال الإقلاع، ولهذا بالضبط يجب إنهاء المرحلة التفاعلية أولاً.

اجعل العملية الجارية قابلة للعثور عليها والإيقاف

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

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

لا تضع وضع الخلفية تحت مشرف

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

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

تعامل مع ملف تعريف الجلسة كبيانات اعتماد

يوثّق OpenConnect مرحلة مصادقة منفصلة عبر --authenticate، ويمكن إعادة تسليم المادة الناتجة بواسطة --cookie-on-stdin. ذلك الزوجان موجودان لعمل التكامل، وما ينتجانه حساس بقدر كلمة المرور التي أنشأته.

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

اعمل على القائمة قبل أن تغلق الطرفية

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

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