RouterOS OpenVPN و NPS: user-auth-method را تنظیم کنید، نه auth

RouterOS می‌تواند با ورود OpenVPN به NPS برسد و باز هم رد شود، و علت معمول دو تنظیم است که نام هر دو شبیه احراز هویت به نظر می‌رسد. یکی خلاصهٔ رمزنگاری برای تونل انتخاب می‌کند؛ دیگری تصمیم می‌گیرد اعتبارنامهٔ کاربر چگونه به RADIUS ارائه شود. تغییر خلاصه هرگز یک درخواست PAP را به MS-CHAPv2 تبدیل نمی‌کند، هر چند بار که سرویس دوباره راه‌اندازی شود. چک‌لیست زیر این دو را جدا می‌کند و سپس یک ورود ناموفق را از میان سیاست NPS که درباره‌اش داوری کرده دنبال می‌کند.

گام 1: پیش از تغییر هر یک، هر دو تنظیم را بخوانید

پیکربندی مؤثر سرور OpenVPN را روی روتری که تونل را پایان می‌دهد چاپ کنید، نه از روی نسخهٔ پشتیبان یا پست کپی‌شدهٔ انجمن. دو فیلدی که به آن‌ها نیاز دارید معمولاً در همان منو هستند و طوری خوانده می‌شوند که گویی گزینه‌های جایگزین‌اند. چنین نیستند: یکی دربارهٔ کانال داده است و دیگری دربارهٔ تبادل اعتبارنامه.

/interface ovpn-server server print
/interface ovpn-server server export

فیلد auth خلاصه‌هایی مانند sha1 و sha256 را فهرست می‌کند و HMACای را کنترل می‌کند که بسته‌های تونل را احراز هویت می‌کند. فیلد user-auth-method pap یا mschap2 را انتخاب می‌کند و تصمیم می‌گیرد روتر اعتبارنامهٔ کاربر را چگونه به RADIUS ارائه دهد. تغییر خلاصه نمی‌تواند رفتار دوم را عوض کند، و به همین دلیل همان رد شدن پس از هر تنظیم روی اولی باقی می‌ماند.

اگر نسخهٔ شما user-auth-method را اصلاً ارائه نمی‌کند، اینجا توقف کنید. ساخت‌های قدیمی‌تر RouterOS ممکن است آن را روی سرور OpenVPN ارائه نکنند، و اصلاح باید در نسخه‌ای باشد که می‌توانید پشتیبانی کنید، نه در فرمانی کپی‌شده از نسخهٔ جدیدتر.

گام 2: سیاستی را پیدا کنید که واقعاً ورود را رد کرده است

در سمت NPS، یک درخواست اتصال بر پایهٔ سیاست‌های شبکه ارزیابی می‌شود، و روش احراز هویتی که در سیاست منطبق نام برده شده باید یکی از روش‌هایی باشد که کلاینت واقعاً ارائه کرده است. یک ورود ناموفق را بر اساس زمان و کاربر به هم مرتبط کنید، نه با خواندن یک شمارش خلاصه. گزارش امنیتی درخواست‌های پذیرفته و ردشده را با کد دلیل ثبت می‌کند، که بسیار بیشتر از خط خطای عمومی روتر به شما می‌گوید.

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

سه چیز را در رویداد بخوانید: نام سیاست منطبق، روش احراز هویت و کد دلیل. سیاستی که MS-CHAPv2 می‌خواهد حتی وقتی گذرواژه درست است درخواست PAP را رد می‌کند، و سیاستی که حساب دامنه می‌خواهد حساب محلی را رد می‌کند. ورودی کلاینت RADIUS نیز باید با نشانی مبدأ روتر مطابقت داشته باشد، وگرنه درخواست پیش از بررسی هر سیاستی کنار گذاشته می‌شود. هیچ‌یک از این‌ها در گزارش OpenVPN دیده نمی‌شود.

اگر درخواست هرگز به NPS نمی‌رسد، اینجا توقف کنید. این مشکل راز مشترک، نشانی کلاینت یا UDP 1812 است، و تغییر روش‌های احراز هویت آن را درست نمی‌کند.

گام 3: یک روش را در هر دو طرف تغییر دهید

اگر طراحی تأییدشده MS-CHAPv2 است، آن را روی روتر تنظیم کنید و تأیید کنید که سیاست منطبق آن را می‌پذیرد. یک طرف را تغییر دهید، دوباره آزمایش کنید، سپس طرف دیگر را تغییر دهید؛ تغییر هر دو همزمان شما را از گفتن اینکه کدام مهم بود ناتوان می‌کند.

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

برای از بین رفتن خطا، هر روش ضعیف‌تری را روی NPS فعال نکنید. بک‌اند باید موادی داشته باشد که روش انتخاب‌شده بتواند بررسی کند: MS-CHAPv2 به دسترسی به گذرواژه یا دامنه نیاز دارد، و سیاست نمی‌تواند آن مواد را از خود بسازد. گستردن سیاست همچنین گسترش می‌دهد که مهاجم چه چیزی را علیه همان حساب امتحان کند. روش، نام سیاست و ارجاع تغییر را با هم ثبت کنید تا نفر بعدی تصمیمی را به ارث ببرد، نه حدسی.

اعتبارسنجی گواهی تونل را دقیقاً همان‌طور که بود نگه دارید. روش اعتبارنامه جایگزین هویت سرور نیست، و پایین آوردن بررسی‌های TLS برای قبولی یک آزمون یک مشکل را با مشکلی بدتر عوض می‌کند.

گام 4: سه ورود و یک مجوز را آزمایش کنید

یک کاربر مجاز، یک گذرواژهٔ اشتباه و یک کاربر کنارگذاشته‌شده را آزمایش کنید، هر یک در نشستی تازه. اولی مسیر را ثابت می‌کند، دومی ثابت می‌کند بررسی اعتبارنامه واقعی است، و سومی ثابت می‌کند سیاست هنوز کسانی را که باید کنار بگذارد، کنار می‌گذارد. نشست ذخیره‌شده می‌تواند هر سه را پنهان کند، پس میان تلاش‌ها قطع اتصال کنید.

/log print where topics~"ovpn"
/radius monitor 0

موفقیت احراز هویت پایان چک‌لیست نیست. نشانی‌ای را که کلاینت گرفته و منابعی را که آن نشانی می‌تواند به آن‌ها برسد بررسی کنید، زیرا کاربر می‌تواند درست احراز هویت شود و باز هم در استخر اشتباه بیفتد. اگر نشانی تخصیص‌یافته اشتباه است، مشکل در پروفایل یا در ویژگی‌های پاسخ RADIUS است، نه در روش. پیش از بستن تیکت هر دو را تأیید کنید.

چک‌لیست زمانی کامل است که تنظیم روتر و سیاست NPS یک روش را نام ببرند، یک کاربر مجاز با نشستی تازه متصل شود، یک گذرواژهٔ اشتباه رد شود، یک کاربر کنارگذاشته‌شده همچنان کنار گذاشته باشد و نشانی تخصیص‌یافته با استخر موردنظر مطابقت داشته باشد. هر چیز کمتر، ورود بعدی را به شانس می‌سپارد.