لماذا لا يمكن لتعديل ملف .ovpn أن يشغّل التحقق بخطوتين على الخادم

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

المطالبة تُثبت أن العميل طلب، لا أكثر

ملف .ovpn مستند من جهة العميل. يمكنه أن يطلب من العميل طلب بيانات الاعتماد، أو تخزينها مؤقتًا أو التوقف عن ذلك. ولا يمكنه تسجيل مستخدم، أو تثبيت وحدة PAM، أو جعل الخادم يشترط عاملًا ثانيًا لا يتحقق منه حاليًا.

وتثبيت تطبيق مصادقة على الهاتف لا ينشئ تلك العلاقة أيضًا. مشروع Google Authenticator PAM مكوّن للتحقق من كلمات المرور لمرة واحدة يمكن أن يجلس خلف OpenVPN؛ وهو ليس طريقة لربط تسجيل الدخول بحساب Google بملف تعريف مستورد.

التسجيل هو الجزء الذي لا يستطيع الملف التعريفي فعله

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

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

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

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

اقرأ مكدس PAM لتعرف ما هو مطلوب فعليًا

سطر مثل account required pam_permit.so لا ينفّذ أهلية الحساب ولا يضيف عاملًا. إنه يسمح بمرحلة إدارة حسابات PAM تلك، وهو بيان عن مرحلة لا عن مستخدميك.

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

طابِق تفاعل العميل مع تصميم الخادم

auth-user-pass

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

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

أبقِ البذور ومواد QR خارج ملفات التعريف المشتركة وسجلات التشخيص الروتينية. الرمز المُرسَل عبر قناة تسجيل الدخول الموثّقة ليس الكائن نفسه الذي وُفِّر أثناء تسجيل مُدار، وخلطهما في تذكرة دعم هو الطريق الذي تتسرب منه الأسرار.

إعادة الاتصال والرموز والاختبار الذي يحسم الأمر

خطّط لما يحدث بعد أول تسجيل دخول ناجح. قد يكون الرمز المقبول سابقًا منتهي الصلاحية أو مرفوضًا كإعادة إرسال عند المصادقة التالية. auth-nocache يتحكم في الاحتفاظ ببيانات الاعتماد ولا يثبّت التحقق بخطوتين، أما reneg-sec 0 فليس تعريفًا لدعم TOTP مهما تكرر ظهوره في مواضيع المنتديات.

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

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