OpenVPN mssfix: لماذا يتوقف عميل واحد في عمليات النقل الكبيرة

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

ما الذي يعيد الخيار كتابته

يعدّل mssfix الحد الأقصى لحجم المقطع المعلن في مصافحات TCP التي تمر عبر النفق، حتى يختار الجانب المرسل مقاطع تناسب الميزانية المغلفة. وهو يعمل على المصافحة، ما يعني أن الاتصال الذي فُتح قبل التغيير يحتفظ بالقيمة التي تفاوض عليها.

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

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

النطاق هو TCP داخل النفق

لا يُعاد كتابة سوى حركة TCP. جلسة QUIC أو لعبة أو تطبيق يرسل مخططات UDP كبيرة سيحتفظ بأحجام حزمه، وإذا كانت تلك هي عمليات النقل المتوقفة، فإن الإصلاح يقع عند MTU النفق أو المسار بدلًا من ذلك. اقرأ البروتوكول الذي تستخدمه العملية الفاشلة قبل اللجوء إلى خيار TCP، لأن الطبقة الخاطئة لها إصلاحها الخاص.

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

الرقم والكلمة المفتاحية غير قابلين للنقل

يقبل إصدار المجتمع من OpenVPN 2.6 كلمة مفتاحية اختيارية بعد القيمة. مع mtu، يصف الرقم حجم الحزمة الخارجية بما يشمل ترويسات IP وUDP؛ ومن دونه، يتبع الوسيط اصطلاحًا حسابيًا مختلفًا. لذلك فإن سطرًا منسوخًا بين الإصدارات لا يصف الميزانية نفسها للحزم. راجع صفحة الدليل التي تُشحن مع البنية التي تشغّلها فعلًا بدلًا من درس تعليمي لإصدار آخر.

تبدو الصيغة هكذا:

mssfix 1400 mtu

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

تأكّد على العميل الواحد أولًا

قِس المسار من الجهاز الفاشل قبل تغيير أي شيء. الحمولة التي يستطيع المسار حملها دون تجزئة هي الرقم الذي تبحث عنه:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

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

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