عدم تطابق MAC في IKE يعني فشل التحقق من المفتاح المشترك

يُظهر سجل Cloud VPN لديك محاولة بمفتاح مشترك يتبعها MAC mismatched، وغالباً ما تكون الغريزة الأولى البحث عن مشكلة في العنوان. في هذا الفرع، MAC هو رمز مصادقة للرسالة: قيمة تُحسب على التبادل بالمفتاح المتفاوض عليه. وقد قارن الطرف المقابل حسابه الخاص بالقيمة التي تلقاها، فاختلفتا. لا توجد بطاقة شبكة هنا، ولا يغيّر أي إعداد واجهة تلك المقارنة.

يحدث ذلك عملياً بشرطين: ألا تكون الأسرار على الطرفين القيمة نفسها، أو ألا تتطابق الهويتان المستخدمتان لاختيار السر. حدّد أيّهما بقراءة الزوج، لا النفق الواحد.

ما الذي تثبته المرحلة

يجري التحقق بعد أن يتبادل الطرفان المعلمات الأولية ويعرّف كل منهما عن نفسه. تختار العملية مفاتيح مشتركة مرشحة للهويتين المحلية والبعيدة وتحاول التحقق من بيانات المصادقة المستلمة؛ وعندما لا ينجح أي منها، يُصدر التشخيص. هذا تأكيد قوي على المصادقة وضعيف على السبب، لأنه لا يقول أيّ طرف هو المخطئ.

النجاح السابق لا ينتقل إلى هذا التحقق. اكتمال IKE_SA_INIT، أو حمولة كشف NAT أعادت القيم المتوقعة، يثبت أن الطرفين يستطيعان التحدث. ولا يثبت شيئاً عن كونهما يشتركان في سر.

خطآن تكوينيان، رسالة واحدة

الأول هو عدم تطابق حقيقي في السر، وهو عادةً حادث تزويد: قيمة مولّدة ثُبّتت على وحدة تحكم وأُعيد كتابتها على الأخرى، أو حرف زائد نجا على أحد الطرفين، أو علامة اقتباس جاءت مع اللصق. والثاني هو عدم تطابق في الهوية، حيث يكون السر صحيحاً لكن الهوية التي يقدمها الطرف المقابل تختار مدخلاً مختلفاً، فلا يُجرَّب السر الصحيح أبداً. وكلاهما ينتج السطر نفسه، ولهذا يكلف التخمين فترة بعد الظهر.

قارن الزوج قبل أن تمس أي سر. طابق النفق ونقطة نهاية الطرف المقابل والنافذة الزمنية والتكوين البعيد، لأن نفقين زائدين قد يحملان سرين مختلفين وقد لا تكون الشاشة أمامك هي التي فشلت.

كشف NAT مرحلة مختلفة

يسأل كشف NAT كيف تُعاد كتابة الحزم، لا من هو الطرف المقابل. ولا تزال بوابة العميل خلف NAT تصادق بشكل صحيح عندما تكون هويتها المهيأة هي التي يتوقعها الطرف المقابل، وتظهر مشكلة NAT كعدم تطابق في المقترح أو المنفذ بدلاً من فشل مقارنة المصادقة.

لا تنقل عبارة قديمة عن إصدار بائع واحد إلى نشر حالي. ما يتطلبه اجتياز NAT في إصدارك مكانه وثائقه الخاصة، وعبارة MAC mismatch ليست دليلاً لصالحه أو ضده.

قرّر من الزوج، لا من الشاشة

اقرأ التكوينين جنباً إلى جنب مع حجب السر، ثم اطرح ثلاثة أسئلة. هل الهوية على كل طرف هي بالضبط ما يتوقعه الآخر، حرفاً بحرف؟ هل يستخدم الطرفان إصدار IKE نفسه وطريقة المصادقة نفسها؟ هل يتوافق النفق الفاشل مع التكوين الذي تقرأه؟ أي «لا» على أحدها يحدد الإصلاح دون المساس بالسر.

إذا كانت الثلاثة سليمة، فاستبدل السر عبر سير العمل المعتمد بدلاً من التحرير حوله.

بعد أن يصادق الطرف المقابل

بمجرد نجاح المصادقة، يكون سطح الفشل التالي هو اقتران الأمان الفرعي: المقترحات ومحددات حركة المرور. وتدوير سر قُبل بالفعل لا يصلح فشلاً فرعياً، بل يطيل الانقطاع. اقرأ حالة الفرع، ثم المحددات والنطاقات المحمية على الطرفين، وطابق إرشادات استكشاف أخطاء Cloud VPN وإصلاحها مع المرحلة التي فشلت فعلاً.

اربط سجلات جديدة من الطرفين للزوج نفسه والنافذة نفسها. فطرف واحد وحده يعطي حكماً دون مدخلات الطرف الآخر، وهذا هو الغموض الذي أنتج الرسالة أصلاً.

ما لا يجب استنتاجه

لا تقرأ الرسالة كمطالبة بتغيير عناوين MAC، ولا تنشر السر المشترك أثناء طلب المساعدة؛ فالمقتطف الذي يحتوي على المفتاح يجب أن يُزال منه المفتاح، لا أن يُحتفظ بالسجل. ولا تفترض عطلاً في التوجيه أيضاً، لأن الطرفين اللذين لا يصل أحدهما إلى الآخر لا ينتجان مقارنة مصادقة على الإطلاق. ولا تعمّم قيداً موثقاً من عائلة منتجات واحدة على كل تطبيق IPsec.

سجّل الزوج الفاشل، وحالة النفق قبل وبعد، وأي الشرطين غيّرت. وهذا السجل يحوّل الحدوث التالي إلى فحص من خمس دقائق.