VPN گیٹ وے کے ذریعے EAP: طریقہ کون ختم کرتا ہے

مدد کے ٹکٹ ناکام VPN لاگ اِن اور زیادہ مضبوط طریقہ مانگنے والی RADIUS پالیسی کو ایک ہی مسئلہ بتاتے ہیں، حالانکہ ایسا نہیں ہے۔ گیٹ وے یا تو اسناد قبول کر کے آگے بھیجتا ہے، یا کلائنٹ اور تصدیق کنندہ سرور کے درمیان EAP گفتگو لے جاتا ہے۔ ان میں سے کیا ہوتا ہے، یہ طے کرتا ہے کہ سرور کی طرف کوئی تبدیلی کچھ درست کر سکتی ہے یا نہیں۔ سرور گروپ میں ترمیم سے پہلے تبادلہ پڑھیں۔

لاگ میں ایک جیسے نظر آنے والے دو تصدیقی راستے

پہلے راستے میں VPN گیٹ وے صارف نام اور پاس ورڈ جمع کر کے پاس ورڈ خصوصیت کے ساتھ RADIUS Access-Request بھیجتا ہے۔ تصدیق کنندہ سرور اسے اپنے ذخیرے سے موازنہ کرتا ہے اور قبول یا مسترد کا جواب دیتا ہے۔ کلائنٹ کبھی EAP طریقہ نہیں چلاتا، کیونکہ کسی نے اس کی درخواست نہیں کی۔

دوسرے راستے میں کلائنٹ اور تصدیق کنندہ سرور EAP طریقہ شروع سے آخر تک چلاتے ہیں، اور گیٹ وے ان کے درمیان EAP-Message خصوصیات بھیجتا ہے۔ گیٹ وے اب بھی بیرونی RADIUS گفتگو ختم کرتا ہے، لیکن طریقہ کی منطق دونوں سروں پر ہے۔

دونوں راستے لاگ میں ایک سطر بناتے ہیں کہ تصدیق ناکام ہوئی۔ صرف دوسرا سرور کے پسندیدہ EAP طریقہ سے متاثر ہو سکتا ہے، اور صرف پہلا اس بات سے کہ گیٹ وے پاس ورڈ کیسے پڑھتا ہے۔ انہیں بدلے جانے والے سمجھنا ہی وجہ ہے کہ ٹیمیں ایسے کلائنٹ کے لیے دن بھر سرور گروپ بدلتی ہیں جو کبھی PEAP نہیں بولنے والا تھا۔

طریقہ حقیقت میں کہاں چلتا ہے

RFC 3579 گزرنے کا انتظام متعین کرتا ہے: NAS RADIUS خصوصیات میں EAP پیکٹ لے جاتا ہے اور ہر EAP قسم کے لیے طریقہ مخصوص کوڈ کی ضرورت نہیں ہوتی۔ اسی لیے گیٹ وے PEAP اور EAP-TLS دونوں کو کسی ایک کو نافذ کیے بغیر معاونت کر سکتا ہے۔

پاس ورڈ بھیجنے والا گیٹ وے PEAP نہیں لے جاتا، چاہے بیک اینڈ کسی دوسرے کلائنٹ سے PEAP قبول کرے۔ سرور پالیسی میں PEAP فعال کرنا ایسے کلائنٹ میں طریقہ نہیں جوڑتا جس نے کبھی ایک بھی پیش نہیں کیا۔

PPP تصدیق کی ترتیبات PPP سروس کی ہیں۔ وہ ایک ہی AAA سرور استعمال کرنے والے ہر IPsec یا پرانے XAuth راستے کو خاموشی سے دوبارہ تشکیل نہیں دیتیں، اس لیے ایک رسائی قسم کے لیے کام کرنے والی تبدیلی دوسرے کو اچھوتا چھوڑ سکتی ہے۔

NAS کو کیا معاونت کرنی چاہیے

