توقف تسجيل الدخول إلى VPN بعد Access-Challenge من RADIUS

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

تسجيل دخول واحد، وتبادلان مع RADIUS

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

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

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

ما الذي يحمله التحدّي فعلًا

يصف مواصفة RADIUS الرمز 11 في القسم 4.4 ويسمح بسمتين مهمّتين هنا. تحمل Reply-Message نصًّا موجّهًا إلى المستخدم، وتحمل State قيمة معتمة يريد الخادم إعادتها. وليس على NAS أن يفسّر State، بل أن يعيدها دون تغيير.

يستخدم طلب المتابعة Identifier جديدًا وRequest Authenticator جديدًا، وعليه أن يحمل قيمة State نفسها إضافةً إلى ردّ المستخدم. ويطابق الخادم الطلب مع التحدّي المعلّق عبر تلك State، ولهذا لا تستطيع بوابة تعيد توليد السمة أو تُسقطها إتمام المراسم. كما يجب أن يتحقق response authenticator في كل ردّ، وإلا فعلى NAS تجاهل الحزمة.

ويضيف القسم 4.4 التفصيل الذي يفسّر معظم حالات الفشل الصامت: إن NAS غير القادر على دعم التحديات يعامل Access-Challenge على أنه رفض. وإذا كانت خدمة VPN في بوابتك أقدم من ذلك الدعم أو تفتقده، يتحول طلب الخلفية لعامل ثانٍ إلى «فشل المصادقة» فوري دون أي مطالبة.

أين يضيع الطلب المتسلسل

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

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

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

تتبّع محاولة واحدة من البداية إلى النهاية

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

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

في الخَرْج، ابحث عن شكل المحادثة لا عن سطر واحد. طلب Access-Request أول بـIdentifier 3، ثم Access-Challenge يحمل State، ثم طلب Access-Request ثانٍ بـIdentifier 4 يكرّر تلك State ويتضمن ردّ المستخدم. إذا غاب الطلب الثاني فالبوابة لم تتابع أبدًا. وإذا وصل دون State فلا يستطيع الخادم مطابقته مع التحدّي المعلّق وسيرفضه عادةً.

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

الحالة المكتملة التي تريدها هي محادثة مكتملة ومصرَّح بها تتبعها إتاحة الخدمة المقصودة. أما وصول ردّ من خادم RADIUS فيثبت أقل بكثير من ذلك.