OpenVPN username-as-common-name: لماذا يخرج فحص CN فارغًا
قد يقارن سكربت client-connect بين common_name وusername فيقارن اسمًا بنفسه. اربط الشهادة بالحساب قبل تنفيذ الاستبدال.
تضيف سكربت client-connect يرفض أي اتصال يختلف فيه common_name عن username، فيبدو الأمر كأنه ربط بين شهادة وحساب. على خادم يعمل بخيار username-as-common-name، تكون تلك المقارنة قد فقدت معناها بحلول وقت تشغيل السكربت. القيمتان هما السلسلة نفسها، لذا ينجح الفحص مع شهادة صادرة لشخص آخر تمامًا.
الفحص ليس خاطئًا لأن السكربت مكتوب بشكل سيئ. بل هو خاطئ لأن القيمة التي يقرأها كانت قد استُبدلت في وقت سابق من الاتصال نفسه.
ما الذي يبدو أن المقارنة تثبته
مصادقة الشهادة ومصادقة كلمة المرور برهانان منفصلان، ويمكن للخادم أن يطلب كليهما دون أن يطلب أن يعودا إلى الشخص نفسه. الفجوة حقيقية: شهادة جهاز صالحة مع أي حساب صالح ادعاء مختلف عن شهادة الجهاز نفسها مع حساب واحد محدد بالاسم. السكربت الذي يقارن common_name مع username يُقرأ كأنه الحلقة المفقودة بين الاثنين. وسيكون كذلك لو كان common_name لا يزال يعني ما قالته الشهادة.
ويعتمد ذلك على خيار واحد في الخادم، وعادةً ما يُفعَّل ذلك الخيار لسبب غير ذي صلة، مثل تسهيل تسمية ملفات الإعداد لكل مستخدم.
ما الذي يفعله username-as-common-name بالاسم
عند تفعيل username-as-common-name، يستبدل OpenVPN الاسم الشائع للشهادة باسم المستخدم الموثَّق بعد التحقق من اسم المستخدم وكلمة المرور. لا يزال خطاف التحقق الذي يعمل أثناء ذلك الفحص يستقبل الاسم الشائع للشهادة، لأن الاستبدال لم يحدث بعد. كل ما يأتي بعد ذلك، بما فيه client-connect، يرى اسم المستخدم. لذا يتلقى النداء اللاحق هوية واحدة مرتين ولا يستطيع مقارنتها بالشهادة التي قُدِّمت.
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
تتبَّع اتصالًا توضيحيًا واحدًا: شهادة صادرة لجهاز bob-device، ودخول ناجح إلى الدليل باسم alice، والخيار مفعَّل. لا تزال مرحلة التحقق ترى سلسلتين مختلفتين. وترى مرحلة الاتصال alice و alice.
يوضح ذلك المثال سبب كون المقارنة فارغة. ولا يوضح أن الاتصال كان سيُقبل لولا ذلك، لأن التحقق من الشهادة والتحقق من كلمة المرور لا يزالان يعملان بمفردهما.
ضع الربط حيث توجد الهويتان معًا
يجب فرض القاعدة في مرحلة ترى هوية الشهادة والحساب في الوقت نفسه، وهذا يعني عمليًا خطاف التحقق من اسم المستخدم وكلمة المرور أو إضافة تُحمَّل هناك. الإضافة المدعومة التي تنفذ بالفعل التحقق من كلمة المرور هي عادةً المكان المناسب لإضافة قاعدة اقتران، لأن استبدالها بمقارنة أسماء سيسقط فحص كلمة المرور بالكامل.
حدِّد التعيين قبل كتابة الشيفرة، لأن التساوي نادرًا ما يكون السياسة الحقيقية. غالبًا ما تحدد الشهادة جهازًا بينما يحدد تسجيل الدخول شخصًا، وقد يخدم جهاز واحد عدة أشخاص بشكل مشروع. خزِّن العلاقة في صيغة تتحكم أنت في إصدارها، وقرِّر ما يحدث عند تغيير الاسم وعند إعادة الإصدار وعند الأسماء المؤهلة بالنطاق. إن تحويل بادئة النطاق إلى أحرف صغيرة أو إزالتها دون فهم الدليل قد يدمج حسابين كان يُقصد بهما البقاء منفصلين.
تذكَّر أن الخيار يغيّر أيضًا أي إعداد لكل عميل ينطبق، لأن client-config-dir مفهرس بالاسم الشائع.
اختبر الاقتران ببيانتي اعتماد صالحتين
ابدأ بالزوج الذي تسمح به سياستك وتأكد من اتصاله. ثم قدِّم الشهادة الصالحة نفسها مع حساب مختلف لكنه صالح في بقية النواحي: يجب أن تفشل تلك المحاولة، ويجب أن تفشل بسبب قاعدة الاقتران لا بسبب كلمة مرور مكتوبة خطأً. كلمة مرور خاطئة تثبت أن فحص كلمة المرور يعمل ولا تقول شيئًا عن قاعدة ربط الشهادة بالحساب.
افحص أيضًا مسارَي الشهادة المفقودة والشهادة غير الصالحة، وتأكد من الهوية التي يستخدمها الخادم لإعدادات كل عميل. وإذا كانت الطريقة الوحيدة لجعل المقارنة تعمل هي تعطيل username-as-common-name، فاحسب تكلفة ذلك التغيير أولًا، لأنه يعيد بحث إعدادات كل عميل إلى اسم الشهادة.