دو هویت در یک ورود IKEv2: اول ماشین، بعد کاربر
دور دوم IKEv2 به توافق هر دو طرف نیاز دارد. local و remote را از همان سروری که روی آن هستید بخوانید، سپس جفت‌هایی را که هرگز نمی‌خواستید مجاز کنید بیازمایید.
گواهی کلاینت تأیید می‌شود، تبادل نخست کامل می‌شود و سپس اتصال با خطایی درباره دور احراز هویت اضافی متوقف می‌شود. هیچ چیز در زنجیره گواهی اشتباه نیست و هیچ چیز در شبکه تغییر نکرده است. دروازه طوری پیکربندی شده که از طرف متصل شونده مدرک دومی بخواهد و کلاینت هرگز آن را نمی‌فرستد. تصمیم‌گیری درباره اینکه چه کسی چه چیزی را و به چه ترتیبی اثبات می‌کند تمام کار است و با خواندن سیاست از همان سروری که روی آن ایستاده‌اید آغاز می‌شود. دو مدرک از دو نوع متفاوت، به ترتیبی ثابت، یک تصمیم طراحی است نه یک چک‌باکس.
نشانه: شکست پس از نخستین مدرک موفق
تبادل نخست کامل می‌شود و گزارش سالم به نظر می‌رسد، تا وقتی دروازه هویت کاربر را از طریق EAP می‌خواهد. آن‌گاه دست‌دهی متوقف می‌شود یا خطای پروتکلی برمی‌گردد که دور اضافی را نام می‌برد. گواهی ماشین کاملاً معتبر به دلیلی رد می‌شود که هیچ ارتباطی با اعتبارش ندارد. سیاست مدرک دوم را خواسته بود و پاسخ کلاینت هرگز نرسید.
هر دو توصیف این شکست بسته به اینکه کجا ایستاده‌اید درست است. از سمت کلاینت مانند سروری است که گواهی معتبر را رد می‌کند و از سمت سرور مانند کلاینتی که نمی‌تواند ورود را تمام کند. همان رویداد در یک گزارش مشکل اعتماد و در دیگری مشکل توانایی خوانده می‌شود. تنها سیاست پیکربندی‌شده به شما می‌گوید کدام است.
آنچه این افزونه اضافه می‌کند و آنچه اضافه نمی‌کند
IKEv2 افزونه‌ای برای اجرای بیش از یک تبادل احراز هویت در یک نشست دارد. RFC 4739 در کنار توالی‌های دیگر، کلاینتی را ترسیم می‌کند که هویت گواهی را اثبات می‌کند و سپس شخصی را از طریق EAP احراز هویت می‌کند. سند در وضعیت Experimental است، یعنی هیچ پیاده‌سازی‌ای این قابلیت را به شما بدهکار نیست. تا زمانی که طرف مقابل درباره آن مذاکره نکند هیچ فرضی درباره پشتیبانی نکنید.
هر دو طرف باید افزونه را پشتیبانی کنند و در هنگام تبادل بر آن توافق کنند. دروازه‌ای که برای دور دوم پیکربندی شده نمی‌تواند کلاینت را به اجرای آن مجبور کند و کلاینتی که آن را پشتیبانی می‌کند تا سرور نخواهد از آن استفاده نمی‌کند. همین عدم تقارن دلیل آن است که شکست معمولاً به‌صورت پایان مهلت یا خطای پروتکل ظاهر می‌شود نه بیانیه‌ای روشن درباره توانایی. خواندن پیکربندی یک طرف نیمی از آنچه رخ خواهد داد را به شما می‌گوید.
یک مدرک به ازای هر سرور شکل عادی است و این آن طراحی نیست. دروازه گواهی خود را ارائه می‌دهد، کاربر از طریق EAP پاسخ می‌دهد و هر طرف دقیقاً یک بار طرف دیگر را احراز هویت کرده است. آن دو مدرک از دو سرور مقابل می‌آیند، پس هیچ‌کدام به‌طور جداگانه چیزی درباره ماشین و شخصی که از آن استفاده می‌کند نمی‌گوید.
EAP-TLS شکل سومی است و آن هم این یکی نیست. آنجا گواهی کلاینت درون یک روش EAP ارائه می‌شود، پس کلاینت همچنان یک احراز هویت IKE را کامل می‌کند. اعتبارنامه‌ها می‌توانند با حالت چنددوره یکسان به نظر برسند در حالی که پروتکل یک دور به جای دو دور حمل می‌کند. به همین دلیل طراحی‌ای که از استقرار EAP-TLS کپی شده دقیقاً در جایی شکست می‌خورد که مدرک دوم انتظار می‌رود.
همان فایل روی دروازه متفاوت خوانده می‌شود
همان فایل swanctl بسته به اینکه کجا اجرا شود متفاوت خوانده می‌شود و همین بخشی است که مردم را به اشتباه می‌اندازد. روی لپ‌تاپ دروازه طرف مقابل است و روی دروازه لپ‌تاپ طرف مقابل است، پس سمت local را به‌صورت «من کیستم» و سمت remote را به‌صورت «چه کسی را می‌پذیرم» بنویسید. بلوک local توضیح می‌دهد که این سرور چگونه خودش را احراز هویت می‌کند و بلوک remote بیان می‌کند که از طرف دیگر چه می‌خواهد. کپی کردن یک بلوک میان دو فایل معنای آن را بدون تغییر یک حرف برعکس می‌کند. مقایسه دو فایل تقریباً هیچ چیزی به شما نمی‌گوید، چون همان واژه‌ها در هر یک معنای متضاد دارند.
جایگاه یک بخش ترتیب آن را تعیین می‌کند مگر اینکه شماره دور آن را زیر پا بگذارد. بنابراین بخش‌های local یا remote اضافی دورهای اضافی را توصیف می‌کنند نه گزینه‌های جایگزین، و شماره دور صریح در مرجع swanctl.conf دقیقاً برای آگاهانه کردن این ترتیب وجود دارد. بدون آن، جابه‌جا کردن یک بلوک رفتار را تغییر می‌دهد. به همین دلیل دو پیکربندی که روی کاغذ معادل به نظر می‌رسند می‌توانند در ترتیب معکوس عمل کنند.
این قاعده ترتیب حالت شکستی را می‌سازد که ارزش به خاطر سپردن دارد. بلوک remote دوم یک گزینه قابل قبول دیگر نیست؛ یک خواسته دوم است، و به همین دلیل سیاستی که مانند «یا/یا» خوانده می‌شود مانند «و-سپس» رفتار می‌کند. سیاست دروازه می‌تواند گواهی ماشین ثبت‌شده را بپذیرد و سپس تبادل EAP همان کاربر را به همان ترتیب بخواهد.
دورها را از عوامل مستقل جدا کنید
دو دور به‌طور خودکار دو عامل مستقل نیستند. تکرار یک مدرک، یا نگه داشتن دو اعتبارنامه در یک انبار، نیرویی را که طراحی قرار بود بیفزاید فراهم نمی‌کند. استقلال ویژگی نحوه نگهداری رازها و آنچه آنها را به خطر می‌اندازد است، نه تعداد تبادلاتی که پروتکل اجرا می‌کند. طراحی‌ای که دورها را عامل می‌شمارد آنچه دارد را بیش از واقع نشان می‌دهد. این تمایز وقتی بیشترین اهمیت را دارد که پرسشی درباره انطباق می‌پرسد ورود واقعاً چند عامل استفاده می‌کند.
گواهی ماشین مالکیت کلید پذیرفته‌شده‌اش را اثبات می‌کند و نه بیشتر. این یک گواهی سخت‌افزاری و نه گزارش سلامت دستگاه نیست، پس سیاستی که به اطلاعات وضعیت نیاز دارد به سازوکار دیگری نیاز دارد. فیلد subject هم برچسب انبار قابل اعتماد نیست، چون subject را کسی انتخاب می‌کند که گواهی را صادر یا ثبت کرده است. اگر طراحی به مدرکی نیاز دارد که ماشین سالم است، آن مدرک باید از مؤلفه‌ای بیاید که ماشین را اندازه می‌گیرد.
پیش از افزودن هر دور بنویسید که آن دور واقعاً چه چیزی را اثبات می‌کند. وقتی دو دور یک چیز را دو بار اثبات می‌کنند، دومی به جای اطمینان تأخیر و تیکت پشتیبانی می‌افزاید. همین یادداشت است که بحث درباره اینکه دور اضافی هزینه‌اش را می‌ارزد یا نه متوقف می‌کند.
قاعده جفت‌سازی را بنویسید و ردها را بیازمایید
تصمیم بگیرید کدام هویت‌های ماشین می‌توانند با کدام افراد جفت شوند و قاعده را همان‌جا که اجرا زندگی می‌کند بنویسید. دو اعتبارنامه معتبر در کنار هم هیچ چیزی درباره جفت‌سازی اثبات نمی‌کنند، چون جفت‌سازی یک تصمیم مجوزدهی است نه نتیجه احراز هویت. سوابق ثبت‌نام یا بک‌اند احراز هویت باید رابطه‌ای را که سازمان می‌خواهد اجرا کند.
سپس چیزی را بیازمایید که باید شکست بخورد: کاربری پذیرفته‌شده روی ماشینی تأییدنشده، کاربری تأییدنشده که اعتبارنامه ماشین را دارد و طرفی که نمی‌تواند دور اضافی را انجام دهد. اگر هر سه بی‌صدا همان دسترسی را بگیرند، سیاست به جای اجرا کردن یک قصد را توصیف می‌کند. پیکربندی اعلام‌شده را با آنچه دیمن گزارش می‌دهد مقایسه کنید، چون اتصالی که هرگز مطابقت پیدا نکرده دقیقاً مانند قاعده‌ای است که عبور کرده:
swanctl --list-conns
swanctl --list-sasدورهای مذاکره‌شده و مجوز حاصل را بررسی کنید، نه فقط ورود موفق را. و برای میان‌بر به تنظیمات قدیمی IKEv1 XAuth دست نزنید: پروتکل، نقش‌ها، ترتیب و رفتار واقعی کلاینت را تطبیق دهید به جای حذف یک دور لازم تا وقتی اتصالی موفق شود. حذف دوری که شکست می‌خورد همان روشی است که یک طراحی دومدرکی بی‌صدا به طراحی یک‌مدرکی تبدیل می‌شود که هیچ‌کس آن را بازبینی نکرده است. حذف را در سابقه تغییر نگه دارید.