لماذا يتوقف VPN عند النقل الكبير وليس عند الصغير

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

ثلاثة أعداد يسميها الناس MTU

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

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

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

اختبر المسار بحمولة تتحكم بها

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

ping -M do -s 1372 -c 2 203.0.113.20
ping -4 -f -l 1372 vpn.example

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

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

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

ضبط MSS لا يساعد إلا TCP

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

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ip link show tun0

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

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

OpenVPN يتيح خيارات مثل tun-mtu و mssfix وإعدادات متعلقة بالتجزئة، وسلوكها يعتمد على الإصدار وعلى ما إذا كانت قناة البيانات AEAD. اقرأ الدليل الخاص بالإصدار المستخدم، وغيّر خيارًا واحدًا في كل مرة.

غيّر إعدادًا واحدًا مدعومًا وأعد تشغيل الاختبارين

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

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

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