هناك نوع معين من الرضا الزائد يتسلل إلى إعدادات الـ firewall بمجرد أن يكون نفق VPN "يشتغل تمام" لسنوات. ما أحد يلمسه، وما أحد يراجعه. وهذه بالضبط هي المشكلة، لأن النفق الذي يعمل بصمت على IKEv1 منذ 2014 لم يعد مجرد "قديم" — أصبح بروتوكولاً ميتاً رسمياً، وفي 2026 صار تحديداً الشيء الذي راح المهاجمون يبحثون عنه.

ليش IKEv1 أصبح ميتاً رسمياً

هذا الكلام ما عاد رأياً شخصياً. IETF أصدرت RFC 9395 التي تُلغي رسمياً IKEv1 وتنقله إلى حالة Historic. والوثيقة واضحة وصريحة: تطوير IKEv1 توقف قبل أكثر من عشر سنوات، والأنظمة التي ما زالت تشغّله يجب ترقيتها وإعادة ضبطها لتعمل على IKEv2. هذا الكلام مو هامش صغير في آخر الصفحة — هذا هو الهدف المعلن من الوثيقة نفسها.

والجهات الوطنية أخذت هذا الموضوع على محمل الجد. إرشادات NCSC البريطانية حول IPsec تنص الآن بشكل صريح أنه بما أن IKEv1 أُلغي رسمياً عبر RFC 9395 ونُقل إلى Historic، فهي توصي بقوة بعدم استخدام IKEv1 إطلاقاً، نقطة انتهى الموضوع. وإذا كنت في مؤسسة خليجية تربط سياساتها بأطر بريطانية أو NIST — وكثير من البنوك وشركات المقاولات الحكومية ومزودي الرعاية الصحية عندنا يفعلون ذلك — فهذا لم يعد بند "نحسّنه لاحقاً"، بل انحراف موثّق عن أفضل الممارسات الحالية موجود في شبكتك الآن.

جرس الإنذار: استغلال فعلي في 2026

إذا كانت إشعارات الإلغاء ما تحرّك الميزانيات، فالثغرات المُستغلة عادة تفعل. في يونيو 2026، كشفت Check Point عن CVE-2026-50751، وهي ثغرة حرجة في تجاوز المصادقة (CVSS 9.3) تصيب منتجات Check Point Remote Access VPN وMobile Access وSpark Firewall. الثغرة عبارة عن خلل منطقي تحديداً في مسار مصادقة الشهادات ضمن IKEv1 — مو ضعف عام في VPN، بل ثغرة موجودة أصلاً لأن IKEv1 ما زال مفعّلاً.

وهذا الجزء اللي يستحق فعلاً أن يقلقك: فريق Watchtowr Labs وجد أدلة على أن هذه الثغرة كانت تُستغل فعلياً في البرية منذ 7 مايو 2026 على الأقل — أي قبل شهر تقريباً من صدور أي تحديث أمني — ضد عشرات المؤسسات المستهدفة تحديداً. هذه فترة حقيقية كان فيها مجرد وجودك على الإنترنت مع تفعيل مصادقة الشهادات على IKEv1 كافياً ليضربوك، سواء طبّقت التحديث أو لا. وسيسكو أيضاً لها تاريخها في هذا الموضوع: الإرشادات الأمنية المنشورة تغطي مشاكل تجزئة (fragmentation) وحرمان خدمة (denial-of-service) في IOS وIOS XE، حيث يستطيع مهاجم يملك بيانات اعتماد VPN صالحة لـ IKEv1 أن يجبر الجهاز على إعادة التشغيل. مزوّد مختلف، لكن نفس الدرس: IKEv1 يستمر بإنتاج ثغرات جديدة لأن ما أحد يستثمر جهد هندسي حقيقي في إصلاح بروتوكول متجاوز بالشكل الصحيح. يرقّعونه بالحد الأدنى فقط ليزيلوا المشكلة الفورية.

وين يختبئ IKEv1 في شبكات الخليج