گزرنا ضرورت کو طریقہ کوڈ سے لے جانے والے کی معاونت تک منتقل کرتا ہے۔ گیٹ وے کو اپنے VPN پروٹوکول پر EAP لے جانا ممکن ہونا چاہیے، اور اس پر RADIUS کلائنٹ متعلقہ جسامت کی EAP-Message خصوصیات بھیج اور وصول کر سکے۔

IKEv2 کے لیے EAP متعین تصدیقی بہاؤ کا حصہ ہے، اور سرور کی شناخت اور اعتماد کی جانچ اسی بہاؤ سے آتی ہے۔ 802.1X تعیناتی سے مستعار PEAP لیبل خود بخود منتقل نہیں ہوتا، کیونکہ اس کے گرد بات چیت مختلف ہے۔

کلائنٹ کی طرف بھی تقاضے ہیں۔ اسے طریقہ کے لیے ترتیب دیا گیا ہو، طریقہ کے پیش کردہ سرور سرٹیفکیٹ پر اعتماد ہو، اور ایسی اسناد ہوں جو طریقہ استعمال کر سکے۔ کلائنٹ سرٹیفکیٹ کے بغیر سرٹیفکیٹ پر مبنی طریقہ RADIUS کے کچھ دیکھنے سے پہلے ہی ناکام ہو جاتا ہے، یہ سرور پالیسی نہیں بلکہ فراہمی کا مسئلہ ہے۔

پالیسی بدلنے سے پہلے ایک کوشش پڑھیں

گیٹ وے اور تصدیق کنندہ سرور پر ایک منظور شدہ کوشش کیپچر کریں۔ RADIUS درخواست میں EAP-Message خصوصیات تلاش کریں۔ ان کی موجودگی بتاتی ہے کہ گزرنے کا راستہ استعمال میں ہے؛ نہ ہونا اسناد کے تبادلے کی طرف اشارہ کرتا ہے۔

Linux گیٹ وے پر RADIUS پورٹ پر کیپچر دکھاتا ہے کہ تار پر کون سی خصوصیات ہیں:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

پھر مسترد ہونے کے مقام کا موازنہ کریں۔ کسی بھی RADIUS پیکٹ سے پہلے گیٹ وے پر ناکامی کا مطلب ہے کہ کلائنٹ اور گیٹ وے طریقہ پر متفق نہیں تھے۔ EAP خصوصیات والا RADIUS مسترد ہونا مطلب ہے کہ دونوں سرے طریقہ چلا چکے اور ان میں سے ایک نے نتیجہ مسترد کیا۔

منتقلی کو شروع سے آخر تک ایک ہی تبدیلی کے طور پر منصوبہ بنائیں

طریقہ بدلنے کا مطلب ہے کلائنٹ ترتیب، گیٹ وے کی حامل معاونت، سرور کی طریقہ پالیسی اور اسناد کا ذخیرہ ایک ساتھ بدلنا۔ یہ اسی ترتیب سے کریں اور نیا ثابت ہونے تک کام کرتا راستہ رکھیں۔ صرف سرور کی طرف کی تبدیلی ایک اندازہ ہے، اور یہ عام طور پر کام کرنے والے کلائنٹ توڑ دیتی ہے۔ گروپ کو چھونے سے پہلے ایک آزمائشی شناخت پر تبدیلی تیار کریں۔

کام کرنے والا امتزاج لکھیں: VPN پروٹوکول، EAP حامل، ساتھی کا طریقہ، سرور کا طریقہ، اسناد کی قسم اور سرور شناخت کی جانچ۔

انتظامی لاگ اِن AAA کو VPN تصدیق سے الگ رکھیں، جب تک کام واضح طور پر دونوں شامل نہ کرے۔ دور رسائی کے لیے سوچی گئی تبدیلی آپ سے اس آلے کے انتظام کی صلاحیت نہیں چھیننی چاہیے جو اسے ختم کرتا ہے۔