IKEv2 یک تبادل نیست: ابتدا IKE SA، سپس احراز هویت و بعد CHILD SA
پاسخ دروازه، دسترسی را ثابت می‌کند نه هویت را. IKE_SA_INIT، IKE_AUTH و نخستین CHILD SA را دنبال کنید و سپس ببینید پیش از عبور ترافیک چه چیزی باید برقرار باشد.
ممکن است فکر کنید یک اتصال IKEv2 همان یک تبادل است که با رمز شدن ترافیک تمام می‌شود. دست‌کم دو تبادل است و اولی هیچ‌کس را احراز هویت نمی‌کند. دو طرف با پیام‌های کنترلی شروع می‌کنند، درباره پارامترهای رمزنگاری توافق می‌کنند، هویت را اثبات می‌کنند و تنها پس از آن وضعیتی را مذاکره می‌کنند که بسته‌های برنامه را حمل می‌کند. همین ترتیب، ناسازگاری‌ای را توضیح می‌دهد که کاربران مدام گزارش می‌کنند: دروازه پاسخ می‌دهد، کلاینت می‌گوید متصل است و برنامه خصوصی همچنان از مهلت زمانی رد می‌شود. آنچه هر مرحله واقعاً انجام می‌دهد و آنچه باید پس از آن برقرار باشد، همین است.
افسانه: اگر دروازه پاسخ دهد، متصل هستید
پاسخی به نخستین پیام ثابت می‌کند که نقطه پایانی در دسترس است و آماده گفت‌وگو است. ثابت نمی‌کند که حسابی پذیرفته شده، زنجیره گواهی معتبر شده یا سیاست داده‌ای نصب شده است.
این شکست‌ها دیرتر رخ می‌دهند و نشانه‌های متفاوتی تولید می‌کنند. رد گواهی یا خطای EAP پس از موفقیت نخستین تبادل می‌رسد و به همین دلیل یک ping به UDP 500 و آیکون سبز کلاینت چیز زیادی نمی‌گویند.
IKE_SA_INIT: توافق بر پارامترها، نه هویت
نخستین تبادل، پیشنهادهای مربوط به انجمن امنیتی IKE را حمل می‌کند: الگوریتم‌های رمزنگاری و یکپارچگی، یک تابع شبه‌تصادفی و یک گروه Diffie-Hellman. دو طرف nonce هم مبادله می‌کنند و هر سو مواد کلید IKE SA را از راز مشترکی که این مقادیر تولید می‌کنند استخراج می‌کند. هیچ چیز در این تبادل مشخص نمی‌کند طرف دیگر چه کسی است. فقط مشخص می‌کند که هر دو سو می‌توانند کلیدهای یکسانی محاسبه کنند و بر یک پیشنهاد توافق دارند. پاسخ‌دهنده‌ای که هیچ پیشنهادی را نپسندد، تبادل را همین‌جا رد می‌کند و به همین دلیل ناسازگاری نسخه یا الگوریتم شبیه خاموش بودن سرور دیده می‌شود.
IKE SA که در این نقطه ساخته می‌شود همه تبادل‌های مدیریتی بعدی را محافظت می‌کند. کار او همین است و این کاری متفاوت از محافظت از بسته‌های شماست.
IKE_AUTH: اثبات هویت و سپس ساخت نخستین CHILD SA
تبادل دوم حامل هویت است. با گواهی‌ها، هر طرف با کلید خصوصی خود امضا می‌کند و زنجیره‌ای ارائه می‌دهد که طرف دیگر باید آن را معتبر کند؛ با EAP، پاسخ‌دهنده از طریق روش انتخاب‌شده از آغازگر چالش می‌گیرد. اینجا جایی است که نام سرور اشتباه، گواهی منقضی یا گذرواژه ردشده بالاخره آشکار می‌شود.
در حالت عادی IKE_AUTH نخستین CHILD SA را هم مذاکره می‌کند، بنابراین حفاظت داده در همان رفت‌وبرگشت توافق می‌شود. آغازگر انتخاب‌گرهای ترافیک را پیشنهاد می‌دهد، پاسخ‌دهنده آن‌ها را محدود یا رد می‌کند و کلیدهای مسیر داده از IKE SA استخراج می‌شوند. یعنی یک تبادل می‌تواند در دو جای کاملاً متفاوت شکست بخورد: هویت یا سیاست. بار مفید اطلاع‌رسانی یا خطا را بخوانید، نه شکست عمومی دست‌دهی را، چون درمان یکی گواهی است و درمان دیگری ناسازگاری زیرشبکه.
دو SA، دو وظیفه
| انجمن | محافظت می‌کند | رفتار عمر |
|---|---|---|
| IKE SA | تبادل‌های مدیریتی: تولید مجدد کلید، حذف، بارهای پیکربندی | طبق برنامه خودش کلید عوض می‌کند؛ مسیر داده می‌تواند از این تغییر جان سالم به در ببرد |
| CHILD SA | ترافیک برنامه که با انتخاب‌گرهای ترافیک مطابقت دارد | به‌طور مستقل و اغلب با دفعات بیشتر کلید عوض می‌کند |
جدا نگه‌داشتن آن‌ها دو رفتاری را توضیح می‌دهد که شبیه باگ به نظر می‌رسند. یک تونل می‌تواند برقرار نشان داده شود در حالی که تولید مجدد کلید در پس‌زمینه شکست می‌خورد، و یک CHILD SA می‌تواند جایگزین شود بدون آنکه کلاینت اتصال را از دست بدهد.
در strongSwan، مرجع پیکربندی IKEv2 و swanctl --list-sas هر دو سطح را نشان می‌دهند، و ip xfrm state به‌همراه ip xfrm policy نشان می‌دهند که هسته واقعاً چه چیزی نصب کرده است. مقایسه این دو نما سریع‌ترین راه برای دیدن این است که مذاکره تمام شده یا فقط تمام‌شده به نظر می‌رسد. اگر دیمن CHILD SAای فهرست کند که هسته برایش وضعیتی ندارد، نصب بی‌صدا شکست خورده است. اگر هسته وضعیتی داشته باشد که دیمن از آن خبر ندارد، شما به بازمانده یک تلاش قبلی نگاه می‌کنید.
چه چیزی باید پس از بالا آمدن تونل همچنان برقرار باشد
انتخاب‌گرهای ترافیک مشخص می‌کنند کدام نشانی‌ها پوشش داده می‌شوند. اگر کلاینت یک زیرشبکه پیشنهاد دهد و سرور زیرشبکه دیگری انتظار داشته باشد، CHILD SA نصب می‌شود اما چیز مفیدی حمل نمی‌کند، و خطا به‌صورت مشکل مسیریابی و نه مشکل مذاکره ظاهر می‌شود. سپس پشته محلی باید همکاری کند: فعال بودن ارسال در جایی که میزبان مسیریابی می‌کند، مسیرهایی که به تونل اشاره می‌کنند، قواعد فایروال که بسته‌های کپسول‌گشایی‌شده را مجاز می‌داند و یک resolver داخلی اگر نام‌های خصوصی در کار باشند. هر یک از این‌ها جداگانه شکست می‌خورد و هیچ‌کدام با راه‌اندازی مجدد دیمن IKE درست نمی‌شود.
هنگام عیب‌یابی گزارش را در دید نگه دارید: تبادل اولیه، سپس اعتبارسنجی هویت، بعد احراز هویت کاربر در جایی که اعمال می‌شود، سپس نصب CHILD و در پایان ترافیک برنامه. مرحله‌ای که متوقف می‌شود همان مرحله‌ای است که باید اصلاح شود، و شکست مسیریابی در مرحله بعد هرگز دلیلی برای سست کردن بررسی‌های هویتی که قبلاً گذشته‌اند نیست.