آپ NPS کے RADIUS کلائنٹ کے طور پر کون سا پتہ رجسٹر کرتے ہیں؟
گیٹ وے کے اصل بیک اینڈ ماخذ کا پتہ رجسٹر کریں، عوامی ہوسٹ نیم یا کلائنٹ پول نہیں۔ مشترکہ سیکرٹ ملائیں، پھر ایک کنٹرول شدہ درخواست سے تصدیق کریں۔
وہ 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 سرور ڈائریکٹری اوصاف پڑھے، تو یہ اجازت کلائنٹ رجسٹریشن سے الگ انتظامی کام ہے، اور اس کی عدم موجودگی میں خرابی مختلف انداز میں ظاہر ہوتی ہے۔