IKEv2 در Windows و FortiGate: سه تنظیمی که مردم با هم یکی می‌کنند
تبادل کلید IKE، حفاظت CHILD SA و احراز هویت همتا سه ردیف جداگانه‌اند. یکسان بودن شماره گروه‌ها در دو پنجره آن‌ها را یکی نمی‌کند.
توافق IKEv2 میان یک کلاینت Windows و یک درگاه FortiGate همچنان شکست می‌خورد، و جست‌وجوی شماره‌ای که نمی‌خواند فهرست بلندتری از شماره‌ها می‌سازد. این فهرست تنها زمانی قابل مدیریت می‌شود که به سه ردیف تقسیم شود که مستقل از هم شکست می‌خورند: تبادل کلیدی که IKE را محافظت می‌کند، حفاظتی که روی CHILD SA اعمال می‌شود، و احراز هویتی که ثابت می‌کند هر طرف کیست. شماره‌های گروه در دو تا از این ردیف‌ها ظاهر می‌شوند و معناهای متفاوتی دارند.
سه ردیف که مستقل از هم شکست می‌خورند
ردیف اول تبادل کلید درون خود IKE است که کلیدهایی را تولید می‌کند که مذاکره را محافظت می‌کنند. ردیف دوم پیشنهاد برای CHILD SA است که ترافیکی را که تونل حمل می‌کند محافظت می‌کند. ردیف سوم احراز هویت است که تعیین می‌کند هر طرف چه چیزی ارائه می‌دهد و طرف دیگر چگونه آن را اعتبارسنجی می‌کند.
شکست‌ها در جاهای متفاوتی رخ می‌دهند. شکست تبادل، مذاکره را پیش از آنکه هیچ تونلی وجود داشته باشد متوقف می‌کند. شکست CHILD SA پس از موفقیت احراز هویت رخ می‌دهد، گاهی فقط هنگام تجدید کلید. شکست احراز هویت در گزارش‌ها می‌تواند مانند شکست تبادل به نظر برسد اگر فقط خطای اول را بخوانید.
جدا کردن ردیف‌ها کار دفتری نیست. تعیین می‌کند کدام تنظیم ارزش تغییر دارد، و پرهزینه‌ترین حرکت در کل این حوزه را مانع می‌شود، یعنی بازتولید گواهی‌های سالم برای رفع ناسازگاری پیشنهاد. تغییر یک ردیف هرگز نباید دو ردیف دیگر را مجبور به تغییر با خود کند. همین استقلال تمام دلیل جدا نوشتن آن‌ها است.
دو فیلد Windows چه چیزی را کنترل می‌کنند
Windows دو فیلد را جدا نگه می‌دارد: DHGroup خود تبادل IKE را پیکربندی می‌کند، در حالی که PfsGroup سیاست IPsec را پیکربندی می‌کند که ترافیک درون تونل را محافظت می‌کند. آن‌ها به فازهای متفاوتی تعلق دارند. مقایسه یک فیلد IKE در Windows با مقدار فاز 2 در FortiGate جفت اشتباه را می‌آزماید، و شماره‌ها می‌توانند یکسان باشند در حالی که تبادل زیربنایی همچنان شکست می‌خورد.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAدستور دوم و سوم انجمن‌های امنیتی را که واقعاً وجود دارند گزارش می‌کنند، و این نزدیک‌ترین چیز به پاسخی است که یک کلاینت می‌تواند به شما بدهد. انجمن حالت اصلی بدون انجمن حالت سریع یک مشکل CHILD SA است، و نشانه ناسازگاری فاز 2 است نه مشکل گواهی.
ثبت کنید در یک تلاش چه چیزی پیشنهاد و چه چیزی انتخاب شد. فهرست پیشنهادی که شامل یک پیشنهاد قابل قبول است و پیشنهاد انتخاب‌شده‌ای که با سیاست درگاه نمی‌خواند، اختلاف پیکربندی است، نه معمای هم‌کنش‌پذیری.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
یک گروه خم بیضوی کلید امضای شما را انتخاب نمی‌کند
پایدارترین استنباط نادرست در این حوزه این است که انتخاب یک گروه DH خم بیضوی به گواهی خم بیضوی نیاز دارد. گروه DH مواد تبادل کلید را فراهم می‌کند؛ الگوریتم امضا توسط چارچوب احراز هویت مذاکره می‌شود، و این دو تصمیم جداگانه در IKEv2 هستند.
RFC 7427 دقیقاً به این دلیل وجود دارد که این تصمیم‌ها پیش‌تر در هم تنیده بودند، و تعریف می‌کند که الگوریتم‌های امضا چگونه مستقل از تبادل کلید اعلام و انتخاب می‌شوند. یک درگاه می‌تواند هم‌زمان هم یک گروه خم و هم مجموعه‌ای از طرح‌های امضا را پشتیبانی کند.
بنابراین وقتی مذاکره‌ای پس از تغییر گروه شکست می‌خورد، پیش از نگاه کردن به نوع کلید گواهی، به روش احراز هویت نگاه کنید. تغییر گواهی کاری کند و پرخطر است که به‌ندرت پاسخ است، و انجام آن به‌عنوان نخستین اقدام توانایی شما را برای تشخیص اینکه کدام تغییر واقعاً کمک کرد از بین می‌برد. پیش از دست زدن به مخزن گواهی، ردیف احراز هویت را بخوانید.
این دو را در ردیف‌های جداگانه برگه توافق نگه دارید تا اشتباه دیگر وسوسه‌انگیز نباشد. یک ردیف گروه‌ها را فهرست می‌کند، ردیف دیگر طرح‌های امضا و هویت‌ها را، و هیچ‌کدام شاهدی درباره دیگری نیست.
هر کلید خصوصی را کنار صاحب واقعی‌اش بگذارید
درگاهی که گواهی خودش را ارائه می‌دهد به کلید خصوصی متناظر با آن نیاز دارد. همتایی که زنجیره را اعتبارسنجی می‌کند به گواهی CA نیاز دارد و مشخصاً به کلید امضای CA نیاز ندارد. اشتباه گرفتن این سه قطعه همان چیزی است که مردم را به وارد کردن کلید خصوصی CA در یک دستگاه VPN می‌کشاند تا گواهی در دسته دیگری ظاهر شود.
در FortiOS نقش‌ها متمایزند: یک گواهی محلی با کلیدش، یک گواهی راه دور برای شناسایی همتا، و یک ورودی CA راه دور که اعتماد به گواهی‌های امضاشده توسط آن CA را برقرار می‌کند. ورودی CA راه دور بدون کلید خصوصی ناقص نیست؛ برای هدف خود درست است.
کلیدهای امضای CA واردشده اختیارات هر کسی را که بتواند آن دستگاه را بخواند گسترش می‌دهند. آن‌ها اعتبارسنجی معمول همتا را هم حل نمی‌کنند، چون اعتبارسنجی به گواهی عمومی و تصمیم اعتماد نیاز دارد، نه به توانایی صدور گواهی‌های جدید.
کلید امضای CA را کنار فرایند خود صادرکننده نگه دارید و ثبت کنید کدام دستگاه کدام کلید را دارد. وقتی حسابرسی می‌پرسد چه کسی می‌توانست خود را جای چه کسی جا بزند، یک جدول کوتاه از صاحبان ارزشمندتر از جدول بلندتری از الگوریتم‌ها است. هیچ‌کس کلیدی را که می‌داند فقط برای فهرست موجودی است وارد نمی‌کند. فهرست موجودی را پیش از حادثه بنویسید، نه پس از آن.