VPN متصل لكن النقل الكبير يتوقف؛ افحص MTU

الموقف الحرج: تستطيع Ping للخادم عبر VPN وتفتح صفحة الدخول، لكن رفع ملف أو تحميل التطبيق كاملاً يتوقف. قد يناسب هذا النمط مشكلة حجم الحزمة، لكنه لا يثبت أن MTU هو السبب؛ فقدان الحزم وقيود المسار والتطبيق نفسه احتمالات أيضاً.

اختيار اختبار قابل للتكرار

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

فحص أولي على Windows وIPv4

يستخدم المثال عنواناً مخصصاً للتوثيق، ولا يُفترض أن يجيب كما هو. استبدله بوجهة مصرح بها وتستجيب ضمن مسار النفق. خيار DF لهذا الاختبار خاص بـIPv4.

ping /4 /n 2 /f /l 1472 192.0.2.10
ping /4 /n 2 /f /l 1400 192.0.2.10
netsh interface ipv4 show subinterfaces

في IPv4 دون خيارات إضافية، نضيف عادةً 28 بايت من ترويسات IP وICMP لتحويل حجم بيانات Ping إلى حجم حزمة IP. لذلك تقابل بيانات بحجم 1472 بايت حزمة بحجم 1500 بايت؛ العدد 1472 نفسه ليس MTU.

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

حصر الإصلاح في المسار نفسه

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

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

معيار الإنقاذ تكرار النقل الحقيقي

اختبر الملف والطلب ومسار الذهاب والعودة نفسيهما عدة مرات. نجاح Ping أو نقل قصير لا يكفي. أوصي بالاحتفاظ بسيناريو نقل صغير لكل نفق مهم ليبقى الاختبار قابلاً للتكرار بعد تغيير المزود أو المعدات.

قرار الإنقاذ: قِس حجم الحزمة؛ اتصال VPN لا يثبت سلامة مسار البيانات.

المراجع الفنية: Microsoft / Ping · RFC / PMTUD.