اسأل أغلب مدراء تقنية المعلومات عندنا إذا كانوا ما زالوا يشغّلون IKEv1، والجواب الصادق غالباً يكون "لازم أتحقق". وهذا هو الخطر الحقيقي. يختبئ في أماكن متوقعة: راوتر الفرع الذي تم تركيبه قبل خمس أو ست سنوات وما أحد لمسه منذ التشغيل الأولي؛ ملف تعريف remote-access تم إنشاؤه لمقاول ترك الشركة لكن إعدادات عميل VPN الخاصة به ما راجعها أحد؛ صورة firewall وصلت End-of-Life وما تمت ترقيتها لأن "عقد الدعم انتهى وهي ما زالت تمرّر الترافيك". الشركات الصغيرة والمتوسطة في عُمان والخليج عموماً تشغّل الكثير من الأجهزة لفترة أطول بكثير من عمرها الافتراضي، وإعدادات VPN من أقل الزوايا التي تتم مراجعتها في هذه الأجهزة، تحديداً لأنها تعمل بصمت في الخلفية.

إذا كنت تدير أكثر من موقعين أو ثلاثة، افترض أن نفقاً واحداً على الأقل أو ملف remote-access ما زال على IKEv1 إلى أن تتأكد فعلياً من العكس.

الجرد قبل الترحيل: احصر كل شيء قبل ما تلمس أي شيء

لا تبدأ بإعادة الضبط من اليوم الأول. ابنِ الجرد أولاً. لكل firewall وراوتر ومركّز VPN عندك، اسحب إعدادات IPsec الحالية ودوّن:

• كل تعريف peer على IKEv1 — سواء site-to-site أو remote-access — مع معاملات phase 1 وphase 2 الخاصة به.
• كل مفتاح مشترك مسبقاً (pre-shared key) قيد الاستخدام حالياً، ومن يعرفه غيرك.
• كل ملف تعريف عميل remote-access، بما فيها ملفات المقاولين والفروع البعيدة، وأي تطبيقات VPN موبايل قديمة قد تكون ما زالت مضبوطة على IKEv1 بدل IKEv2 أو SSL VPN.
• إصدار الـ firmware أو نظام التشغيل على كل جهاز، وهل هذا الإصدار أصلاً يدعم IKEv2 بشكل صحيح، أو يحتاج ترقية أولاً.

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

خطوات الانتقال خطوة بخطوة

بعد ما تعرف وش عندك بالضبط، الترحيل نفسه يتبع نمطاً شبه موحّد بغض النظر عن المزوّد:

1. شغّل IKEv2 بالتوازي. لا تلمس نفق IKEv1 الموجود بعد. اضبط peer جديد على IKEv2 بجانبه، باستخدام proposal مختلف لـ phase 1، بحيث يتعايش الاثنان خلال فترة الانتقال.
2. قرر: شهادات أم PSK؟ المفاتيح المشتركة مسبقاً أسهل في النشر لكنها أضعف على المدى الطويل، خصوصاً في remote-access. إذا كان عندك أصلاً أي نوع من CA داخلي أو Active Directory Certificate Services، استخدم الشهادات مع IKEv2 — هذا يزيل مشكلة انتشار الأسرار المشتركة تماماً، وهو الاتجاه الذي تدفع نحوه أغلب وثائق المزوّدين حالياً.
3. تحقق من دعم NAT-T وMOBIKE. تأكد أن NAT Traversal يتفاوض بشكل صحيح على الطرفين، وإذا عندك مستخدمون متنقلون أو roaming، تحقق من تفعيل MOBIKE بحيث تبقى الجلسات صامدة عند تغيّر الشبكة دون إعادة مفاتيح كاملة.
4. نفّذ تحويل العملاء على مراحل. لا تحوّل كل مستخدمي remote-access دفعة واحدة. حوّل مجموعة تجريبية أولاً — فريق تقنية المعلومات أولاً، ثم قسم واحد — تأكد من استقرار الاتصال لعدة أيام، ثم وسّع.
5. احتفظ بخطة تراجع خلال نافذة الصيانة. جدول موعد التحويل الفعلي لـ site-to-site ضمن نافذة محددة، احتفظ بإعدادات peer القديم على IKEv1 محفوظة وجاهزة لإعادة التفعيل، ولا تحذفها إلا بعد أن يثبت النفق الجديد استقراره تحت ترافيك حقيقي لمدة أسبوع على الأقل.

ملاحظات خاصة بكل مزوّد

