SSH يتجمّد عبر OpenVPN؟ قِس وحدة نقل المسار أولًا

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

اقرأ شكل الفشل قبل أن تلمس الملف الشخصي

الحزم الصغيرة تمرّ والكاملة لا. سطر الأوامر أو لافتة أو ضغطة مفتاح واحدة تتسع بسهولة؛ أما قائمة مجلد أو تنزيل أو كتلة مُلصقة فلا. الحجم الذي يتغيّر عنده السلوك هو الدليل، لا كون SSH هو البرنامج المعني.

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

قِس السقف من الجانبين

قارن وحدة نقل النفق بالرابط الفيزيائي قبل أن تغيّر أيًّا منهما. النفق الذي نسخ القيمة الفيزيائية أخبرك بالفعل أين يقع التعارض.

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

ip link show tun0
ping -M do -s 1380 10.9.0.1

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

mssfix وfragment يقومان بمهمتين مختلفتين

mssfix يقيّد حجم المقطع الذي تعلنه اتصالات TCP داخل النفق أثناء المصافحة. وهو الرافعة الصحيحة لـ SSH وHTTPS ونسخ الملفات، ولهذا يزول التعليق غالبًا بمجرد ضبطه. وهو لا يمسّ حمولات UDP إطلاقًا.

النفق الذي يحمل أيضًا خدمة UDP قد يظل يفشل بعد إصلاح SSH، وتلك النتيجة تربك كل من يفترض أن خيارًا واحدًا يغطي كل شيء.

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

خفض وحدة نقل الواجهة هو الخيار الفظّ

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

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

أعد الاختبار بالنقل الذي تجمّد

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

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