اكتشاف MTU المسار عبر VPN: تحديد الحجم وفجوة ICMP

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

ما الذي يقيسه MTU المسار فعليًا

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

بالنسبة إلى النفق، الرقم المهم هو MTU الداخلي، أي سماح المسار الخارجي ناقص ما يستهلكه التغليف. يضيف WireGuard ترويسة IP خارجية وترويسة UDP؛ وتضيف وسائل نقل أخرى ترويساتها. اضبط الحجم الداخلي مرتفعًا جدًا فتحتاج كل حزمة بالحجم الكامل إلى تجزئة قد لا تحدث أبدًا.

لماذا يقلّص النفق الحزمة القابلة للاستخدام

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

النتيجة العملية حجم يناسب المصافحة ولا يناسب الحمولة. رسالة TLS ClientHello أو استعلام DNS صغيرة بما يكفي لعبور مسار متقلّص دون تأثر، بينما النقل الكبير ليس كذلك. لذلك تتجمّع الأعراض حول عمليات محددة بدلًا من مضيفين محددين.

الاكتشاف لا يعمل إلا عندما تصل التغذية الراجعة

يعتمد اكتشاف IPv4 على بت عدم التجزئة: الموجّه الذي لا يستطيع تمرير الحزمة يعيد ICMP fragmentation-needed مع MTU القفزة التالية، فيخفض المرسل تقديره. ويستخدم IPv6 رسائل Packet Too Big بدلًا من ذلك، لأن الموجّهات لا تجزئ أثناء العبور. تفترض الآليتان أن الرسالة تجد طريقها عائدة إلى المرسل، عبر النفق وعبر أي جدار حماية على مسار العودة. وعندما يفشل هذا الافتراض، يظل المرسل يعيد محاولة حجم لا يستطيع المسار حمله.

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

قد تقع التصفية نفسها داخل النفق. إذا أسقط المسار الداخلي الخطأ بينما يحمله المسار الخارجي، فقد يتكيّف المرسل مع حدّ لا تراه حركة المرور المغلّفة فعليًا أبدًا.

اختبر المسار بدلًا من تخمين رقم

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

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

الـ ping الذي يمرّ لا يثبت أن مقاطع التطبيق الحقيقية بالحجم الكامل تمرّ، لذا كرّر الاختبار مع النقل الذي فشل فعليًا. قارن أكبر مسبار ناجح بـ MTU النفق الذي ضبطته، واحتفظ بالرقمين منفصلين في ملاحظاتك. إذا اختلفا بمقدار ترويسة تقريبًا، فقد وجدت عبء التغليف لا خللًا.

يستكشف PLPMTUD، الموصوف في RFC 4821، صاعدًا ويستخدم إقرارات النقل بدلًا من الثقة بالأخطاء المُسلَّمة. يساعد على المسارات التي تصفّي ICMP، لكن الدعم يختلف حسب الحزمة البرمجية والتطبيق. قد يتعافى تدفق TCP من تلقاء نفسه بينما يستمر تطبيق UDP بحجم مخطط بيانات ثابت في الفشل.

اختر قيمة وسجّل سببها

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

آلية IPv4 موصوفة في RFC 1191 وإرشادات تحزيم IPv6 في RFC 8201؛ وتسمية الاثنين تمنع المهندس التالي من إعادة استنتاج الافتراض. إذا استمر النقل في التعثّر عند الحجم الذي اخترته، فتوقف عن خفض الرقم وانظر إلى الطبقة التالية. المسار الذي يفشل عند كل حجم ليس مشكلة MTU.