Git tersekat dalam WSL2 melalui VPN: MTU antara muka atau laluan?

Klon mengesahkan, bilangan objek muncul, dan kemudian tiada apa bergerak selama beberapa minit. Windows melaporkan VPN disambungkan, nama hos diselesaikan, dan pelayar pada mesin yang sama mengambil halaman repositori yang sama tanpa kesukaran. Gabungan itu menunjuk kepada saiz paket dan bukan kelayakan, dan soalan saiz mesti diajukan di dua tempat kerana WSL2 mempunyai antara muka Linux sendiri dengan MTU sendiri. Satu nombor milik bahagian Windows laluan itu, satu lagi milik distribusi, dan membaca penyesuai VPN sahaja meninggalkan separuh laluan tidak diperiksa.

Tiga isyarat memisahkan masalah saiz daripada yang lain

Isyarat pertama ialah bentuk: penyediaan sambungan dan pertukaran kecil berjaya, kemudian pemindahan pukal berhenti maju. Kedua ialah simetri: repositori dan pengangkutan yang sama gagal manakala hos lain pada laluan yang sama berfungsi, atau kegagalan berubah dengan saiz muatan dan bukan dengan waktu hari. Ketiga ialah kesenyapan: tiada ralat pengesahan, tiada penolakan proksi, tiada kegagalan penyelesaian nama, hanya pemindahan yang tidak pernah selesai.

Ketiga-tiganya bersama mewajarkan hipotesis saiz paket. Kegagalan DNS, token tamat tempoh, kunci SSH ditolak dan proksi yang menolak CONNECT masing-masing menghasilkan ralat sendiri, dan tiada satu pun kelihatan seperti terhenti selepas berjaya. Mengekalkan repositori, pengangkutan dan tetingkap masa yang sama semasa menguji itulah yang menjadikan perbandingan jujur.

Bandingkan kedua-dua antara muka sebelum membuat keputusan

Kumpulkan pandangan Windows dan pandangan Linux dalam sesi yang sama, dan pegang alamat repositori daripada meneka antara muka mana yang membawanya. Perintah di bawah menyelesaikan destinasi terlebih dahulu supaya carian laluan menerangkan pelayan sebenar yang dihubungi klon, yang mungkin berbeza daripada nama yang ditunjukkan pelayar. Jalankan kedua-dua bahagian berdekatan, kerana VPN boleh mengubah metrik antara muka antara percubaan.

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 bahagian Linux di dalam distribusi dan bukan menampal output ke dalam shell Windows, kerana nama antara muka dan pemilihan laluan hanya bermakna di sana. Tampalan daripada shell Windows melaporkan nombor yang salah dengan penuh keyakinan. Catat peranti, laluan terpilih dan MTU dari setiap sisi sebelum menukar apa-apa.

Putuskan sama ada nombor itu patut lebih kecil

MTU antara muka yang lebih besar daripada yang boleh dibawa laluan bukanlah kecacatan automatik, kerana penemuan MTU laluan wujud khusus untuk itu. Mod kegagalan muncul apabila penemuan ditindas: mesej ICMP ditapis di suatu tempat di sepanjang laluan, penghantar tidak pernah mengetahui hadnya, dan paket besar hilang manakala yang kecil berjaya. Itu sifat laluan, bukan sifat Git. Itu juga sebab fail kecil boleh berjaya pada sambungan di mana fail besar tidak pernah selesai.

Jika bukti menyokongnya, perubahan sementara pada antara muka Linux ialah ujian paling murah. Pilih nilai di bawah saiz laluan yang boleh digunakan, catat nilai sebelumnya, dan kekalkan segala-galanya supaya perbandingan bermakna. Jika pemindahan selesai pada nilai yang lebih kecil, anda mempunyai diagnosis dan 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 tetapan harus tinggal

Tiga pilihan menyusuli daripada ujian itu, dan biasanya hanya satu yang sesuai. Jika nilai yang lebih kecil membaiki pemindahan dan nilai itu benar-benar diperlukan untuk rangkaian ini, tetapan memerlukan pemilik kitaran hayat: cangkuk permulaan dalam distribusi, konfigurasi rangkaian yang diuruskan platform, atau prosedur terdokumen. Jika nilai itu tidak membaiki apa-apa, kembalikannya dan kembali kepada soalan pengangkutan, proksi dan pengesahan.

Sama ada cangkuk permulaan wujud bergantung pada versi Windows dan WSL yang digunakan serta mod rangkaian yang dikonfigurasi. Mencerminkan rangkaian Windows boleh mengubah cara VPN berinteraksi dengan distribusi dengan cara yang lebih penting daripada pelarasan MTU, jadi kenal pasti mod itu sebelum merancang penyelesaian sementara untuknya. Nilai yang sesuai untuk satu pengendali atau satu profil VPN bukan lalai untuk yang seterusnya.

Apa yang perlu dielakkan ialah penempatan yang menggoda: perintah rangkaian istimewa dalam fail permulaan setiap shell interaktif, atau sudo tanpa kata laluan untuk keseluruhan binari ip supaya skrip boleh menjalankan satu baris. Kedua-duanya mengubah diagnosis menjadi pendedahan kekal dan menjadikan masalah asal lebih sukar dilihat kemudian.

Sahkan selepas permulaan bersih, kemudian balikkan

Perubahan yang hanya bertahan sehingga distribusi dimulakan semula bukan pembaikan. Mulakan semula distribusi, sambung semula VPN, dan ulangi operasi Git asal dan bukan pengganti seperti ping atau permintaan HTTP kecil. Kemudian sahkan bahawa antara muka membawa nilai yang dimaksudkan dalam sesi baharu.

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

Simpan nilai asal yang direkodkan di sebelah perubahan supaya eksperimen boleh dibatalkan dengan bersih, dan catat keluarga alamat mana yang diuji, kerana keputusan IPv4 tidak memberitahu apa-apa tentang sambungan IPv6 pada hos yang sama. Dokumentasi rangkaian WSL menerangkan mod yang menentukan bagaimana pembaikan sepatutnya kelihatan; nombor MTU itu sendiri ialah ukuran setempat, bukan cadangan.