يقول السطر PID_ERR replay-window backtrack occurred، وكل نتائج البحث تفسّره على أنه حزم مُسقَطة ونفق معطوب. في مسار UDP في Community OpenVPN 2.6، تُكتب تلك الرسالة بينما لا تزال دالة الاستقبال تقرّر ما ستفعله بالحزمة. إنها تسجّل حدًّا أقصى جديدًا للتراجع، ثم تفحص الدالة نفسها المسافة مقابل النافذة والحالة المسجّلة قبل أن تقبل أو ترفض. قراءة وسم السجل على أنه الحكم هي الخطأ الذي توجد هذه القائمة لمنعه.

المحطة الأولى: تحديد ما هو السطر

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

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

المحطة الثانية: العثور على نتيجة تلك الحزمة

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

journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"

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

المحطة الثالثة: تحديد ما إذا كانت إعادة الترتيب حقيقية

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

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

المحطة الرابعة: معاملات النافذة، وما ليست عليه

يأخذ replay-window حجم تسلسل وقيمة زمنية اختيارية، لذا فإن توسيعه يغيّر تحمّلين مختلفين في آن واحد. رفع الرقم يسمح بحزم أبعد عن الترتيب؛ أما القيمة الزمنية فتحدّ المدة التي يمكن أن تُعتبر فيها الحزمة. التوسيع تغيير سياسي له كلفة أمنية، وهو لا يقوّي شفرة ولا يعطّل كشف التكرار. يتحرك التحمّلان معًا شئت أم أبيت.

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

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

mute 20
replay-window 64 15

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

المحطة الخامسة: اختبار المسار الذي يهم المستخدم

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

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

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

مقالات ذات صلة