iOS IKEv2 به strongSwan: هیچ پیشنهادی انتخاب نشد، فهرست را اصلاح کنید
نبود پیشنهاد انتخاب‌شده یعنی دو فهرست هرگز هم‌پوشانی ندارند. SHA1 را به SHA-96، modp1024 را به group 2 ترجمه کنید و پیشنهاد فرزند را هم تنظیم کنید.
آیفون تونل را بالا می‌آورد، دروازه هیچ پاسخی نمی‌دهد و گوشی یک خطای عمومی نشان می‌دهد. گزارش strongSwan مشخص‌تر است: هیچ پیشنهادی انتخاب نشد. این پیام یعنی دو فهرست مجموعه‌های رمزنگاری قابل قبول هرگز هم‌پوشانی نداشتند، بنابراین تبادل پیش از آغاز احراز هویت پایان یافت. این یک مشکل تطابق است و راه‌حل این است که فهرست‌ها هم‌پوشانی پیدا کنند.
دروازه سیاست خود را کجا اعلام می‌کند
strongSwan سیاست خود را در پیکربندی می‌نویسد و علامت تعجب انتهایی تعیین می‌کند که آن سیاست چگونه خوانده شود. با این علامت فهرست کامل است: همان ورودی‌ها و هیچ چیز دیگری پذیرفته می‌شود. بدون آن، همان خط یک ترتیب ترجیح است و سرویس‌دهنده ممکن است چیزی را انتخاب کند که قصدش را نداشتید. پیش از ترجمه هر چیزی بپرسید کدام شکل مستقر است، چون این دو در برابر یک کلاینت یکسان رفتار متفاوتی دارند. خط دقیق را همراه با علامت ثبت کنید و همان را آزمایش کنید.
کلاینتی که فهرست گسترده‌تری ارائه می‌دهد همچنان می‌تواند به دروازه‌ای با فهرست تثبیت‌شده متصل شود، به شرط آنکه یک ترکیب در هر دو طرف وجود داشته باشد. چیزی که نمی‌تواند رخ دهد مذاکره بیرون از مجموعه تثبیت‌شده است.
به همین دلیل پروفایلی که از برنامه VPN دیگری کپی شده ممکن است جایی کار کند که پروفایل شما کار نمی‌کند: آن برنامه فهرست دیگری همراه داشت.
نام‌ها باید منطبق باشند، نه بهتر
دو ترجمه افرادی را گرفتار می‌کند که مقادیر را از strongSwan به iOS منتقل می‌کنند. الگوریتم یکپارچگی که در یک پیشنهاد IKE به صورت SHA1 نوشته می‌شود، در شکل کوتاه‌شده خود سفر می‌کند که iOS آن را .SHA96 می‌نامد. گروه دیفی-هلمن که به صورت modp1024 نوشته می‌شود group 2 است که iOS آن را .group2 می‌نامد. جایگزینی با SHA-256 یا group 14 با دروازه‌ای که فقط جفت قدیمی‌تر را می‌پذیرد مذاکره نخواهد کرد. کلاینت باید همان الگوریتم را توصیف کند، نه الگوریتمی قوی‌تر.
آن مقادیر را به صراحت در NEVPNProtocolIKEv2 تنظیم کنید. مقادیر پیش‌فرض ممکن است گسترده‌تر یا محدودتر از پروفایلی باشند که جایگزین می‌کنید و تفاوت تنها زمانی دیده می‌شود که دست‌دادن شکست بخورد.
پیشنهاد فرزند دیرتر و آرام‌تر شکست می‌خورد
انجمن امنیتی فرزند را نیز مانند انجمن IKE پیکربندی کنید. وقتی فقط پارامترهای IKE منطبق باشند، تونل احراز هویت می‌شود و سپس هیچ ترافیکی حمل نمی‌کند که شکستی بسیار آرام‌تر از رد شدن است. رمزنگاری، یکپارچگی، گروه و عمر فرزند را در همان مرحله تنظیم کنید. عمر کلاینت را در مقدار دروازه یا کمتر از آن نگه دارید، چون پافشاری بر عمری طولانی‌تر همان پیام نبود پیشنهاد انتخاب‌شده را از علتی دیگر تولید می‌کند. ناسازگاری در آنجا دقیقا مانند ناسازگاری IKE در گزارش دیده می‌شود.
بررسی کنید که پروفایل با گواهی‌ها احراز هویت می‌کند یا با یک راز مشترک، زمانی که در پیکربندی هستید. رد پیشنهاد و رد احراز هویت در خطوط متفاوتی ظاهر می‌شوند و اصلاح مورد اشتباه یک روز هزینه دارد. پس از هر تغییر با اتصال تازه آزمایش کنید، هر بار یک متغیر، چون وضعیت ذخیره‌شده پنهان می‌کند کدام پارامتر جابه‌جا شده است.
مجموعه قدیمی را فقط تا زمانی که لازم است نگه دارید
تثبیت SHA-1 با گروه 1024 بیتی یک پل است، نه مقصد. هر دو منسوخ‌اند و کلاینت‌های جدیدتر ممکن است آن‌ها را کاملا رد کنند، یعنی پروفایل در دستگاه بعدی بدون هیچ تغییری از سمت شما شکست می‌خورد. تثبیت را موقت بدانید و این را در سابقه بنویسید.
اگر strongSwan از خودتان است، یک پیشنهاد مدرن اضافه کنید و بگذارید دو طرف به سمت بالا مذاکره کنند در حالی که ورودی قدیمی برای دستگاه‌های قدیمی‌تر می‌ماند. خروجی وضعیت سرویس‌دهنده را بخوانید تا ببینید هر اتصال واقعا از کدام مجموعه استفاده کرده است. سپس وقتی جفت مدرن تایید شد تثبیت سمت کلاینت را بردارید. تونلی که بالا می‌آید شاهد کافی نیست، چون ممکن است روی مجموعه‌ای بالا بیاید که می‌خواستید بازنشسته کنید. مستندات IKEv2 در strongSwan نحو پیشنهادها و نشانگر سخت‌گیرانه را توصیف می‌کند.