VirtualBox NAT թե կամուրջ՝ որտեղ է ավարտվում VM-ի VPN-ը

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

Ով է իրականում ավարտում գաղտնագրված սեանսը

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

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

NAT-ը վերագրում է հյուրին, մինչև այն նմանվի հոսթին

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

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

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

Կամուրջը հյուրին տալիս է իր վարձույթը և իր բացվածությունը

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

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

Ինչու հյուրը չի կարող լինել հոսթի դարպասը

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

Աշխատունակ փոխարինողներն են փոխանցումները և վստահված սերվերները։ SSH տեղական փոխանցումը թույլ է տալիս հոսթին միանալ իր loopback-ին, մինչ հյուրը հոսքը տանում է թունել, ինչը ծածկում է TCP ծառայությունները՝ առանց երկրորդ հաճախորդ տեղադրելու։ Հոսթի սեփական IP երթևեկին փոխարենը հյուրի թունելը օգտագործել տալը պահանջում է երթուղիչ հյուրի ներսում, գումարած հստակ երթուղի հոսթի վրա և թարգմանություն հոսթի վրա։ Սա փոքր ցանցային ձևավորում է, ոչ թե նշատուփ, և պահանջում է վերադարձի ուղու ծրագիր։ Երբ հյուրը գոյություն ունի միայն հաճախորդը գործարկելու համար, դիր հաճախորդը հոսթի վրա և ջնջիր ավելորդ թռիչքը։

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Լուծիչներն ու երթուղիները չեն հատում սահմանը

DNS-ը հետևում է այն ադապտորին, որը ստացել է ընտրանքը, ուստի հյուրը չի ժառանգում հոսթի թունելի լուծիչը, և հոսթը երբեք չի իմանում հյուրին ուղարկված սերվերը։ Ուղարկված dhcp-option DNS արժեքները վերաբերում են այն ինտերֆեյսին, որը դրանք ընդունել է, և դրա համար հաճախորդ չունեցող կամրջված հյուրը չի կարող լուծել ներքին անունները։ NAT հյուրը սովորաբար օգտագործում է հիպերվիզորի DNS մշակումը, և տարբերությունը երևում է մեկ հրամանով յուրաքանչյուր միջավայրում։

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

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