WSL2 kehilangan DNS setelah VPN terhubung? Dua penyebab

Ping berdasarkan alamat berfungsi di dalam distribusi, pemasangan paket dan pengambilan git tidak, dan kegagalan muncul tepat setelah terowongan naik. Hanya nama yang berhenti diselesaikan, yang mengarah ke DNS dan bukan ke konektivitas. Memasang ulang paket adalah langkah pertama yang salah dan paling populer di sini. WSL2 memiliki dua cara independen untuk menghasilkan gejala yang persis sama, dan keduanya membutuhkan perbaikan berbeda.

Mengapa distribusi menyimpan resolver sendiri

Klien DNS Windows tidak dipakai di dalam distribusi. WSL2 membangun berkas resolver sendiri saat mulai, menunjuk ke alamat stub yang diterbitkan Windows pada sakelar virtual untuk mesin virtual pembantu.

Susunan itu stabil terhadap perubahan jaringan biasa karena ditulis sekali dan dipakai ulang. Susunan berhenti benar ketika klien terowongan menulis ulang daftar adaptor host setelah mesin virtual pembantu sudah mulai.

Tidak ada apa pun di dalam distribusi yang memantau perubahan itu, jadi berkas tetap menunjuk ke alamat yang mungkin sudah tidak ada di jalur. Pencarian berikutnya lalu menunggu, habis waktu, atau mendapat jawaban dari server yang belum pernah mendengar tentang zona internal. Dari dalam, resolver berhenti menjawab begitu saja, dan semua nama gagal sekaligus.

Kumpulkan bukti di kedua sisi lebih dulu

Catat apa yang dilihat distribusi, lalu apa yang dilihat Windows, sebelum mengubah salah satunya. Kedua tampilan itulah yang bersama-sama membedakan mode kegagalan.

Di dalam distribusi, cetak berkas resolver, tabel rute, dan satu pencarian internal serta satu pencarian publik:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

Di Windows, daftarkan server DNS per adaptor dan tabel IPv4 beserta metriknya. Klien VPN biasanya memasang rute untuk subnet WSL2, dan metriknya menentukan apakah lalu lintas itu keluar lewat terowongan atau tetap lokal.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Metrik rute atau berkas usang

Kegagalan pertama adalah berkas usang. Resolver ditulis untuk keadaan adaptor saat mulai, dan terowongan mengubah keadaan itu. Alamat stub-nya sekarang mungkin tidak terjangkau, atau menamai server yang tidak tahu apa pun tentang zona internal.

Yang kedua adalah masalah perutean. Ketika VPN menambahkan rute yang mencakup subnet WSL2 dengan metrik lebih rendah daripada rute tautan host, paket yang dialamatkan ke mesin virtual pembantu masuk ke terowongan. Lalu setiap layanan WSL2 habis waktu, bukan hanya DNS.

Uji pembeda hanya butuh satu baris. Jika alamat numerik seperti resolver publik masih menjawab ping sementara nama gagal, jalurnya utuh dan DNS adalah masalahnya. Itulah kasus ketika perubahan resolver dibenarkan, dan kasus ketika tidak juga menjadi jelas. Jika uji numerik juga gagal, mesin virtual pembantu kehilangan rutenya dan tidak ada berkas resolver yang bisa memperbaikinya.

Untuk kasus perutean, hapus metrik otomatis pada adaptor terowongan dan beri angka di atas rute tautan WSL2:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

Mematikannya penting. Mengubah metrik tidak menulis ulang mesin virtual pembantu yang berjalan, jadi distribusi harus dibangun ulang sebelum perubahan terlihat.

Ambil alih berkasnya, dengan sengaja

Jika perutean benar dan hanya nama internal yang gagal, resolver yang bersalah dan Anda dapat menghentikan generator. Itu perubahan yang disengaja dengan biaya pemeliharaan, bukan tambalan yang dipasang sembarangan.

Buat /etc/wsl.conf di dalam distribusi dengan bagian jaringan yang menonaktifkan pembuatan, lalu tulis sendiri berkas resolver, server korporat lebih dulu dan server publik sebagai cadangan:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Urutannya penting. Resolver publik tidak dapat menjawab nama internal, dan cadangan hanya ada untuk pencarian internet. Begitu berkas menjadi milik Anda, tidak ada yang membuatnya ulang, jadi resolver korporat yang berpindah menjadi gangguan yang harus Anda sadari sendiri.

Periksa nama, lalu paket

Verifikasi satu nama internal dan satu nama publik dengan resolver sistem, lalu ulangi operasi yang gagal. Manajer paket kadang memakai resolver sendiri, karena itu getent yang bekerja bisa hidup berdampingan dengan pemasangan yang rusak.

Jika Anda mengotomatiskan penulisan ulang, buatlah idempoten: tanpa terowongan, pertahankan berkas yang sudah ada alih-alih menulis daftar server kosong.

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

Pencarian internal yang bekerja dan pencarian publik yang bekerja, dari dalam distribusi, adalah hasil yang layak dicatat. Ikon VPN hijau di host tidak membuktikan keduanya.