خدمة OpenVPN تتوقف عند طلب كلمة مرور المفتاح الخاص: كيف تصلحها
لا تملك الخدمة طرفية، لذا يحتاج المفتاح المشفَّر إلى askpass وملف قابل للقراءة. افصل عبارة مرور المفتاح عن تسجيل الدخول إلى الخادم وافحص الوحدة.
OpenVPN يطلب عبارة مرور المفتاح الخاص على الجهاز المحلي، لذا لا يجيبها أبدًا ملف دخول صالح. في الخدمة لا توجد طرفية للكتابة، والبدء إما يتعلّق أو يفشل مع قيد في السجل يسمّي المدخل لا السبب. هنا سرّان، وكل واحد منهما يحتاج إلى مصدر مقروء خاص به قبل إعادة تشغيل الوحدة. الخطوات أدناه تفصل بينهما، ثم تتحقق من الهوية التي تفتح كل ملف فعلاً.
ميّز بين الطلبين
عبارة مرور المفتاح تفكّ تشفير المفتاح الخاص المحلي؛ وبيانات الحساب تصادق الجلسة مع الخادم. المصدر مختلف، ولحظة الفشل مختلفة، والرسائل مختلفة. الخلط بينهما يدفع الناس إلى البحث عن إعادة تعيين كلمة المرور بينما لم يكن للحساب دور. اقرأ نص الطلب قبل تغيير أي خيار، فالصياغة هي الدليل الموثوق الوحيد على السر الناقص.
في Community OpenVPN 2.x يسمّي askpass ملفًا يحمل عبارة مرور المفتاح في سطره الأول، ويسمّي auth-user-pass ملفًا فيه اسم المستخدم في سطر وكلمة المرور في السطر التالي. لا يمكن لأي من الملفين أن يفي بالخيار الآخر. قد يحتفظ تطبيق سطح مكتب أو ملف NetworkManager بالاثنين في مخزن أسراره الخاص، وهو ما لا يقرأه عميل سطر الأوامر أبدًا، فحدّد العميل الذي تضبطه قبل كتابة أي مسار.
وجّه الخيارين إلى ملفات مقروءة
الملف الذي يحتاج المدخلين ينتهي إلى ثلاثة مراجع ملفات : المفتاح المشفّر، وعبارة المرور التي تفتحه، وزوج الدخول. أضفها دون المساس بـ CA أو فحوص الهوية، فهي تحدد من هو الخادم وليست جزءًا من هذه المشكلة. وإذا كان النشر لا يستخدم بيانات الحساب إطلاقًا، فإن إضافة auth-user-pass تخلق مدخلًا لا يستطيع أحد تزويده.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authالخيارات المجرّدة تتصرف بشكل مختلف عن الخيارات ذات المسارات، والفرق مهم في الخدمة. askpass بلا وسيط يقرأ الطرفية رغم ذلك، وملف auth-user-pass يحمل اسم مستخدم فقط يترك طلب كلمة المرور منتظرًا. وبعد أن يتحول العميل إلى خدمة خلفية لا يستطيع طلب مدخل من طرفية إطلاقًا، فالخدمة المضبوطة بهذه الطريقة لا تقوم.
المسارات المطلقة تزيل سؤال دليل العمل لكنها لا تمنح الوصول. يأتي بعدها المالك والوضع والعبور، وكلها تُفحص مقابل الحساب الذي تعمل به العملية.
اقرأ إعداد الوحدة قبل ملف التعريف
الوحدة، لا الملف الذي كنت تحرّره، هي التي تقرر أي إعداد تُحمّله النسخة. اقرأ سطر أوامرها وأي ملفات drop-in، ثم تتبّع دليل العمل إلى ملف التعريف المستخدم فعلاً. وإشارة عبارة المرور المضافة إلى ملف .ovpn آخر لا تغيّر شيئًا لهذه النسخة.
ثلاثة أوامر للقراءة فقط تجيب عن معظم ذلك. الأول يطبع الوحدة وأي drop-in، والثاني يطبع الهوية وإعدادات العزل التي تقيّد العملية، والثالث يطبع ما شكا منه آخر تشغيل فعلاً. استخدم اسم النسخة الموجود على المضيف:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bانتبه إلى ProtectHome وإلى خيارات الملف نفسه: user و group و chroot. قد يكون ملف تحت دليل منزلي مقروءًا في صدفتك وغير مرئي داخل الخدمة بعد إخفاء الأدلة المنزلية. والحساب الذي يبدأ به systemd ليس دائمًا الحساب الذي يفتح المفتاح في النهاية.
أثبت أن هوية التشغيل تستطيع فتح الملفين
قراءة الوضع لا تكفي، لأن كل دليل على المسار يجب أن يكون قابلًا للعبور من الهوية نفسها. امشِ على المسار مكوّنًا مكوّنًا، ثم اختبر الفتح بحساب العملية. ملف بوضع 600 يملكه root يعمل فقط ما دامت العملية root، وهذا لا يصح بعد خفض الصلاحيات الذي تفعله ملفات كثيرة. أمرَان يغطيان العبور والفتح:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableالأمر الأول يطبع وضع كل مكوّن ويفشل حيث لا يستطيع الحساب العبور؛ والثاني يجيب عن السؤال الوحيد المهم: هل تستطيع هوية التشغيل فتح الملف للقراءة. لا يطبع أي منهما محتوى الملف، وهذا هو المقصود حين يحمل الملف عبارة مرور. كرّر الاختبار لملف الدخول، لأن الاثنين يُخزَّنان غالبًا بملكية مختلفة.
إن استخدمت العملية chroot أو namespace مقيّدًا، فشغّل الاختبار نفسه من داخل تلك الرؤية، وإلا وصف الجواب نظام ملفات خاطئًا. وعبارة المرور المخزنة تحت دليل منزلي مخفي هي المثال المعتاد لاختبار ينجح خارج الوحدة ويفشل داخلها.
افحص البدء الأول، ثم إعادة الاتصال
شغّل النسخة مرة واحدة واقرأ أول فشل لا آخره. ملف مدخل ناقص، وفشل فك تشفير المفتاح، و AUTH_FAILED من الخادم ثلاثة أحداث مختلفة بثلاثة إصلاحات مختلفة. وإصلاح تحذير أذونات لا يثبت شيئًا عن فتح المفتاح.
سطر السجل يخبرك أي الثلاثة لديك. والإصلاح يتبع المدخل الذي فشل:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
ثم اختبر دورة الحياة التي تحتاجها فعلاً : البدء عند الإقلاع وأي إعادة اتصال مدعومة، لا مجرد بدء يدوي من صدفتك. ومع auth-nocache تُسقَط المدخلات بعد أول استخدام، فإعادة الاتصال اللاحقة تحتاج مصدرًا مقروءًا. وسلسلة مفاتيح تُفتح عند تسجيل دخول سطح المكتب لا تتوفر لخدمة بدأت قبل أن يسجّل أحد الدخول، وهذا هو السبب المعتاد لنجاح اختبار يدوي وفشل إعادة التشغيل. وإذا نجح البدء الأول وفشلت إعادة اتصال لاحقة، فاقرأ السجل بحثًا عن حدث إعادة الاتصال قبل تغيير الأذونات مرة أخرى.
تخزين عبارة المرور بجانب المفتاح يقلّل ما يمنحه التشفير، فقيّد ذلك الملف ونسخه الاحتياطية. واعتبر إزالة عبارة مرور المفتاح قرارًا منفصلًا بشأن بيانات الاعتماد لا إصلاحًا لمدخل ناقص. والنشر الذي يعتمد على موافقة بشرية أو MFA تفاعلية يحتاج وكيلًا مدعومًا أو تكامل إدارة؛ ورمز لمرة واحدة محفوظ دائمًا ليس بديلًا مكافئًا.