OpenVPN عبر PPPoE: هل تخفض link-mtu أم tun-mtu أم mssfix؟

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

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

ثلاثة مقابض، ثلاث طبقات مختلفة

link-mtu هو الميزانية الخارجية: الحمولة المشفرة زائد رأس OpenVPN ورأس UDP ورأس IP الخارجي. يصف ما يغادر الجهاز، ولهذا هو الرقم الذي يقيّده المسار الفيزيائي.

tun-mtu هو الميزانية الداخلية: الواجهة التي يراها مرورك. إنه أكبر مما يستطيع المسار حمله بمقدار الحمل الزائد للنفق بالضبط، و OpenVPN عادةً يشتقه بدلًا من أن يجعلك تضبطه.

mssfix آلية مختلفة تمامًا. يعيد كتابة الحد الأقصى لحجم المقطع المُعلن أثناء مصافحات TCP، ليختار نظراء TCP مقاطع تناسب بعد التغليف. لا يغيّر واجهة MTU، وليس له أي تأثير على UDP.

إذا ضبطت link-mtu صراحةً، يطرح OpenVPN حمله الزائد الخاص لاشتقاق MTU الداخلي. ذلك الحمل ليس ثابتًا؛ بل يعتمد على التشفير والمصادقة، ولهذا فإن قيمة منسوخة من منشور منتدى قد تكون خاطئة على ملف تعريف مختلف. ضبط link-mtu و tun-mtu معًا يمنح العميل تعليمين متناقضين.

قِس المسار قبل اختيار أي رقم

قِس من الواجهة الفيزيائية، لا من داخل النفق، وتذكّر أن ping يبلّغ عن الحمولة، لا عن حجم الحزمة. أضف 28 بايت لرؤوس IPv4 وICMP قبل مقارنة الحمولة بإطار من 1500 بايت، واحتفظ بهذا التصحيح في ذهنك عندما يبلّغ نظير برقم مختلف.

على عميل Linux، يمنع ping -M do -s 1472 التجزئة ويفشل إذا كانت الحزمة كبيرة جدًا. خفّض الحمولة حتى تنجح، ثم أضف 28 للحصول على MTU المسار. تكلّف PPPoE 8 بايتات، لذا 1492 طبيعي على DSL. تكلّف DS-Lite وبعض المسارات المتنقلة 40 أو أكثر، والجواب عادةً أقل مما يوحي به معدل الوصلة الاسمي.

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

اقصر TCP أولًا، وقلّص النفق ثانيًا

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

خفّض MTU الداخلي عندما لا يكون المرور المتأثر TCP. خدمة UDP، أو نفق داخل نفق، أو تطبيق يرسل مخططات بيانات بالحجم الكامل، ستظل تفشل بعد قصر MSS لأن شيئًا لا يعيد كتابة حجم حزمتها. قلّل tun-mtu في تلك الحالة، أو اضبط link-mtu ودع العميل يشتق القيمة الداخلية، لكن لا تفعل الاثنين معًا أبدًا.

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

لماذا تظل الفحوصات الصغيرة تعمل

استعلامات DNS وصدى ICMP ومصافحات TCP كلها أقل بكثير من الحجم الذي يفشل. لذلك يبدو النفق سليمًا في كل اختبار سريع بينما تفشل مصافحات TLS واستجابات HTTP بهدوء. هذا المزيج، traceroute يعمل ومتصفح يتعطل عند أول استجابة كبيرة، هو البصمة التي يجب البحث عنها. الجأ إلى فحص بالحجم الكامل قبل أن تلجأ إلى ملف تعريف جديد.

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

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