WSL2-ը չի հասնում VPN ենթացանցին․ կարդացեք հոսթի երթուղին

Դիստրիբուտիվի ներսից դեպի ներքին սերվեր ping-ը ավարտվում է ժամկետանցությամբ, մինչդեռ նույն հասցեն պատասխանում է Windows-ից։ VPN-ը միացված է, և Windows-ի երթուղին ճիշտ է, ուստի բացը WSL-ի սահմանն է։ Անցեք ուղին ձախողված հրամանից հետ դեպի հոսթի ինտերֆեյս։ Ուղղումը կոնֆիգուրացիայի ֆայլում ֆիքսված CIDR չէ․ այն ընթացիկ հասցեն կարդալն ու ավելացնելն է այնտեղ, որտեղ դիստրիբուտիվը կարող է օգտագործել այն։

Հաստատեք, թե որտեղ է կանգնում ուղին

Կատարեք նույն թեստը երկու կողմերում՝ լուծեք և միացեք մեկ ներքին հոսթի Windows-ից, ապա կրկնեք դա դիստրիբուտիվում։ Windows-ում հաջողությունը գումարած դիստրիբուտիվում ժամկետանցությունը տեղորոշում է խափանումը նրանց միջև, ոչ VPN-ի հաճախորդում կամ ներքին սերվերում։ Արեք դա ցանկացած երթուղի փոխելուց առաջ, որպեսզի երկու արդյունքները նկարագրեն նույն նպատակակետը։

Դիստրիբուտիվի ներսում ip -4 addr-ը ցույց է տալիս վիրտուալ ադապտեր WSL NAT-ի տիրույթից հասցեով, իսկ ip route-ը ցույց է տալիս լռելյայն երթուղի դեպի WSL-ի դարպաս։ Կորպորատիվ նախածանցի համար երթուղի չկա, քանի որ հոսթի թունելային ադապտերը դիստրիբուտիվի ներսում համարժեք չունի։ Լռելյայն դարպասը տանում է դեպի WSL NAT, ոչ դեպի կորպորատիվ ցանց։

Կորպորատիվ երթուղին ավելացնելը՝ առանց նախապես հասանելի կապի վրա տեղական հասցե ավելացնելու, առաջացնում է ժամկետանցություն կամ ցանցն անհասանելի է սխալ։ Հասցեն այն մասն է, որն օգտագործելի է դարձնում երթուղին, ուստի նախ կարդացեք այն, իսկ երթուղին համարեք երկրորդ քայլ։

Ընտրեք հայելային ցանց կամ սկրիպտային երթուղի

Հայելային ցանցը դիստրիբուտիվին տալիս է հոսթի սեփական ինտերֆեյսները, ուստի թունելը և նրա երթուղիները հայտնվում են առանց պատճենման։ Գործառույթը կախված է վերջերս թողարկված Windows-ի կառուցվածքից և .wslconfig-ում networkingMode=mirrored-ից, և դրա միացումը փոխում է անկապ վարքագիծ, օրինակ՝ localhost-ի փոխանցումը։ Վերաբերվեք դրան որպես պլատֆորմի փոփոխություն, ոչ որպես երթուղու կարգավորում։ Եթե կառուցվածքը սատարում է, և կողմնակի ազդեցությունները ընդունելի են, սա ամենակարճ ուղին է։

Ավելի նեղ մոտեցումը պահպանում է լռելյայն NAT-ը և ամեն անգամ, երբ թունելը բարձրանում է, պատճենում է թունելի հասցեն և երթուղին դիստրիբուտիվի մեջ։ Այն աշխատում է ավելի շատ կառուցվածքներում, չի փոխում localhost-ի վարքագիծը և տեսանելիորեն ձախողվում է, երբ VPN-ն անջատված է։ Գինը փոքր սկրիպտ է, որը պետք է գործարկվի յուրաքանչյուր միացման ժամանակ։

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

Քաշեք թունելի ընթացիկ մանրամասները հոսթից

