IKEv2 سرٹیفکیٹ کا SAN: شناخت کی جانچ کیوں ناکام ہوتی ہے

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

علامت ہمیشہ ایک ہی شکل کی ہوتی ہے

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

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

شناخت کنندہ کی قسم ملائیں، صرف قدر نہیں

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

وائلڈ کارڈز صرف DNS کی سہولت ہیں اور اپنے مماثلت کے قواعد کی پیروی کرتے ہیں، یہ ایک اور وجہ ہے کہ IP پر مبنی پروفائل کو کبھی ان پر انحصار نہیں کرنا چاہیے۔

تلاش کریں کہ ہر کلائنٹ توقع کہاں رکھتا ہے

strongSwan میں، سرٹیفکیٹ سے موازنہ کی جانے والی قدر ساتھی کی شناخت کی ترتیب سے آتی ہے: rightid کلاسک کنفیگریشن میں، یا id swanctl میں ریموٹ کنکشن سیکشن کے id سے۔ Apple IKEv2 باہمی تعامل کے بارے میں اس کی دستاویزات یہاں مفید ہیں کیونکہ یہ ان شناختی روایات کی وضاحت کرتی ہیں جو پروفائل سے چلنے والا کلائنٹ استعمال کرتا ہے، اور وہ روایات ایسی عدم مطابقت کی ایک قسم کی وضاحت کرتی ہیں جو تار پر بے ترتیب دکھتی ہے۔

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

پروفائل یا سرٹیفکیٹ کو دانستہ طور پر ٹھیک کریں

کچھ بھی بدلنے سے پہلے منظور شدہ اوزاروں سے ساتھی کا سرٹیفکیٹ معائنہ کریں اور SAN اندراجات ان کی اقسام کے ساتھ فہرست کریں۔ اس معائنے کے لیے نہ نجی کلید چاہیے نہ اپ لوڈ، اور یہ سوال سیکنڈوں میں طے کر دیتا ہے۔ اگر تعیناتی کا ارادہ ایک DNS شناخت ہے، تو سرٹیفکیٹ کو اسے dNSName اندراج کے طور پر رکھنا چاہیے، اور اگر تعیناتی کا ارادہ پتہ ہے، تو سرٹیفکیٹ کو بالکل اسی پتے کے لیے iPAddress اندراج چاہیے۔

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

ہر کلائنٹ پلیٹ فارم کے لیے متوقع شناخت دستاویز کریں، کیونکہ ایک کلائنٹ کی خودکار طور پر حاصل کردہ قدر دوسرے پر واضح طور پر درکار ہو سکتی ہے۔

تجدید کی درخواست کو چار حقائق دیں

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