WSL2 perdis DNS post kiam la VPN konektiĝis? Du kaŭzoj
Malnova resolver-dosiero kaj konkurenca itinmezurado produktas la saman simptomon ene de WSL2. Registru ambaŭ flankojn, poste riparu tiun, kiu vere difektas.
Ping laŭ adreso funkcias ene de la distribuo, pakaĵinstaladoj kaj git-elŝutoj ne, kaj la fiasko aperis tuj post kiam la tunelo leviĝis. Nur nomoj ĉesis solviĝi, kio montras al DNS prefere ol al konektebleco. Reinstali pakaĵojn estas la plej populara malĝusta unua paŝo ĉi tie. WSL2 havas du sendependajn manierojn produkti ĝuste tiun simptomon, kaj ili postulas malsamajn riparojn.
Kial la distribuo tenas sian propran resolver
La Windows-DNS-kliento ne estas uzata ene de la distribuo. WSL2 konstruas sian propran resolver-dosieron ĉe lanĉo, indikante stub-adreson, kiun Windows publikigas sur la virtuala ŝaltilo por la helpa virtuala maŝino.
Tiu aranĝo estas stabila tra ordinaraj retaj ŝanĝoj, ĉar ĝi estas skribata unufoje kaj reuzata. La aranĝo ĉesas esti ĝusta kiam tunela kliento reskribas la adaptilan liston de la gastiganto post kiam la helpa virtuala maŝino jam lanĉiĝis.
Nenio ene de la distribuo observas la ŝanĝon, do la dosiero daŭre indikas adreson, kiu eble jam ne estas sur la vojo. La sekva serĉo tiam atendas, tempolimas, aŭ ricevas respondon de servilo, kiu neniam aŭdis pri la interna zono. De interne la resolver simple ĉesas respondi, kaj ĉiuj nomoj fiaskas samtempe.
Unue kolektu pruvojn ambaŭflanke
Registru, kion vidas la distribuo, poste kion vidas Windows, antaŭ ol ŝanĝi iun ajn. La du vidoj kune estas tio, kio distingas la fiaskmanierojn.
Ene de la distribuo, presu la resolver-dosieron, la itintabelon kaj unu internan kaj unu publikan serĉon:
ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.comEn Windows, listigu la DNS-servilojn laŭ adaptilo kaj la IPv4-tabelon kun mezuroj. VPN-kliento kutime instalas itinon por la WSL2-subreto, kaj ĝia mezuro decidas ĉu tiu trafiko eliras tra la tunelo aŭ restas loka.
Get-NetAdapter | Get-DnsClientServerAddress
route print -4
Itinmezurado aŭ malnova dosiero
La unua fiasko estas la malnova dosiero. La resolver estis skribita por la adaptila stato ĉe lanĉo, kaj la tunelo ŝanĝis tiun staton. Ĝia stub-adreso nun eble neatingeblas, aŭ ĝi nomas servilon, kiu scias nenion pri la interna zono.
La dua estas itina problemo. Kiam la VPN aldonas itinon kovrantan la WSL2-subreton kun mezuro pli malalta ol la ligila itino de la gastiganto, pakaĵoj adresitaj al la helpa virtuala maŝino eniras la tunelon. Tiam tempolimas ĉiu WSL2-servo, ne nur DNS.
La distinga testo kostas unu linion. Se numera adreso kiel publika resolver ankoraŭ respondas al ping dum nomoj fiaskas, la vojo estas sendifekta kaj DNS estas la problemo. Tio estas la kazo, kie ŝanĝo de resolver estas pravigita, kaj la kazo, kie ĝi ne estas, ankaŭ fariĝas evidenta. Se la numera testo ankaŭ fiaskas, la helpa virtuala maŝino perdis sian itinon kaj neniu resolver-dosiero riparos tion.
Por la itina kazo, forigu la aŭtomatan mezuron de la tunela adaptilo kaj donu al ĝi nombron super la WSL2-ligila itino:
Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown
La malŝalto gravas. Ŝanĝi la mezuron ne reskribas la kurantan helpan virtualan maŝinon, do la distribuo devas esti rekonstruita antaŭ ol la ŝanĝo videblas.
Prenu la dosieron, konscie
Se itinado estas ĝusta kaj nur internaj nomoj fiaskas, la resolver kulpas kaj vi povas haltigi la generatoron. Tio estas konscia ŝanĝo kun prizorga kosto, ne provizora solvo por apliki hazarde.
Kreu /etc/wsl.conf ene de la distribuo kun la reta sekcio, kiu malŝaltas generadon, poste skribu la resolver-dosieron mem, unue la firmaa servilo kaj due publika rezerva adreso:
[network]
generateResolvConf = falsesearch corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9
La ordo gravas. Publika resolver ne povas respondi internan nomon, kaj la rezervo ekzistas nur por interretaj serĉoj. Post kiam la dosiero estas via, nenio regeneras ĝin, do firmaa resolver, kiu translokiĝas, fariĝas interrompo, kiun vi mem devas rimarki.
Kontrolu nomojn, poste pakaĵojn
Kontrolu unu internan kaj unu publikan nomon per la sistema resolver, poste ripetu la operacion, kiu fiaskis. Pakaĵmastrumiloj foje uzas propran resolver, tial funkcianta getent povas kunekzisti kun difektita instalo.
Se vi aŭtomatigas la reskribon, faru ĝin idempota: sen tunelo, konservu la dosieron, kiu jam ekzistas, anstataŭ skribi malplenan servilan liston.
getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com
Funkcianta interna serĉo kaj funkcianta publika serĉo, de interne de la distribuo, estas la rezulto inda je registrado. Verda VPN-ikono sur la gastiganto pruvas nek unu nek la alian.