RouterOS OpenVPN اور NPS: auth نہیں، user-auth-method مقرر کریں

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 پالیسی ایک ہی طریقہ بتائیں، اجازت یافتہ صارف نئی نشست کے ساتھ جڑے، غلط پاس ورڈ مسترد ہو، خارج شدہ صارف خارج ہی رہے اور مختص کیا گیا پتہ مطلوبہ پول سے مطابقت رکھے۔ اس سے کم کچھ اگلے لاگ اِن کو اتفاق پر چھوڑ دیتا ہے۔