resolv.conf v WSL 2: DNS zomrie, keď sa pripojí VPN
WSL regeneruje resolv.conf z tých adaptérov Windows, ktoré vidí, takže resolver VPN nemusí nikdy doraziť. Zastavte generovanie a potom otestujte firemné meno.
Prehliadanie vnútri distribúcie funguje a prvé interné meno hostiteľa zlyhá vo chvíli, keď sa zdvihne tunel. Reflex je pridať verejný resolver, čo obnoví internet a urobí firemné meno nedostupným na zvyšok dňa. Vo WSL 2 je /etc/resolv.conf generovaný výstup, nie konfigurácia, a práve tento mechanizmus stojí za pochopenie. Oprava nie je lepší resolver, ale vlastníctvo súboru.
Súbor sa generuje, nekonfiguruje
WSL 2 zapisuje súbor pri štarte z adaptérov Windows, ktoré v tej chvíli vidí, a navrch vytlačí komentár, ktorý to hovorí. Keď potom klient VPN pridá alebo prepíše adaptér, distribúcia nemusí nič znovu vygenerovať, a súbor ďalej opisuje sieť, ktorá už neexistuje.
Druhý režim zlyhania je tichší: WSL môže kopírovať servery len z niektorých adaptérov. Ak má fyzický adaptér už resolver IPv6, servery IPv4, ktoré dodáva adaptér VPN, môžu byť vyhodené namiesto pridané, a súbor vyzerá úplne, pričom vynecháva práve ten, ktorý odpovedá na interné mená.
Porovnajte pohľad z Windows s pohľadom z Linuxu
Prečítajte obe strany pred úpravou. Vnútri distribúcie sa pozrite, čo súbor obsahuje a či je to bežný súbor alebo odkaz. Vo Windows vypíšte resolver pre každý adaptér, vrátane toho, ktorý vytvoril VPN:
ls -l /etc/resolv.conf
cat /etc/resolv.conf
Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'
Keď adaptér VPN ukazuje firemné servery a Linux niečo iné, rozpor je v generovaní, nie v dosiahnuteľnosti. Porovnajte zoznam adaptérov aj adresy, pretože chýbajúci adaptér vysvetľuje chýbajúci server. Toto rozlíšenie rozhoduje, či opravujete WSL alebo firewall, a obe nemajú nič spoločné.
Vypnite generovanie a napíšte vlastný súbor
Jedno dokumentované nastavenie bráni WSL prepisovať súbor a nachádza sa v /etc/wsl.conf. Pridajte do toho súboru sieťovú sekciu:
[network]
generateResolvConf = false
Potom ukončite distribúciu z Windows pomocou wsl --shutdown a znova ju spustite. Ak je cesta symbolický odkaz a nie bežný súbor, odkaz pred zápisom vlastného obsahu odstráňte, pretože zápis cez odkaz môže pri ďalšom štarte znovu vytvoriť generovaný cieľ. Od tej chvíle je súbor váš a nič ho neprepisuje.
nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate
Bez vyhľadávacej domény sa nekvalifikované meno hostiteľa doplní verejným koreňom a vráti sa ako žiadna taká doména. timeout bráni mŕtvemu prvému serveru zablokovať každé hľadanie, attempts obmedzuje, koľko pokusov hľadanie spotrebuje, a rotate rozprestiera opakovania namiesto vždy začať zhora. Kompromis je, že súbor už nenasleduje VPN, ktorej adresa resolvera sa medzi reláciami mení.
Vyriešte resolver, ktorý sa posúva, a potom overte
Niektorí klienti vydávajú resolver špecifický pre reláciu, takže statický súbor sa pri ďalšom pripojení rozbije. Dva postupy sú obhájiteľné. Zapisujte súbor z malého skriptu vždy, keď sa adresa zmení, alebo ponechajte generovanie zapnuté a uistite sa, že adaptér, z ktorého WSL kopíruje, nesie firemný server. Druhý nepotrebuje háčik a zlyháva vždy, keď generovanie preskočí adaptér VPN; oba stále vyžadujú najprv vyriešiť konflikt s IPv6.
Windows uplatňuje aj vlastné zásady mien, napríklad zoznam na hľadanie prípon alebo zásadu prekladu pre konkrétne domény, a kopírovanie adries adaptérov tieto pravidlá nereprodukuje. Ak sa meno preloží vo Windows a nie v distribúcii s tým istým serverom, porovnajte spracovanie prípon, než obviníte tunel.
Testujte menom, nie paketom: getent hosts sensor-access0.corp.example prechádza zásobníkom resolvera, zatiaľ čo ping môže uspieť proti uloženej alebo doslovnej adrese. Potom to zopakujte po odpojení a opätovnom pripojení, pretože nastavenie, ktoré funguje raz a pri obnovení sa regeneruje, nebolo nikdy opravené. Uložte predchádzajúci obsah a poznamenajte, ktorá komponenta cestu na tom stroji vlastní, aby ďalšia zmena začala s dôkazmi.