Համապատասխանեցրեք ադապտերը MAC հասցեով, ոչ անունով, քանի որ անունները փոխվում են VPN-ի հաճախորդի և միացման հերթականության հետ։ Մեկ անգամ թվարկեք ադապտերները, նշեք թունելային ադապտերի MAC-ը, ապա հարցրեք նրա հասցեն և նախածանցը։ MAC-ը մնում է վիրտուալ ադապտերի հետ վերամիացումների միջև, մինչդեռ անունը և ինտերֆեյսի ինդեքսը՝ ոչ։

powershell.exe 'Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" } | Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress, PrefixLength'

Դարպասը գալիս է ինտերֆեյսի կոնֆիգուրացիայից։ Նախ ստացեք ինտերֆեյսի ինդեքսը, ապա կարդացեք հաջորդ ցատկը։ Ինդեքսը կարող է փոխվել վերագործարկումից կամ ադապտերի վերակայումից հետո, դրա համար սկրիպտը պետք է կարդա այն, ոչ թե պահի։

powershell.exe '(Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" }).InterfaceIndex'
powershell.exe '(Get-NetIPConfiguration -InterfaceIndex 27).IPv4DefaultGateway.NextHop'

Անցկացրեք ելքը tr -d '\r'-ով նախքան այն փոփոխականին վերագրելը։ PowerShell-ը տողերն ավարտում է carriage return-ով, և առանց հեռացնելու վերջին դաշտը կրում է թաքնված նշան, որը երթուղու հրամանը ձախողում է շփոթեցնող վերլուծության սխալով։

Կիրառեք հասցեն և երթուղին դիստրիբուտիվի ներսում

Տեղադրեք թունելի հասցեն որպես նախածանցով հասցե դիստրիբուտիվի ինտերֆեյսի վրա, ապա ուղղորդեք կորպորատիվ բլոկը հոսթի դարպասով։

sudo ip addr add 172.20.14.37/22 dev vpn
sudo ip route add 172.20.0.0/16 via 172.20.12.1 dev vpn

NetworkManager-ը գցում է ձեռքով կարգավորված հասցեն, երբ կապը ցիկլվում է, և ոչ մի DHCP հաճախորդ փոխարինում չի խնդրում։ Սահմանեք մեթոդը ավտոմատ, որպեսզի յուրաքանչյուր վերամիացում թարմացնի հասցեն, ապա նորից բարձրացրեք կապը։ Ձեռքով մեթոդը կայուն է թվում մինչև առաջին վերամիացումը։

nmcli con show vpn
sudo nmcli con mod vpn ipv4.method auto
sudo nmcli con up vpn

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

Ամրացրեք անունը և ապացուցեք ուղին

Միջուկը կարող է ցանցի փոխարկումից հետո վերանվանել դիստրիբուտիվի ինտերֆեյսը eth1-ի և eth2-ի միջև, և անվան վրա գրված սկրիպտն այդ ժամանակ խմբագրում է սխալ սարքը։ MAC-ին կապված udev կանոնը ինտերֆեյսին տալիս է կայուն պիտակ։

SUBSYSTEM=="net", ACTION=="add", ATTRS{address}=="3c:52:82:0a:1b:7c", NAME="vpn"

Ապա ստուգեք հասցեով, երթուղով և իրական TCP միացումով՝ ip -4 addr show dev vpn, ip route get 172.20.4.10 և միացում հայտնի ներքին պորտին։ Երթուղու որոնումը պետք է նշի vpn սարքը և ձեր ավելացրած աղբյուրի հասցեն։

Եթե բոլոր երեքը անցնում են դիստրիբուտիվի ներսում, և կապը դեռ ձախողվում է, փաթեթը լքում է WSL-ը և դեն է նետվում Windows-ի կողմում։ Ստուգեք հոսթի firewall-ը և VPN-ի հաճախորդի սեփական զտումը նախքան սկրիպտը փոխելը, քանի որ ևս մեկ երթուղու խմբագրում չի շտկի փաթեթը, որն արդեն հասնում է հոսթին։