توقّف Git في WSL2 عبر VPN: هل المشكلة في MTU الواجهة أم في المسار؟

تتم المصادقة على الاستنساخ، ويظهر عدد الكائنات، ثم لا يتحرك شيء لدقائق. يُبلغ Windows بأن VPN متصل، ويُحلّ اسم المضيف، ويجلب متصفح على الجهاز نفسه صفحة المستودع نفسها دون صعوبة. تشير هذه التركيبة إلى حجم الحزم لا إلى بيانات الاعتماد، ويجب طرح سؤال الحجم في مكانين لأن WSL2 لديه واجهة Linux خاصة به وبـ MTU خاص بها. أحد الرقمين يخص جانب Windows من المسار، والآخر يخص التوزيعة، وقراءة مهايئ VPN وحده تترك نصف المسار دون فحص.

ثلاث إشارات تفصل مشكلة الحجم عن غيرها

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

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

قارن الواجهتين قبل أن تقرر

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

netsh interface ipv4 show subinterfaces
wsl -d Ubuntu -- bash -lc 'dest=$(getent ahostsv4 github.com | awk \'NR==1{print $1}\'); ip -br link show; ip route get "$dest"'

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

قرّر ما إذا كان الرقم ينبغي أن يكون أصغر

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

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

ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0

حدّد أين يجب أن يقيم الإعداد

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

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

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

تحقّق بعد بداية جديدة، ثم اعكس التغيير

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

ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"

أبقِ القيمة الأصلية المسجلة بجوار التغيير كي يمكن التراجع عن التجربة بنظافة، وسجّل أي عائلة عناوين اختُبرت، لأن نتيجة IPv4 لا تقول شيئًا عن اتصال IPv6 على المضيف نفسه. توثّق وثائق شبكات WSL الأنماط التي تحدد شكل الإصلاح؛ ورقم MTU نفسه قياس محلي، لا توصية.