نطاق مصادقة VPN: أي فضاء أسماء للحسابات يفوز؟

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

ماذا يختار النطاق

تستقبل البوابة اسم مستخدم وعليها أن تقرر أين تتحقق منه. النطاق هو الجزء من ذلك الاسم، أو السمة المجاورة له، الذي يختار قاعدة البيانات: دليل، أو مجموعة RADIUS، أو ملف حسابات محلي. تسمّي NPS من Microsoft هذا اسم نطاق وتوجّه به طلبات الاتصال، بينما يحمل معرّف الوصول الشبكي EAP الفكرة نفسها كلاحقة بعد علامة @ في RFC 7542. كلاهما محدِّدان، ولا يقرر أيّهما صلاحية بيانات الاعتماد.

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

صياغة النطاق تخص النشر. بعض الخدمات تريد اسمًا غير مؤهَّل مع سمة، وأخرى تريد user@domain، وقليل منها يتوقع صيغة بشرطة مائلة خلفية لا تذكرها معظم الأدلة.

استخدم الصيغة التي تتوقعها الخلفية

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

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

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

تتبّع الطلب عبر الوسيط

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

grep -n -A4 '^realm' /etc/freeradius/3.0/proxy.conf
radtest '[email protected]' 'wrong-password' 10.20.30.10 0 testing123
journalctl -u freeradius --since '-10 min' | grep -iE 'realm|stripped'

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

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

سجّل المحاولة دون تسريبها

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

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