Git در WSL2 روی VPN متوقف می‌شود: MTU رابط یا مسیر؟

کلون احراز هویت می‌کند، تعداد اشیا ظاهر می‌شود و سپس چند دقیقه هیچ چیز حرکت نمی‌کند. ویندوز VPN را متصل گزارش می‌کند، نام میزبان حل می‌شود و مرورگری روی همان ماشین همان صفحه مخزن را بدون دشواری می‌گیرد. این ترکیب به اندازه بسته اشاره می‌کند نه به اعتبارنامه‌ها، و پرسش اندازه باید در دو جا مطرح شود چون WSL2 رابط Linux خودش را با MTU خودش دارد. یکی از اعداد به سمت ویندوز مسیر تعلق دارد، دیگری به توزیع، و خواندن فقط آداپتور VPN نیمی از مسیر را بررسی‌نشده می‌گذارد.

سه نشانه مسئله اندازه را از چیز دیگری جدا می‌کند

نشانه اول شکل است: برقراری اتصال و تبادل کوچک موفق می‌شوند، سپس انتقال انبوه از پیشرفت بازمی‌ماند. دومی تقارن است: همان مخزن و همان انتقال شکست می‌خورند در حالی که میزبان دیگری روی همان مسیر کار می‌کند، یا شکست با اندازه بار مفید تغییر می‌کند نه با ساعت روز. سومی سکوت است: هیچ خطای احراز هویت، هیچ رد پروکسی، هیچ شکست حل نام، فقط انتقالی که هرگز کامل نمی‌شود.

این سه با هم فرضیه اندازه بسته را توجیه می‌کنند. شکست DNS، توکن منقضی، کلید SSH ردشده و پروکسی‌ای که CONNECT را رد می‌کند هر یک خطای خودشان را تولید می‌کنند و هیچ‌کدام شبیه توقف پس از موفقیت نیستند. حفظ همان مخزن، انتقال و بازه زمانی در هنگام آزمایش همان چیزی است که مقایسه را صادقانه می‌کند.

پیش از تصمیم، هر دو رابط را مقایسه کنید

نمای ویندوز و نمای 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 را درون توزیع اجرا کنید نه اینکه خروجی را در پوسته ویندوز بچسبانید، چون نام‌های رابط و انتخاب مسیر فقط آنجا معنا دارند. چسباندن از پوسته ویندوز اعداد اشتباه را با اطمینان زیاد گزارش می‌کند. پیش از تغییر هر چیزی، دستگاه، مسیر انتخاب‌شده و 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

تصمیم بگیرید که تنظیم کجا باید زندگی کند

سه گزینه از آزمایش نتیجه می‌شود و معمولاً فقط یکی از آن‌ها مناسب است. اگر مقدار کوچک‌تر انتقال را درست کند و مقدار واقعاً برای این شبکه لازم باشد، تنظیم به صاحب چرخه عمر نیاز دارد: قلاب راه‌اندازی در توزیع، پیکربندی شبکه‌ای که پلتفرم مدیریت می‌کند، یا رویه مستند. اگر مقدار چیزی را درست نمی‌کند، آن را برگردانید و به پرسش‌های انتقال، پروکسی و احراز هویت بازگردید.

وجود قلاب راه‌اندازی به نسخه‌های ویندوز و WSL در استفاده و به حالت شبکه پیکربندی‌شده بستگی دارد. آینه‌کردن شبکه ویندوز می‌تواند نحوه تعامل 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 اندازه‌گیری محلی است، نه توصیه.