Mengapa WSL kehilangan nama host kerja saat VPN tersambung?

Windows menyelesaikan host internal tanpa keluhan, dan nama yang sama gagal di dalam WSL pada saat terowongan aktif. Perbaikan yang biasa adalah menulis resolver publik ke dalam distribusi, yang memulihkan penjelajahan biasa dan membuat nama host kerja tidak mungkin diselesaikan. Itu menukar satu kegagalan dengan kegagalan lain, dan menyembunyikan lapisan yang sebenarnya rusak. Sebelum menambahkan atau menghapus baris resolver apa pun, tentukan lapisan mana dari tiga lapisan yang gagal.

Singkirkan dulu kegagalan perutean

Kueri nama yang sepenuhnya memenuhi syarat yang sama di kedua sisi, bukan dua nama yang mirip. Keberhasilan di Windows dan kegagalan di WSL untuk string yang sama adalah tanda dua jalur resolusi, dan sedikit hal lain yang menghasilkan pola itu dengan begitu bersih. Jika WSL juga tidak dapat menjangkau layanan pada alamat numeriknya yang diketahui, ada juga masalah perutean atau penyaringan. Dalam kasus itu pekerjaan DNS tidak akan mengungkapnya, dan sore hari pergi ke lapisan yang salah.

Tiga gejala mencakup sebagian besar kasus ini, dan masing-masing menunjuk ke tempat yang berbeda. Baca baris yang cocok sebelum membuka file konfigurasi:

Baris tengah adalah yang salah dibaca orang, karena perubahan yang merusaknya dilakukan berminggu-minggu sebelumnya dan tampak berhasil saat itu. Baris ketiga adalah yang salah didiagnosis orang, karena nama yang berhasil diselesaikan terasa seperti bukti bahwa jaringan sehat. Kedua baris mengarahkan Anda ke bagian yang berbeda di bawah.

Tunneling DNS punya batas versi minimum

Microsoft mendokumentasikan mode jaringan WSL yang menerowongkan permintaan DNS ke resolver Windows melalui kanal virtualisasi. Pada build Windows 11 yang didukung, mode ini aktif secara default, itulah sebabnya dua mesin di jaringan perusahaan yang sama berperilaku berbeda. Variabelnya adalah nomor build, bukan kebijakan perusahaan.

Panduan jaringan WSL menjelaskan mode itu dan versi yang mendukungnya. Fitur ini penting karena kebijakan DNS perusahaan biasanya berada di resolver Windows, dan distribusi yang mewarisi jalur Windows mewarisi kebijakan itu juga. Distribusi yang menanyakan resolver publik tidak punya rute ke nama privat, seberapa rapi pun konfigurasinya sendiri. Mekanisme itulah yang menjelaskan seluruh gejala, dan menjelaskan mengapa solusi resolver publik gagal.

Baca build sebelum mengubah apa pun. Pengaturan yang disalin dari instalasi yang lebih baru bukan bukti bahwa instalasi yang lebih lama menerapkannya. Catat nomor build di samping perubahan, karena perbedaan antara dua mesin hampir selalu versi, bukan kebijakan.

Penimpaan lama bertahan lebih lama daripada masalah yang diselesaikannya

Resep lama menonaktifkan file resolver yang dihasilkan, mengodekan server nama secara keras, atau mengunci file dengan atribut tak berubah. Perubahan itu tetap ada jauh setelah masalah konektivitas yang memicunya hilang, dan biasanya itulah sebabnya pengaturan yang lebih baru tampak tidak melakukan apa-apa. Perubahan itu juga bertahan melewati pemasangan ulang distribusi dalam bentuk profil shell yang menulis ulang file pada setiap login. Yang terakhir paling sulit ditemukan, karena tidak terlihat dari file yang diperiksa semua orang.

Cari file resolver yang ditulis tangan, atribut tak berubah padanya, dan skrip startup yang menulis ulangnya. Periksa flag tak berubah sebelum mengedit, karena penulisan ke file yang terkunci gagal dengan cara yang terbaca seperti masalah izin. Periksa profil shell sesudahnya, karena skrip di sana memulihkan konten lama dalam hitungan detik setelah perbaikan Anda.

Menghapus penimpaan punya konsekuensi, jadi catat apa yang Anda hapus dan mengapa. Distribusi yang benar-benar membutuhkan resolver statis untuk tujuan lain akan rusak saat file yang dihasilkan kembali.

Dua file, dua peran berbeda

Kedua file konfigurasi berada di tempat berbeda dan mengendalikan hal berbeda, dan mencampuradukkannya menghasilkan penyuntingan yang diterapkan ke lapisan yang salah. File di sisi Windows mengatur properti mesin virtual, sedangkan file di sisi distribusi mengatur bagaimana distribusi itu membangun konfigurasi resolver-nya sendiri. Tidak ada yang menimpa yang lain, itulah sebabnya keduanya harus sepakat.

Untuk instalasi yang mendukung fitur itu, fragmen di sisi Windows singkat. Itulah seluruh perubahan di sisi tersebut:

[wsl2]
dnsTunneling=true

Fragmen itu berada di profil pengguna Windows dan berlaku untuk mesin virtual, bukan untuk satu distribusi. Tunneling juga mensyaratkan distribusi tidak menonaktifkan pembuatan resolver, jadi file di sisi distribusi harus membiarkan perilaku itu. Ubah satu tanpa yang lain dan mode itu diam-diam tidak melakukan apa-apa, dan itulah cara paling umum perbaikan ini dilaporkan sebagai rusak. Periksa kedua file dalam sesi yang sama, karena dua penyuntingan yang dibuat berminggu-minggu terpisah adalah dua penyuntingan yang tidak dapat dikaitkan siapa pun.

Mulai ulang, lalu kueri dari kedua sisi

Pengaturan ini dibaca saat lingkungan mulai, jadi shell baru di dalam distribusi yang sedang berjalan tidak akan memuatnya ulang. Matikan lingkungan alih-alih memulai ulang shell, dan simpan dulu pekerjaan yang sedang berjalan karena setiap distribusi berhenti bersamanya. Kelalaian itu saja menjelaskan sebagian besar laporan bahwa suatu perubahan tidak berefek.

Lalu ajukan pertanyaan yang sama dari kedua sisi. Keluarannya juga menunjukkan resolver mana yang akhirnya dipakai distribusi:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

Perintah pertama mengakhiri lingkungan, yang kedua menunjukkan resolver mana yang sekarang dipakai distribusi, dan dua yang terakhir mengajukan pertanyaan yang sama ke masing-masing sisi. Bandingkan jawabannya, bukan status pengaturannya. Kueri yang masih gagal setelah mulai ulang bersih dengan kedua file benar menunjuk ke kebijakan resolver perusahaan, dan percakapan itu punya pemilik lain.