نقل حزمة داخلية ثابتة بحجم 1,500 بايت عبر VPN
الحزمة الداخلية الثابتة بحجم 1,500 بايت لن تتسع في مسار خارجي بحجم 1,500 بايت. قِس الكلفة الإضافية، ثم اختر MTU أساسية أكبر أو تجزئة مدعومة.
لديك متطلب لا يقبل المساومة: يجب أن يستقبل الطرف البعيد حزمة IP نفسها بحجم 1,500 بايت التي يرسلها المرسل، بما في ذلك الترويسات. لا يمكن للنفق أن يلفّ تلك الحزمة مع تأطيره الخاص داخل حزمة IP ثانية بحجم 1,500 بايت، لذلك لا بد أن يتنازل شيء في التصميم. الترتيب أدناه هو ما أتبعه في نافذة التغيير: اكتب ميزانية البايتات، وأثبت ما يمكن للشبكة الأساسية حمله فعلاً، ثم اختر آلية نقل واحدة بالضبط وتأكد من الحزمة الداخلية على الطرف البعيد.
اكتب ميزانية البايتات قبل تحرير أي ملف تعريف
يضيف التغليف بايتات في عدة طبقات، والإجمالي خاصية لملفك التعريفي وليس ثابتاً يمكنك البحث عنه. فئة العنوان واختيار الشيفرة وبروتوكول النقل وأي خيار ضغط أو تأطير كلها تحرّك الرقم، ولهذا فإن طرحاً منسوخاً من نشر آخر لا قيمة له كميزانية. ابدأ من المتطلب الداخلي، وأضف الكلفة المقيسة لكل حزمة في تهيئتك، واكتب حجم الحزمة الخارجية الناتج في تذكرة التغيير قبل أن يحرر أحد ملفاً.
رقمان يحددان التصميم: أكبر حزمة خارجية يحملها المسار دون تجزئة، والبايتات الإضافية التي يحتاجها التغليف. عندما يكون الأول أصغر من الثاني زائد 1,500، لا بد أن يتغير أحدهما. عندئذ يكون الخيار ضيقاً لا إبداعياً، ولهذا أكتب الرقمين قبل مناقشة الخيارات. لا شيء في طبقة النفق يضغط تلك البايتات، ولا يوجد عدد MTU واحد يزيل المتطلب الذي أُعطي لك.
اختبر الشبكة الأساسية برسائل ping مع بت عدم التجزئة
قِس المسار بدلاً من الوثوق بـ MTU الواجهة، لأن أصغر وصلة في المسار الخارجي هي المهمة. في Linux، -M do تضبط بت عدم التجزئة و-s تأخذ حمولة ICMP، لذلك يستجيب إطار بحجم 1,500 بايت عند 1,472 بايت من الحمولة بعد طرح ترويسة IP البالغة 20 بايت وترويسة ICMP البالغة 8 بايت. ارفع الحمولة تدريجياً حتى يفشل الاختبار، ثم اقفز إلى حجم جامبو لترى هل يحمله المسار أصلاً.
ping -M do -s 1472 -c 2 198.51.100.10 ping -M do -s 8972 -c 2 198.51.100.10 tracepath -n 198.51.100.10
المسار الذي يمرر 1,472 ويفشل عند 8,972 لا يمكنه حمل حزمة داخلية بحجم 1,500 بايت مع الكلفة الإضافية في حزمة خارجية واحدة. هذا هو الجواب الذي كنت تحتاجه قبل فتح تهيئة VPN. وهو أيضاً يحدد أي القسمين التاليين ينطبق عليك، لذا احفظ نتيجتي الاختبار بجانب التذكرة. التخمين هنا يكلف نافذة صيانة، لأن نفقاً يعلن أنه يعمل لا يخبرك بشيء عن أكبر حزمة سيقبلها المسار.
ارفع MTU المسار فقط حيث توافق كل قفزة
الإطارات الجامبو خاصية من طرف إلى طرف، وليست إعداداً تنشّطه على الطرفين اللذين تديرهما. يجب أن تتفق كل مقسم وموجه ونقطة تسليم عند مزود على المسار الخارجي على الحجم الأكبر، وأي قفزة واحدة بحجم 1,500 بايت ستُسقط بصمت الحزمة التي كبّرتها للتو. رفع الواجهة المحلية وحدها هو التغيير الناقص الكلاسيكي الذي يجعل النفق يبدو معطلاً بينما تسقط الشبكة الأساسية بهدوء.
ip link set dev eth1 mtu 9000 ip link show dev eth1 ping -M do -s 8972 -c 2 198.51.100.10
غيّر الواجهة، ثم أعد اختبار المسار نفسه قبل أن تغيّر أي شيء آخر. إذا ظل الاختبار فاشلاً، ارجع بـ ip link set dev eth1 mtu 1500 وانتقل إلى التجزئة بدلاً من الجدال مع مزود حول وصلة لا تملكها.
استخدم تجزئة النفق عندما لا تستطيع الشبكة الأساسية النمو
آلية تجزئة مدعومة تحت الحزمة الداخلية تتيح لعدة حزم خارجية أن تحمل حزمة داخلية واحدة، ويعيد طرف النفق البعيد تجميعها قبل تسليم الأصلية إلى الطبقات العليا. خيار تجزئة UDP في Community OpenVPN هو أحد تطبيقات هذه الفكرة، وليس الشيء نفسه كتجزئة IP العادية للحزمة الخارجية. يجب أن يشغّل الطرفان نسخة تدعم التنسيق، ويجب أن يكون مسار البيانات هو ما تظنه: عملاء OpenVPN 3 وقنوات البيانات المعجّلة في النواة لها حدود مختلفة، لذلك قد يفشل ملف تعريف يعمل على عميل واحد على عميل آخر.
openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4
التجزئة الخارجية العادية هي الخيار الآخر، وهي الأضعف. لا تجزئ موجهات IPv6 حزمة مُمرَّرة إطلاقاً، لذا تموت الحزمة الخارجية الكبيرة ببساطة ولا يعلم المرسل إلا إذا نجت رسالة ICMPv6 المعنية عبر المسار. كما أن التجزئات تستدعي الترشيح وتضخيم الفقدان، ولهذا أتعامل معها كخطة بديلة لا كخطة.
الناقل الخارجي القائم على التدفق يتجاوز مسألة الحجم بتقسيم تدفق بايتاته، ويمكن أن تبقى الحزمة الداخلية المعاد بناؤها بحجم 1,500 بايت. هذا قرار نقل له كلفته، بما في ذلك السلوك المعروف لـ TCP داخل TCP، فاتخذه عمداً لا كأثر جانبي لنقاش حول MTU.
تأكد من وصول الحزمة الداخلية دون تغيير
التحقق ليس مصافحة ناجحة. التقط على واجهة النفق عند الطرفين وقارن حجم ومحتوى الحزمة التي أرسلها التطبيق فعلاً بتلك التي استقبلها الطرف البعيد.
ip link show dev tun0 ping -M do -s 1472 -c 2 10.8.0.1 tcpdump -ni tun0 -c 5 'icmp and greater 1000'
إذا أظهر الالتقاط الحزمة الداخلية كاملة الحجم عند الطرف البعيد، فاختيار النقل يعمل والمهمة المتبقية هي تسجيله. وإذا لم يُظهر شيئاً بينما يعلن النفق أنه يعمل، فالحزمة الخارجية تُسقط في مكان ما بين الطرفين، وهذا يعيدك إلى الاختبار لا إلى إعدادات الشيفرة.
سجّل ثلاثة أشياء في تذكرة التغيير قبل إغلاقها: الميزانية الخارجية المقيسة، والآلية التي اخترتها، والأمر الذي أثبت نجاة الحزمة الداخلية. سيحتاج الشخص التالي الذي يلمس هذا النفق إلى الثلاثة، ولا يمكن إعادة بناء أي منها من ملف التهيئة وحده.