Git يتوقف دون VPN؟ OpenSSH يوسم الحزم بـIPQoS

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

اقرأ العَرَض كفرق في التوجيه

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

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

العميل يضع بايت QoS على كل مقبس SSH

كل اتصال OpenSSH من 7.8 فصاعدًا يحمل قيمة في ترويسة IP قد يستخدمها الموجهون لإعطاء الأولوية للحركة. جلسات الطرفية تأخذ قيمة والنسخ الكبيرة تأخذ أخرى، على نظرية أن الإنسان الذي يكتب يستحق معاملة أفضل من نقل ملف. معظم الشبكات تتجاهل التلميح تمامًا، ولهذا يمر دون ملاحظة لسنوات. أقلية من برامج تشغيل Wi-Fi وشركات الاتصال المتنقلة ومركزات VPN تتصرف بناءً عليه، وبعضها يتصرف بشكل سيئ.

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

أكّد إصدار العميل أولًا بالأمر ssh -V. أي إصدار عند 7.8 أو أعلى يحمل هذا السلوك افتراضيًا.

ثلاثة أوامر تفصل هذا عن MTU وDNS

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

ssh -o IPQoS=none -v [email protected]
ssh -G [email protected] | grep -i ipqos
sudo tcpdump -ni any -vv "tcp port 22"

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

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

ضع الاستثناء في ملف واحد، ومضيفًا واحدًا في كل مرة

الاستثناء يجب أن يكون بجوار المضيف الذي ينطبق عليه، مع تعليق يوضح سبب وجوده.

Host gitlab.example.internal
    IPQoS none
    # direct route rewrites the marking; the tunnel route passes it

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

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

أغلق الحلقة مع مالك الشبكة

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

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

تغيير العميل حل مؤقت له تاريخ انتهاء. اكتب ذلك التاريخ في التعليق.