IKEv2 سرور ایڈریس بمقابلہ شناخت: کلائنٹ اصل میں کیا چیک کرتا ہے۔

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

ان کو اس ترتیب میں چیک کریں اور پہلی بے مماثلت پر رکیں، کیونکہ بعد کے چیکس فرض کرتے ہیں کہ پہلے والے گزر چکے ہیں۔

سب سے پہلے، کون سی قدر ایڈریس ہے

کنکشن ایڈریس جو بھی کلائنٹ ڈائل کرتا ہے وہ ہوتا ہے: ایک IP، ایک DNS نام جو ایک کو حل کرتا ہے، یا بوجھ سے متوازن فرنٹ اینڈ۔ یہ نقل و حمل کی معلومات ہے اور کچھ نہیں۔ شناخت IKEv2 ID پے لوڈ میں سوار ہوتی ہے اور پھر اسے ہم مرتبہ کے سرٹیفکیٹ سے ملایا جاتا ہے۔ ایڈریس باکس میں ایک DNS نام متوقع شناخت نہیں بنتا ہے، اور ایک خام IP شناخت نہیں بنتا ہے صرف اس وجہ سے کہ ساکٹ اس سے جڑا ہوا ہے۔

strongSwan شرائط میں، پتہ right یا left ہے، اور متوقع شناخت rightid یا leftid ہے، اور یہ وہی ہے جو IKEv2 کنفیگریشن دستاویزات بیان کرتی ہے۔ اگر آپ نے صرف ایڈریس میں ترمیم کی ہے، تو آپ نے نصف جوڑی ترتیب دی ہے۔

دوسرا، سند سے کیا ثابت ہو سکتا ہے

شناخت کی ایک قسم ہے، اور سرٹیفکیٹ میں ایک مماثل نام ہونا ضروری ہے۔ ایک DNS شناخت مضمون کے متبادل نام کی توسیع میں dNSName اندراج سے مطمئن ہے، ایک IP شناخت کے لیے iPAddress اندراج کی ضرورت ہے۔ vpn.example.com کے لیے جاری کردہ سرٹیفکیٹ لغوی پتے 203.0.113.10 کے بارے میں کچھ بھی ثابت نہیں کرتا، اور اس پتے کے لیے جاری کردہ سرٹیفکیٹ نام کے بارے میں کچھ بھی ثابت نہیں کرتا ہے۔ اس لیے کسی دوسرے نام کے لیے دوبارہ جاری کرنا ڈراپ ان کا متبادل نہیں ہے، یہاں تک کہ جب ایک ہی کلید اور CA کو دوبارہ استعمال کیا جائے۔

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

تیسرا، ہر کلائنٹ کی توقع کیسے بیان کی جاتی ہے

Windows آپ کے ٹائپ کردہ سرور کا نام یا پتہ لیتا ہے اور اس سے مماثل ہونے کے لیے سرٹیفکیٹ کی ضرورت ہوتی ہے، لہذا IP ٹائپ کرنے سے IP کی توقع پیدا ہوتی ہے۔ Android کا IKEv2 کلائنٹ اسی طرح برتاؤ کرتا ہے، اور دونوں ایک درست، عوامی طور پر قابل اعتماد سرٹیفکیٹ کو مسترد کرتے ہیں جو ایک مختلف میزبان کا نام رکھتا ہے۔ ایک پروفائل صرف اس وجہ سے ناکام ہونا شروع کر سکتا ہے کہ کسی نے ہجرت کے دوران میزبان نام کو اس کے ایڈریس سے بدل دیا ہے۔ سرٹیفکیٹ میں کیا ہے یہ دیکھنے سے پہلے دیکھیں کہ کلائنٹ نے کیا مانگا ہے۔

strongSwan پر توقع واضح ہے: rightid کو اس شناخت پر سیٹ کریں جو سرور اصل میں پیش کرتا ہے، جو دائیں سے مختلف ہو سکتی ہے۔ اسے %any پر سیٹ کرنے سے ہم مرتبہ جو کچھ بھی پیش کرتا ہے اسے قبول کرتا ہے اور بالکل وہی چیک ہٹا دیتا ہے جسے آپ رکھنے کی کوشش کر رہے ہیں۔

چوتھا، ہم مرتبہ کی شناخت سے الگ صارف لاگ ان

EAP توثیق اور سرور کی شناخت مختلف سوالات کے جوابات دیتے ہیں۔ ایک EAP شناخت جیسا کہ [email protected] کہتا ہے کہ صارف کون ہے، اس کے بعد کلائنٹ کے فیصلہ کرنے کے بعد کہ سرور صحیح ہے۔ اس پاس ورڈ کو گھمانے سے ہم مرتبہ کی شناخت کی مماثلت کو ٹھیک نہیں کیا جا سکتا، کیونکہ کنکشن کبھی بھی صارف کے لاگ ان مرحلے تک نہیں پہنچتا ہے۔

ایک سینیٹائزڈ رپورٹ میں دونوں کے نام ہونے چاہئیں: وہ شناخت جس کی کلائنٹ کی توقع ہے، وہ شناخت جو سرور نے پیش کی ہے، اور سرٹیفکیٹ کی SAN اندراجات۔

پانچویں، تصدیق شدہ چینل کے ذریعے اسے تبدیل کریں

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

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