خرافات MTU في VPN: لماذا تتقلص حزمك وأين تذهب المساحة

يقول لك أحدهم إن شبكة VPN «تفقد الحزم بسبب MTU»، فتُعين النفق على 1400، فيعود النقل إلى العمل. تبدو هذه النتيجة وكأنها تشخيص. لكنها في الغالب مصادفة حسابية: فقد اخترت رقمًا صغيرًا بما يكفي ليستقر تحت حدٍّ لم تحدده قط، وستلقى الحد نفسه مرة أخرى على الشبكة التالية بميزانية مختلفة.

خرافتان تسبّبان معظم هذا. الأولى أن MTU لواجهة النفق هو MTU المسار. الثانية أن التغليف يكلّف «ترويسة واحدة» وأن PPPoE لا يكلّف شيئًا يستحق الحساب. وكلتاهما خاطئة بطرق تجعل الرقم الذي تختاره يبدو اعتباطيًا بينما هو في الواقع محدَّد.

الخرافة الأولى: MTU النفق هو MTU المسار

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

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

الخرافة الثانية: التغليف يكلّف ترويسة واحدة

عُدّ الطبقات الخارجية بصدق. ترويسة IP الخارجية 20 بايت في IPv4 أو 40 في IPv6. ويضيف تغليف UDP لاختراق NAT مقدار 8 بايتات. ويضيف بروتوكول النفق ترويسته الخاصة، ومتجه تهيئة أو nonce، وحشوًا حتى حد الكتلة أو المحاذاة للشيفرة، ومقطعًا ختاميًا، وقيمة تحقق من السلامة. وبحسب البروتوكول والشيفرة، يقع المجموع بأريحية في العشرات من البايتات قبل أن تبدأ الحزمة الداخلية أصلًا.

ثم اطرح مرة أخرى ترويسات الحزمة الداخلية نفسها. مقطع TCP داخل النفق يحمل ترويسة IP خاصة به من 20 بايت وترويسة TCP من 20 بايت، ويُشتق MSS في TCP من MTU، لا من الحمولة الاسمية للنفق. لهذا قد ينجح ping بحمولة أصغر بينما يتوقف نقل ملف: الأداتان تختبران أشياء مختلفة، وواحدة فقط منهما تمارس مقطع TCP كامل الحجم.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

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

الخرافة الثالثة: PPPoE لا يزال يمنحك 1500 نظيفًا

وصلة وصول PPPoE التقليدية لا تحمل حزمة IP من 1500 بايت. فترويسة PPPoE مع حقل بروتوكول PPP تستهلك 8 بايت داخل إطار Ethernet، ما يترك 1492 لحزمة IP. هذا هو الحد التقليدي الموصوف في RFC 2516. وإذا شغّلت VPN فوق وصلة كهذه، فإن أعباء النفق تُخصم من 1492 تلك، لا من 1500.

يعرّف RFC 4638 طريقة للتفاوض على حمولة PPP أكبر عندما يدعمها كل من مجمّع الوصول وتجهيز العميل، ولهذا فإن عبارة «هذا الاتصال يستخدم PPPoE» وحدها لا تثبت رقمًا محددًا. لا يستطيع إعداد محلي أن يجعل جهازًا وسيطًا يقبل حزمة لم يُضبط لها قط، لذا فالسؤال المفيد هو ما الذي تفاوضت عليه الوصلة فعلًا، لا ما يقوله الملصق.

لماذا يبدو العطل انتقائيًا

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

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

ما الذي تغيّره، وبأي ترتيب

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

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