WSL2 kehilangan DNS selepas VPN disambungkan? Dua punca

Ping mengikut alamat berfungsi di dalam distribusi, pemasangan pakej dan tarikan git tidak, dan kegagalan muncul sejurus selepas terowong naik. Hanya nama berhenti diselesaikan, yang menunjuk kepada DNS dan bukan kepada ketersambungan. Memasang semula pakej ialah langkah pertama yang salah dan paling popular di sini. WSL2 mempunyai dua cara bebas untuk menghasilkan gejala yang sama itu, dan kedua-duanya memerlukan pembaikan berbeza.

Mengapa distribusi menyimpan resolver sendiri

Klien DNS Windows tidak digunakan di dalam distribusi. WSL2 membina fail resolver sendiri semasa mula, menunjuk ke alamat stub yang diterbitkan Windows pada suis maya untuk mesin maya pembantu.

Susunan itu stabil merentas perubahan rangkaian biasa kerana ia ditulis sekali dan digunakan semula. Susunan berhenti menjadi betul apabila klien terowong menulis semula senarai penyesuai hos selepas mesin maya pembantu sudah bermula.

Tiada apa-apa di dalam distribusi memantau perubahan itu, jadi fail terus menunjuk ke alamat yang mungkin tiada lagi di laluan. Carian seterusnya kemudian menunggu, tamat masa, atau mendapat jawapan daripada pelayan yang tidak pernah mendengar tentang zon dalaman. Dari dalam, resolver berhenti menjawab begitu sahaja, dan semua nama gagal serentak.

Kumpulkan bukti di kedua-dua belah pihak dahulu

Rekod apa yang dilihat distribusi, kemudian apa yang dilihat Windows, sebelum menukar mana-mana satu. Kedua-dua pandangan itulah yang membezakan mod kegagalan.

Di dalam distribusi, cetak fail resolver, jadual laluan dan satu carian dalaman serta satu carian awam:

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

Pada Windows, senaraikan pelayan DNS bagi setiap penyesuai dan jadual IPv4 berserta metriknya. Klien VPN biasanya memasang laluan untuk subrangkaian WSL2, dan metriknya menentukan sama ada trafik itu keluar melalui terowong atau kekal setempat.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Metrik laluan atau fail lapuk

Kegagalan pertama ialah fail lapuk. Resolver ditulis untuk keadaan penyesuai semasa mula, dan terowong mengubah keadaan itu. Alamat stubnya kini mungkin tidak dapat dicapai, atau ia menamakan pelayan yang tidak tahu apa-apa tentang zon dalaman.

Yang kedua ialah masalah penghalaan. Apabila VPN menambah laluan yang merangkumi subrangkaian WSL2 dengan metrik lebih rendah daripada laluan pautan hos, paket yang dialamatkan kepada mesin maya pembantu masuk ke dalam terowong. Ketika itu setiap perkhidmatan WSL2 tamat masa, bukan DNS sahaja.

Ujian yang membezakan hanya memerlukan satu baris. Jika alamat berangka seperti resolver awam masih menjawab ping sementara nama gagal, laluan itu utuh dan masalahnya ialah DNS. Itulah kes apabila perubahan resolver wajar dilakukan, dan kes apabila ia tidak wajar juga menjadi jelas. Jika ujian berangka juga gagal, mesin maya pembantu telah kehilangan laluannya dan tiada fail resolver dapat membaikinya.

Untuk kes penghalaan, buang metrik automatik pada penyesuai terowong dan berinya nombor melebihi laluan pautan WSL2:

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

Mematikannya penting. Menukar metrik tidak menulis semula mesin maya pembantu yang sedang berjalan, jadi distribusi mesti dibina semula sebelum perubahan kelihatan.

Ambil alih fail itu, dengan sengaja

Jika penghalaan betul dan hanya nama dalaman gagal, resolver yang bersalah dan anda boleh hentikan penjana. Itu perubahan yang disengajakan dengan kos penyelenggaraan, bukan jalan pintas yang dipakai secara sambil lewa.

Cipta /etc/wsl.conf di dalam distribusi dengan bahagian rangkaian yang mematikan penjanaan, kemudian tulis sendiri fail resolver, pelayan korporat dahulu dan pelayan awam sebagai sandaran:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Urutan penting. Resolver awam tidak boleh menjawab nama dalaman, dan sandaran hanya wujud untuk carian internet. Setelah fail itu milik anda, tiada apa menjananya semula, jadi resolver korporat yang berpindah menjadi gangguan yang anda sendiri perlu perhatikan.

Periksa nama, kemudian pakej

Sahkan satu nama dalaman dan satu nama awam dengan resolver sistem, kemudian ulangi operasi yang gagal. Pengurus pakej kadangkala menggunakan resolver sendiri, sebab itulah getent yang berfungsi boleh wujud bersama pemasangan yang rosak.

Jika anda mengautomasikan penulisan semula, jadikannya idempoten: tanpa terowong, kekalkan fail yang sudah ada dan bukannya menulis senarai pelayan kosong.

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

Carian dalaman yang berfungsi dan carian awam yang berfungsi, dari dalam distribusi, ialah hasil yang wajar direkodkan. Ikon VPN hijau pada hos tidak membuktikan keduanya.