كيف تقرأ أول تبادل IKEv2 في التقاط حزم

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

تأكّد من أنك تنظر إلى التبادل الافتتاحي

يبدأ تفاوض IKEv2 بـ IKE_SA_INIT، ونوع التبادل 34، ومعرِّف الرسالة 0. ويختار المبادر SPI غير صفري، بينما يكون SPI المستجيب صفرياً في ذلك الطلب الأول وغير صفري في الرد. وهذه الحقائق الثلاث تفصل المحاولة الجديدة عن تجديد المفاتيح أو عن رسالة IKE_AUTH تصادف وجودها في أعلى الالتقاط.

حقول الترويسة قابلة للقراءة، وكذلك حمولات الاقتراح وتبادل المفاتيح والـ nonce. لكن كونها قابلة للقراءة لا يعني أنها موثَّقة: فلا أحد الطرفين أثبت هويته في هذه المرحلة، والقيمة الخاصة لـ Diffie-Hellman لا تظهر أبداً على السلك.

اطبع الحقول كجدول بدلاً من التمرير في لوحة فك الترميز، لأن عمليات إعادة الإرسال واختلاف SPI يصبحان واضحين في الأعمدة.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

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

اقرأ الرفض قبل أن تقرأ النجاح

الرد ليس تقدماً تلقائياً. فقد يجيب المستجيب بإشعار cookie ويتوقع أن يعيد المبادر المحاولة، أو بـ INVALID_KE_PAYLOAD يسمّي مجموعة يقبلها بدلاً منها. وكلاهما يصل كرسائل IKE سليمة البنية، وكلاهما يبدو كتبادل مكتمل لمرشِّح يعدّ الحزم فقط.

افتح حمولة الإشعار واقرأ النوع قبل أي شيء آخر. فتحدّي cookie يعني أن المستجيب يدافع عن نفسه ضد عناوين مصدر مزوّرة، وعلى العميل أن يعيد الإرسال مع إرفاق الـ cookie. والمجموعة غير الصالحة تعني أن الاقتراحين لا يتفقان، وهو ما لن يغيّره أي قدر من إعادة المحاولة حتى يتحرك إعداد أحد الطرفين.

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

المنفذ 4500 ليس بروتوكولاً واحداً

عادةً يحمل UDP 500 التبادل الافتتاحي. وبعد أن يجري كشف NAT ينتقل IKE إلى 4500 ويضع قبل كل رسالة علامة غير ESP من أربعة بايتات وقيمتها صفر. أما ESP المُغلَّف على المنفذ نفسه فيبدأ بـ SPI خاص بـ ESP غير صفري، وتبقى رسالة إبقاء NAT من بايت واحد شكلاً ثالثاً يظهر حين لا يحدث شيء آخر.

المرشِّح الذي يطابق المنفذ وحده يخلط الثلاثة، ولهذا فإن عبارة "هناك حركة على 4500" لا تحسم إلا القليل. افصل العرض حسب البروتوكول قبل أن تستنتج أي شيء عن الطرف الآخر.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

الصمت يصف نقطة المراقبة

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

عدم قابلية الوصول عبر ICMP دليل من نوع آخر. اقرأ الحزمة المقتبسة داخله وحدّد أي جهاز أرسله، لأن رفض الموجّه الإداري ليس خطأً موثَّقاً من الطرف الآخر.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

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