أي عنوان تسجّله كعميل RADIUS في NPS؟
سجّل مصدر الواجهة الخلفية الفعلي للبوابة، لا اسم المضيف العام ولا تجمّع العملاء. طابق السر المشترك، ثم تأكد بطلب واحد مضبوط.
تحتاج بوابة VPN التي تسلّم المصادقة إلى Windows NPS إلى كائن واحد على جانب NPS قبل أن يعمل أي نهج للمستخدمين: إدخال عميل RADIUS للبوابة. معظم المحاولات الفاشلة تسجّل العنوان الخطأ، لأن العنوان المهم هو الذي تستخدمه البوابة على مسار الواجهة الخلفية، لا اسم المضيف الذي يكتبه الموظفون في تطبيق VPN. إذا أخطأت في تلك القيمة، يتجاهل NPS الطلب بصمت، فيبدو الأمر من جانب العميل ككلمة مرور خاطئة. ثلاثة شروط تحدد أي عنوان ينتمي إلى الحقل، فاعمل عليها قبل فتح وحدة التحكم.
سجّل البوابة، لا الحواسيب المحمولة ولا التجمّع
يمثّل كائن عميل RADIUS جهاز الوصول إلى الشبكة الذي يرسل طلبات المصادقة. هذا الجهاز هو بوابة VPN، لا كل حاسوب محمول يشغّل العميل، ولا نطاق العناوين الممنوحة داخل الأنفاق.
لا تظهر عناوين الأنفاق هذه أبدًا كمصدر لطلب RADIUS، لأن الطلب يسير عبر مسار شبكة البوابة نفسه. تسجيل إدخال لتجمّع العملاء ينتج نهجًا لا يمكن أن يطابق شيئًا، بينما يصل الطلب الحقيقي من عنوان لم يسمع به NPS قط. ويؤدي الالتباس نفسه إلى إضافة عنوان IP المنزلي لكل موظف، وهو أمر متعذر الصيانة وخاطئ في الوقت نفسه.
ثلاثة شروط تحدد العنوان الذي تُدخله
أولًا، اعثر على عنوان المصدر الذي تستخدمه البوابة فعليًا تجاه NPS. كثيرًا ما ترسل بوابة متعددة الواجهات من واجهة إدارية أو خلفية بدلًا من مستقبل VPN العام. ثانيًا، تحقق من وجود NAT بين الطرفين: إذا تُرجم الطلب، يرى NPS العنوان المترجم، وهذه هي القيمة التي تُسجّلها. ثالثًا، إذا اشتركت بوابتان في الدور، فكل مصدر طلب يحتاج إدخال عميل خاصًا به، لأن كائنًا واحدًا بعنوان واحد يغطي واحدًا منهما فقط.
سجل بطرفين يحفظ الاقتران سليمًا. يستخدم الجدول أدناه عناوين خاصة للتوضيح، فاستبدلها بالعناوين التي يستخدمها مسارك فعلًا.
| At NPS | At the VPN gateway |
|---|---|
| RADIUS client address 10.20.0.10 | Authentication server 10.20.0.20 |
| Shared secret, agreed value | The same secret, same value |
| UDP 1812 permitted from 10.20.0.10 | UDP 1812 permitted toward 10.20.0.20 |
تأكد من المصدر بدلًا من تخمينه. راقب سجل NPS أو جدار الحماية خلال محاولة واحدة، أو التقط على مضيف NPS باستخدام sudo tcpdump -ni any udp port 1812. العنوان في ذلك الالتقاط هو الجواب الوحيد القابل للدفاع عنه في إدخال العميل. إذا كانت للبوابة عدة مصادر محتملة، فسجّل كل واحد باسم ودّي خاص به.
السر المشترك قيمة بين البوابة وNPS
يصدّق السر المشترك علاقة الجهازين. وهو ليس كلمة مرور مستخدم ولا يُوزّع أبدًا على الموظفين ولا يُضمّن في ملفات تعريف العملاء.
اختر قيمة واحدة، وأدخلها في الموضعين، واحفظها حيث يعيش نسخ إعداد البوابة. عدم التطابق ينتج طلبًا يُسقطه NPS دون خطأ مفيد، وهو ما لا يمكن تمييزه عن خادم غير قابل للوصول في سجل البوابة. بدّل القيمة خلال نافذة صيانة وحدّث الطرفين في التغيير نفسه.
تأكد بطلب واحد مسموح به
استخدم حسابًا مضبوطًا واربط محاولة واحدة على الجانبين. عند البوابة، تأكد من أن الطلب خرج نحو الخادم المقصود؛ وعند NPS، تأكد من أنه وصل من العميل المسجّل وطابق نهج طلب الاتصال المتوقع. انتهاء المهلة والرفض يعنيان شيئين مختلفين، ومعالجة كليهما كمشكلة بيانات اعتماد تهدر الساعة التالية. ثم اختبر حسابًا صالحًا غير مؤهل وكلمة مرور خاطئة، لأن نهجًا يقبل كل شيء ينجح أيضًا في الاختبار الأول.
أخيرًا، تحقق مما تفعله البوابة بالتفويض المُعاد. تسجيل عميل RADIUS لا يسمح للجهاز إلا بالمشاركة؛ ولا يمنح كل جلسة ناتجة وصولًا إلى الشبكة المحلية.
أبقِ المخرجات التشخيصية محدودة: لا أسرار مشتركة، ولا كلمات مرور مستخدمين، ولا حمولات حزم كاملة في تذكرة دعم. إذا كان التصميم يتطلب أن يقرأ خادم NPS سمات الدليل، فهذا الإذن مهمة إدارية منفصلة عن تسجيل العميل، ويفشل بطريقة مختلفة عند غيابه.