VMware-ի կամրջված հյուրը OpenVPN-ից հետո կորցրել է ցանցը

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

Հյուրը չփոխվեց, կամուրջը փոխվեց

Windows-ում OpenVPN հաճախորդի տեղադրումը ավելացնում է վիրտուալ ցանցային ադապտեր, որին ծառայությունը կապվում է, երբ թունելը բարձրանում է։ Օպերացիոն համակարգի համար այն սովորական ինտերֆեյս է՝ կապի վիճակով և հաճախ սեփական հասցեներով։ Դա բավական է, որպեսզի VMware-ը այն դիտարկի որպես կամրջի թեկնածու։

VMnet0-ը լռելյայն դրված է Ավտոմատ, ինչը նշանակում է, որ հիպերվիզորը յուրաքանչյուր կամուրջ ստեղծելիս ընտրում է հոսթի ադապտեր։ Նոր տեղադրված վիրտուալ ադապտերը մտնում է այդ խմբի մեջ, և եթե այն ընտրվի, հյուրի ուղարկած յուրաքանչյուր շրջանակ գնում է թունելային սարք, այլ ոչ թե ֆիզիկական անջատիչի պորտ։

Ամրացրե՛ք կամուրջը կամ երթուղայնացրե՛ք հյուրին

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

Որոշե՛ք դա նախ, որովհետև երկու պատասխանները տանում են տարբեր աշխատանքի։ Հերթականությունը շրջելը ստեղծում է ճիշտ ամրացված կամուրջ, որը կապված է հյուրի հետ, որը երբեք չպետք է կամրջվեր։

Առաջին ճյուղի համար բացե՛ք Virtual Network Editor-ը հոսթում, ընտրե՛ք VMnet0-ը և Ավտոմատը փոխարինե՛ք ֆիզիկական ադապտերով։ Եթե մի քանի ադապտեր կա, օգտագործե՛ք ավտոմատ կարգավորումների ցանկը և հանե՛ք նշումը այն ամենից, ինչը երբեք չպետք է կրի հյուրի երթևեկությունը՝ OpenVPN TAP կամ Wintun սարքը, ինչպես նաև Hyper-V, WSL, Docker և loopback ադապտերները։ Թողե՛ք նշված և՛ լարային, և՛ անլար ֆիզիկական ադապտերը նոութբուքում, այլապես հյուրը կկորցնի կամուրջը հաջորդ անգամ, երբ օգտատերը միացնի այն դոկին։

Երեք պայման, որոնք որոշում են ընտրությունը

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

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

VMware Player-ը իր ինտերֆեյսում ցանցի խմբագրիչ չունի, ուստի հոսթը, որտեղ աշխատում է միայն Player-ը, այս կարգավորումներին հասնելու համար պետք է ինքնուրույն խմբագրիչ կամ Workstation տեղադրում։ Այդ սահմանափակումը երբեմն ինքն է որոշում մոտեցումը։

Կարդացե՛ք արդյունքը հյուրի ներսից

Վերագործարկե՛ք վիրտուալ ցանցային քարտը կամ վերագործարկե՛ք հյուրին, որպեսզի այն նորից վարձակալություն հայցի։ Ապա կարդացե՛ք, թե ինչ է իրականում ստացել, այլ ոչ թե ինչ հոսթը կարծում է, թե կարգավորել է։

ipconfig /all
ip addr
ip route

Կարդացե՛ք այդ ելքի երկու դաշտը և առայժմ անտեսե՛ք մնացածը։ Դարպասը պետք է լինի LAN երթուղղիչը, իսկ ադապտերի նկարագրությունը պետք է նշի VMware Ethernet սարքը, այլ ոչ թե թունել։ 169.254.0.0/16-ի ներսում ինքնահատկացված հասցեն նշանակում է, որ ոչ մի DHCP սերվեր չի պատասխանել, և հենց այդպես է թունելային ադապտերի վրա կամուրջը երևում հյուրի կողմից։

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