تمييز تجزئة IKEv2 عن مشكلة سلسلة الشهادات

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

آليتان للتجزئة وعرض واحد

لـ IKEv2 امتداد تجزئة خاص به، محدد في RFC 7383، يقسّم رسائل IKE المحمية إلى رسائل IKE أصغر. يتفاوض الطرفان على تلك الإمكانية، وتُعاد تجميع الرسالة بواسطة تطبيق IKE لا بواسطة طبقة IP.

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

يضيف اختراق NAT متغيرًا ثالثًا، لأن ESP يُغلّف عندئذ داخل UDP وتصبح الحزمة الخارجية أكبر بينما تبدو كحركة UDP عادية على المنفذ 4500. المسار الذي يمرر UDP جيدًا قد يفشل مع ذلك في رسالة لم تعد تتسع.

اقرأ التبادل الذي فشل

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

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

غيّر المسار لا الشهادة

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

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

قِس التبادل قبل أن تعدّل أي شيء

احصل على حجم السلسلة وحجم المسار. كلا الرقمين يقيّدان ما يمكن للمصافحة إرساله، وكلاهما رخيص القياس:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

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

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

أصلح الطبقة المكسورة فعلًا

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

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

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