IKEv2 ایک ہی مصافحہ نہیں: پہلے IKE SA، پھر تصدیق، پھر CHILD SA

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

افسانہ: اگر گیٹ وے جواب دے تو آپ منسلک ہیں

پہلے پیغام کا جواب ثابت کرتا ہے کہ آخری نقطہ قابل رسائی ہے اور بات کرنے کو تیار ہے۔ یہ ثابت نہیں کرتا کہ اکاؤنٹ قبول ہوا، سرٹیفکیٹ کا سلسلہ درست ثابت ہوا، یا کوئی ڈیٹا پالیسی نصب ہوئی۔

وہ ناکامیاں بعد میں ہوتی ہیں اور مختلف علامات دیتی ہیں۔ سرٹیفکیٹ کی مستردگی یا EAP کی ناکامی پہلے تبادلے کے کامیاب ہونے کے بعد آتی ہے، اسی لیے UDP 500 پر ping اور کلائنٹ کا سبز نشان بہت کم بتاتے ہیں۔

IKE_SA_INIT: پیرامیٹرز پر اتفاق کریں، شناخت پر نہیں

پہلا تبادلہ IKE سکیورٹی ایسوسی ایشن کے لیے تجاویز لے کر جاتا ہے: خفیہ کاری اور سالمیت کے الگورتھم، ایک سیوڈو رینڈم فنکشن اور ایک Diffie-Hellman گروپ۔ دونوں فریق nonce بھی بدلتے ہیں، اور ہر فریق ان اقدار سے بننے والے مشترکہ راز سے IKE SA کے لیے کلیدی مواد حاصل کرتا ہے۔ اس تبادلے میں کوئی چیز یہ طے نہیں کرتی کہ دوسرا فریق کون ہے۔ یہ صرف یہ طے کرتا ہے کہ دونوں فریق ایک جیسی چابیاں شمار کر سکتے ہیں اور ایک تجویز پر متفق ہیں۔ جسے کوئی تجویز پسند نہ ہو وہ جواب دینے والا یہیں تبادلہ مسترد کر دیتا ہے، اسی لیے ورژن یا الگورتھم کا اختلاف سرور کے بند ہونے جیسا لگتا ہے۔

اس مقام پر بنایا گیا IKE SA بعد کے تمام انتظامی تبادلوں کی حفاظت کرتا ہے۔ یہی اس کا کام ہے، اور یہ آپ کے پیکٹوں کی حفاظت سے مختلف کام ہے۔

IKE_AUTH: شناخت ثابت کریں اور پھر پہلا CHILD SA بنائیں

دوسرا تبادلہ شناخت لے کر جاتا ہے۔ سرٹیفکیٹ کے ساتھ، ہر فریق اپنی نجی چابی سے دستخط کرتا ہے اور ایسا سلسلہ پیش کرتا ہے جسے دوسرے کو درست ثابت کرنا ہوتا ہے؛ EAP کے ساتھ، جواب دینے والا منتخب طریقے سے شروع کرنے والے کو چیلنج دیتا ہے۔ یہیں آخرکار غلط سرور نام، میعاد ختم شدہ سرٹیفکیٹ یا مسترد شدہ پاس ورڈ سامنے آتا ہے۔

عام طور پر IKE_AUTH پہلے CHILD SA پر بھی بات کرتا ہے، اس لیے ڈیٹا تحفظ اسی سفر میں طے ہوتا ہے۔ شروع کرنے والا ٹریفک چنندہ تجویز کرتا ہے، جواب دینے والا انہیں محدود یا مسترد کرتا ہے، اور ڈیٹا راستے کی چابیاں IKE SA سے حاصل ہوتی ہیں۔ یعنی ایک تبادلہ دو بہت مختلف جگہوں پر ناکام ہو سکتا ہے: شناخت یا پالیسی۔ عام مصافحہ ناکامی کے بجائے اطلاعی پے لوڈ یا خرابی پڑھیں، کیونکہ ایک کا علاج سرٹیفکیٹ ہے اور دوسرے کا سب نیٹ کا اختلاف۔

دو SA، دو کام

انہیں الگ رکھنا دو ایسے رویوں کی وضاحت کرتا ہے جو بگ لگتے ہیں۔ ٹنل قائم دکھ سکتا ہے جبکہ پس منظر میں چابیوں کی تجدید ناکام ہو رہی ہو، اور کلائنٹ کا کنکشن ختم کیے بغیر CHILD SA تبدیل کیا جا سکتا ہے۔

strongSwan پر، IKEv2 ترتیب کا حوالہ اور swanctl --list-sas دونوں سطحیں دکھاتے ہیں، اور ip xfrm state کے ساتھ ip xfrm policy دکھاتے ہیں کہ کرنل نے واقعی کیا نصب کیا۔ ان دو نظاروں کا موازنہ سب سے تیز طریقہ ہے یہ دیکھنے کا کہ گفت و شنید مکمل ہوئی یا صرف مکمل دکھی۔ اگر ڈیمون ایسا CHILD SA دکھائے جس کے لیے کرنل کے پاس کوئی حالت نہیں، تو تنصیب خاموشی سے ناکام ہوئی۔ اگر کرنل کے پاس ایسی حالت ہے جو ڈیمون نہیں جانتا، تو آپ پچھلی کوشش کی باقیات دیکھ رہے ہیں۔

ٹنل اٹھنے کے بعد بھی کیا درست رہنا چاہیے

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

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