كيف يصل تسجيل الدخول إلى VPN إلى RADIUS ومزوّد الهوية لديك
تتبّع تسجيل الدخول إلى VPN من العميل إلى طلب RADIUS من البوابة، ومزوّد الهوية خلفه، والسياسة المطبّقة بعد القبول.
في الأسبوع الماضي استطاع مستخدم تسجيل الدخول إلى VPN ثم وجد نفسه على شبكة لا يُحلّ فيها أي اسم. قال العميل إنه متصل، وقال سجل البوابة Access-Accept، وقال فريق الهوية إن الحساب سليم. كان تسجيل الدخول قد نجح؛ لكن التفويض خلفه لم ينجح. عندما يفشل تسجيل الدخول إلى VPN، أسلك المسار الذي يسلكه الطلب فعلاً — العميل، والبوابة، وخادم RADIUS، ومزوّد الهوية — وأتوقف عند أول قفزة تختلف إجابتها عن التالية.
العميل لا يتحدث RADIUS أبداً
مهما يعرضه التطبيق على الحاسوب المحمول، فإن أول قفزة له هي بروتوكول VPN: IKEv2 أو OpenVPN أو WireGuard أو عميل قائم على TLS. لا يظهر RADIUS في ذلك التبادل. يوثّق العميل نفسه عند البوابة بشهادة أو باسم مستخدم وكلمة مرور أو طريقة EAP تُحمل داخل إعداد النفق.
هذا مهم عند قراءة السجلات، لأن خطأ المصادقة العام الذي يراه المستخدم تنتجه البوابة بعد أن تكون قد تحدّثت إلى شيء آخر بالفعل. إذا لم يصل العميل إلى البوابة قط، فلا يوجد طلب RADIUS لتصحيحه، وتكون الساعة التي تُقضى على خادم RADIUS مهدورة. تأكّد من أن النفق قام أصلاً قبل أن تلمس الواجهة الخلفية.
البوابة هي عميل RADIUS
بمجرد أن يصل إعداد النفق إلى النقطة التي يجب فيها التحقق من بيانات الاعتماد، تصبح البوابة خادم وصول شبكي. تبني طلب Access-Request: User-Name، وكلمة مرور أو حمولة EAP، وNAS-IP-Address أو NAS-Identifier، وMessage-Authenticator عندما تتطلب الطريقة ذلك. يذهب الطلب إلى UDP 1812 افتراضياً، والمحاسبة إلى 1813. لا تزال عمليات النشر الأقدم تستخدم 1645 و1646، لذا فإن قاعدة جدار ناري مكتوبة لزوج واحد تفسّر الكثير من حالات الفشل الصامت.
يتشارك الطرفان سراً، وهو ليس بيانات اعتماد مستخدم. إنه يوقّع التبادل، ويُتحقق من كل رد مقابله. اضبط السر بشكل مختلف على الطرفين فلا يرد الخادم بسر خاطئ — بل يُسقط الطلب أو يفشل التحقق من الرد، فتُبلّغ البوابة عن مهلة. السر الخاطئ والخادم الميت يبدوان متطابقين من البوابة، ولهذا أختبر القفزة بأداة عميل قبل أن ألوم الدليل.
البروتوكول صغير وقديم — RFC 2865 يعرّف تبادل المصادقة — لكن السمات التي يحملها هي ما تُبنى عليه معظم سياسات VPN.
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'قد لا يكون خادم RADIUS إلا واجهة أمام مزوّد الهوية
يقول الناس RADIUS ومزوّد الهوية كأنهما الصندوق نفسه. غالباً ليسا كذلك. يستقبل خادم RADIUS طلب Access-Request ثم يسأل شيئاً آخر — Active Directory عبر LDAP أو Kerberos، أو ملف مستخدمين محلي، أو خدمة خارجية — قبل أن يجيب. FreeRADIUS مع وحدة LDAP أو krb5، وWindows NPS، وCisco ISE كلها تقف في هذا الموضع.
التمييز يحدد أين تنظر. كلمة مرور مرفوضة هي إجابة مزوّد هوية يمررها RADIUS. المهلة عادةً هي الجزء بين RADIUS والدليل: حساب ربط منتهي، أو دليل غير قابل للوصول، أو طلب يُوجّه إلى واجهة خلفية خاطئة. إذا حمل اسم المستخدم لاحقة نطاق، فقد يوجّه الخادم عليها، وقد يصل الحساب نفسه المرسل كـ CORP\alice و[email protected] إلى مكانين مختلفين. في Windows NPS، يسجّل سجل Security الرقم 6272 عند المنح و6273 عند الرفض، وهذا يخبرك إن كان القرار قد جاء من NPS أصلاً.
اقرأ الفشل عند القفزة التي أنتجته
رسالة واحدة تعذّر الاتصال تغطي أربعة أعطال مختلفة. قبل تغيير أي شيء، طابق العَرَض مع القفزة التي أنتجته.
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
الصف الأخير هو الذي يرسل الناس إلى الفريق الخطأ. Access-Accept يعني أن بيانات الاعتماد قُبلت؛ ولا يعني أن البوابة وضعت المستخدم في التجمع الصحيح أو دفعت المسارات. سمات المجموعة لا تهم إلا إذا قرأتها سياسة البوابة. رأيت تسجيل دخول صحيحاً يهبط في تجمع ضيوف لأن تعيين المجموعة كان مضبوطاً على جانب RADIUS لسمة مختلفة عن تلك التي تفحصها البوابة.
تتبّع تسجيل دخول واحد من البداية إلى النهاية
اختر حساب اختبار واحداً وبوابة واحدة، ثم راقب المحاولة نفسها عند النقاط الأربع. ابدأ تشغيل تصحيح على جانب RADIUS — يطبع freeradius -X الطلب وكل وحدة يلمسها — وتابع سجل مصادقة البوابة، وشغّل tcpdump لتبادل UDP. اتصل مرة واحدة واقرأ الآثار الأربعة بالترتيب.
ما تريد رؤيته هو التوافق: سألت البوابة عن المستخدم الذي توقعته، واختار خادم RADIUS الواجهة الخلفية التي توقعتها، وأعادت تلك الواجهة قراراً، وتطابقت السمات في الرد مع السياسة التي تطبقها البوابة. أول مكان تختلف فيه الآثار هو خط العطل لديك. إذا لم يحمل الرد أي سمة مجموعة، فالمشكلة على جانب RADIUS وليست في ملف VPN؛ وإذا كانت السمة موجودة وتجاهلتها البوابة، فسياسة البوابة هي المشكلة.
ملاحظة أمنية واحدة ما دمت هناك. السر المشترك يحمي التبادل، لكنه لا يشفّر معظم السمات. إذا كانت البوابة وخادم RADIUS على مقاطع مختلفة، فضع تلك القفزة على RADIUS عبر TLS أو مسار خاص. النفق المشفّر للمستخدم لا يقول شيئاً عن رابط الواجهة الخلفية.
قبل أن تغلق التذكرة، تأكّد من أربعة أشياء. تستطيع البوابة الوصول إلى خادم RADIUS على المنفذ المضبوط فعلاً. السر المشترك متطابق على الطرفين. يحلّ خادم RADIUS شكل اسم المستخدم الدقيق الذي ترسله البوابة. يحمل القبول السمات التي تحتاجها سياسة البوابة. عندما تصح الأربعة جميعاً، فإن تسجيل دخول يفشل مع ذلك هو مشكلة سياسة بوابة، لا مشكلة مصادقة.