تبادل IKEv2 کار می‌کند و سپس احراز هویت شکست می‌خورد: کجا
تونل پاسخ می‌گیرد و سپس متوقف می‌شود: تبادل کلید انجام شد و بررسی بعدی نه. از مرحله رد شدن استفاده کنید تا بفهمید کدام هویت رد شده است.
کاربری که پاسخ IKEv2 دریافت می‌کند ثابت کرده است که دروازه در دسترس است، که دو طرف می‌توانند درباره یک پیشنهاد توافق کنند و که تبادل کلید اولیه کامل شده است. اما ثابت نکرده است که کسی احراز هویت شده باشد. تبادل بعدی هویت‌ها، گواهی‌ها یا EAP را حمل می‌کند و معمولاً همان‌جا اتصال متوقف می‌شود. خواندن اینکه کدام‌یک از این بررسی‌ها شکست خورده است تمام تشخیص است و پیام خطا به‌تنهایی به‌ندرت آن را می‌گوید.
بررسی 1: مرحله را بخوانید، نه پیام را
رد شدن می‌تواند از سه جا بیاید: کاربر هویت سرور را رد می‌کند، دروازه اثبات کاربر را رد می‌کند و یک سرویس احراز هویت بیرونی حساب را رد می‌کند.
هر یک خط گزارش متفاوتی روی ماشین متفاوتی تولید می‌کند و هر یک راه‌حل متفاوتی دارد. رد کردن گواهی سرور در سمت کاربر مشکلی از جنس اعتماد یا نام در کاربر است؛ رد کردن گواهی کاربر در سمت دروازه مشکلی از جنس اعتماد در دروازه است؛ شکست EAP مشکلی مربوط به حساب یا بک‌اند است. پیامی که می‌بینید معمولاً خلاصه کاربر از یکی از این‌هاست، به همین دلیل گزارش دروازه به اندازه گزارش کاربر مهم است.
بررسی 2: کدام هویت بررسی شد
کاربر می‌تواند گواهی سرور یا هویت مورد انتظار را پیش از ارائه هرگونه اعتبارنامه کاربری رد کند و نشانی کاری سرور جایگزین آن بررسی نیست. شناسه‌ای که کاربر انتظار دارد باید با آنچه دروازه ارائه می‌کند مطابقت داشته باشد، و این واقعیتی مربوط به پیکربندی است نه شبکه.
در اصطلاحات strongSwan این rightid در کاربر است و در طرف دیگر هویت خود دروازه، و ناسازگاری پیش از آنکه حتی درباره EAP صحبت شود شکست می‌خورد.
دروازه به‌طور جداگانه می‌تواند گواهی کاربر، اثبات کلید او یا احراز هویت حساب او را رد کند و این سه یکدیگر را جایگزین نمی‌کنند. بازنشانی گذرواژه کاربر گواهی دستگاه را تمدید نمی‌کند و نصب دوباره گواهی دستگاه هویت اشتباه سرور را درست نمی‌کند. در شکست گواهی‌ها ابتدا ساعت را بررسی کنید، سپس زنجیره اعتماد و سپس شناسه مورد انتظار؛ کاربری که ساعتش چند دقیقه اختلاف دارد در بررسی اعتبار شکست می‌خورد که شبیه شکست اعتماد به نظر می‌رسد. swanctl --list-certs در هر دو طرف نشان می‌دهد هر طرف در واقع چه چیزی دارد.
بررسی 3: اگر EAP در میان باشد
کاربر و سرور باید درباره روشی پشتیبانی‌شده توافق کنند و بک‌اند باید هویت ارائه‌شده را بپذیرد.
نام کاربری ممکن است به پسوند دامنه یا قالب حساب مشخصی نیاز داشته باشد که استقرار می‌طلبد و قالب مستند است، نه حدسی. ارائه فیلدهای مستندشده اپراتور سریع‌تر از آزمودن حالت‌های مختلف است و از مشکل دومی جلوگیری می‌کند: تلاش‌های مکرر می‌تواند قفل حساب را فعال کند که سپس مرحله اصلی را پشت شکستی تازه پنهان می‌کند. اگر روش EAP-MSCHAPv2 در برابر یک دایرکتوری باشد، شکست ممکن است مربوط به دایرکتوری باشد و اصلاً نه VPN.
مشکلات هویت را با خاموش کردن بررسی‌های هویت آزمایش نکنید. این کار شکست قابل تشخیص را به شکست غیرقابل تشخیص تبدیل می‌کند و اتصال را ضعیف‌تر از قبل رها می‌کند.
بررسی 4: پس از ورود موفق چه اتفاقی می‌افتد
پس از تکمیل IKE_AUTH، مذاکره CHILD_SA تعیین می‌کند کدام انتخاب‌گرهای ترافیک نصب شوند و همان‌جا ممکن است اتصالی موفق شود و با این حال چیزی عبور ندهد.
ورودی که تازه کار می‌کند اغلب مشکل انتخاب‌گر یا مسیری را آشکار می‌کند که پیش‌تر پشت شکست احراز هویت پنهان بود. اگر تونل بالا بیاید و برنامه‌ای هنوز به مقصد خود نرسد، به انتخاب‌گرهای مذاکره‌شده و مسیرها نگاه کنید، نه دوباره به هویت. تغییر تنظیمات هویت در آن نقطه مرحله اشتباه را هدف می‌گیرد و معمولاً ورودی کاری را خراب می‌کند. با این تأیید کنید: swanctl --list-sas که فرزندان و انتخاب‌گرهایشان را جدا از IKE SA نشان می‌دهد.
بررسی 5: چه چیزی به پشتیبانی بدهید
یک خط زمانی پاک‌سازی‌شده و رد شدن دقیق ارزشمندتر از یک خروجی تشخیصی کامل است و آن خروجی ممکن است کلیدهای خصوصی یا اعتبارنامه‌هایی داشته باشد که نباید به اشتراک بگذارید.
زمان را با منطقه زمانی، نسخه‌های کاربر و دروازه، روش، رشته هویتی که ارائه شده و نه گذرواژه، و مرحله دقیقی که آن را رد کرده ثبت کنید. مستندات پیکربندی IKEv2 در strongSwan تنظیمات هویت و EAP را توصیف می‌کند که این نتایج را تعیین می‌کنند و مرجعی است که باید پیش از تغییر یک فیلد خوانده شود. سپس یک چیز را تغییر دهید و اتصال تازه‌ای را دوباره آزمایش کنید، زیرا نشست ذخیره‌شده در حافظه پنهان از پیکربندی قدیمی برایتان می‌گوید.