WSL2-ը կորցրե՞լ է DNS-ը VPN-ի միացումից հետո։ Երկու պատճառ

Հնացած resolver ֆայլը և մրցակցող երթուղու մետրիկան նույն ախտանիշն են առաջացնում WSL2-ի ներսում։ Գրանցեք երկու կողմերը, ապա ուղղեք այն, որն իսկապես կոտրված է։

Ping-ը հասցեով աշխատում է բաշխման ներսում, փաթեթների տեղադրումը և git-ի ներբեռնումները ոչ, և խափանումը ի հայտ եկավ թունելի բարձրանալուց անմիջապես հետո։ Միայն անուններն են դադարել լուծվել, ինչը ցույց է տալիս DNS-ի, այլ ոչ միացման վրա։ Փաթեթների վերատեղադրումը այստեղ ամենատարածված սխալ առաջին քայլն է։ WSL2-ն ունի ճիշտ այդ ախտանիշն առաջացնելու երկու անկախ եղանակ, և դրանք տարբեր վերանորոգում են պահանջում։

Ինչու է բաշխումը պահում իր resolver-ը

Windows-ի DNS հաճախորդը չի օգտագործվում բաշխման ներսում։ WSL2-ը գործարկման պահին կառուցում է իր resolver ֆայլը՝ ուղղված stub հասցեին, որը Windows-ը հրապարակում է վիրտուալ անջատիչում օժանդակ վիրտուալ մեքենայի համար։

Այդ դասավորությունը կայուն է սովորական ցանցային փոփոխությունների ժամանակ, որովհետև գրվում է մեկ անգամ և կրկին օգտագործվում։ Դասավորությունը դադարում է ճիշտ լինելուց, երբ թունելի հաճախորդը վերագրում է հոսթի ադապտերների ցանկը այն բանից հետո, երբ օժանդակ վիրտուալ մեքենան արդեն գործարկվել է։

Բաշխման ներսում ոչինչ չի հետևում փոփոխությանը, ուստի ֆայլը շարունակում է ուղղված մնալ հասցեին, որը գուցե այլևս ուղու վրա չէ։ Հաջորդ որոնումն այնուհետև սպասում է, ժամկետանց է լինում կամ պատասխան է ստանում սերվերից, որը երբեք չի լսել ներքին գոտու մասին։ Ներսից resolver-ը պարզապես դադարում է պատասխանել, և բոլոր անունները ձախողվում են միաժամանակ։

Նախ հավաքեք ապացույցներ երկու կողմից

Գրանցեք, թե ինչ է տեսնում բաշխումը, ապա ինչ է տեսնում Windows-ը, նախքան դրանցից որևէ մեկը փոխելը։ Երկու տեսարանները միասին են տարբերում խափանման եղանակները։

Բաշխման ներսում տպեք resolver ֆայլը, երթուղային աղյուսակը և մեկ ներքին ու մեկ հանրային որոնում:

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

Windows-ում թվարկեք DNS սերվերները ըստ ադապտերի և IPv4 աղյուսակը մետրիկաներով։ VPN հաճախորդը սովորաբար երթուղի է տեղադրում WSL2 ենթացանցի համար, և նրա մետրիկան է որոշում՝ այդ տրաֆիկը դուրս է գալիս թունելով, թե մնում տեղական։

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Երթուղու մետրիկա, թե հնացած ֆայլ

Առաջին խափանումը հնացած ֆայլն է։ Resolver-ը գրվել էր գործարկման պահին ադապտերի վիճակի համար, և թունելը փոխել է այդ վիճակը։ Նրա stub հասցեն այժմ կարող է անհասանելի լինել, կամ այն անվանում է սերվեր, որը ոչինչ չգիտի ներքին գոտու մասին։

Երկրորդը երթուղային խնդիր է։ Երբ VPN-ն ավելացնում է երթուղի, որը ծածկում է WSL2 ենթացանցը հոսթի հղման երթուղուց ցածր մետրիկայով, օժանդակ վիրտուալ մեքենային հասցեագրված փաթեթները մտնում են թունել։ Այնուհետև ժամկետանց է լինում յուրաքանչյուր WSL2 ծառայություն, ոչ միայն DNS-ը։

Տարբերող փորձարկումը մեկ տող արժե։ Եթե թվային հասցեն, օրինակ հանրային resolver-ը, դեռ պատասխանում է ping-ին, մինչ անունները ձախողվում են, ուղին անձեռնմխելի է, և խնդիրը DNS-ն է։ Սա այն դեպքն է, երբ resolver-ի փոփոխությունը արդարացված է, և այն դեպքը, երբ արդարացված չէ, նույնպես ակնհայտ է դառնում։ Եթե թվային փորձարկումը նույնպես ձախողվի, օժանդակ վիրտուալ մեքենան կորցրել է իր երթուղին, և ոչ մի resolver ֆայլ դա չի շտկի։

Երթուղային դեպքի համար հեռացրեք ավտոմատ մետրիկան թունելի ադապտերից և տվեք նրան WSL2 հղման երթուղուց բարձր թիվ:

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

Անջատումը կարևոր է։ Մետրիկայի փոփոխությունը չի վերագրում աշխատող օժանդակ վիրտուալ մեքենան, ուստի բաշխումը պետք է վերակառուցվի նախքան փոփոխությունը տեսանելի կդառնա։

Վերցրեք ֆայլը, գիտակցաբար

Եթե երթուղավորումը ճիշտ է, և ձախողվում են միայն ներքին անունները, resolver-ն է մեղավոր, և կարող եք կանգնեցնել գեներատորը։ Սա գիտակցված փոփոխություն է սպասարկման ծախսով, ոչ թե հապճեպ կիրառվող շրջանցում։

Բաշխման ներսում ստեղծեք /etc/wsl.conf՝ ցանցային բաժնով, որն անջատում է գեներացումը, ապա ինքներդ գրեք resolver ֆայլը՝ նախ կորպորատիվ սերվերը, ապա հանրային պահուստայինը:

[network]
generateResolvConf = false
search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Հերթականությունը կարևոր է։ Հանրային resolver-ը չի կարող պատասխանել ներքին անվանը, և պահուստը գոյություն ունի միայն ինտերնետ որոնումների համար։ Հենց ֆայլը ձերն է, ոչինչ այն նորից չի գեներացնի, ուստի տեղափոխվող կորպորատիվ resolver-ը դառնում է ընդհատում, որը դուք ինքներդ պետք է նկատեք։

Ստուգեք անունները, ապա փաթեթները

Ստուգեք մեկ ներքին և մեկ հանրային անուն համակարգի resolver-ով, ապա կրկնեք ձախողված գործողությունը։ Փաթեթների կառավարիչները երբեմն օգտագործում են իրենց resolver-ը, դրա համար աշխատող getent-ը կարող է գոյակցել կոտրված տեղադրման հետ։

Եթե ավտոմատացնում եք վերագրումը, դարձրեք այն իդեմպոտենտ՝ թունելի բացակայության դեպքում պահեք արդեն գոյություն ունեցող ֆայլը՝ դատարկ սերվերների ցանկ գրելու փոխարեն։

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

Աշխատող ներքին որոնումը և աշխատող հանրային որոնումը՝ բաշխման ներսից, այն արդյունքն է, որ արժե գրանցել։ Հոսթի վրա կանաչ VPN պատկերակը չի ապացուցում դրանցից ոչ մեկը։

Առնչվող հոդվածներ