FortiGate Azure وإعادة المفتاح: مقترح SA للنظير لا يطابق السياسة المحلية

أقلع النفق، وجرى المرور، ثم تقول السجلات لاحقاً peer SA proposal not match local policy. يقرأ معظم الناس هذا السطر كدليل على أن التهيئتين لم تتطابقا قط. وهو يعني عادة شيئاً أضيق: تطابقتا من أجل أول CHILD SA ثم توقفتا عن التطابق عند أول تجديد، لأن الارتباط الأول لم يحتج قط إلى التبادل الذي تجريه الارتباطات اللاحقة. هذا الفرق يحدد أين تنظر.

أول CHILD SA يرث، واللاحقة تتفاوض

في IKEv2 يُنشأ CHILD SA الأولي أثناء IKE_AUTH، وتُشتق مفاتيحه من مادة مفاتيح IKE SA. ولا يوجد تبادل Diffie-Hellman منفصل عند تلك النقطة، لذلك فإن مجموعة PFS التي لا يقبلها أحد النظيرين لا تُختبر بعد ببساطة. يبدو النفق سليماً لأن الشرط الذي ستفشل فيه لاحقاً لم يُختبر قط.

إعادة مفتاح CHILD_SA تسلسل رسائل مختلف. فعند تكوين PFS، يجري النظيران تبادلاً جديداً للمفاتيح وعليهما الاتفاق على مجموعة يقبلها الطرفان، إضافة إلى مقترح 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، فالعلاج هو مجموعة يقبلها النظيران على الجانبين، يعبَّر عنها بسياسة مطابقة. وإيقاف PFS لإخفاء الخطأ يغير خاصية الأمان التي كنت تحاول الحفاظ عليها، ويعود عادة لاحقاً كعدم تطابق مختلف.

فخ واحد خاص بـ Azure: عند اختيار GCM لـ ESP، يجب أن تسمي اختيارات التشفير والسلامة الخوارزمية نفسها وطول المفتاح نفسه. فخلط شيفرة GCM بخوارزمية سلامة منفصلة ينتج تركيبة ترفضها الخدمة، وتبدو كعدم تطابق بين النظيرين حتى تقرأ السياسة عن قرب.

اختر أقوى تركيبة يدعمها الطرفان ويسمح بها شرطك، ثم اكتبها في سجل التغيير. سيقارن الشخص التالي بذلك السجل، لا بذكرى نفق كان يعمل. ضع مجموعة PFS ومقترح ESP فيه، لا اسم السياسة وحده. وعندما يسأل أحد لاحقاً لماذا فشل تدقيق أو لماذا إعادة المفتاح بطيئة، يجيب ذلك السطر عن السؤالين.

تحقق من التبادل الذي فشل

جدول التغيير مع مسار للاستعادة، لأن تحرير السياسة قد يقطع النفق الذي تحاول إصلاحه. بعد عودة المرور، انتظر تجديد CHILD_SA أو أطلقه، وتأكد من إنشاء الارتباط الجديد بمجموعة PFS المقصودة. ثم تأكد من استمرار مرور التطبيقات عبره.

ثمة مسارَان مضللان يستحقان الذكر. أعمار SA مواصفات محلية، لذا فإن القيم غير المتساوية طبيعية، وتغييرها يغير فقط موعد ظهور المشكلة. يكتشف DPD ما إذا كان النظير حياً؛ ورفع مهلة ذلك لا يوائم اختيارات ESP أو PFS.

سجّل النتيجة المتفاوض عليها والحدث التالي بعد التغيير. إذا فشل الاتصال الآن قبل اكتمال مصادقة IKE، فأنت تنظر إلى إعدادات IKE التي عدلتها للتو، لا إلى عطل تجديد CHILD الأصلي.