IKEv2: تمدید کلید در برابر احراز هویت مجدد — چرا اتصال بعداً قطع می‌شود
یکی مواد کلیدی را تازه می‌کند، دیگری بررسی هویت را تکرار می‌کند. اینکه نشست شما از کدام مرز گذشته باشد تعیین می‌کند چه چیزی را درست کنید.
تونل صبح بالا می‌آید و ساعت‌ها کار می‌کند. سپس قطع می‌شود، پس از یک تلاش دوباره وصل می‌شود و روز بعد همین کار را تکرار می‌کند. در شبکه هیچ چیز تغییر نکرده و هیچ‌کس به گذرواژه دست نزده است. نشست‌هایی که در مرز تمدید شکست می‌خورند معمولاً یکی از دو عملیات متفاوت را طی می‌کنند و تنها یکی از آن‌ها اعتبارنامه‌های شما را دوباره بررسی می‌کند. خواندن اینکه کدام‌یک فعال شده، تمام تشخیص است.
دو عملیاتی که از بیرون شبیه هم به نظر می‌رسند
تمدید کلید، انجمن‌های امنیتی یا مواد کلیدی را در چارچوب تبادل تعریف‌شدهٔ پروتکل جایگزین می‌کند. احراز هویت تکرار نمی‌شود، بنابراین هویتی که در آغاز نشست پذیرفته شده بود صرفاً به جلو حمل می‌شود.
احراز هویت مجدد فراتر می‌رود: رابطه‌ای تازه و تأییدشده برقرار می‌کند، یعنی اعتبارنامه‌ها دوباره ارزیابی می‌شوند. هر چیزی که منقضی شده، لغو شده یا در دایرکتوری تغییر کرده باشد، همان لحظه آشکار می‌شود.
تمدید کلید در واقع چه چیزی را جایگزین می‌کند
IKEv2 دو نوع انجمن با چرخه‌های عمر جداگانه نگه می‌دارد. IKE SA کانال کنترل را محافظت می‌کند و CHILD SA ترافیک واقعی را. تمدید یکی به معنای اتصال دوبارهٔ کلاینت نیست.
این جدایی الگویی آشنا را توضیح می‌دهد: ترافیک خوب جریان دارد، سپس یک CHILD SA تمدید می‌شود و پیشنهاد دیگر نمی‌خواند، چون کسی هفته‌ها پیش فاز 2 را در یک طرف ویرایش کرده بود. تغییر بی‌آزار آنجا نشسته بود تا اینکه تمدید آن را به کار انداخت.
ناسازگاری‌های طول عمر هم همین رفتار را دارند. هر طرفی که اول به محدودیتش برسد تبادل را آغاز می‌کند و طرف دیگر باید آن را بپذیرد.
احراز هویت مجدد چه چیزی را دوباره ارزیابی می‌کند
با احراز هویت مجدد، ممکن است گواهی کلاینتی که هنگام ورود معتبر بود اکنون منقضی شده باشد. اعتبارنامهٔ لغوشده، گذرواژهٔ چرخانده‌شده یا عامل دومی که در دسترس نیست، همه اینجا ظاهر می‌شوند نه در زمان تمدید.
به همین دلیل است که تمدید هر طول عمر شبیه یک اصلاح به نظر می‌رسد و نیست. شما بررسی را به تعویق انداخته‌اید نه اینکه از آن گذشته باشید. تمدید بعدی با همان نقص و با پنجرهٔ قطع کوتاه‌تری برای توجه به آن می‌رسد.
برخی پیاده‌سازی‌ها در هنگام احراز هویت مجدد وضعیت قدیمی و جدید را همپوشان می‌کنند. برخی دیگر شکاف کوتاهی ایجاد می‌کنند. بنابراین تنظیمات یکسان در دو فروشنده می‌تواند تجربهٔ کاربری متفاوتی بدهد. رفتار را آزمایش کنید نه اینکه فرض کنید استاندارد آن را تعیین می‌کند.
پیش از تغییر هر چیزی مهرهای زمانی را بخوانید
لحظهٔ شکست را همراه با وضعیت انجمن پیش و پس از آن ثبت کنید. اگر انجمن قدیمی بدون تبادل احراز هویت جایگزین شده بود، شما در مرز تمدید بودید. اگر درست پیش از شکست تبادل AUTH ظاهر می‌شود، شما در احراز هویت مجدد بودید.
strongSwan این را به‌صورت تنظیمات جداگانه ارائه می‌دهد: rekey تمدید کلید را کنترل می‌کند، reauth کنترل می‌کند که آیا احراز هویت جدیدی رخ می‌دهد، و مقادیر margin تعیین می‌کنند هرکدام چه‌قدر پیش از انقضا آغاز شود. مستندات تمدید کلید این تعامل را توصیف می‌کند و ارزش خواندن دارد پیش از آنکه طول عمری را از یک پست انجمن کپی کنید.
همهٔ این‌ها را از یک قطعی سادهٔ شبکه جدا کنید. پیوند قطع‌شده رویداد تشخیص همتای مرده یا طوفان ارسال دوباره تولید می‌کند، نه تبادلی تمیز با پیشنهادهای منطبق.
چیزی را که شکست خورد تغییر دهید
رد اعتبارنامه نیازمند اصلاح مشکل هویت است: گواهی را تمدید کنید، حساب را بازیابی کنید، عامل را دوباره ثبت کنید. ناسازگاری پیشنهاد یا طول عمر نیازمند مقایسهٔ پارامترها در هر دو طرف است.
کشیدن طول عمرها برای پرهیز از نشانه، تنها گزینه‌ای است که همیشه شبیه موفقیت به نظر می‌رسد و هرگز موفق نمی‌شود.
یک تمدید کنترل‌شده را آزمایش کنید
تمدید را به زور اجرا کنید نه اینکه یک روز منتظرش بمانید. سپس اگر استقرار از آن پشتیبانی می‌کند با احراز هویت مجدد تکرار کنید و هر دو سر را زیر نظر بگیرید.
ورود اولیهٔ موفق هیچ‌یک از این‌ها را تمرین نمی‌کند. چرخهٔ عمر پس از آن جایی است که این استقرارها واقعاً می‌شکنند.