Միացնե՞լ VPN-ը հոսթի վրա, թե VM-ի ներսում։ Որոշման ուղեցույց
Թունելի սեփականատերն է որոշում՝ ինչն ինչ է ծածկում։ Ընտրեք տեղը հոսթի կամ հյուրի կողմում, ապա հաստատեք այն երթուղու, DNS-ի և ելքի ստուգումներով հյուրի ներսում։
Թունելը հյուրի ներսում կառուցելը և այն հոսթի վրա կառուցելը երկուսն էլ փոխում են այն հասցեն, որը հայտնում է բրաուզերը, և նմանությունն այստեղ է ավարտվում։ Հյուրին պատկանող թունելը պահում է իր բանալիները, իր լռելյայն երթուղին և իր լուծիչը հյուրի միջուկում, մինչդեռ հոսթը գաղտնագրված փաթեթները փոխանցում է մեկ հեռավոր հասցեի։ Հոսթին պատկանող թունելը դրա հայելային պատկերն է: հոսթի հաճախորդը պահում է նստաշրջանը և կիրառում է երթուղիներ ու քաղաքականություն, իսկ հյուրը փոխառում է այն, ինչ դուրս է գալիս։ Սխալ սեփականատեր ընտրելու դեպքում յուրաքանչյուր հետագա ախտանիշ ձեզ կուղարկի սխալ մեքենայի մոտ։ Երկու հրաման լուծում են հարցը մոտ մեկ րոպեում, և այս ուղեցույցի մնացած մասը այն է, թե ինչ անել պատասխանի հետ։
Որոշեք սեփականատիրոջը, նախքան հաճախորդին դիպչելը
Կանոնը վերաբերում է նրան, թե որտեղ է ստեղծվում գաղտնագրված տեքստը, ոչ թե նրան, թե որ մեքենան է ցույց տալիս VPN-ի պատկերակ։ Եթե այն ստեղծում է հյուրը, հյուրին պետք է աշխատող երթուղի դեպի VPN սերվերը և ոչինչ ավելի հոսթից։ Եթե այն ստեղծում է հոսթը, հյուրի ուղին հոսթով պետք է դիմանա ցանկացած քաղաքականության, որը հոսթի հաճախորդը պարտադրում է տեղական երթևեկությանը։
Երեք հարց սովորաբար ընտրում են տեղը ձեզ փոխարեն։ Արդյո՞ք հյուրի երթևեկությունը պետք է դիմանա հոսթի վրա գտնվող կորպորատիվ հաճախորդին։ Այդ դեպքում թունելը հյուրի ներսում է։ Արդյո՞ք մի քանի հյուրերի պետք է մեկ վկայագիր և մեկ ելքի հասցե։ Այդ դեպքում այն հոսթի վրա է՝ դիտավորյալ կարգավորված փոխանցմամբ։ Արդյո՞ք հյուրի երթևեկությունը պետք է ամբողջությամբ մնա հոսթի VPN-ից դուրս։ Այդ դեպքում հյուրի թունելը միակ դասավորությունն է, որ դա տալիս է կառուցվածքով։
Պատասխանը գրեք մեկ տողով VM-ի անվան կողքին՝ guest-owned կամ host-owned։ Վեց մեքենայից բաղկացած լաբորատորիայում այդ նշումը ավելի շատ ժամանակ է խնայում, քան ստորև նշված ցանկացած քայլ, որովհետև այն խանգարում է ձեզ որոնել թունելի խնդիր, որը երբեք չի եղել այն մեքենայում, որտեղ դուք մուտք եք գործել։
WSL1-ը և WSL2-ը հակառակ դեպքեր են
WSL1-ը վիրտուալ մեքենա չէ, ուստի տեղադրման հարցը հիմնականում գոլորշիանում է։ Նրա Linux երկուական ֆայլերը աշխատում են Windows-ի ցանցային կույտի դեմ թարգմանական շերտով, և Linux VPN հաճախորդը չունի ինքնուրույն ինտերֆեյսեր կարգավորելու համար։ Աշխատող դասավորությունը Windows-ի կողմում թունելն է, և բաշխումը օգտվում է արդյունքից՝ ոչինչ չտիրանալով։
WSL2-ը հակառակն է։ Այն իրական միջուկ է աշխատեցնում թեթև օժանդակ VM-ում՝ Hyper-V վիրտուալ անջատիչի հետևում, և նրա հասցեային տարածքը NAT-վում է հոսթի կողմի ադապտերով։ Այդ պատճառով բաշխման ներսում Linux հաճախորդն իրեն պահում է այնպես, ինչպես ֆիզիկական Linux տուփի վրա: այն ստեղծում է tun0 կամ wg0, տեղադրում է իր երթուղիները և աշխատում է։ Խափանումն ապրում է հոսթի կողմում։ Երբ Windows VPN հաճախորդը միանում է քաղաքականությամբ, որը արգելափակում է երթևեկությունը տեղական ցանցերում, այն WSL2 ենթացանցը համարում է անվստահելի տեղական ցանց և կտրում է NAT ուղին։ Այնուհետև բաշխումը կորցնում է DNS-ը և ելքի հասանելիությունը, մինչ նրա սեփական թունելը դեռ առողջ է: wg show-ը հաղորդում է ձեռքսեղմում, ip route-ը ճիշտ է թվում, և curl-ը կախվում է։
Թե որ ուղղումը կարող եք օգտագործել, կախված է Windows-ի կառուցվածքից։ Ավելի հինը հոսթի հաճախորդում WSL ենթացանցի համար բացառություն է, որն ավելացվում է հաճախորդի տեղական ցանցի կամ բաժանված թունելի կարգավորումների տակ։ Ավելի նորը, այն Windows 11 կառուցվածքներում, որոնք աջակցում են դրան, հայելային ցանցավորումն է: տեղադրեք networkingMode=mirrored-ը %UserProfile%\.wslconfig-ի [wsl2] բաժնում, գործարկեք wsl --shutdown-ը, և բաշխումը կկիսի հոսթի ինտերֆեյսները՝ մասնավոր NAT ենթացանցի փոխարեն։ Հայելային ռեժիմը նաև փոխում է localhost-ի և մուտքային պորտերի վարքը, ուստի դիտարկեք այն որպես միգրացիա, ոչ որպես անջատիչ։
NAT, կամուրջ և ինչ կարող է տեսնել հոսթը
NAT-ի ներքո հյուրի թունելի փաթեթները հասցեագրվում են VPN սերվերի հանրային հասցեին և դուրս են գալիս հոսթի ադապտերով որպես գաղտնագրված UDP կամ TCP։ Հոսթը տեսնում է մեկ հոսք և նրա բայթերի քանակը, ոչինչ՝ դրա ներսի նպատակակետերի մասին։ Կամուրջ ադապտերի ներքո հյուրն ունի իր սեփական 2-րդ շերտի ինքնությունը ֆիզիկական LAN-ում, վերցնում է իր DHCP վարձույթը և MAC-ի վրա հիմնված ցանկացած քաղաքականության համար երևում է որպես երկրորդ սարք։ Ոչ մի ռեժիմ թույլ չի տալիս հոսթին կարդալ թունելի ծանրաբեռնվածությունը: կամրջված հյուրը պարզապես շատ ավելի տեսանելի է իր շուրջի ցանցի համար։
Մեկուսացման համար էլ կա ստորին սահման։ Հյուրը չի կարող թաքնվել այն մեքենայից, որին պատկանում է նրա հիշողությունը, և ով վերահսկում է հոսթը, կարող է բանալիներ կարդալ հյուրի RAM-ից։ Հյուրի թունելը ձեզ տալիս է երթուղային սահման և չարամիտ ծրագրերի սահման, ոչ պաշտպանություն նոթբուքը պահող մարդուց։ Արժե փաստաթղթավորված ադապտերային ռեժիմները բաց պահել ընտրության ընթացքում, քանի որ ռեժիմը փոխում է և՛ այն, ինչ տեսնում է հոսթը, և՛ այն, ինչ տեսնում է LAN-ը։
Ուղեցույց: տեղադրել, կարգավորել, ապացուցել
Գործարկեք այս չորս ստուգումները հերթով թարմ հյուրի shell-ում և կանգ առեք առաջինի մոտ, որը չի համընկնում ձեր գրած սեփականատիրոջ հետ։
ip route get 1.1.1.1-ը, որը վերադարձնում էtun0կամwg0, նշանակում է հյուրի սեփականություն, իսկeth0-ը՝ մասնավոր հաջորդ ցատկով, նշանակում է հոսթի սեփականություն։resolvectl query example.com, կամ կարդացեք/etc/resolv.conf-ը այնտեղ, որտեղ հյուրը լուծիչ ծառայություն չի աշխատեցնում։ Այն թունելը, որը կրում է երթևեկություն, բայց ոչ DNS, ամենատարածված կիսակարգավորված վիճակն է։- Համեմատեք ելքերը:
curl -4 -s https://ifconfig.me-ը հյուրում ընդդեմcurl.exe -4 -s https://ifconfig.me-ի հոսթի վրա։ Տարբեր հասցեներ նշանակում են, որ հյուրն է տիրում թունելին, և VPN-ի վրա գտնվող հոսթը՝ տնային մատակարարին ցույց տվող հյուրով, այն դեպքն է, երբ ոչինչ չի ժառանգվել։ - Կրկնեք երկուսն էլ
-6-ով։ Միայն v4 թունելը արտահոսում է v6, եթե հաճախորդը չարգելափակի կամ չուղղորդի այն, և շատ հաճախորդներ լռելյայն թողնում են v6-ը ֆիզիկական ինտերֆեյսի վրա։
Հոսթ-դարպասի ձևավորման դեպքում, որտեղ մի քանի հյուրեր կիսում են մեկ թունել, հոսթը պետք է փոխանցի և թարգմանի։ Linux հոսթի վրա դա երեք մաս է, և հյուրը հանգիստ վերադառնում է իր սովորական երթուղուն, երբ դրանցից որևէ մեկը բացակայում է:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPTWireGuard-ի կողմում հոսթի գործընկերոջ AllowedIPs-ը պետք է ներառի հյուրերի ենթացանցը, օրինակ՝ 192.168.122.0/24, հակառակ դեպքում վերադարձի փաթեթները երբեք չեն հասնի, և կարգավորումը նման կլինի հրային պատի խնդրի։ Windows հոսթը նույն արդյունքին հասնում է Ինտերնետ կապի համօգտագործմամբ կամ Hyper-V անջատիչի վրա NAT կանոնով, և նրան անհրաժեշտ է վերադարձի ուղու նույն ստուգումը։
Երբ դասավորությունը դեռ բաց է, այս աղյուսակը ծածկում է ամենահաճախ հանդիպող տարբերակները:
| Situation | Owner | Check first |
|---|---|---|
| One VM, host also on a corporate VPN | Guest | Does the host client block local networks? |
| Six lab VMs, one exit address | Host plus forwarding | ip_forward, NAT rule, server AllowedIPs |
| Malware or research VM | Guest, NAT | Snapshot age and resolver state |
| Bridged VM on an office LAN | Guest | DHCP lease and port security |
Երկու թունել, երկու հյուր և նրանց միջև հակասությունները
Երբ միաժամանակ երկու ելք է պետք, դիմացող ձևը մեկ թունելն է յուրաքանչյուր հյուրի համար։ Յուրաքանչյուր VM պահում է իր լռելյայն երթուղին և լուծիչը, հոսթը մնում է սովորական ցանցում, և երկու թունելները երբեք չեն վիճում նույն երթուղային աղյուսակի համար։ Երկու հյուրերի կամրջելը նաև չի միավորում նրանց երթուղիները: վիրտուալ ցանցը տալիս է ուղի, և յուրաքանչյուր հաճախորդի դեռ պետք է ասել, որ այս տեղական երթևեկությունը կարող է շրջանցել թունելը։
Հոսթի թունելի և հյուրի թունելի միասին աշխատեցնելը օրինական է, և դիտավորյալ ներդնումը երբեմն հենց այն է, ինչ ուզում եք՝ հյուրը դուրս է գալիս իր թունելով, և այդ թունելը դուրս է գալիս հոսթի թունելով։ Ընդհատման է վերածում այն, որ ոչ ոք չի գրել, թե որ վերջնակետը որ շերտով պետք է հասնել։ Պահեք երկու սյունակից բաղկացած ցանկ՝ նպատակակետ և սեփականատեր, և երթուղային հակասությունը դառնում է որոնում՝ հայտնագործության կեսօրի փոխարեն։
Ստուգեք, ապա վերականգնումը թողեք սեփականատիրոջը
Փորձարկեք հյուրի ներսից թարմ հավելվածային պրոցեսով: երթևեկություն, անունների լուծում, հասցեների երկու ընտանիքները և ինչ է տեղի ունենում, երբ թունելն ընկնում է։ Հոսթի VPN պատկերակը ոչինչ չի ասում հյուրի ծածկույթի մասին, և դա է ամենատարածված կեղծ հաստատումը այս ամբողջ բնագավառում։
Վերականգնումը նույնպես պատկանում է սեփականատիրոջը։ Հյուրի սեփականության թունելը վերականգնվում է հյուրի սեփական հաճախորդով և նրա գրած երթուղիներով։ Հոսթի սեփականության ձևավորումը վերականգնվում է հոսթի բեռնարկման հաջորդականությամբ, և փոխանցման կանոնները չեն վերապրում վերագործարկումը, եթե միավոր կամ մեկնարկային առաջադրանք դրանք նորից չկիրառի։ Վերականգնված պատկերը տեղադրում է, ոչ չեղարկում, որովհետև այն սկավառակի հետ վերադարձնում է հին հավատարմագրեր և հին երթուղիներ։ Նախքան աշխատանքը ավարտված հայտարարելը հաստատեք, որ սեփականատերը դեռ համապատասխանում է ձեր գրած տողին, որ DNS-ը և հասցեների երկու ընտանիքները լուծվում են հյուրի ներսում, որ մեռած թունելը թողնում է օգտագործելի ցանց՝ սև խոռոչի փոխարեն, և որ վերագործարկումը կամ պատկերի վերականգնումը վերարտադրում է նույն վիճակը։