EAP یا کلائنٹ سرٹیفکیٹ؟ IKEv2 تصدیق کا فیصلہ

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

دونوں میں سے کسی چیز کو چھونے سے پہلے طے کریں کہ کون سا دعویٰ ناکام ہوا۔ ناکامی کا مرحلہ آپ کو یہ بتاتا ہے، اگر آپ ترتیب سے پڑھیں۔

دو اسناد، دو دعوے

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

نجی کلید کھولنے والا پاس فریز اکاؤنٹ کا پاس ورڈ نہیں ہے، چاہے دونوں درخواستیں ایک دوسرے سے سیکنڈوں میں ظاہر ہوں۔ ایک آلے کے کلید ذخیرے میں مقامی ہے، اور دوسرے کی توثیق گیٹ وے کے پیچھے موجود تصدیقی سرور کرتا ہے۔

EAP ایک برتن ہے، طریقہ نہیں

EAP ایک ڈھانچہ ہے: گیٹ وے اور کلائنٹ کسی طریقے پر بات چیت کرتے ہیں، اور طریقہ طے کرتا ہے کہ پاس ورڈ، ٹوکن، سرنگ کے اندرونی تبادلے یا سرٹیفکیٹ شامل ہیں، جیسا کہ IKEv2 پر strongSwan کی دستاویز بیان کرتی ہے۔ اسی لیے EAP-TLS کلائنٹ کی طرف سے EAP-MSCHAPv2 جیسا بالکل نہیں لگتا، اگرچہ دونوں مینو میں EAP کے طور پر دکھائی دیتے ہیں۔ صرف EAP بتانے والا پروفائل آپ کو یہ نہیں بتاتا کہ صارف سے کیا پوچھا جائے گا۔

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

مخلوط تعیناتی عام ہے

صارف کے لیے سرور سرٹیفکیٹ کے ساتھ EAP وہ شکل ہے جو زیادہ تر دور دراز رسائی گیٹ ویز تعینات کرتے ہیں، کیونکہ یہ کلائنٹ کو قابل تصدیق اختتامی نقطہ اور آپریٹر کو مرکزی اکاؤنٹ ذخیرے میں ہر صارف کی شناخت دیتا ہے۔ کلائنٹ سرٹیفکیٹ کے ساتھ تعیناتیاں بھی موجود ہیں، عام طور پر وہاں جہاں آلے کی شناخت پاس ورڈ سے زیادہ اہم ہو۔ دونوں جائز ہیں، اور غلطی یہ ہے کہ گزشتہ ہفتے جو دیکھا وہی سامنے موجود سمجھا جائے۔

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

ناکامی کے مرحلے سے فیصلہ

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

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

دونوں ماڈل چلانا

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

انہیں اپنے نوٹس میں الگ رکھیں۔ سرٹیفکیٹ کی میعاد ختم ہونا کسی تاریخ پر ناکامی پیدا کرتا ہے، اکاؤنٹ لاک آؤٹ پاس ورڈ بدلنے کے بعد ناکامی پیدا کرتا ہے، اور طریقے کی عدم مطابقت صرف ایک پلیٹ فارم پر ناکامی پیدا کرتی ہے۔

شناخت قبول ہونے کے بعد

تصدیق ایک دروازہ ہے۔ child سیکیورٹی ایسوسی ایشن، ٹریفک منتخب کنندگان، DNS اور ایپلیکیشن کی اپنی اجازتیں بعد کے دروازے ہیں، اور ہر ایک اپنی شرائط پر ناکام ہوتا ہے۔ قبول شدہ شناخت جو کہیں نہ پہنچے وہ تصدیق کا مسئلہ نہیں۔

طریقہ، استعمال شدہ اکاؤنٹ یا سرٹیفکیٹ اور ناکام ہونے والا مرحلہ درج کریں۔ وہ نوٹ اگلے واقعے کو تجربے کے بجائے تلاش میں بدل دیتا ہے۔