ایک ہی IKEv2 لاگ اِن میں دو شناختیں: پہلے مشین، پھر صارف

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

علامت: کامیاب پہلے ثبوت کے بعد ناکامی

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

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

توسیع کیا شامل کرتی ہے، اور کیا نہیں

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

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

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

EAP-TLS تیسری شکل ہے، اور وہ بھی یہ نہیں ہے۔ وہاں کلائنٹ سرٹیفکیٹ کسی EAP طریقے کے اندر پیش کیا جاتا ہے، اس لیے کلائنٹ پھر بھی ایک ہی IKE توثیق مکمل کرتا ہے۔ اسناد کئی مرحلوں والے معاملے جیسی دکھ سکتی ہیں جبکہ پروٹوکول دو کے بجائے ایک مرحلہ اٹھائے ہوئے ہے۔ اسی لیے EAP-TLS تعیناتی سے نقل کیا گیا ڈیزائن ٹھیک اسی مقام پر ناکام ہوتا ہے جہاں دوسرے ثبوت کی توقع ہوتی ہے۔

وہی فائل گیٹ وے پر مختلف پڑھی جاتی ہے

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

کسی حصے کی پوزیشن اس کی ترتیب طے کرتی ہے الا یہ کہ مرحلے کا نمبر اسے زیر کر دے۔ اس لیے اضافی local یا remote حصے متبادل کے بجائے اضافی مرحلے بیان کرتے ہیں، اور swanctl.conf حوالہ جات میں واضح مرحلہ نمبر اسی لیے موجود ہے کہ اس ترتیب کو دانستہ بنایا جائے۔ اس کے بغیر، بلاک کو ہلانا رویہ بدل دیتا ہے۔ اسی لیے کاغذ پر برابر دکھنے والی دو ترتیبیں متضاد ترتیب میں برتاؤ کر سکتی ہیں۔

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

مرحلوں کو خودمختار عوامل سے الگ کریں

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

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

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

جوڑی کا قاعدہ لکھیں اور مسترد ہونے کی جانچ کریں

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

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

swanctl --list-conns
swanctl --list-sas

صرف کامیاب لاگ اِن نہیں، طے شدہ مرحلے اور ان سے نکلنے والی اجازت بھی دیکھیں۔ اور پرانی IKEv1 XAuth ترتیبات کو شارٹ کٹ کے طور پر نہ اپنائیں: کنکشن کامیاب ہونے تک مطلوبہ مرحلہ حذف کرنے کے بجائے پروٹوکول، کردار، ترتیب اور کلائنٹ کا اصل رویہ ملائیں۔ ناکام ہونے والے مرحلے کو حذف کرنا ہی وہ طریقہ ہے جس سے دو ثبوت والا ڈیزائن خاموشی سے ایسا ایک ثبوت والا ڈیزائن بن جاتا ہے جس کا کسی نے جائزہ نہیں لیا۔ حذف کو تبدیلی کے ریکارڈ میں رکھیں۔