IKEv2 NO_PROPOSAL_CHOSEN: کون سے مرحلے نے سوٹ کو مسترد کیا؟

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

پہلے: کون سا تبادلہ مسترد ہوا

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

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

مکمل سوٹ کا موازنہ کریں، الگ الگ کلیدی الفاظ کا نہیں

تجویز ایک امتزاج ہے: انکرپشن الگورتھم، سالمیت یا AEAD، کلید کے تبادلے کا گروپ، اور کوئی بھی سیوڈو-بے ترتیب فعل۔ صرف انکرپشن کا نام موازنہ کرنا عام غلطی ہے، کیونکہ دو ساتھی AES-256 پر متفق ہو کر بھی SHA-1 اور SHA-256 پر اختلاف رکھ سکتے ہیں۔ ناکام مرحلے پر پیش کردہ اور اجازت شدہ سوٹ ساتھ ساتھ لکھیں، پھر خالی تقاطع تلاش کریں۔

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

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

IKE سوٹ اور ESP سوٹ الگ الگ اشیاء ہیں

IKE تجویز میں ترمیم مسترد شدہ CHILD تجویز کو درست نہیں کرے گی، اور اس کے برعکس بھی درست ہے۔ strongSwan میں یہ الگ ترتیبات ہیں، تقریباً IKE SA کے لیے proposals = aes256-sha256-modp2048 اور CHILD SA کے لیے الگ ESP فہرست۔ ناکام تبادلے سے مطابقت رکھنے والی فہرست بدلیں، پھر اصلاح کے کام کرنے کا فرض کرنے کے بجائے لاگ دوبارہ پڑھیں۔

CHILD SA کے لیے متعلقہ ترتیب ESP تجویز فہرست ہے، IKE فہرست نہیں۔ اس میں IKE سطر نقل کرنے سے ایسی ترتیب بنتی ہے جو پارس ہوتی ہے مگر غلط شے پر گفت و شنید کرتی ہے۔

کام کرنے والا ٹنل جو کلید کی تجدید پر ناکام ہوتا ہے

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

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

ipsec statusall | grep -E "IKE:|ESP:"

ایک تقاطع چنیں، پھر دونوں مراحل کی تصدیق کریں

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

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