گواهی درگاه سالم است: چرا ورود IKEv2 PEAP هنوز شکست می‌خورد

گواهی درگاه VPN شما معتبر است، زنجیره اعتبارسنجی می‌شود، و کلاینت IKEv2 همچنان ورود را با پیامی درباره بازه اعتبار یک گواهی رد می‌کند. نخستین واکنش این است که گواهی درگاه را دوباره صادر کنید یا روش EAP را عوض کنید، و هر دو معمولاً اشتباه‌اند. تلاش ورود دو هویت جداگانه سرور را حمل می‌کند: گواهی درگاهی که IKE استفاده می‌کند، و گواهی‌ای که هر چیزی که PEAP را پایان می‌دهد ارائه می‌دهد. یکی از آن‌ها سالم است، و دیگری دلیل توقف کلاینت است.

دو هویت، یک تلاش ورود

گواهی موجود در پروفایل VPN به تبادل IKE تعلق دارد: اثبات می‌کند که درگاه همان همتایی است که پروفایل نام می‌برد، زیر سیاست IKE پیکربندی‌شده. گواهی‌ای که اینجا شکست می‌خورد به گفت‌وگویی دیگر تعلق دارد، همان نشست TLS که PEAP با هر چیزی که کاربر را احراز هویت می‌کند باز می‌کند، که اغلب سرور RADIUS مانند NPS است و نه خود درگاه. یک بررسی سوم، یعنی اعتبارنامه کاربر، درون همان نشست رخ می‌دهد. گذرواژه معتبر نمی‌تواند گواهی سرور منقضی را ترمیم کند، و گواهی معتبر درگاه نمی‌تواند برای نقطه پایانی PEAP ضمانت بدهد.

این لایه‌بندی توضیح می‌دهد چرا خطای گواهی جایی ظاهر می‌شود که تنها گواهی پیکربندی‌شده گواهی درگاه بوده است. همچنین توضیح می‌دهد چرا صدور دوباره آن گواهی چیزی را تغییر نمی‌دهد.

خط گزارش را در برابر مرحله بخوانید

پیامی را پیدا کنید که دلیل و تاریخ‌ها را نام می‌برد. شکایت درباره بازه اعتبار در کنار خطای موضوع یعنی سرور گواهی ارائه‌شده را رد کرده است، نه اینکه کاربر ورود را رد کرده باشد. سپس مرحله را پیدا کنید: گزارش charon در strongSwan پیش از آغاز تبادل EAP عبارت IKE_SA .* established را نشان می‌دهد، پس خطای گواهی پس از آن خط به هویت EAP تعلق دارد، در حالی که خطای پیش از آن به درگاه اشاره می‌کند. متن مرحله در پنجره اتصال کلاینت Windows همین را می‌گوید.

پیش از دست زدن به هر گواهی، ساعت کلاینت را بررسی کنید. دستگاهی که چند ساعت اختلاف دارد همان خطای اعتبار گواهی واقعاً منقضی را تولید می‌کند. تنظیم ساعت اصلاحی پنج‌ثانیه‌ای است، و جایگزینی گواهی‌ای که هرگز مشکل نبوده یعنی قطع سرویس.

پیدا کنید کدام نقطه پایانی PEAP را پایان می‌دهد

در طراحی درگاه به‌همراه RADIUS، درگاه EAP را هدایت می‌کند و آن را پایان نمی‌دهد. افزونه eap-radius در strongSwan تبادل را به سرور RADIUS می‌سپارد که مالک نشست TLS مربوط به PEAP و گواهی آن است. یک تلاش ناموفق را در هر دو گزارش تطبیق دهید و تأیید کنید کدام فرایند واقعاً برای آن نشست گواهی انتخاب کرده است.

برای NPS گواهی باید در مخزن رایانه محلی باشد، هدف احراز هویت سرور را داشته باشد، با نامی که کلاینت‌ها انتظار دارند بخواند، و برای حساب سرویس قابل خواندن باشد. الزامات گواهی Microsoft برای NPS این شرایط را فهرست می‌کند. سرورهای EAP دیگر قواعد انتخاب خودشان را دارند، پس ویژگی‌های NPS را به استقرار FreeRADIUS و نه برعکس کپی نکنید. قاعده‌ای که در هر دو حالت دوام می‌آورد این است که نقطه پایانی‌ای که PEAP را پایان می‌دهد مالک گواهی‌ای است که می‌خواهید تغییر دهید.

گواهی را همان‌جا که EAP پایان می‌یابد جایگزین کنید

گواهی را روی نقطه پایانی‌ای که PEAP را پایان می‌دهد، از طریق فرایند پشتیبانی‌شده تمدید یا جایگزین کنید و هدف احراز هویت سرور و نام مورد انتظار را حفظ کنید. زنجیره کامل را همان‌جا که سرویس جست‌وجو می‌کند نصب کنید و به سرویس دسترسی به کلید خصوصی بدهید. سرویس را دوباره راه‌اندازی یا دوباره متصل کنید، چون بسیاری از سرویس‌ها گواهی قدیمی را در حافظه نگه می‌دارند و همچنان آن را ارائه می‌دهند. فایلی که روی ماشین کپی شده باشد چیزی درباره این که سرویس واقعاً کدام گواهی را ارائه می‌دهد اثبات نمی‌کند.

تغییر را با تطبیق تلاش بعدی با گزارش خود سرویس یا با بررسی گواهی‌ای که نشست ارائه کرده تأیید کنید. اگر آن گزارش هنوز اثر انگشت قدیمی را نشان می‌دهد، راه‌اندازی مجدد اثر نکرده است.

فرض نکنید که جدیدترین فایل در یک پوشه همان فایل در حال استفاده است. نسخه‌ای با نام درست و مجوزهای نادرست چیزی را تغییر نمی‌دهد. تغییر را با هویت ارائه‌شده بسنجید، نه با برچسب زمان فایل.

چه کاری نکنید

اعتبارسنجی PEAP را غیرفعال نکنید و برای گذر از خطا روش داخلی ضعیف‌تری را تحمیل نکنید. این کار سیاست را تغییر می‌دهد و ویژگی احراز هویت سرور را که همان ابتدا گواهی منقضی را گرفت حذف می‌کند. شما یک بررسی کارآمد را با یک اتصال کارآمد معاوضه می‌کردید، و گواهی منقضی بعدی بی‌آنکه چیزی آن را اعلام کند می‌رسید.

اتصال موفق یک سیستم‌عامل دیگر را دلیل قابل‌قبول بودن گواهی ندانید. آن کلاینت ممکن است روش EAP دیگری، مخزن اعتماد دیگری یا اصلاً هیچ اعتبارسنجی سروری به کار ببرد، پس موفقیتش چیزی درباره بررسی‌ای که اینجا شکست خورد نمی‌گوید. یک آزمون منفی عمدی، مانند گواهی با نام نادرست یا زنجیره نامعتبر، را نگه دارید که مطابق انتظار شکست بخورد. اگر آن آزمون اکنون قبول شود، شما یک بررسی را حذف کرده‌اید نه اینکه گواهی را درست کرده باشید. بنویسید کدام هویت شکست خورد، تا نفر بعد دوباره با گواهی درگاه شروع نکند.