سكربت auth-user-pass-verify في OpenVPN: اضبط رمز الخروج على الصواب

OpenVPN يتصرف بناءً على مخرج واحد فقط من سكربت تسجيل الدخول: حالة الخروج. كل ما يفعله السكربت بعد ذلك زينة. يمكن للخطاف أن يصل إلى المدقق الصحيح ويحلل الرد ويطبع سطرًا ودودًا بينما يعيد حالة تعني عكس ما قصده كاتبه. اقرأ العقد أولًا واكتب المحول حوله، فتختفي تلك الفئة كاملة من الأخطاء.

العقد صغير: حدد الحساب الذي أُرسل، واسأل المدقق المعتمد السؤال المقصود، واقبل فقط النتيجة الإيجابية الموثقة لذلك المدقق عن ذلك الطلب. كل ما عدا ذلك بنية تحتية.

الحالات الثلاث التي يمكن أن يعيدها الخطاف

بالنسبة إلى auth-user-pass-verify، يحدد دليل OpenVPN 2.6 رمز الخروج 0 على أنه قبول، و1 على أنه رفض، و2 على أنه تحقق مؤجل. هذه هي الإجابات الثلاث الوحيدة التي يفهمها الخادم، ولكل واحدة منها أثر مختلف على الاتصال. السكربت الذي يخرج بحالة أمره الأخير يكون قد ترك استدعاء تسجيل أو خطوة تنظيف يقرر بالنيابة عنه. اكتب الحالة صراحةً في كل فرع، بما فيها الفروع التي لم تصل إلى المدقق أبدًا.

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

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

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

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

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

قرر ماذا يعني جواب غير قابل للتصنيف

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

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

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

تحقق من الحكم، لا من السطر المطبوع

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

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

احتفظ بتخطيط نتيجة المدقق إلى حالة الخروج بجانب السكربت في المستودع، حتى يستطيع المهندس التالي قراءة العقد دون هندسة عكسية للكود.