آپ کا IKEv2 SA چل رہا ہے مگر کوئی چائلڈ SA نہیں: تبادلہ پڑھیں
تصدیق مکمل ہو سکتی ہے جبکہ چائلڈ SA کی بات چیت ناکام ہو جائے۔ راستوں یا شمار کنندگان سے پہلے چائلڈ SA بنانے کا تبادلہ، پھر تجویز اور منتخب کنندگان پڑھیں۔
IKE کہتا ہے کہ سرنگ چل رہی ہے، چائلڈ SA موجود نہیں، اور دونوں بیانات بیک وقت درست ہو سکتے ہیں۔ قائم شدہ کنٹرول تعلق ڈیٹا کی وابستگی نہیں ہے، اور دونوں اشیاء کی عمر، بات چیت اور ناکامی کے طریقے الگ ہیں۔ پہلے کو کنیکٹیویٹی بتانا وہ راستہ ہے جس سے ٹکٹ آخرکار دعوی کرتا ہے کہ سرنگ چل رہی ہے جبکہ کچھ بھی کام نہیں کرتا۔ کنکشن کے خلاصے کے لیبل کے بجائے وابستگیوں کی فہرست پڑھیں، کیونکہ وہی فہرست واحد جگہ ہے جہاں غائب شے نظر آتی ہے۔ آگے وہ ترتیب ہے جس میں فہرست معنی رکھتی ہے۔
دو وابستگیاں، دو کام
IKE SA کنٹرول چینل اٹھاتا ہے: شناختیں، کلیدیں اور خود کنٹرول تبادلے کے لیے تجاویز۔ چائلڈ SA ESP تحفظ اٹھاتا ہے، اپنے الگورتھم اور اپنے ٹریفک منتخب کنندگان کے ساتھ۔ تصدیق اور چائلڈ SA بنانا عام طور پر ساتھ جاتے ہیں، کیونکہ پہلا چائلڈ SA IKE_AUTH کے اندر طے ہوتا ہے، اور یہی جوڑ لوگوں کو اس علیحدگی پر حیران کرتا ہے۔
یہ ان دو ناکامی کی شکلوں کی بھی وضاحت کرتا ہے جن سے آپ ملیں گے۔ ابتدائی تبادلے کے دوران مسترد شدہ چائلڈ SA عام طور پر IKE SA کو بھی ساتھ نیچے لے جاتا ہے، اس لیے آپ کو کوئی قائم شدہ کنٹرول چینل نظر نہیں آتا۔ اکیلا کھڑا IKE SA اکثر یہ بتاتا ہے کہ پہلا چائلڈ SA کامیاب ہوا اور بعد کی چائلڈ SA بنانے کی کوشش ناکام ہوئی، مثلاً کلید کی تجدید کے دوران۔ وقت کی مہریں ان صورتوں کو کسی بھی ترتیب کے جائزے سے زیادہ تیزی سے الگ کرتی ہیں۔
کون سی پرت نے انکار کیا
جب چائلڈ SA مسترد ہوتا ہے تو اطلاع پرت کا نام لیتی ہے۔ تجویز کا انکار مطلب یہ ہے کہ فریق الگورتھم پر متفق نہیں ہو سکے، اکثر اس لیے کہ ایک فریق مختلف مکمل آگے کی رازداری کا گروپ یا ایسا سائفر مانگتا ہے جو دوسرا قبول نہ کرے۔ منتخب کنندہ کا انکار مطلب یہ ہے کہ ٹریفک کا مجموعہ سیدھا مسترد ہو گیا، اور یہ دائرہ کار کی دلیل ہے، خفیہ نگاری کی نہیں۔
کبھی کبھی چائلڈ SA کا نہ ہونا ہی ڈیزائن ہے۔ بغیر چائلڈ والا IKE SA ایک متعین توسیع ہے جو وہاں استعمال ہوتی ہے جہاں ڈیٹا کی وابستگی طلب پر بنائی جانی چاہیے، اس لیے عدم موجودگی درست ہے اور موزوں ٹریفک آنے پر چائلڈ SA ظاہر ہوتا ہے۔ IKEv2 کے بارے میں strongSwan کے نوٹس طلب کی طرز اور پہلی صورت طے کرنے والی تجویز کی ترتیبات دونوں کا احاطہ کرتی ہیں۔
خرابی کی تشخیص سے پہلے دیکھیں کہ طلب پر یا جال کی ترتیب موجود ہے یا نہیں۔ اگر چائلڈ SA سست روی سے بنتے ہیں تو خاموش حالت میں چائلڈ SA کا نہ ہونا متوقع حالت ہے، اور اصل امتحان یہ ہے کہ ٹریفک ایک کو اوپر لاتا ہے یا نہیں۔ یہ امتحان سست ڈیزائن کو خاموش ناکامی سے بھی الگ کرتا ہے، کیونکہ ناکام تخلیق محرک کو صرف خاموش نہیں، بلا جواب چھوڑ دیتی ہے۔
پھر ڈیٹا کے راستے کے بارے میں پوچھیں
چائلڈ SA موجود ہو تو اگلے سوال کا جواب شمار کنندگان دیتے ہیں۔ ip -s xfrm state ہر وابستگی کے لیے پیکٹ اور بائٹ کی گنتی بتاتا ہے، اور جب آپ ٹریفک پیدا کرتے ہیں تو کچھ نہ اٹھانے والا چائلڈ SA ملاپ یا راستہ بندی کی طرف اشارہ کرتا ہے غائب وابستگی کی طرف نہیں۔ swanctl --list-sas ان شمار کنندگان کے ساتھ چائلڈ SA کے منتخب کنندگان چھاپتا ہے، اور یہی تصدیق کرتا ہے کہ پیکٹ قبول شدہ مجموعے کے اندر ہے۔
رپورٹ میں کامیاب تصدیق اور ناکام چائلڈ SA تبادلے کو الگ رکھیں۔ وہ رپورٹ جو کہے تصدیق ناکام ہوئی اگلے انجینئر کو سرٹیفکیٹ کے ذخیرے میں بھیجتی ہے، اور درست جملہ بہت مختصر ہے: IKE SA اوپر آیا، اور اس بہاؤ کے لیے چائلڈ SA کبھی قبول نہیں ہوا۔
دونوں سرے ملائیں
جس سرور کو آپ خود چلاتے ہیں اس کے لیے ایک گھنٹے کے وقفے سے دو دوبارہ جڑنے کی کوششیں موازنہ کرنے کے بجائے اسی تبادلے کے کلائنٹ اور گیٹ وے لاگ لیں۔ اطلاعات دونوں طرف یکساں ہونی چاہئیں، اور جہاں یکساں نہ ہوں وہاں آپ نے غلط ترتیب والا رخ ڈھونڈ لیا ہے۔
چائلڈ SA کی بات چیت درست کریں، پھر مطلوبہ منتخب کنندہ کے اندر ٹریفک کے ساتھ دوبارہ جانچیں۔ یہی واحد امتحان ہے جو ثابت کرتا ہے کہ غائب شے اب موجود ہے، کیونکہ خاموش حالت میں تازہ کی گئی وابستگیوں کی فہرست درستی سے پہلے اور بعد یکساں دکھ سکتی ہے۔