WSL2 tidak mewarisi VPN korporat, dan itulah pepijatnya

Wiki dalaman dimuatkan dalam Edge, manakala git clone di dalam distribusi tamat masa. Pemerhatian tunggal itu biasanya dibaca sebagai «VPN menyekat WSL2», dan jam berikutnya pergi kepada mengedit /etc/resolv.conf. Bacaan yang lebih berguna ialah WSL2 tidak pernah mempunyai laluan rangkaian hos: ia berjalan dalam VM utiliti dengan penyesuai sendiri, laluan sendiri dan fail resolver yang dijana Windows untuknya. Semua yang berikut bergantung pada yang mana antara ketiga-tiganya sebenarnya tiada pada anda.

VM mempunyai tindanan, metrik dan resolver sendiri

Dalam mod NAT lalai, distribusi berada di belakang suis maya dan mencapai internet melalui hos, tetapi tidak melihat penyesuai hos. ip addr menunjukkan satu antara muka dengan alamat peribadi, ip route menunjukkan laluan lalai melalui suis itu, dan /etc/resolv.conf ialah fail yang dijana yang menunjuk kepada stub resolver yang dipilih Windows. Tiada satu pun daripada itu berubah kerana klien VPN dimulakan di sebelah Windows.

Itulah sebabnya «pelayar berfungsi» membuktikan begitu sedikit. Pelayar menggunakan tindanan hos, terowong dan dasar resolver hos. Shell anda menggunakan tindanan lain yang kebetulan berkongsi kad rangkaian fizikal. Kedua-duanya bersetuju dalam kes baik dan berbeza tepat apabila VPN memasang penapis, menulis semula senarai DNS atau menambah laluan untuk subnet suis maya.

Dua ujian menentukan dunia mana anda berada, dan kedua-duanya mesti 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 ialah masalah resolver. Nama dan alamat gagal bersama ialah masalah laluan, dan tiada pengeditan resolver akan menyentuhnya. Bukti dari sebelah Windows menyusul: Get-NetAdapter | Get-DnsClientServerAddress dan route print -4 menunjukkan sama ada terowong telah mengambil alih subnet tempat VM anda tinggal.

Mitos pertama: pelayan DNS korporat membetulkannya

Mengedit fail resolver ialah nasihat klasik, dan ia betul kira-kira separuh masa. Apabila betul, ia betul atas sebab tertentu: fail yang dijana menunjuk kepada resolver yang hanya mengenal nama awam, jadi pertanyaan untuk intranet.example.internal kembali sebagai tidak wujud walaupun laluan itu elok.

Menyemat pelayan VPN bermakna menghentikan Windows daripada menjana semula fail, kerana apa-apa fail yang anda tulis dengan tangan diganti pada permulaan seterusnya:

[network]
generateResolvConf = false

Simpan itu sebagai /etc/wsl.conf, jalankan wsl --shutdown daripada Windows, kemudian mulakan distribusi dan tulis /etc/resolv.conf dengan pelayan terowong dahulu dan resolver awam hanya sebagai sandaran. Ini perubahan kekal dengan kos penyelenggaraan: fail itu tidak lagi mengikut hos, jadi apabila alamat DNS korporat berubah distribusi terus bertanya yang lama. Seseorang mesti memiliki fail itu.

Ia juga tidak melakukan apa-apa apabila kegagalan lebih luas. Jika curl ke 1.1.1.1 tamat masa, klien terowong sedang menapis suis maya atau menghalakan subnet VM ke dalam terowong, dan resolver yang betul hanya memberi nama yang masih tidak dapat dicapai.

Mitos kedua: perubahan metrik kekal

Apabila nama diselesaikan tetapi trafik keluar melalui penyesuai fizikal, tuasnya ialah metrik antara muka. Beri penyesuai VPN kos tinggi dan suis WSL kos rendah:

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

Kemudian ingat bahawa dalam banyak binaan klien penyesuai terowong dicipta semula pada setiap sambungan dan metrik kembali kepada lalai. Perintah sekali jalan ialah pembetulan yang tamat tempoh secara senyap, biasanya sepanjang hujung minggu, dan tiket kembali dengan «minggu lepas ia berfungsi». Tugas berjadual yang dicetuskan oleh peristiwa VPN, atau skrip yang dijalankan pengguna selepas menyambung, ialah versi jujur pembetulan ini.

Tamat tempoh yang sama terpakai kepada laluan hos yang ditambah untuk satu awalan degil. Ia berharga sebagai diagnostik, kerana memberitahu sama ada masalah itu satu destinasi atau seluruh laluan, tetapi ia bukan seni bina.

Mitos ketiga: satu pembetulan meliputi setiap binaan Windows

wsl-vpnkit ialah corak sidecar: distribusi kecil memiliki laluan di sebelah hos dan memajukan untuk distribusi lain melalui soket maya, jadi trafik aplikasi berhenti bergantung pada suis yang ditapis. Ia memerlukan laluan standard berfungsi, iaitu membuang pengatasan networkingMode dan dnsTunneling daripada %UserProfile%\.wslconfig, memulihkan generateResolvConf = true dalam setiap distribusi yang berfungsi dan memulakan perkhidmatan semasa log masuk.

Mod cermin ialah alternatif terbina dalam pada Windows 11 22H2 dan lebih baharu, dan ia satu tetapan tambah satu penutupan:

[wsl2]
networkingMode=mirrored

Di dalam distribusi ip addr kemudian menyenaraikan penyesuai hos, terowong mungkin muncul antaranya, dan terowong DNS memajukan carian melalui resolver Windows walaupun klien menulis semula senarai DNS. Ia tidak universal: sesetengah pemacu penapis masih menggugurkan laluan cermin, dan peraturan tembok api Hyper-V mungkin memerlukan kebenaran jelas. Panduan rangkaian WSL Microsoft ialah halaman yang perlu dibandingkan dengan binaan anda sebelum menggunakan resipi yang ditulis untuk yang lebih baharu.

Uji tiga perkara selepas setiap perubahan

Pilih satu mekanisme setiap mesin dan catatkannya, kerana kedua-duanya bergabung dengan buruk. Sidecar di atas mod cermin menggandakan pemajuan, dan hos cermin dengan entri sidecar lapuk dalam .wslconfig cenderung gagal selepas peningkatan, bukan sebelumnya.

Apa pun pilihan anda, ujian penerimaan ialah tiga permintaan yang sama di dalam distribusi: nama dalaman, nama awam dan alamat mentah. Kemudian ulangi selepas memutuskan dan menyambung semula terowong, dan selepas wsl --shutdown. Hanya nama dalaman gagal bermakna dasar resolver; nama dalaman dan awam gagal bersama dengan alamat yang berfungsi masih bermakna dasar resolver; semuanya gagal bermakna laluan.

Jika satu hos dalaman gagal sementara yang lain berfungsi, berhenti melihat resolver dan cari laluan yang hilang untuk awalan itu. Jika semuanya berfungsi sehingga sambungan semula seterusnya, anda telah menemui pembetulan yang bergantung pada keadaan masa jalan, dan ia mesti digunakan semula secara automatik atau diganti dengan salah satu daripada dua mekanisme di atas.