IKEv2 ليس مصافحة واحدة: أولاً IKE SA، ثم المصادقة، ثم CHILD SA

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

الأسطورة: إذا أجابت البوابة فأنت متصل

الاستجابة للرسالة الأولى تثبت أن نقطة النهاية قابلة للوصول ومستعدة للتحدث. وهي لا تثبت أن حسابًا قُبل، أو أن سلسلة شهادات تُحققت، أو أن أي سياسة بيانات نُصبت.

تحدث تلك الإخفاقات لاحقًا، وتُنتج أعراضًا مختلفة. رفض الشهادة أو فشل EAP يصل بعد نجاح التبادل الأول بالفعل، ولهذا لا تقول لك إشارة ping إلى UDP 500 وأيقونة عميل خضراء إلا القليل.

IKE_SA_INIT: الاتفاق على المعاملات، لا على الهوية

يحمل التبادل الأول مقترحات رابطة أمن IKE: خوارزميات التشفير والسلامة، ودالة شبه عشوائية، ومجموعة Diffie-Hellman. ويتبادل الطرفان أيضًا قيم nonce، ويشتق كل جانب مادة المفاتيح لرابطة IKE SA من السرّ المشترك الذي تُنتجه تلك القيم. لا شيء في هذا التبادل يحدد هوية الطرف الآخر. إنه يثبت أن الجانبين يستطيعان حساب المفاتيح نفسها وأنهما متفقان على مقترح. والمستجيب الذي لا يعجبه أي مقترح يرفض التبادل هنا، ولهذا يبدو اختلاف الإصدار أو الخوارزمية كأن الخادم متوقف.

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

IKE_AUTH: إثبات الهوية، ثم بناء أول CHILD SA

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

في الحالة الطبيعية تتفاوض IKE_AUTH أيضًا على أول CHILD SA، فتُتفق حماية البيانات في الرحلة نفسها. يقترح البادئ محدِّدات حركة المرور، ويضيّقها المستجيب أو يرفضها، وتُشتق مفاتيح مسار البيانات من IKE SA. وهذا يعني أن تبادلًا واحدًا يمكن أن يفشل في موضعين مختلفين جدًا: الهوية أو السياسة. اقرأ حمولة الإشعار أو الخطأ بدلًا من فشل المصافحة العام، لأن إصلاح الأول شهادة وإصلاح الثاني عدم تطابق الشبكة الفرعية.

رابطتان، مهمتان

إبقاؤهما منفصلتين يفسّر سلوكين يبدوان كخللين. يمكن أن يظهر النفق قائمًا بينما يفشل إعادة التوليد في الخلفية، ويمكن استبدال CHILD SA دون أن يُسقط العميل الاتصال.

على strongSwan، يعرض مرجع إعداد IKEv2 وswanctl --list-sas المستويين، ويعرض ip xfrm state مع ip xfrm policy ما ثبّته النواة فعليًا. ومقارنة هذين العرضين هي أسرع طريقة لمعرفة ما إذا كانت المفاوضة قد اكتملت أم بدت مكتملة فقط. إذا سرد الخادم CHILD SA لا حالة لها في النواة، فقد فشل التثبيت بصمت. وإذا احتفظت النواة بحالة لا يعرفها الخادم، فأنت تنظر إلى بقايا محاولة سابقة.

ما يجب أن يظل صحيحًا بعد قيام النفق

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

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