Git macet di WSL2 lewat VPN: MTU antarmuka atau jalur?

Klon mengautentikasi, jumlah objek muncul, lalu tidak ada yang bergerak selama beberapa menit. Windows melaporkan VPN tersambung, nama host terurai, dan peramban di mesin yang sama mengambil halaman repositori yang sama tanpa kesulitan. Kombinasi itu menunjuk ke ukuran paket, bukan kredensial, dan pertanyaan ukuran harus diajukan di dua tempat karena WSL2 punya antarmuka Linux sendiri dengan MTU sendiri. Satu angka milik sisi Windows dari jalur, yang lain milik distribusi, dan hanya membaca adaptor VPN membuat separuh jalur tidak diperiksa.

Tiga tanda memisahkan masalah ukuran dari hal lain

Tanda pertama adalah bentuk: penyiapan koneksi dan pertukaran kecil berhasil, lalu transfer besar berhenti maju. Kedua adalah simetri: repositori dan transport yang sama gagal sementara host lain di jalur yang sama berfungsi, atau kegagalan berubah dengan ukuran muatan, bukan dengan waktu hari. Ketiga adalah kesenyapan: tidak ada galat autentikasi, tidak ada penolakan proksi, tidak ada kegagalan resolusi nama, hanya transfer yang tidak pernah selesai.

Ketiganya bersama membenarkan hipotesis ukuran paket. Kegagalan DNS, token kedaluwarsa, kunci SSH ditolak, dan proksi yang menolak CONNECT masing-masing menghasilkan galatnya sendiri, dan tak satu pun tampak seperti macet setelah berhasil. Mempertahankan repositori, transport, dan jendela waktu yang sama saat menguji itulah yang membuat perbandingan jujur.

Bandingkan kedua antarmuka sebelum memutuskan

Kumpulkan tampilan Windows dan tampilan Linux dalam sesi yang sama, dan pegang alamat repositori alih-alih menebak antarmuka mana yang membawanya. Perintah di bawah ini mengurai tujuan terlebih dahulu agar pencarian rute menggambarkan server sebenarnya yang dihubungi klon, yang mungkin berbeda dari nama yang ditampilkan peramban. Jalankan kedua bagian berdekatan, karena VPN dapat mengubah metrik antarmuka antarpercobaan.

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"'

Jalankan bagian Linux di dalam distribusi alih-alih menempelkan keluarannya ke shell Windows, karena nama antarmuka dan pemilihan rute hanya bermakna di sana. Tempelan dari shell Windows melaporkan angka yang salah dengan sangat percaya diri. Catat perangkat, rute terpilih, dan MTU dari tiap sisi sebelum mengubah apa pun.

Putuskan apakah angkanya harus lebih kecil

MTU antarmuka yang lebih besar daripada yang bisa dibawa jalur bukan otomatis cacat, karena penemuan MTU jalur ada justru untuk itu. Mode kegagalan muncul ketika penemuan ditekan: pesan ICMP disaring di suatu tempat di jalur, pengirim tidak pernah mengetahui batasnya, dan paket besar menghilang sementara yang kecil berhasil. Itu sifat jalur, bukan sifat Git. Itu juga alasan berkas kecil bisa berhasil pada koneksi tempat berkas besar tidak pernah selesai.

Jika buktinya mendukung, perubahan sementara pada antarmuka Linux adalah uji termurah. Pilih nilai di bawah ukuran jalur yang dapat digunakan, catat nilai sebelumnya, dan jaga semua hal lain tetap agar perbandingannya bermakna. Jika transfer selesai pada nilai yang lebih kecil, Anda punya diagnosis, bukan kebetulan.

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

Putuskan di mana pengaturan harus hidup

Tiga opsi menyusul dari uji itu, dan biasanya hanya satu yang tepat. Jika nilai yang lebih kecil memperbaiki transfer dan nilai itu benar-benar diperlukan untuk jaringan ini, pengaturan memerlukan pemilik siklus hidup: kait mulai di distribusi, konfigurasi jaringan yang dikelola platform, atau prosedur terdokumentasi. Jika nilainya tidak memperbaiki apa pun, kembalikan dan kembali ke pertanyaan transport, proksi, dan autentikasi.

Ada atau tidaknya kait mulai bergantung pada versi Windows dan WSL yang dipakai serta mode jaringan yang dikonfigurasi. Mencerminkan jaringan Windows dapat mengubah cara VPN berinteraksi dengan distribusi dengan cara yang lebih penting daripada penyesuaian MTU, jadi kenali modenya sebelum merancang solusi sementara untuknya. Nilai yang cocok untuk satu operator atau satu profil VPN bukan default untuk berikutnya.

Yang harus dihindari adalah penempatan yang menggoda: perintah jaringan berhak istimewa di berkas mulai setiap shell interaktif, atau sudo tanpa kata sandi untuk seluruh biner ip agar skrip bisa menjalankan satu baris. Keduanya mengubah diagnosis menjadi paparan permanen dan membuat masalah aslinya lebih sulit dilihat nanti.

Verifikasi setelah mulai bersih, lalu balikkan

Perubahan yang hanya bertahan sampai distribusi dimulai ulang bukan perbaikan. Mulai ulang distribusi, sambungkan VPN lagi, dan ulangi operasi Git semula alih-alih pengganti seperti ping atau permintaan HTTP kecil. Lalu pastikan antarmuka membawa nilai yang dimaksud pada sesi baru.

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

Simpan nilai asli yang tercatat di samping perubahan agar percobaan dapat dibatalkan dengan bersih, dan catat keluarga alamat mana yang diuji, karena hasil IPv4 tidak mengatakan apa pun tentang koneksi IPv6 pada host yang sama. Dokumentasi jaringan WSL menjelaskan mode yang menentukan seperti apa perbaikan seharusnya; angka MTU itu sendiri adalah pengukuran lokal, bukan rekomendasi.