VM երթևեկության երթուղավորում host-only ցանցում TUN OpenVPN սերվերի միջոցով
Առանձին պահեք թունելը և host-only նախածանցը, հրեք հյուրի երթուղին, ապա յուրաքանչյուր վիրտուալ մեքենայի տվեք դիտավորյալ վերադարձի ուղի հոսթի միջով։
host-only ադապտերները ստեղծում են տեղական վիրտուալ ցանց, իսկ երթուղավորված TUN թունելները IP փաթեթներ են տեղափոխում հասցեների միջև։ Դրանցից ոչ մեկը կամուրջ չէ մյուսին, դրա համար էլ աշխատող կարգավորումը պետք է ասի, թե ով է փոխանցում և ումն է վերադարձի երթուղին։ Եթե այս երկու վերապահումները շփոթեք, հյուրը թունելին կպատասխանի այնպիսի աղբյուրով, որը թունելի հաճախորդը երբեք չի խնդրել։ Ստորև ներկայացված ձևավորումը երկու նախածանցներն էլ առանձին է պահում և վերադարձի ուղին դարձնում է բացահայտ։
Երկու ցանց, երկու նախածանց
Թունելի լողավազանին և host-only ցանցին տվեք տարբեր նախածանցներ և երբեք մի՛ օգտագործեք մեկը մյուսի փոխարեն։ Այս օրինակում VPN լողավազանը 10.44.0.0/24 է, իսկ host-only ցանցը՝ 192.168.99.0/24, հոսթը՝ 192.168.99.1, և մի հյուր՝ 192.168.99.20 հասցեով։ Նույն նախածանցը թե՛ TUN սարքին, թե՛ host-only ադապտերին տալը նրանց չի միավորում։ Այն ստեղծում է երկու պահանջ մեկ հասցեային տիրույթի համար, և երթուղային աղյուսակը հետո պատասխանում է այն պահանջի օգտին, որը պատահաբար պահել է։
host-only ադապտերը գոյություն ունի հոսթի վրա և հյուրի ներսում, և ինքն իրենով մեքենայից դուրս ելքի ուղի չունի։ Կամուրջային և NAT միացումներն այլ ազդեցություն ունեն, և կամուրջային ռեժիմի անցնելը պարտադիր չէ մեկ հյուրի ծառայությանը հասնելու համար։
Հոսթն արդեն պահում է ուղին
Նայեք, թե ինչ կա, նախքան որևէ բան ավելացնելը։ Հոսթն ունի ինտերֆեյս host-only ցանցում և երթուղի այդ նախածանցի համար, երկուսն էլ ստեղծվել են, երբ ադապտերը բարձրացավ։
ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forwardԵրրորդ տողն այն մեխանիզմն է, որը հոսթին դարձնում է ցատկող կետ։ Առանց դրա՝ թունելից եկող փաթեթը հասցեագրվում է ցանցին, որին հոսթը կարող է հասնել, բայց չի փոխանցի։ Փոխանցումը անհրաժեշտ է և բավարար չէ։ Զտման քաղաքականությունը դեռևս որոշում է, թե արդյոք թույլատրված է կոնկրետ հոսքը թունելի ինտերֆեյսի և host-only ինտերֆեյսի միջև, և այդ որոշումը պետք է լինի գրավոր, այլ ոչ թե լռելյայն քաղաքականության մեջ, որը ոչ ոք չի կարդացել։
Հրեք երթուղին, ապա զտեք այն, ինչին այն հասնում է
Սերվերը կարող է host-only նախածանցը տրամադրել այն հաճախորդներին, որոնք ընդունում են հրված երթուղիները, ինչը նույն մեխանիզմն է, որն օգտագործվում է թունելի հետևում գտնվող ցանկացած այլ ենթացանցի համար։
push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPTԱյս երկու կանոնները թույլատրում են մեկ ծառայություն մեկ ուղղությամբ և դրա պատասխանները։ Ամբողջ նախածանցին հասնող երթուղին և մեկ պորտ թույլատրող զտիչը դիտավորյալ համակցություն են. երթուղին գումարած անվերապահ ընդունումն այն ճանապարհն է, որով լաբորատոր ծառայությունը դառնում է բաց ծառայություն։ Հրված երթուղին նույնպես լիազորում չէ։ Հաճախորդն ընդունում է այն, հոսթը փոխանցում է այն, և հյուրի firewall-ը և ծառայությունն ինքը դեռ ձայն ունեն։
Հյուրին վերադարձի ուղի է պետք
10.44.0.x-ից հասանելի հյուրը պետք է իր պատասխաններն ուղարկի հոսթի host-only հասցեին, կամ հոսթը պետք է թարգմանի աղբյուրը։ VirtualBox DHCP-ից հասցե ստանալը ոչինչ չի ասում այս երկու դասավորություններից ոչ մեկի մասին։
ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15Այդ երթուղին հյուրի ներսում ավելացնելը պահպանում է սկզբնական աղբյուրը, ինչը իմաստալից է պահում յուրաքանչյուր հաճախորդի քաղաքականությունն ու մատյանները։ Հոսթի վրա սահմանափակ աղբյուրի թարգմանությունը այլընտրանքն է, և այն աշխատում է, բայց այն գնով, որ թաքցնում է, թե որ հաճախորդն է միացել։ Համընկնումը ձախողման մյուս ռեժիմն է։ Հեռավոր հաճախորդը, որի տնային LAN-ն արդեն օգտագործում է 192.168.99.0/24, հրված երթուղին կկարդա որպես իր ցանց, և սերվերի կողմում ոչ մի փոփոխություն չի լուծում այդ երկիմաստությունը։ Վերահամարակալեք մի կողմը կամ ընտրեք նախածանց, որը հավանաբար չի բախվի։
TUN սարքը IP փաթեթներ է տեղափոխում, ուստի հյուրի ներսում լռելյայն դարպաս ավելացնելը թունելը host-only ադապտերի հետ Ethernet հատված չի դարձնում։ TAP կամուրջը այլ ձևավորում է՝ իր հաճախորդների աջակցությամբ և հասցեների սեփականությամբ, և երկու նկարագրությունները խառնելը հանգեցնում է կարգավորումների, որոնք երբեք չեն մերձենում։
Ստուգեք, ապա դարձրեք այն վերագործարկմանը դիմացկուն
Փորձարկեք մեկ անվնաս ծառայություն սովորական հեռավոր հաճախորդից, ստուգեք հյուրի վերադարձի երթուղին և հաստատեք, որ ձեր չթույլատրած ծառայությունը մերժվում է, այլ ոչ թե դանդաղ է։
ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20Ապա վերագործարկեք VPN ծառայությունը և վիրտուալ մեքենայի ցանցը, և կրկնեք նույն երեք ստուգումները։ Ձեռքով ավելացված երթուղին ապրում է մինչև հաջորդ վերագործարկումը, և այն կարգավորումը, որն աշխատում է միայն տաք սեսիայում, ձևավորում չէ։ Գրանցեք երկու նախածանցները, փոխանցման քաղաքականությունը և հյուրի երթուղին միասին։ Ով ավելացնի հաջորդ վիրտուալ մեքենան, երեքի կարիքն էլ կունենա, և հակառակ դեպքում նորից կհայտնաբերի դրանք մեկ ձախողված միացումից հետո։