WSL2-ը չի ժառանգում կորպորատիվ VPN-ը, և հենց դա է սխալը
WSL2-ն աշխատում է իր սեփական վիրտուալ ցանցում և երբեք չի ժառանգում հոսթի VPN կույտը։ Անունների ձախողումները ճանապարհի ձախողումներից առանձնացրեք նախքան resolv.conf-ը խմբագրելը։
Ներքին վիքին բացվում է Edge-ում, մինչդեռ git clone-ը բաշխման ներսում ժամանակավերջ է ստանում։ Այդ մեկ դիտարկումը սովորաբար ընթերցվում է որպես «VPN-ը արգելափակում է WSL2-ը», և հաջորդ ժամը գնում է /etc/resolv.conf-ի խմբագրմանը։ Ավելի օգտակար ընթերցումն այն է, որ WSL2-ը երբեք չի ունեցել հոսթի ցանցային ճանապարհը. այն աշխատում է օժանդակ VM-ում՝ իր ադապտերով, իր երթուղիներով և resolver-ի ֆայլով, որը Windows-ը ստեղծում է նրա համար։ Ամեն ինչ հետագա կախված է նրանից, թե այդ երեքից որն է իրոք ձեզ պակասում։
VM-ն ունի իր կույտը, չափիչները և resolver-ը
Լռելյայն NAT ռեժիմում բաշխումը նստում է վիրտուալ անջատիչի հետևում և ինտերնետին հասնում է հոսթի միջով, բայց չի տեսնում հոսթի ադապտերները։ ip addr-ը ցույց է տալիս մեկ ինտերֆեյս մասնավոր հասցեով, ip route-ը ցույց է տալիս լռելյայն երթուղի այդ անջատիչով, իսկ /etc/resolv.conf-ը գեներացված ֆայլ է, որը ցույց է տալիս Windows-ի ընտրած stub resolver-ին։ Այս ամենից ոչինչ չի փոխվում նրանից, որ Windows-ի կողմում VPN հաճախորդ է գործարկվել։
Այդ պատճառով «դիտարկիչը աշխատում է» այնքան քիչ ապացույց է։ Դիտարկիչն օգտագործում է հոսթի կույտը, թունելը և հոսթի resolver քաղաքականությունը։ Ձեր shell-ն օգտագործում է այլ կույտ, որը պատահաբար կիսում է ֆիզիկական ցանցային քարտը։ Նրանք համընկնում են լավ դեպքում և տարբերվում են հենց այն ժամանակ, երբ VPN-ը տեղադրում է զտիչ, վերագրում է DNS ցանկը կամ ավելացնում է երթուղի վիրտուալ անջատիչի ենթացանցի համար։
Երկու թեստ որոշում է, թե որ աշխարհում եք, և դրանք պետք է գործարկվեն բաշխման ներսում։
getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.confԱնունների ձախողումը, երբ բառացի հասցեն պատասխանում է, resolver-ի խնդիր է։ Անունների և հասցեների միասին ձախողումը ճանապարհի խնդիր է, և resolver-ի ոչ մի խմբագրում դրան չի դիպչի։ Հետո գալիս են Windows-ի կողմի ապացույցները. Get-NetAdapter | Get-DnsClientServerAddress-ը և route print -4-ը ցույց են տալիս, թե արդյոք թունելը զավթել է այն ենթացանցը, որտեղ ապրում է ձեր VM-ը։
Առաջին առասպելը. կորպորատիվ DNS սերվերները լուծում են
Resolver-ի ֆայլը խմբագրելը դասական խորհուրդ է, և այն ճիշտ է ժամանակի մոտ կեսին։ Երբ ճիշտ է, ճիշտ է կոնկրետ պատճառով. գեներացված ֆայլը ցույց է տալիս resolver-ին, որը գիտի միայն հանրային անուններ, ուստի intranet.example.internal-ի հարցումը վերադառնում է որպես գոյություն չունեցող, թեև ճանապարհը կարգին է։
VPN-ի սերվերները ամրացնելը նշանակում է կանխել Windows-ին ֆայլը կրկին գեներացնելուց, որովհետև ձեռքով գրված ցանկացած ֆայլ փոխարինվում է հաջորդ մեկնարկին.
[network]
generateResolvConf = falseՊահպանեք դա որպես /etc/wsl.conf, գործարկեք wsl --shutdown-ը Windows-ից, ապա մեկնարկեք բաշխումը և գրեք /etc/resolv.conf-ը՝ թունելի սերվերները առաջինը և հանրային resolver-ը միայն որպես պահուստ։ Սա երկարաժամկետ փոփոխություն է սպասարկման ծախսով. ֆայլն այլևս չի հետևում հոսթին, ուստի երբ կորպորատիվ DNS հասցեները փոխվում են, բաշխումը շարունակում է հարցնել հներին։ Ինչ-որ մեկը պետք է պատասխանատու լինի այդ ֆայլի համար։
Այն ոչինչ չի անում նաև, երբ ձախողումն ավելի լայն է։ Եթե curl-ը դեպի 1.1.1.1 ժամանակավերջ է ստանում, թունելի հաճախորդը զտում է վիրտուալ անջատիչը կամ VM-ի ենթացանցը ուղղում թունել, և ճիշտ resolver-ը ձեզ տալիս է միայն անուններ, որոնց դեռ հնարավոր չէ հասնել։
Երկրորդ առասպելը. չափիչի փոփոխությունը մնում է
Երբ անունները լուծվում են, բայց երթևեկությունը դուրս է գալիս ֆիզիկական ադապտերով, լծակը ինտերֆեյսի չափիչներն են։ VPN ադապտերին տվեք բարձր արժեք, իսկ WSL անջատիչին՝ ցածր.
Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1Ապա հիշեք, որ հաճախորդի շատ կառուցվածքներում թունելի ադապտերը վերստեղծվում է ամեն միացման ժամանակ, և չափիչը վերադառնում է լռելյայնին։ Մեկանգամյա հրամանը ուղղում է, որը լուռ սպառվում է, սովորաբար հանգստյան օրերի ընթացքում, և տոմսը վերադառնում է «անցյալ շաբաթ աշխատում էր» արտահայտությամբ։ VPN իրադարձությամբ գործարկվող պլանավորված առաջադրանքը կամ միացումից հետո օգտատիրոջ կողմից գործարկվող սկրիպտը այս ուղղման ազնիվ տարբերակն է։
Նույն ժամկետնությունը վերաբերում է մեկ համառ նախածանցի համար ավելացված հոսթի երթուղիներին։ Դրանք արժեքավոր են որպես ախտորոշում, որովհետև ասում են՝ խնդիրը մեկ նպատակ է, թե ամբողջ ճանապարհը, բայց դրանք ճարտարապետություն չեն։
Երրորդ առասպելը. մեկ ուղղումը ծածկում է յուրաքանչյուր Windows կառուցվածք
| Approach | What it actually does |
|---|---|
| Resolver pin | Fixes private names only; no effect on path failures |
| Sidecar distribution | Forwards traffic over a socket to a helper VM, so the switch's filter no longer matters |
| Mirrored networking | Gives the distribution the host's interface set; also enables DNS tunnelling |
wsl-vpnkit-ը sidecar օրինակն է. փոքր բաշխումը տիրապետում է հոսթի կողմի ճանապարհին և վիրտուալ socket-ով փոխանցում է այլ բաշխումների համար, ուստի հավելվածների երթևեկությունը դադարում է կախված լինել զտված անջատիչից։ Անհրաժեշտ է, որ ստանդարտ ճանապարհը աշխատի, այսինքն՝ հեռացնել networkingMode և dnsTunneling վերագրանցումները %UserProfile%\.wslconfig-ից, վերականգնել generateResolvConf = true-ը յուրաքանչյուր աշխատող բաշխման մեջ և ծառայությունը մեկնարկել մուտքի պահին։
Հայելային ռեժիմը ներկառուցված այլընտրանքն է Windows 11 22H2-ում և ավելի նորերում, և դա մեկ կարգավորում գումարած անջատում է.
[wsl2]
networkingMode=mirroredԲաշխման ներսում ip addr-ն այնուհետև թվարկում է հոսթի ադապտերները, թունելը կարող է հայտնվել նրանց մեջ, և DNS թունելավորումը հարցումները փոխանցում է Windows-ի resolver-ով նույնիսկ այն ժամանակ, երբ հաճախորդը վերագրում է DNS ցանկը։ Սա համընդհանուր չէ. որոշ զտիչ վարորդներ դեռ գցում են հայելային ճանապարհը, և Hyper-V հրապարակի կանոնները կարող են պահանջել բացահայտ թույլտվություն։ Microsoft-ի WSL ցանցային ուղեցույցը այն էջն է, որը պետք է համեմատել ձեր կառուցվածքի հետ նախքան ավելի նորի համար գրված բաղադրատոմսը կիրառելը։
Փորձարկեք երեք բան յուրաքանչյուր փոփոխությունից հետո
Ընտրեք մեկ մեխանիզմ մեքենայի համար և գրեք այն, որովհետև երկուսը վատ են զուգակցվում։ Հայելային ռեժիմի վրա sidecar-ը կրկնապատկում է փոխանցումը, իսկ .wslconfig-ում հնացած sidecar գրառում ունեցող հայելային հոսթը հակված է ձախողվել արդիականացումից հետո, ոչ թե առաջ։
Ինչ էլ ընտրել եք, ընդունման թեստը բաշխման ներսում նույն երեք հարցումներն են. ներքին անուն, հանրային անուն և հում հասցե։ Ապա կրկնեք դրանք թունելն անջատելու և նորից միացնելուց հետո, և wsl --shutdown-ից հետո։ Միայն ներքին անվան ձախողումը resolver քաղաքականություն է. ներքին և հանրային անունների միասին ձախողումը աշխատող հասցեի դեպքում դեռ resolver քաղաքականություն է. ամեն ինչի ձախողումը ճանապարհն է։
Եթե մեկ ներքին հոսթ ձախողվում է, մինչ մնացածն աշխատում են, դադարեք նայել resolver-ին և փնտրեք բացակայող երթուղի այդ նախածանցի համար։ Եթե ամեն ինչ աշխատում է մինչև հաջորդ վերամիացումը, դուք գտել եք ուղղում, որը կախված է գործարկման ժամանակի վիճակից, և այն պետք է ավտոմատ կրկին կիրառվի կամ փոխարինվի վերևի երկու մեխանիզմներից մեկով։