في Cisco ASA/FTD، عند بناء طوبولوجيات VPN جديدة، انتبه أن مجموعة Diffie-Hellman رقم 5 أُلغيت بالنسبة لـ IKEv1 وأُزيلت تماماً من IKEv2، ومجموعات DH رقم 2 و24 مع خوارزميات مثل 3DES وAES-GMAC يتم إزالتها من أدلة الضبط الحالية — لا تنسخ proposals قديمة لـ phase 1 كما هي، ابنِ سياسة IKEv2 من الصفر. وفي IOS/IOS XE، راجع سجل الإرشادات الأمنية للمنصة قبل ما تفترض أن IKEv1 "قديم لكن غير ضار" — إرشادات سيسكو الأمنية نفسها تغطي مشاكل تجزئة وDoS حيث تسمح بيانات اعتماد IKEv1 الصالحة للمهاجم بإجبار الجهاز على إعادة التشغيل.

في MikroTik RouterOS، أنظف طريقة هي إنشاء profile مخصص لـ peer على IKEv2 له مجموعة policy template خاصة، وmode-configuration، واستيراد شهادات منفصل تماماً عن أي تعريف peer قديم على IKEv1، بدل محاولة تعديل الـ peer القديم في مكانه. خطوة إضافية بسيطة، لكنها تتجنب الخطأ الكلاسيكي وهو تعديل جزئي لـ peer موجود وكسر البروتوكولين مع بعض.

في Check Point Remote Access VPN، وبما أن CVE-2026-50751 تستهدف تحديداً مسار مصادقة الشهادات ضمن IKEv1، فهذه هي المنصة التي فيها الترحيل ليس واجباً منزلياً اختيارياً — بل قريب من الاستجابة لحادثة أمنية فعلية. إذا كنت ما زلت تشغّل مصادقة شهادات على IKEv1 في بوابات Check Point، فهذا البند رقم واحد على قائمتك هذا الأسبوع، مو هذا الربع.

التحصين بعد الترحيل

تشغيل IKEv2 مو خط النهاية. بمجرد أن تتأكد أن كل peer وكل عميل يعمل على IKEv2، عطّل مستمع (listener) IKEv1 بالكامل على كل جهاز — لا تكتفِ بتقليل أولويته، أطفئه تماماً. مستمع IKEv1 خامل يبقى سطح هجوم حتى لو ما أحد شرعي يستخدمه بعد الآن.

بخصوص اختيار الخوارزميات، استخدم NIST SP 800-77 Rev. 1 كمرجع. الوثيقة توثّق أن IKEv2 يدعم النطاق الكامل من أنواع التبادل المعياري، بينما كان IKEv1 محصوراً في Main Mode وQuick Mode، وAggressive Mode الأضعف بشكل ملحوظ — وهذا بالضبط نوع التبادل الذي تريده أن يتقاعد مع البروتوكول نفسه. ابنِ مقترحات IKEv2 الجديدة حول مجموعات DH من الجيل الحالي وخوارزميات AES-GCM، بدل ما تنقل ما تم ضبطه قبل عشر سنوات كما هو.

أخيراً، لا تعتبر المشروع منتهياً بمجرد رفع الأنفاق. أضف فشل مصادقة IKEv2 ومحاولات تفاوض phase 1 غير المتوقعة إلى أي نظام مراقبة سجلات أو SIEM تشغّله أصلاً. وبما أن استغلال Check Point في 2026 استمر بلا اكتشاف في البرية لمدة شهر تقريباً قبل الإفصاح، فالمؤسسات التي لاحظت وجود خلل مبكراً هي التي كانت فعلاً تراقب سجلات VPN الخاصة بها، مو التي ضبطت النفق مرة واحدة وما رجعت له بعدها.

ابدأ اليوم بشيء واحد: اسحب إعدادات IPsec من firewall أو راوتر الحافة عندك، وابحث فيها عن "IKEv1" أو "ikev1-policy". إذا وجدته، صار عندك الآن ملاحظة موثّقة وسبب واضح لجدولة التحويل هذا الشهر — مو "لاحقاً".

المصادر

• RFC 9395 - Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms
• NCSC: Using IPsec to protect data
• Check Point Blog: Patch Critical Check Point VPN Vulnerability (CVE-2026-50751)
• Watchtowr Labs: Marking Your Own Homework (CVE-2026-50751 analysis)
• Cisco Security Advisory: IOS XE IKEv1 Denial of Service
• NIST SP 800-77 Rev. 1, Guide to IPsec VPNs
• Cisco Firepower Management Center Configuration Guide - VPN Overview
• How to Deploy IPsec/IKEv2 on MikroTik (Medium)

مصدر الصورة: John Pavelka — BY