کدام نشانی را به‌عنوان کلاینت 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 فقط به دستگاه اجازه مشارکت می‌دهد؛ به هر نشست حاصل دسترسی به LAN نمی‌دهد.
خروجی تشخیصی را محدود نگه دارید: هیچ راز مشترکی، هیچ گذرواژه کاربری و هیچ بار کامل بسته‌ای در بلیت پشتیبانی نباشد. اگر طراحی می‌خواهد سرور NPS ویژگی‌های دایرکتوری را بخواند، آن اجازه کاری اداری جدای از ثبت کلاینت است، و وقتی نیست به شکلی دیگر شکست میخورد.