انقطاع VPN أثناء عمليات الرفع الكبيرة: اقرأ قائمة الانتظار أولاً

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

غيّر متغيراً واحداً في كل تشغيل، وأبقِ نقطة النهاية ثابتة.

بناء مقارنة حمل قابلة للتكرار

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

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

احفظ الخرج مع الطوابع الزمنية حتى يمكن مقارنة التشغيلين المحمّل والخامل سطراً بسطر.

اقرأ قائمة الانتظار، لا السرعة

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

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

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

افحص الجهاز ومسار التحكم

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

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

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

غيّر شيئاً واحداً وأعد التجربة

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

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

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