RouterOS OpenVPN و NPS: اضبط user-auth-method لا auth
في RouterOS يختار auth خلاصة النفق، بينما يقرر user-auth-method كيف يتم فحص طلب RADIUS. طابق الثاني مع سياسة NPS.
قد يصل RouterOS إلى NPS عبر تسجيل دخول OpenVPN ويظل مرفوضًا، والسبب المعتاد إعدادان يشبه اسماهما المصادقة. أحدهما يختار خلاصة تشفيرية للنفق؛ والآخر يقرر كيفية تقديم بيانات اعتماد المستخدم إلى RADIUS. تغيير الخلاصة لن يحوّل طلب PAP إلى MS-CHAPv2 أبدًا، مهما تكرر إعادة تشغيل الخدمة. تفصل القائمة أدناه بين الاثنين، ثم تتبع تسجيل دخول فاشل واحد عبر سياسة NPS التي حكمت عليه.
الخطوة 1: اقرأ الإعدادين قبل تغيير أي منهما
اطبع تكوين خادم OpenVPN الفعّال على الموجّه الذي ينهي النفق، لا من نسخة احتياطية أو منشور منتدى منسوخ. الحقلان المهمان عادةً في القائمة نفسها ويبدوان كبديلين. ليسا كذلك: أحدهما يتعلق بقناة البيانات، والآخر بتبادل بيانات الاعتماد.
/interface ovpn-server server print
/interface ovpn-server server export
يسرد الحقل auth خلاصات مثل sha1 وsha256، ويتحكم في HMAC الذي يصادق على حزم النفق. يختار الحقل user-auth-method pap أو mschap2 ويقرر كيف يقدّم الموجّه بيانات اعتماد المستخدم إلى RADIUS. لا يمكن لتغيير الخلاصة أن يغيّر السلوك الثاني، ولهذا يبقى الرفض نفسه مع كل تعديل على الأول.
توقف هنا إذا كان إصدارك لا يعرض user-auth-method إطلاقًا. قد لا توفره إصدارات RouterOS الأقدم على خادم OpenVPN، والإصلاح ينتمي إلى إصدار يمكنك دعمه لا إلى أمر منسوخ من إصدار أحدث.
الخطوة 2: اعثر على السياسة التي رفضت تسجيل الدخول فعليًا
على جانب NPS، يُقيَّم طلب الاتصال مقابل سياسات الشبكة، ويجب أن تكون طريقة المصادقة المذكورة في السياسة المطابقة إحدى الطرق التي عرضها العميل فعلًا. اربط تسجيل دخول فاشل واحد بالوقت والمستخدم بدل قراءة عدد إجمالي. يسجل سجل الأمان الطلبات الممنوحة والمرفوضة برمز سبب، وهو يخبرك بأكثر بكثير من سطر الفشل العام للموجّه.
Get-WinEvent -LogName Security -MaxEvents 200 |
Where-Object { $_.Id -in 6272,6273 } |
Format-List TimeCreated,Id,Message
اقرأ ثلاثة أشياء في الحدث: اسم السياسة المطابقة، وطريقة المصادقة، ورمز السبب. السياسة التي تتطلب MS-CHAPv2 ترفض طلب PAP حتى عندما تكون كلمة المرور صحيحة، والسياسة التي تتطلب حساب نطاق ترفض حسابًا محليًا. يجب أن يطابق إدخال عميل RADIUS عنوان مصدر الموجّه أيضًا، وإلا يُسقط الطلب قبل استشارة أي سياسة. لا يظهر أي من ذلك في سجل OpenVPN.
توقف هنا إذا لم يصل الطلب إلى NPS أبدًا. تلك مشكلة في السر المشترك أو عنوان العميل أو UDP 1812، ولن يصلحها تغيير طرق المصادقة.
الخطوة 3: غيّر طريقة واحدة، على الجانبين
إذا كان التصميم المعتمد هو MS-CHAPv2، فاضبطه على الموجّه وتأكد من أن السياسة المطابقة تقبله. غيّر جانبًا واحدًا، وأعد الاختبار، ثم غيّر الآخر؛ تغيير الاثنين معًا يتركك غير قادر على القول أيهما كان مهمًا.
/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"
لا تفعّل كل طريقة أضعف على NPS لتختفي المشكلة. يجب أن تحتفظ الخلفية بالمواد التي يمكن للطريقة المختارة التحقق منها: تحتاج MS-CHAPv2 إلى الوصول إلى كلمة المرور أو إلى النطاق، ولا يمكن للسياسة أن تخترع تلك المواد. توسيع السياسة يوسّع أيضًا ما يمكن لمهاجم تجربته ضد الحساب نفسه. سجّل الطريقة واسم السياسة ومرجع التغيير معًا، حتى يرث الشخص التالي قرارًا لا تخمينًا.
أبقِ التحقق من شهادة النفق كما كان تمامًا. طريقة بيانات الاعتماد ليست بديلًا عن هوية الخادم، وخفض فحوص TLS لنجاح اختبار يبادل مشكلة بمشكلة أسوأ.
الخطوة 4: اختبر ثلاثة تسجيلات دخول وصلاحية واحدة
اختبر مستخدمًا مسموحًا، وكلمة مرور خاطئة، ومستخدمًا مستبعدًا، كلًا في جلسة جديدة. الأول يثبت المسار، والثاني يثبت أن فحص بيانات الاعتماد حقيقي، والثالث يثبت أن السياسة ما زالت تستبعد من ينبغي استبعاده. يمكن لجلسة مخزنة أن تخفي الثلاثة، لذا افصل بين المحاولات.
/log print where topics~"ovpn"
/radius monitor 0
نجاح المصادقة ليس نهاية القائمة. تحقق من العنوان الذي تلقاه العميل ومن الموارد التي يمكن لذلك العنوان الوصول إليها، لأن المستخدم قد يصادق بشكل صحيح ويقع مع ذلك في التجمع الخاطئ. إذا كان العنوان المخصص خاطئًا، فالمشكلة في الملف الشخصي أو في سمات رد RADIUS، لا في الطريقة. أكّد الاثنين قبل إغلاق التذكرة.
تكتمل القائمة عندما يسمّي إعداد الموجّه وسياسة NPS الطريقة نفسها، ويتصل مستخدم مسموح بجلسة جديدة، وتُرفض كلمة مرور خاطئة، ويبقى مستخدم مستبعد مستبعدًا، ويطابق العنوان المخصص التجمع المقصود. أي شيء أقل يترك تسجيل الدخول التالي للحظ.