حجم IPsec الإضافي: الوضع وNAT-T والخوارزميات كلها تغيّره
رقم واحد منشور عن الحجم الإضافي يصف تغليفًا واحدًا على مسار واحد. اجمع الرؤوس التي يتفاوض عليها نفقك فعليًا، ثم قِس المسار.
في مكان ما من دليل ما يوجد رقم، عادة بين ستين وثمانين بايت، طرحه أحدهم من 1500 للحصول على MTU للواجهة. ذلك الرقم يصف تغليفًا محددًا على مسار محدد. غيّر الوضع أو عائلة العنوان الخارجية أو الخوارزمية أو وجود NAT، ولن تنطبق الحسابات بعد ذلك على نفقك.
الرقم جاء من نفق مختلف
الحجم الإضافي ليس خاصية لـ IPsec في المجرّد. إنه خاصية للحزمة التي تُبنى فعليًا: وضع متفاوض عليه، ورأس خارجي، ورأس حماية، وحشو، وحقل سلامة، وربما غلاف UDP إضافي.
الرقم المذكور لوضع النقل مع IPv4 وبدون NAT يصف حزمة أصغر من وضع النفق مع IPv6 تحت عبور NAT. كلاهما صحيح في حالته. ونسخ أي منهما إلى نشر مختلف هو الطريقة التي ينتهي بها الناس إلى MTU يكسر النقل الكبير. الفشل صامت لأن الطلبات الصغيرة تظل تعمل.
اجمع الطبقات الموجودة فعلًا
ابدأ من رأس IP الخارجي واتجه إلى الداخل. في وضع النفق تكون الحزمة الأصلية في الداخل، لذا فالرأس الخارجي إضافة وليست بديلًا. RFC 4303 يصف رأس ESP والحشو وبيانات السلامة التي تليه.
| Layer | What it adds | When it applies |
|---|---|---|
| Outer IP header | 20 bytes for IPv4, 40 for IPv6 | Always, and 40 rather than 20 if the outer path is v6 |
| ESP header | 8 bytes of SPI and sequence number | Always |
| Block cipher IV | 8 to 16 bytes depending on the transform | When the negotiated cipher uses one |
| Padding and trailer | Padding to the block size, plus two trailer bytes | Always, and the amount varies with payload length |
| Integrity data | 12 to 16 bytes for common authenticated ciphers | When integrity protection is negotiated |
| UDP encapsulation | 8 bytes | NAT traversal on port 4500, which is common for clients behind NAT |
لا يوجد صف ثابت في كل عمليات النشر، بل إن صف الحشو ليس ثابتًا حتى داخل النشر الواحد. وهذا هو السبب الكامل وراء خيبة الأمل من رقم واحد منشور للحجم الإضافي.
قد يختلف موقعان حول النفق نفسه
لا تزال الحزمة المحمية بحاجة إلى عبور المسار الخارجي، والمسار الخارجي ليس واحدًا في كل مكان. وصلة PPPoE تحمل أقل من مقطع Ethernet نظيف. وقد تنكمش شبكة الجوال أكثر، ومزوّد يغلّف حركته بأنبوب خاص يضيف تغليفًا آخر لم يذكره أحد. النفق الذي يعمل على وصلة ويفشل على أخرى يصف الوصلة الثانية، لا البروتوكول.
يمكن أن يختلف الاتجاهان أيضًا. المسار غير المتماثل قد يمنحك رفعًا يعمل وتنزيلًا متوقفًا، وهو ما يُقرأ كمشكلة تطبيق حتى تنظر إلى أحجام الحزم بدلًا من إمكانية الوصول. نجاح ping صغير لا يثبت إلا القليل عن استجابة بالحجم الكامل.
قِس بدلًا من أن تطرح
اعثر على أكبر مخطط بيانات ينجو عبر المسار. ثم قارنه بالقيمة التي تبلغ عنها الواجهة:
ip link show eth0 | grep -o 'mtu [0-9]*' ip xfrm state list ping -M do -s 1400 198.51.100.7 ping -M do -s 1372 198.51.100.7 tcpdump -ni any -c 20 'esp or udp port 4500'
أنزل حجم ping حتى تصل الردود، واعتبر أكبر قيمة تعمل هي الميزانية لذلك المسار. يُخبرك ناتج xfrm بالوضع والخوارزميات التي تم التفاوض عليها، وهي المدخلات لأي حساب صادق. ويؤكد الالتقاط ما إذا كان ESP أو ESP المغلّف بـ UDP هو الموجود على السلك، وهذا يحسم سؤال NAT دون تخمين.
خصّص قيمة واحدة لمستوى التحكم أيضًا. حزم مصافحة IKE لها بنية مختلفة عن حزم البيانات، لذا فالحجم المستنبط من التقاط مصافحة ليس MTU لمستوى البيانات.
ضع الرقم في مكانه الصحيح
بالنسبة إلى TCP عبر نفق، فإن تثبيت MSS غالبًا هو الضابط الأقل تدخلًا، لأنه يقلل ما ترسله الأطراف دون تغيير النفق نفسه. أما في نفق قائم على المسارات فاضبط MTU لواجهة النفق عن قصد ووثّق السبب. وفعل الاثنين معًا ثم القياس لا يعطيك أي معلومة عن أيهما ساعد.
احتفظ في التذكرة بالوضع المتفاوض عليه وعائلة العنوان الخارجية وحالة NAT والعَرَض القابل للتكرار معًا. مجموعة مسجلة من أربع حقائق تتغلب على ثابت محفوظ في الذاكرة، وهي النسخة الوحيدة من هذا التي تنجو من ترقية العميل التالية.