چرا IKEv2 بومی ویندوز اصلاً فیلد PSK ندارد
پروتکل از کلیدهای مشترک پشتیبانی می‌کند، در حالی که سرویس‌گیر داخلی گواهی‌ها و EAP را ارائه می‌دهد. روشی را انتخاب کنید که هر دو طرف پیاده‌سازی می‌کنند، نه یک راه‌حل محلی.
مستندات دروازه می‌گوید کلید از پیش مشترک در سرویس‌گیر وارد می‌شود، اما نمایه ویندوز هیچ فیلدی برای آن ندارد. این شکاف اشکالی نیست که با تایپ کلید در جعبه گذرواژه دور زده شود. این تفاوت میان کاری است که یک پروتکل می‌تواند انجام دهد و کاری که یک پیاده‌سازی مشخص ارائه می‌دهد.
توانمندی پروتکل پشتیبانی سرویس‌گیر نیست
مشخصات IKEv2 احراز هویت با کلید مشترک را در بر می‌گیرد، بنابراین دروازه می‌تواند به‌طور مشروع برای آن پیکربندی شود. نمایه دسترسی از راه دور بومی ویندوز به‌جای آن ترتیبات گواهی و EAP را مستند می‌کند، و توانمندی پروتکل هیچ فیلد، پارامتر یا مقدار رجیستری‌ای که سرویس‌گیر هرگز نداشته ایجاد نمی‌کند.
مردم معمولاً به مرجع PowerShell برای افزودن اتصال VPN می‌رسند و آنجا L2tpPsk برای ترتیب L2TP نشان داده شده است. آن پارامتر به L2TP تعلق دارد و یک راز عمومی IKEv2 نیست. تنظیمات انتخاب الگوریتم پارامترهای حفاظت را برمی‌گزیند که چیز سوم و نامرتبطی است. نقش مسیریابی Windows Server هم همان شیء نیست. یک رابط سرور می‌تواند کنترل‌های پیکربندی داشته باشد که نمایه سرویس‌گیر رومیزی ندارد، و کپی کردن یک تنظیم سرور در نمایه ایستگاه کاری آن توانمندی را بازتولید نمی‌کند.
بین گواهی، EAP یا L2TP یکی را انتخاب کنید
اگر گرداننده دروازه احراز هویت با گواهی را بپذیرد، معمولاً پاک‌ترین مقصد است: سرویس‌گیر گواهی ارائه می‌دهد، دروازه آن را در برابر صادرکننده معتبر بررسی می‌کند و هیچ راز مشترکی در نمایه نمی‌ماند که کسی کپی کند. این کار ثبت‌نام، زنجیره معتبر و پیکربندی دروازه‌ای می‌خواهد که گواهی را به تصمیم مجوز گره بزند.
EAP با اعتبارنامه کاربر مسیر پشتیبانی‌شده دیگر در این سرویس‌گیر است و تصمیم را به ارائه‌دهنده هویت منتقل می‌کند. وابستگی‌های خودش را هم می‌آورد، چون روش EAP، گواهی سرور و اعتماد سرویس‌گیر به آن گواهی باید همه با هم هم‌راستا باشند. تغییر به L2TP/IPsec فقط برای به دست آوردن یک فیلد آشنا پشته پروتکل را عوض می‌کند. این زمانی پذیرفتنی است که انتخابی پشتیبانی‌شده با دلیل مستند باشد، و نتیجه بدی است وقتی رخ می‌دهد چون کسی دنبال جعبه‌ای برای تایپ کلید می‌گشت.
بررسی کنید دروازه چه چیزی را می‌پذیرد
از گرداننده بپرسید سرویس دسترسی از راه دور امروز کدام روش‌های احراز هویت را ارائه می‌دهد، نه اینکه محصول به‌طور کلی از کدام‌ها پشتیبانی می‌کند. سرویسی که برای IKEv2 فقط با PSK پیکربندی شده، گواهی را فقط به این دلیل که سرویس‌گیر آن را ترجیح می‌دهد نمی‌پذیرد.
Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfterروش احراز هویت نمایه و مخزن گواهی را با هم بخوانید. نمایه‌ای که روی EAP تنظیم شده و گواهی قابل استفاده‌ای پشت آن نیست، به شکلی شکست می‌خورد که شبیه مشکل سرور به نظر می‌رسد.
اگر پاسخ این است که فقط PSK در دسترس است، گزینه‌های صادقانه یک سرویس‌گیر تأییدشده که آن را پشتیبانی می‌کند یا تغییری در طراحی احراز هویت دروازه است. هیچ‌کدام راه‌حل محلی نیست، و وانمود کردن به خلاف آن اتصالی می‌سازد که فقط کسی که آن را پیکربندی کرده می‌تواند بازتولید کند.
تصمیم و اسرار را ثبت کنید
روش انتخاب‌شده، لنگر اعتماد، هویتی که به آن نگاشت می‌شود و کسی که تغییر را تأیید کرده را بنویسید. آن سابقه چیزی است که بازبینی حادثه لازم دارد و همچنین چیزی است که مهندس بعدی را از کشف دوباره همان بن‌بست باز می‌دارد.
اسرار را در یادداشت‌هایتان جدا نگه دارید: گذرواژه حساب، عبارت عبور کلید خصوصی و کلید از پیش مشترک دروازه سه چیز متفاوت هستند، حتی وقتی صفحه تنظیمات همه را گذرواژه می‌نامد. اشتباه گرفتن آن‌ها همان راهی است که یک کلید به بلیت می‌رسد. نمایه حاصل را با اتصال تازه و یک درخواست برنامه به منبع خصوصی آزمایش کنید. تونل موفق بدون سرویس قابل دسترس نتیجه‌ای ناقص است و نمایه نباید تا وقتی منبع هم کار نمی‌کند تمام‌شده توصیف شود.