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 اینها تنظیمات جداگانه‌اند، تقریباً proposals = aes256-sha256-modp2048 برای IKE SA و فهرست ESP جداگانه برای CHILD SA. فهرستی را که با تبادل شکست‌خورده می‌خواند تغییر دهید، سپس گزارش را دوباره بخوانید نه اینکه فرض کنید اصلاح کار کرده است.

برای CHILD SA تنظیم مربوطه فهرست پیشنهاد ESP است، نه فهرست IKE. کپی کردن خط IKE در آن پیکربندی‌ای می‌سازد که تجزیه می‌شود اما شیء اشتباه را مذاکره می‌کند.

تونلی که کار می‌کند و در بازتولید کلید شکست می‌خورد

اگر تونل یک ساعت کار کرد و سپس شکست خورد، مذاکره اولیه مشکل نیست. بازتولید کلید می‌تواند شرایط دیگری را بیازماید: گروه تبادل کلید متفاوت پس از تبادل نخست، ناسازگاری طول عمر میان همتاها، یا سیاست پاسخ‌دهنده‌ای که تغییر کرده است. برچسب زمان تمدید و شناسه‌های انجمن را از هر دو طرف نگه دارید. آن الگو به مقایسه پیشنهاد در زمان تمدید نیاز دارد، نه به مهلت طولانی‌تر. تغییر مهلت نشانه را پنهان می‌کند و ناسازگاری را سر جایش می‌گذارد.

ipsec statusall هر انجمن و الگوریتم‌هایی را که واقعاً مذاکره شده‌اند نشان می‌دهد. آن خروجی سریع‌ترین راه تأیید این است که کدام فهرست به کار رفته، و خطای پیکربندی را از تونل کهنه‌ای که هرگز دوباره مذاکره نشده جدا می‌کند.

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

یک اشتراک برگزینید، سپس هر دو فاز را تأیید کنید

از مدیر بخواهید یک اشتراک مدرن مستند را که هر دو همتا پشتیبانی می‌کنند برگزیند و آن را بنویسد. خطا را با فعال کردن همه الگوریتم‌های قدیمی یا با غیرفعال کردن تأیید هویت حل نکنید، زیرا هیچ‌یک از رد شدن نتیجه نمی‌شود. پس از تغییر، اتصال تازه‌ای برقرار کنید و سپس بازتولید کلید را اجبار کنید. تنها اتصال نخست ثابت نمی‌کند که مسیر تمدید کار می‌کند.

ترکیب پذیرفته‌شده را همراه با نسخه‌های میان‌افزار نگه دارید. اگر خطای بعدی درباره انتخاب‌گرهای ترافیک باشد، جداگانه بررسی کنید، زیرا توافق بر رمزنگاری چیزی درباره اینکه تونل کدام زیرشبکه‌ها را محافظت می‌کند نمی‌گوید. مستندات پیشنهادهای strongSwan نحو هر دو فهرست را پوشش می‌دهد.