OpenVPN دون شهادة عميل: سياسة الخادم وليست ملف التعريف

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

ملف التعريف ليس السياسة

تأتي نسخة Community OpenVPN 2.6 وشهادات العميل إلزامية فيها، لأن verify-client-cert يأخذ القيمة الافتراضية require. ضبطه على none هو ما يوقف المطالبة بشهادة ويسلّم مصادقة العميل إلى أي ترتيب لاسم المستخدم وكلمة المرور يعمل به الخادم أصلًا. تلجأ الأدلة الأقدم إلى client-cert-not-required، وهي الصيغة القديمة للفكرة نفسها، لذا استخدم التوجيه الذي توثّقه نسختك المثبّتة. وفي كلتا الحالتين يحدث التغيير على الخادم، ولا يمكن لأي ملف تعريف عميل أن ينفّذه.

المقطع أدناه هو التغيير الكامل على جهة الخادم، وهو بذاته ليس إعداد مصادقة صالحًا للعمل. يزيل verify-client-cert none شرط الشهادة، بينما يجعل username-as-common-name اسم الحساب هو الهوية التي تراها عمليات الاستدعاء اللاحقة وملفات كل عميل. لا يتحقق أي من السطرين من كلمة مرور، لذا لا بد من وجود مدقّق.

verify-client-cert none
username-as-common-name

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

ما لا يزال يتحقق من الخادم

إسقاط شهادة العميل لا يسقط TLS. يحتفظ الخادم بشهادته ومفتاحه، ويحتفظ العميل بثقة CA وفحوص اسم المضيف التي تمنعه من التحدث إلى محتال. إزالة remote-cert-tls server أو حزمة CA لأن العميل لم يعد يملك شهادة سوء فهم شائع وخطير، و مرجع 2.6 صريح في أن الاتجاهين مستقلان. أحدهما يثبت الخادم للعميل؛ والآخر يثبت العميل للخادم.

يمكن أن يحمل ملف التعريف أيضًا كتلة tls-auth أو tls-crypt. هذا مفتاح مشترك لقناة التحكم له دورة توزيع وتدوير خاصة به، لذا فملف بلا أسطر شهادة أو مفتاح ليس آمنًا تلقائيًا للنشر. تعامل معه كسرّ حتى تقرأه.

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

ما يجب أن يفعله المدقّق

بإزالة شرط الشهادة، يصبح كل شيء معتمدًا على المدقّق: إضافة، أو نص برمجي يُشغّله auth-user-pass-verify. عليه أن يرفض بيانات الاعتماد غير الصالحة، ويرفض الحسابات المعطّلة أو غير المؤهلة، وأن يفشل مغلقًا عندما يتعذر عليه الوصول إلى خلفيته. غالبًا ما يُفعّل username-as-common-name إلى جانبه، وهو يغيّر الهوية التي تراها عمليات الاستدعاء اللاحقة وملفات تهيئة كل عميل. لا يتحقق من كلمة مرور، ولا يجعل حسابًا غير مؤهل مؤهلًا. تلك مهام منفصلة، والخلط بينها هو كيف ينجح ترحيل في اختبار المسار السعيد ويفشل في أول حادث حقيقي.

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

غيّر السياسة وملف التعريف والتخطيط معًا

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

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

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