FortiGate Azure و تمدید کلید: پیشنهاد peer SA با سیاست محلی مطابقت ندارد

تونل بالا آمد، ترافیک جاری شد و بعداً گزارش می‌گوید peer SA proposal not match local policy. بیشتر افراد آن خط را گواهی می‌خوانند که دو پیکربندی هرگز مطابقت نداشته‌اند. معمولاً معنای باریک‌تری دارد: آن‌ها برای نخستین CHILD SA مطابقت داشتند و در نخستین تمدید از مطابقت افتادند، چون انجمن نخست هرگز به تبادلی که بعدی‌ها انجام می‌دهند نیاز نداشت. همین تمایز تعیین می‌کند کجا را نگاه کنید.

نخستین CHILD SA ارث می‌برد، بعدی‌ها مذاکره می‌کنند

در IKEv2، CHILD SA آغازین در جریان IKE_AUTH ساخته می‌شود و کلیدهایش از مادهٔ کلید IKE SA مشتق می‌شوند. در آن لحظه تبادل جداگانهٔ Diffie-Hellman وجود ندارد، پس گروه PFS که یک peer نمی‌تواند بپذیرد هنوز آزمایش نمی‌شود. تونل سالم به نظر می‌رسد چون شرطی که بعداً در آن شکست می‌خورید هرگز آزموده نشده است.

تمدید کلید CHILD_SA توالی پیام دیگری است. وقتی PFS پیکربندی شده باشد، peerها تبادل کلید تازه‌ای انجام می‌دهند و باید بر گروهی که هر دو طرف می‌پذیرند و نیز پیشنهاد ESP برای انجمن جدید توافق کنند. همان لحظه است که ناسازگاری آشکار می‌شود و به همین دلیل خطا به‌جای مسیر، یک پیشنهاد را نام می‌برد.

پس «دیروز کار می‌کرد» چیزی دربارهٔ پیشنهاد به شما نمی‌گوید. می‌گوید تبادل آغازین موفق بود، چیزی که از قبل می‌دانستید.

تبادل شکست‌خورده را بخوانید، نه اولین ping را

پیش از هر تغییری، احراز هویت موفق IKE، CHILD SA آغازین و جانشین شکست‌خورده را از هر دو سو جمع کنید. سپس عملیات را دقیق نام بگذارید: تمدید کلید IKE SA، احراز هویت مجدد IKE و تمدید کلید CHILD SA سه رویداد متفاوت‌اند و «فاز 2» در گفت‌وگوی روزمره همه را پوشش می‌دهد.

فیلدهای زیر را برای اتصالی که شکست خورد مقایسه کنید، نه برای تونل به‌طور کلی.

در FortiGate، پیشنهاد فاز-2، تنظیم PFS و گروه‌های DH پذیرفته‌شده برای آن تونل را باز کنید. مقادیر بارگذاری‌شده را بخوانید، نه اینکه آن‌ها را از اتصالی که پیش‌تر برقرار شده بود استنتاج کنید. تصویر صفحهٔ GUI شواهد ضعیف‌تری از پیکربندی در حال اجراست، چون این دو می‌توانند پس از ارتقا ناسازگار شوند. بخشی را که تغییر دادید صادر کنید و همراه تیکت نگه دارید.

سیاست پیش‌فرض Azure هنوز یک سیاست است

نداشتن سیاست سفارشی متصل به اتصال به معنای آن نیست که Azure هیچ سیاستی اعمال نمی‌کند. اتصال به مجموعهٔ پیشنهادهای پیش‌فرض دروازه بازمی‌گردد که می‌تواند گسترده‌تر یا باریک‌تر از آن باشد که FortiGate شما ارائه می‌دهد. اگر دو مجموعه برای IKE هم‌پوشانی داشته باشند اما برای ESP با PFS نه، دقیقاً همین الگوی شکست را می‌گیرید.

این نمای فقط‌خواندنی سیاستی را نشان می‌دهد که واقعاً متصل است، بدون افشای اسرار:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

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

در پورتال، صفحهٔ Configuration همان اتصال جایی است که سیاست سفارشی IPsec/IKE در آن قرار می‌گیرد. راهنمای Microsoft برای سیاست‌های سفارشی پارامترهای پشتیبانی‌شده و الزامات SKU را فهرست می‌کند. Azure برای هر اتصال یک ترکیب کامل می‌گیرد، بنابراین فیلدهای IKE و فیلدهای IPsec را با هم مشخص می‌کنید، نه یکی‌یکی.

PFS یک الزام است، نه کلیدی برای چرخاندن

اگر خط پایهٔ امنیتی شما PFS را الزامی می‌داند، راه‌حل گروهی است که هر دو peer در هر دو سو می‌پذیرند و با سیاستی منطبق بیان می‌شود. خاموش کردن PFS تا خطا ناپدید شود، ویژگی امنیتی را که می‌خواستید حفظ کنید تغییر می‌دهد و معمولاً بعداً به‌صورت ناسازگاری دیگری بازمی‌گردد.

یک تلهٔ مخصوص Azure: وقتی GCM را برای ESP انتخاب می‌کنید، انتخاب‌های رمزنگاری و یکپارچگی باید همان الگوریتم GCM و همان طول کلید را نام ببرند. آمیختن یک رمز GCM با الگوریتم یکپارچگی جداگانه ترکیبی می‌سازد که سرویس آن را رد می‌کند و تا وقتی سیاست را دقیق نخوانید شبیه ناسازگاری peer به نظر می‌رسد.

قوی‌ترین ترکیبی را انتخاب کنید که هر دو سو پشتیبانی می‌کنند و الزام شما اجازه می‌دهد، سپس آن را در سابقهٔ تغییر بنویسید. نفر بعد با آن سابقه مقایسه می‌کند، نه با خاطرهٔ تونلی که کار می‌کرد. گروه PFS و پیشنهاد ESP را در آن بنویسید، نه فقط نام سیاست را. وقتی بعداً کسی می‌پرسد چرا یک ممیزی شکست خورد یا چرا تمدید کلید کند است، همان خط به هر دو پرسش پاسخ می‌دهد.

تبادلی را که شکست خورد بررسی کنید

تغییر را با مسیر بازیابی زمان‌بندی کنید، چون ویرایش سیاست می‌تواند تونلی را که می‌خواهید درست کنید قطع کند. پس از بازگشت ترافیک، منتظر تمدید CHILD_SA بمانید یا آن را راه بیندازید و تأیید کنید که انجمن جدید با گروه PFS مورد نظر برقرار شده است. سپس تأیید کنید که ترافیک برنامه‌ها از آن عبور می‌کند.

دو مسیر انحرافی ارزش نام بردن دارند. عمرهای SA مشخصات محلی‌اند، پس مقادیر نابرابر عادی است و تغییرشان فقط زمان بروز مشکل را جابه‌جا می‌کند. DPD تشخیص می‌دهد که آیا peer زنده است؛ بالا بردن مهلت آن انتخاب‌های ESP یا PFS را هم‌تراز نمی‌کند.

نتیجهٔ مذاکره‌شده و رویداد بعدی پس از تغییر را ثبت کنید. اگر اتصال اکنون پیش از تکمیل احراز هویت IKE شکست بخورد، شما به تنظیمات IKE که همین الان ویرایش کردید نگاه می‌کنید، نه به شکست اصلی تمدید CHILD.