چگونه احراز هویت ترکیبی IKEv1 به احراز هویت کاربران در IKEv2 تبدیل می‌شود
حالت ترکیبی اثبات دروازه را از اثبات کاربر جدا می‌کرد. گذار به IKEv2 این جداسازی را حفظ می‌کند اما تبادل، روش EAP و بررسی‌های گواهی را تغییر می‌دهد.
هر نمایه قدیمی VPN که نخست گواهی سرور و سپس نام کاربری می‌خواهد، دو رویداد احراز هویت را در یک تبادل حمل می‌کند و این شکل از پروتکلی که آن را آورد عمر بیشتری می‌کند. حالت ترکیبی IKEv1 دقیقا برای همین ساخته شد: دروازه خود را با کلید عمومی اثبات می‌کند و کاربر بعدا از طریق XAuth خود را اثبات می‌کند. IKEv2 همان ایده دو مرحله‌ای را با سازوکاری دیگر بیان می‌کند و در همین تفاوت‌هاست که مهاجرت‌ها شکست می‌خورند. هیچ شماره نسخه‌ای یکی را به دیگری تبدیل نمی‌کند و کپی نام گزینه‌های قدیمی در نمایه تازه، کارخواستی می‌دهد که مذاکره می‌کند و سپس چیزی را احراز نمی‌کند.
حالت ترکیبی در داخل IKEv1 چه می‌کرد
در نمایه ترکیبی، طرف پاسخ‌دهنده تبادل مرحله یک را با گواهی خود امضا می‌کند در حالی که آغازگر عمدا هیچ گواهی‌ای ارائه نمی‌دهد. از این رو اثبات هویت نامتقارن است و همین به دروازه اجازه داد PKI موجودش را نگه دارد و کاربران گذرواژه‌های دایرکتوری خود را. وقتی مرحله یک کامل شد، XAuth به‌صورت درخواست و پاسخ اجرا می‌شود که ویژگی‌های نام کاربری و گذرواژه را درون کانال ISAKMP رمزنگاری‌شده حمل می‌کند.
توجه کنید اعتماد کجا فرود می‌آید. گواهی پاسخ می‌دهد که کارخواست به کدام دروازه رسیده است; XAuth پاسخ می‌دهد که کدام کاربر دسترسی می‌خواهد. هیچ‌کدام جای دیگری را نمی‌گیرد و کارخواستی که برای پذیرش هر گواهی سروری تنظیم شده باشد، بی‌صدا پاسخ نخست را دور ریخته است. برچسب ترکیبی برای حالت تهاجمی با کلید از پیش هم‌رسانده به‌همراه XAuth هم به کار می‌رود، چیدمانی دیگر با همان تجربه کاربر، پس نمایه را بخوانید نه نام را. هر دو گونه از پیش‌نویس‌هایی می‌آیند که هرگز استاندارد نشدند و از این رو دو تولیدکننده می‌توانند حالت ترکیبی را پیاده کنند و با هیچ‌کدام هم‌کنش نداشته باشند.
IKEv2 چگونه به همان دو اثبات می‌رسد
IKEv2 کار را میان IKE_SA_INIT و IKE_AUTH تقسیم می‌کند. تبادل نخست پیشنهادها و کلیدها را بدون هیچ هویتی توافق می‌کند؛ دومی IDi، IDr و بارهای AUTH را حمل می‌کند. زیر EAP نخستین بار AUTH آغازگر خالی بیرون می‌رود، پاسخ‌دهنده نخست با گواهی و امضای خود احراز هویت می‌شود و سپس گفت‌وگوی EAP درون پیام‌های IKE_AUTH جریان می‌یابد.
سازوکاری که این را ایمن می‌کند ماده کلید است. یک روش EAP موفق کلید نشست صادر می‌کند و آخرین بار AUTH آغازگر از آن محاسبه می‌شود، بنابراین اثبات کاربر و کلیدهای تونل به هم بسته می‌شوند. XAuth همتایی ندارد: ویژگی‌هایش پس از مرحله یک می‌رسند و چیزی به کلیدها نمی‌افزایند. درست همین شکاف بود که چارچوب IKEv2 برای بستنش طراحی شد و از این رو ورود کارکننده IKEv2 پیش از پرسیدن هر چیز، گواهی سرور را اعتبارسنجی می‌کند.
این ترتیب تشخیصی سودمند هم هست. وقتی کارخواستی پیش از نشان دادن گواهی به شما از داده‌های ورود شکایت می‌کند، اصلا تبادل EAP در IKEv2 انجام نمی‌دهد.
سه هویت را جدا نگه دارید
مهاجرت بد پیش می‌رود وقتی سه هویت در یک میدان فرو می‌ریزند. هویت دروازه‌ای هست که کارخواست اعتبارسنجی می‌کند، معمولا نامی DNS در subject یا SAN گواهی. هویت کاربری هست که در EAP ارائه می‌شود، شاید ورود دامنه، نشانی یا رشته هویت صریح EAP. و منبع مجوزدهی هست که آن کاربر را به شبکه‌ها و مسیرها نگاشت می‌کند.
نحو swanctl در strongSwan جداسازی را دیدنی می‌کند: اتصال remote { auth = pubkey } را برای دروازه و local { auth = eap-mschapv2 } را برای کاربر تنظیم می‌کند و هویت EAP جدا حمل می‌شود.
وقتی هویت کاربر در نمایه تازه با ویژگی‌های قدیمی XAuth تفاوت دارد، مثلا UPN به‌جای نام کوتاه، سرور احراز هویت کاربری ناشناس می‌بیند و خرابی شبیه گذرواژه نادرست به نظر می‌رسد. رشته هویت را پیش از داده‌های ورود بررسی کنید.
گزینه‌ها را نگاشت کنید و سپس انتظار تله‌ها را داشته باشید
نگاشت کوتاه است و هر سطر تله‌ای دارد که تنها هنگام احراز هویت پدیدار می‌شود.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
هیچ‌یک از آن سطرها تغییر نام ساده نیست. بار پیکربندی نشانی‌ها و حل‌کننده‌ها را از طریق فهرست ویژگی نوع‌دار تحویل می‌دهد، در حالی که فضای ویژگی XAuth اختراع خودش بود؛ برخورد با آن‌ها به‌عنوان قابل تبادل همان راهی است که نمایه در پایان تنظیمی را می‌خواهد که دروازه هرگز نخواهد فرستاد.
انتخابگرهای ترافیک هشدار خودشان را می‌خواهند. IKEv1 ترافیک مهم را با شناسه‌های پروکسی وابسته به تبادل حالت سریع بیان می‌کرد، در حالی که IKEv2 انتخابگرها را در جریان IKE_AUTH مذاکره می‌کند و پاسخ‌دهنده می‌تواند آن‌ها را باریک کند. ناسازگاری یک IKE SA برپاشده بدون child SA می‌سازد که برخی کارخواست‌ها با خوشحالی متصل نشانش می‌دهند.
با اتصال قدیمی مانند یک مرز رفتار کنید
RFC 9395 پروتکل IKEv1 را منسوخ اعلام می‌کند، پس اتصال ترکیبی قدیمی مرزی سازگاری با تاریخ است نه بنیاد. در هنگام تغییر هر دو نمایه را کنار هم اجرا کنید، زیرا آزمون مهم این نیست که نمایه تازه بالا می‌آید یا نه، بلکه این است که همان کاربر روی همان دستگاه به همان منابع می‌رسد.
اعتبارسنجی گواهی را تا انتها سخت‌گیرانه نگه دارید. همین که کارخواست ارائه گواهی خودش را متوقف کند، وسوسه می‌شود بررسی سرور را تا کامل شدن دست‌دادن شل کنید و این تنها اثبات باقی‌مانده را با یک نماد سبز عوض می‌کند.
پیش از بازنشسته کردن نمایه قدیمی چهار چیز را بنویسید: روش EAP، رشته هویت، منبع مجوزدهی و تاریخی که پشتیبانی پایان می‌یابد.