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

منسلک ہونے کا مطلب یہ نہیں کہ PFS ترتیبات میل کھاتی ہیں

IKEv2 کے ساتھ، پہلی چائلڈ ایسوسی ایشن تصدیق کی ادل بدل کے دوران بنتی ہے، اور اس کی کلیدیں اس مواد سے اخذ ہوتی ہیں جو IKE ایسوسی ایشن پہلے ہی پیدا کر چکی ہے۔ اس چائلڈ کے لیے الگ Diffie-Hellman ادل بدل نہیں ہوتی، اس لیے تجدید میں اس کا تقاضا کرنے والی پالیسی اٹھانے کے وقت آزمائی نہیں جاتی۔

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

تجویز کی تار میں عدم مطابقت کہاں چھپی ہے

strongSwan میں گروہ چائلڈ تجویز میں شامل کیا جاتا ہے، اسی لیے aes256gcm16-prfsha256-ecp256 جیسی تار خفیہ کاری کی چناؤ لگتی ہے مگر کلید کی ادل بدل کی شرط بھی رکھتی ہے۔ جو فریق صرف aes256gcm16-prfsha256 پیش کرتا ہے اس کے پاس ایسی شرط نہیں، اور دونوں فہرستیں خفیہ کاری پر ملتی ہیں مگر ادل بدل پر مختلف پڑتی ہیں۔

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

ناکامی پڑھیں، وہ فائل نہیں جس میں آپ نے ترمیم کی

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

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

تین واقعات جنہیں سب کلید کی تجدید کہتے ہیں

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

غور کریں کہ فریق کس واقعہ کا نام لیتا ہے، پھر صرف اسی واقعہ کے لیے تجاویز جانچیں۔ ایک فہرست بدلیں، دوبارہ لوڈ کریں اور وہی واقعہ پھر مجبور کریں۔ اگر لاگ دوبارہ تصدیق کا نام لے تو IKE تجویز ہی پڑھنے کے قابل ہے۔ اگر وہ چائلڈ کلید کی تجدید کا نام لے تو اہم گروہ چائلڈ تجویز رکھتی ہے۔

تجدید بند کرنا حل نہیں ہے

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

اس کے بجائے تجاویز ہم آہنگ کریں۔ وہ گروہ چنیں جو دونوں فریق نافذ کرتے ہوں، اسے دونوں سروں پر چائلڈ تجویز میں رکھیں، اور تجدید کی پالیسی کو اسی دائرے میں رکھیں جو تنظیم کو واقعی درکار ہے۔

اسے اسی ادل بدل سے ثابت کریں جو ناکام ہوئی

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

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

متعلقہ مضامین