OpenVPN ينتظر طلب كلمة مرور من systemd: هل يجدر بك الرد؟

تظهر رسالة عن systemd-tty-ask-password-agent في الطرفية، ولا يكون النفق قائماً. القراءة المُغوية هي أن الـ VPN رفض كلمة المرور وأن شيئاً ما ينتظر تصحيحاً. والأدق أن نقول إن خدمة ما طلبت من systemd مدخلات تفاعلية، وإن الطلب لم يُجب بعد. أي خدمة طلبت، وأي سرّ تريد، سؤالان يمكنك حسمهما قبل كتابة أي شيء.

شرطان يحدّدان من ينبغي أن يردّ

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

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

هذه هي القاعدة كلها، ويستحق قولها قبل الأوامر. كل ما يلي يتفرّع عنها.

اسرد الطلب قبل أن تكتب أي شيء

يستطيع الوكيل أن يعدّ ما هو معلّق دون أن يجيب عن أي شيء. يطبع sudo systemd-tty-ask-password-agent --list الطلبات المعلّقة، وهذا الناتج هو الدليل الذي تحتاجه لربط مطالبة بوحدة. اقرأه قبل تقديم أي وثيقة اعتماد، وأبقِ أوصاف الطلبات خارج أي لصق تشخيصي علني.

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

لا تردّ على طلب لا تستطيع نسبته. كلفة الانتظار تأخير، أما كلفة الردّ على المطالبة الخطأ فهي وثيقة اعتماد في الموضع الخطأ.

أي سرّ تحتاجه النسخة فعلاً؟

يتعلق auth-user-pass بمصادقة الحساب لدى خدمة VPN، وبدون ملف اعتماد فإن السلوك الموثّق هو السؤال على الطرفية. أما askpass فيحصل على عبارة المرور التي تفتح مادة المفتاح المحمية، وهو يفعل ذلك قبل أن يتخفى البرنامج كخدمة خلفية. هذان سرّان مختلفان بعُمرين مختلفين.

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

افحص أي توجيه تستخدمه النسخة قبل أن تقرر ما تكتب. اسم التوجيه يخبرك أي سرّ تخصّه المطالبة.

ما يفعله --query ولا يفعله --list

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

استخدم أضيق آلية تنجح. فبالنسبة لخدمة واحدة، يكون مسار المطالبة الخاص بتلك الخدمة أضيق من وكيل عام، ويُبقي الجواب مرتبطاً بالوحدة التي طلبت.

تحويل طلب لمرة واحدة إلى وكيل عام غير مراقَب لأن إشعاراً ظهر مرة واحدة هو الطريق الذي يجعل إزعاجاً مؤقتاً تصميماً دائماً. وينطبق التحذير نفسه على تعطيل وحدات إشعار كلمة المرور على مستوى المضيف.

قرّر، ثم سجّل الخيار

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

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