Kial WSL perdas la laboran gastigantnomon, kiam VPN konektiĝas?

Windows solvas la internan gastiganton sen ajna plendo, kaj la sama nomo malsukcesas ene de WSL en la momento, kiam la tunelo leviĝas. La kutima riparo estas skribi publikan solvilon en la distribuon, kio restarigas ordinaran retumiĝon kaj faras la laboran gastigantnomon nesolvebla. Tio interŝanĝas unu malsukceson kontraŭ alia, kaj ĝi kaŝas la tavolon, kiu efektive rompiĝis. Antaŭ ol aldoni aŭ forigi ajnan solvilan linion, determini, kiun el la tri tavoloj malsukcesas.

Unue ekskludu vojigan malsukceson

Pridemandu la identan plene kvalifikitan nomon ĉe ambaŭ flankoj, ne du nomojn, kiuj similas. Sukceso en Windows kaj malsukceso en WSL por la sama ĉeno estas la subskribo de du solvaj vojoj, kaj malmulto alia produktas tiun ŝablonon tiel pure. Se WSL ankaŭ ne povas atingi la servon ĉe ĝia konata numera adreso, ankaŭ ekzistas vojiga aŭ filtra problemo. En tiu kazo la DNS-laboro ne malkaŝos ĝin, kaj la posttagmezo iras al la malĝusta tavolo.

Tri simptomoj kovras la plej multajn el tiuj kazoj, kaj ĉiu indikas aliloken. Legu la konforman vicon antaŭ ol malfermi agordan dosieron:

La meza vico estas tiu, kiun homoj mislegas, ĉar la ŝanĝo, kiu ĝin rompis, estis farita semajnojn antaŭe kaj tiam aspektis sukcesa. La tria vico estas tiu, kiun homoj misdiagnozas, ĉar nomo, kiu solviĝas, sentiĝas kiel pruvo, ke la reto estas sana. Ambaŭ vicoj sendas vin al malsama sekcio sube.

DNS-tunelado havas minimuman version

Microsoft dokumentas WSL-retan reĝimon, kiu tunelas DNS-petojn al la Windows-solvilo tra virtualiga kanalo. Sur subtenataj Windows 11-konstruaĵoj ĝi estas ŝaltita defaŭlte, kaj tial du maŝinoj en la sama firmaa reto kondutas malsame. La variablo estas la konstruaĵa numero, ne la firmaa politiko.

La WSL-reta gvidilo priskribas tiun reĝimon kaj la versiojn, kiuj subtenas ĝin. La funkcio gravas, ĉar firmaa DNS-politiko kutime loĝas en la Windows-solvilo, kaj distribuo, kiu heredas la Windows-vojon, heredas la politikon kun ĝi. Distribuo, kiu pridemandas publikan solvilon, havas neniun vojon al privata nomo, kiom ajn ordigita aspektas ĝia propra agordo. Tiu mekanismo klarigas la tutan simptomon kaj klarigas, kial la provizora solvo kun publika solvilo malsukcesas.

Legu la konstruaĵan numeron antaŭ ol redakti ion ajn. Agordo kopiita el pli nova instalado ne estas pruvo, ke pli malnova efektivigas ĝin. Notu la konstruaĵan numeron apud la ŝanĝo, ĉar la diferenco inter du maŝinoj preskaŭ ĉiam estas versio kaj ne politiko.

Malnovaj anstataŭigoj postvivas la problemon, kiun ili solvis

Pli malnovaj receptoj malŝaltis generitajn solvilajn dosierojn, malmole kodis nomservilon aŭ ŝlosis la dosieron per neŝanĝebla atributo. Tiuj ŝanĝoj restas en la loko longe post kiam la konekteca problemo, kiu ilin kaŭzis, malaperis, kaj ili kutime estas la kialo, kial pli nova agordo ŝajnas fari nenion. Ili ankaŭ postvivas reinstaladon de la distribuo en la formo de ŝela profilo, kiu reskribas la dosieron ĉe ĉiu ensaluto. La lasta estas la plej malfacile trovebla, ĉar ĝi estas nevidebla el la dosiero, kiun ĉiuj inspektas.

Serĉu mane skribitan solvilan dosieron, neŝanĝeblan atributon sur ĝi kaj startan skripton, kiu reskribas ĝin. Kontrolu la neŝanĝeblan flagon antaŭ redakti, ĉar skribo al ŝlosita dosiero malsukcesas tiel, ke ĝi legeblas kiel permesa problemo. Poste kontrolu la ŝelan profilon, ĉar skripto tie restarigas la malnovan enhavon ene de sekundoj post via riparo.

Forigi anstataŭigon havas sekvojn, do notu, kion vi forigis kaj kial. Distribuo, kiu vere bezonas statikan solvilon por alia celo, rompiĝos, kiam la generita dosiero revenos.

Du dosieroj, du malsamaj roloj

La du agordaj dosieroj loĝas en malsamaj lokoj kaj regas malsamajn aferojn, kaj konfuzi ilin produktas redaktojn aplikitajn al la malĝusta tavolo. La dosiero ĉe la Windows-flanko agordas ecojn de la virtuala maŝino, dum la dosiero ĉe la distribua flanko agordas, kiel tiu distribuo konstruas sian propran solvilan agordon. Neniu anstataŭigas la alian, tial ambaŭ devas konsenti.

Por instalado, kiu subtenas la funkcion, la fragmento ĉe la Windows-flanko estas mallonga. Ĝi estas la tuta ŝanĝo ĉe tiu flanko:

[wsl2]
dnsTunneling=true

Tiu fragmento apartenas al la Windows-uzantprofilo kaj validas por la virtuala maŝino anstataŭ por unu distribuo. Tunelado ankaŭ postulas, ke la distribuo ne malŝaltis solvilan generadon, do la dosiero ĉe la distribua flanko devas lasi tiun konduton trankvila. Ŝanĝu unu sen la alia kaj la reĝimo silente faras nenion, kio estas la plej kutima maniero, kiel ĉi tiu riparo raportiĝas kiel rompita. Kontrolu ambaŭ dosierojn en la sama sesio, ĉar du redaktoj faritaj semajnojn dise estas du redaktoj, kiujn neniu povas atribui.

Restartigu, poste pridemandu de ambaŭ flankoj

Ĉi tiuj agordoj estas legitaj kiam la medio startas, do nova ŝelo ene de kuranta distribuo ne reŝargos ilin. Malŝaltu la medion anstataŭ restartigi la ŝelon, kaj unue konservu ajnan kurantan laboron, ĉar ĉiu distribuo haltas kun ĝi. Nur tiu preterlaso klarigas la plej multajn raportojn pri ŝanĝo sen efiko.

Poste demandu la saman demandon de ambaŭ flankoj. La eligo ankaŭ montras, kun kiu solvilo la distribuo fakte finiĝis:

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'

La unua komando finas la medion, la dua montras, kiun solvilon la distribuo nun uzas, kaj la lastaj du metas la saman demandon al ĉiu flanko. Komparu la respondojn anstataŭ la staton de la agordo. Pridemando, kiu ankoraŭ malsukcesas post pura restartigo kun ambaŭ dosieroj ĝustaj, indikas al la firmaa solvila politiko, kaj tiu konversacio havas alian posedanton.