WSL2 tidak mewarisi VPN perusahaan, dan itulah bugnya

Wiki internal memuat di Edge, sementara git clone di dalam distribusi kehabisan waktu. Satu pengamatan itu biasanya dibaca sebagai «VPN memblokir WSL2», dan jam berikutnya habis untuk mengedit /etc/resolv.conf. Bacaan yang lebih berguna adalah WSL2 tidak pernah memiliki jalur jaringan host: ia berjalan di VM utilitas dengan adaptor sendiri, rute sendiri, dan file resolver yang dibuat Windows untuknya. Semua yang berikut bergantung pada mana dari ketiganya yang sebenarnya hilang.

VM punya tumpukan, metrik, dan resolver sendiri

Dalam mode NAT bawaan, distribusi berada di belakang switch virtual dan mencapai internet melalui host, tetapi tidak melihat adaptor host. ip addr menampilkan satu antarmuka dengan alamat privat, ip route menampilkan rute bawaan melalui switch itu, dan /etc/resolv.conf adalah file yang dihasilkan yang menunjuk ke stub resolver yang dipilih Windows. Tidak ada yang berubah karena klien VPN menyala di sisi Windows.

Itu sebabnya «browser berfungsi» membuktikan begitu sedikit. Browser memakai tumpukan host, tunnel, dan kebijakan resolver host. Shell Anda memakai tumpukan lain yang kebetulan berbagi kartu jaringan fisik. Keduanya sepakat dalam kasus baik dan berbeda justru ketika VPN memasang filter, menulis ulang daftar DNS, atau menambahkan rute untuk subnet switch virtual.

Dua uji menentukan di dunia mana Anda berada, dan keduanya harus dijalankan di dalam distribusi:

getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.conf

Nama gagal sementara alamat literal menjawab adalah masalah resolver. Nama dan alamat gagal bersamaan adalah masalah jalur, dan tidak ada penyuntingan resolver yang akan menyentuhnya. Bukti dari sisi Windows menyusul: Get-NetAdapter | Get-DnsClientServerAddress dan route print -4 menunjukkan apakah tunnel telah mengambil alih subnet tempat VM Anda tinggal.

Mitos pertama: server DNS perusahaan memperbaikinya

Mengedit file resolver adalah nasihat klasik, dan benar sekitar separuh waktu. Saat benar, alasannya spesifik: file yang dihasilkan menunjuk ke resolver yang hanya mengenal nama publik, jadi kueri untuk intranet.example.internal kembali sebagai tidak ada meskipun jalurnya baik.

Menyematkan server VPN berarti menghentikan Windows membuat ulang file, karena file apa pun yang Anda tulis manual diganti saat start berikutnya:

[network]
generateResolvConf = false

Simpan itu sebagai /etc/wsl.conf, jalankan wsl --shutdown dari Windows, lalu mulai distribusi dan tulis /etc/resolv.conf dengan server tunnel lebih dulu dan resolver publik hanya sebagai cadangan. Ini perubahan permanen dengan biaya pemeliharaan: file tidak lagi mengikuti host, jadi ketika alamat DNS perusahaan berubah, distribusi terus menanyakan yang lama. Seseorang harus memiliki file itu.

Ia juga tidak melakukan apa pun ketika kegagalannya lebih luas. Jika curl ke 1.1.1.1 kehabisan waktu, klien tunnel sedang memfilter switch virtual atau merutekan subnet VM ke tunnel, dan resolver yang benar hanya memberi nama yang tetap tidak bisa dijangkau.

Mitos kedua: perubahan metrik bertahan

Ketika nama terurai tetapi lalu lintas keluar melalui adaptor fisik, metrik antarmuka adalah tuasnya. Beri adaptor VPN biaya tinggi dan switch WSL biaya rendah:

Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1

Lalu ingat bahwa di banyak build klien adaptor tunnel dibuat ulang pada setiap koneksi dan metrik kembali ke bawaannya. Perintah sekali jalan adalah perbaikan yang kedaluwarsa diam-diam, biasanya selama akhir pekan, dan tiket kembali dengan «minggu lalu berfungsi». Tugas terjadwal yang dipicu peristiwa VPN, atau skrip yang dijalankan pengguna setelah terhubung, adalah versi jujur dari perbaikan ini.

Kedaluwarsa yang sama berlaku untuk rute host yang ditambahkan untuk satu prefiks keras kepala. Itu berharga sebagai diagnostik, karena memberi tahu apakah masalahnya satu tujuan atau seluruh jalur, tetapi itu bukan arsitektur.

Mitos ketiga: satu perbaikan mencakup setiap build Windows

wsl-vpnkit adalah pola sidecar: distribusi kecil memiliki jalur di sisi host dan meneruskan untuk distribusi lain melalui soket virtual, sehingga lalu lintas aplikasi berhenti bergantung pada switch yang difilter. Ia memerlukan jalur standar berfungsi, yang berarti menghapus penimpaan networkingMode dan dnsTunneling dari %UserProfile%\.wslconfig, memulihkan generateResolvConf = true di setiap distribusi yang berfungsi, dan memulai layanan saat login.

Mode cermin adalah alternatif bawaan di Windows 11 22H2 dan setelahnya, dan itu satu pengaturan plus satu shutdown:

[wsl2]
networkingMode=mirrored

Di dalam distribusi ip addr lalu mendaftar adaptor host, tunnel dapat muncul di antaranya, dan tunnel DNS meneruskan pencarian melalui resolver Windows bahkan ketika klien menulis ulang daftar DNS. Ini tidak universal: beberapa driver filter masih membuang jalur cermin, dan aturan firewall Hyper-V mungkin memerlukan izin eksplisit. Panduan jaringan WSL Microsoft adalah halaman yang harus dicocokkan dengan build Anda sebelum menerapkan resep yang ditulis untuk yang lebih baru.

Uji tiga hal setelah setiap perubahan

Pilih satu mekanisme per mesin dan tuliskan, karena keduanya bergabung dengan buruk. Sidecar di atas mode cermin menggandakan penerusan, dan host cermin dengan entri sidecar usang di .wslconfig cenderung gagal setelah peningkatan, bukan sebelumnya.

Apa pun pilihan Anda, uji penerimaan adalah tiga permintaan yang sama di dalam distribusi: nama internal, nama publik, dan alamat mentah. Lalu ulangi setelah memutus dan menyambung kembali tunnel, dan setelah wsl --shutdown. Hanya nama internal yang gagal berarti kebijakan resolver; nama internal dan publik gagal bersamaan dengan alamat yang berfungsi tetap berarti kebijakan resolver; semuanya gagal berarti jalur.

Jika satu host internal gagal sementara sisanya berfungsi, berhenti melihat resolver dan cari rute yang hilang untuk prefiks itu. Jika semuanya berfungsi sampai koneksi ulang berikutnya, Anda menemukan perbaikan yang bergantung pada keadaan runtime, dan itu harus diterapkan ulang secara otomatis atau diganti dengan salah satu dari dua mekanisme di atas.