Ինչու է WSL-ը կորցնում աշխատանքային հոսթի անունը, երբ VPN-ը միանում է։
Նույն անունը աշխատում է Windows-ում և ձախողվում WSL-ի ներսում, հենց որ թունելը բարձրանում է։ Ստուգեք հարթակի DNS ռեժիմը և հնացած փոխարինումները նախքան լուծիչ ավելացնելը։
Windows-ը լուծում է ներքին հոսթը առանց որևէ բողոքի, իսկ նույն անունը ձախողվում է WSL-ի ներսում այն պահին, երբ թունելը բարձրանում է։ Սովորական շտկումը բաշխման մեջ հանրային լուծիչ գրելն է, ինչը վերականգնում է սովորական զննարկումը և աշխատանքային հոսթի անունը դարձնում անլուծելի։ Դա մեկ ձախողումը փոխարինում է մյուսով և թաքցնում այն շերտը, որն իրականում կոտրվել է։ Նախքան լուծիչի որևէ տող ավելացնելը կամ հեռացնելը, պարզեք, թե երեք շերտերից որն է ձախողվում։
Նախ բացառեք երթուղավորման ձախողումը
Հարցրեք նույն լրիվ որակավորված անունը երկու կողմերում, ոչ թե նման երկու անուն։ Նույն տողի համար Windows-ում հաջողությունը և WSL-ում ձախողումը երկու լուծման ուղիների ստորագրությունն է, և քիչ այլ բան է այդ օրինաչափությունը ստեղծում այդքան մաքուր։ Եթե WSL-ը չի կարողանում հասնել ծառայությանը նաև իր հայտնի թվային հասցեով, ապա կա նաև երթուղավորման կամ զտման խնդիր։ Այդ դեպքում DNS-ի աշխատանքը չի բացահայտի դա, և կեսօրը կանցնի սխալ շերտի վրա։
Երեք ախտանիշ ծածկում են այս դեպքերի մեծ մասը, և յուրաքանչյուրը մատնանշում է այլ տեղ։ Կարդացեք համապատասխան տողը նախքան կարգավորման ֆայլ բացելը:
| Symptom inside WSL | Likely layer | Where to look |
|---|---|---|
| Private name fails while public browsing works | Resolver path | Tunneling mode and the Windows build |
| A name that worked yesterday fails today | Stale override | Generated resolver file, immutable flag, shell profile |
| The name resolves but the service does not | Routing or filtering | The resolved address and the path to it |
Միջին տողը այն է, որը մարդիկ սխալ են կարդում, որովհետև այն կոտրած փոփոխությունը կատարվել էր շաբաթներ առաջ և այն ժամանակ հաջող էր թվում։ Երրորդ տողը այն է, որը մարդիկ սխալ են ախտորոշում, որովհետև լուծվող անունը զգացվում է որպես ապացույց, որ ցանցը առողջ է։ Երկու տողերն էլ ձեզ ուղարկում են ներքևի տարբեր բաժին։
DNS թունելավորումն ունի նվազագույն տարբերակ
Microsoft-ը փաստագրում է WSL ցանցային ռեժիմ, որը DNS հարցումները վիրտուալացման ուղիով թունելավորում է Windows-ի լուծիչ։ Աջակցվող Windows 11 կառուցվածքներում այն միացված է լռելյայն, ինչի պատճառով նույն կորպորատիվ ցանցում երկու մեքենաներ տարբեր կերպ են վարվում։ Փոփոխականը կառուցվածքի համարն է, ոչ թե կորպորատիվ քաղաքականությունը։
WSL ցանցային ուղեցույցը նկարագրում է այդ ռեժիմը և այն տարբերակները, որոնք աջակցում են դրան։ Այս հատկությունը կարևոր է, որովհետև կորպորատիվ DNS քաղաքականությունը սովորաբար ապրում է Windows-ի լուծիչում, և այն բաշխումը, որը ժառանգում է Windows-ի ուղին, ժառանգում է նաև քաղաքականությունը։ Հանրային լուծիչ հարցնող բաշխումը մասնավոր անվան ոչ մի ուղի չունի, որքան էլ նրա սեփական կարգավորումը կոկիկ տեսք ունենա։ Այդ մեխանիզմը բացատրում է ամբողջ ախտանիշը և բացատրում է, թե ինչու է հանրային լուծիչով շրջանցումը ձախողվում։
Կարդացեք կառուցվածքի համարը նախքան որևէ բան խմբագրելը։ Ավելի նոր տեղադրումից պատճենված պարամետրը ապացույց չէ, որ ավելի հինը կիրառում է այն։ Գրեք կառուցվածքի համարը փոփոխության կողքին, որովհետև երկու մեքենաների տարբերությունը գրեթե միշտ տարբերակն է, ոչ թե քաղաքականությունը։
Հին փոխարինումները ապրում են ավելի երկար, քան իրենց լուծած խնդիրը
Ավելի հին բաղադրատոմսերը անջատում էին գեներացված լուծիչի ֆայլերը, կոշտ նշում էին անունների սերվեր կամ կողպում էին ֆայլը անփոփոխելիության ատրիբուտով։ Այդ փոփոխությունները մնում են տեղում երկար այն բանից հետո, երբ նրանց հարուցած կապի խնդիրը անհետացել է, և սովորաբար հենց նրանք են պատճառը, որ ավելի նոր պարամետրը ոչինչ չի անում թվում։ Նրանք նաև վերապրում են վերատեղադրումը shell պրոֆիլի տեսքով, որը ֆայլը վերագրում է ամեն մուտքի ժամանակ։ Վերջինը գտնելն ամենադժվարն է, որովհետև այն անտեսանելի է այն ֆայլից, որը բոլորը ստուգում են։
Փնտրեք ձեռքով գրված լուծիչի ֆայլ, նրա վրա անփոփոխելիության ատրիբուտ և մեկնարկային սկրիպտ, որը վերագրում է այն։ Ստուգեք անփոփոխելիության դրոշը նախքան խմբագրելը, որովհետև կողպված ֆայլին գրելը ձախողվում է այնպես, որ կարդացվում է որպես թույլտվության խնդիր։ Դրանից հետո ստուգեք shell պրոֆիլը, որովհետև այնտեղի սկրիպտը վերականգնում է հին բովանդակությունը ձեր շտկումից վայրկյանների ընթացքում։
Փոխարինումը հեռացնելը հետևանքներ ունի, ուստի գրեք, թե ինչ հեռացրիք և ինչու։ Այն բաշխումը, որն իսկապես ստատիկ լուծիչի կարիք ունի այլ նպատակի համար, կկոտրվի, երբ գեներացված ֆայլը վերադառնա։
Երկու ֆայլ, երկու տարբեր դերեր
Երկու կարգավորման ֆայլերն ապրում են տարբեր տեղերում և վերահսկում են տարբեր բաներ, և դրանք շփոթելը ստեղծում է սխալ շերտի վրա կիրառված խմբագրումներ։ Windows-ի կողմի ֆայլը սահմանում է վիրտուալ մեքենայի հատկությունները, մինչդեռ բաշխման կողմի ֆայլը սահմանում է, թե ինչպես է այդ բաշխումը կառուցում իր սեփական լուծիչի կարգավորումը։ Ոչ մեկը չի փոխարինում մյուսին, դրա համար էլ երկուսը պետք է համաձայնեն։
Այն տեղադրման համար, որը աջակցում է այս հատկությանը, Windows-ի կողմի հատվածը կարճ է։ Դա այդ կողմի ամբողջ փոփոխությունն է:
[wsl2]
dnsTunneling=trueԱյդ հատվածը պատկանում է Windows-ի օգտվողի պրոֆիլին և վերաբերում է վիրտուալ մեքենային, ոչ թե մեկ բաշխման։ Թունելավորումը նաև պահանջում է, որ բաշխումը չանջատած լինի լուծիչի գեներացումը, ուստի բաշխման կողմի ֆայլը պետք է այդ վարքը հանգիստ թողնի։ Փոխեք մեկը առանց մյուսի և ռեժիմը լուռ ոչինչ չի անում, ինչը այս շտկումը կոտրված հաղորդելու ամենատարածված եղանակն է։ Ստուգեք երկու ֆայլերն էլ նույն նստաշրջանում, որովհետև շաբաթների տարբերությամբ արված երկու խմբագրում երկու խմբագրում են, որ ոչ ոք չի կարող վերագրել։
Վերագործարկեք, հետո հարցրեք երկու կողմերից
Այս պարամետրերը կարդացվում են միջավայրի մեկնարկին, ուստի աշխատող բաշխման ներսում նոր shell դրանք նորից չի բեռնի։ Անջատեք միջավայրը՝ shell-ը վերագործարկելու փոխարեն, և նախ պահեք ընթացող աշխատանքը, որովհետև ամեն բաշխում դադարում է դրա հետ։ Միայն այս բացթողումը բացատրում է փոփոխության ազդեցություն չունենալու մասին հաղորդումների մեծ մասը։
Հետո տվեք նույն հարցը երկու կողմերից։ Արդյունքը նաև ցույց է տալիս, թե բաշխումն ի վերջո որ լուծիչի հետ մնաց:
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'Առաջին հրամանը վերջացնում է միջավայրը, երկրորդը ցույց է տալիս, թե բաշխումն այժմ որ լուծիչն է օգտագործում, իսկ վերջին երկուսը նույն հարցը տալիս են յուրաքանչյուր կողմին։ Համեմատեք պատասխանները, ոչ թե պարամետրի կարգավիճակը։ Հարցումը, որը դեռ ձախողվում է մաքուր վերագործարկումից հետո՝ երկու ֆայլերն էլ ճիշտ լինելով, մատնանշում է կորպորատիվ լուծիչի քաղաքականությանը, և այդ զրույցն այլ տեր ունի։