VirtualBox VPN լաբորատորիա՝ դարպասային VM, թե միայն հոսթի ցանց
Ընտրեք ուղղորդված դարպասային VM-ի և միայն հոսթի սեգմենտի միջև VirtualBox VPN լաբորատորիայի համար, ապա ստիպեք հյուրին փակ ձախողվել, երբ թունելն ընկնի։
Դուք պետք է որոշեք, թե որքան մեքենայություն է արժանի ձեր VPN լաբորատորիան։ Երկու VirtualBox սեգմենտների միջև ուղղորդված դարպասային VM-ն վերարտադրում է հասցեների թարգմանությունը, վերադարձի ուղին և այն firewall-ի դիրքը, որի հետևում նստում է իրական հաճախորդ։ Մեկ միայն հոսթի սեգմենտը ձեզ տալիս է մեկ վերահսկվող դուռ և ոչինչ ավելին։ Դարպասային տարբերակը արժե երեք հյուր և մեկ ուղղորդման աղյուսակ, որը դուք պահպանում եք՝ միայն հոսթի տարբերակը արժե մեկ հյուր և մեկ քաղաքականություն։ Երեք հարց բաժանում է նրանց, և երրորդը որոշում է՝ ձեր թեստը կարո՞ղ է ընդհանրապես անցնել։
Պատասխանեք երեք հարցի, նախքան ինչ-որ բան կլոնավորելը
Սկսեք նրանից, ինչ պետք է դիտարկի VPN սերվերը։ Եթե սերվերը պետք է տեսնի աղբյուրի հասցե, որը թեստային հյուրինը չէ, ինչ-որ բան պետք է թարգմանի նրանց միջև, և այդ ինչ-որ բանը պետք է լինի ձեր վերահսկած երթուղիչը։ Միայն հոսթի ցանցը հոսթին տալիս է ադապտեր հյուրի սեգմենտում, ոչ թարգմանիչ։ Երբ հյուրն այնուհետև պետք է հասնի ինչ-որ արտաքին բանի, դուք միացնում եք NAT ադապտեր, և VirtualBox-ի սեփական NAT շարժիչը վերագրում է աղբյուրը՝ ձեզ չհարցնելով։
Ապա հարցրեք՝ կարո՞ղ է հյուրը հասնել ինչ-որ բանի բացի թունելից։ Այդ պատասխանն ընտրում է ներքին կամ միայն հոսթի, և հենց այդ հարցն է, որ բաց թողնում են լաբորատոր նկարագրությունների մեծ մասը։ Վերջում հարցրեք, թե ինչ պետք է տեղի ունենա, երբ թունելն ընկնի, որովհետև դա որոշում է քաղաքականություն, ոչ թե տոպոլոգիա, և լաբորատորիան, որն ապացուցում է միայն երջանիկ ուղին, գրեթե ոչինչ չի փորձարկել։
| What the test requires | Routed gateway VM | Host-only guest |
|---|---|---|
| Server sees a translated source address | Yes, from your own MASQUERADE rule | No, VirtualBox NAT does it instead |
| The guest has exactly one egress | Yes, while the second adapter faces the tunnel | Only until a NAT adapter is attached |
| Policy is testable during a tunnel failure | Rules live in one place | Rules live on each guest |
Միացրեք երեք դերերը ներքին ցանցերով
Օգտագործեք երեք հյուր և երկու անվանված սեգմենտ, ընդ որում դարպասը միակ մեքենան է, որն ադապտեր ունի երկուսում էլ:
VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LANՆերքին ցանցի համար առանձին ստեղծման քայլ չկա։ --intnet1-ի տողը հենց սեգմենտն է՝ երկու մեքենա այն կիսում են միայն այն դեպքում, երբ անունը ճշգրտորեն համընկնում է, և հոսթի վրա ոչինչ կցված չէ դրան։ Հենց այդ վերջին հատկությունն է լաբորատորիայի մաքուր կրկնելիության պատճառը, քանի որ հոսթի երթուղիները, նրա սեփական VPN հաճախորդը և firewall-ը չեն կարող պատահաբար հասնել հյուրերին։ Ներքին սեգմենտը նաև DHCP սերվեր չունի, եթե դուք չավելացնեք մեկը, այնպես որ ստատիկ հասցեները ամենակարճ ուղին են։
Հաճախորդին տվեք միայն նրա WAN հասցեն, ընդ որում լռելյայն դարպասը մատնանշում է դարպասի WAN հասցեին։ Սերվերը ստանում է LAN հասցե և որպես լռելյայն դարպաս օգտագործում դարպասի LAN հասցեն։ Հյուրը, որը մեկ սեգմենտում երկու հասցե է պահում կամ մոլորված երթուղի ունի դեպի մյուս սեգմենտը, ունի երթուղիչի շուրջը տանող ուղի, և ներքևի թեստերը ձեզ սուտ կասեն։
Ես VM-ների անունների կողքին տեքստային ֆայլ եմ պահում չորս հասցեներով և երկու սեգմենտի անուններով և այն տեղադրում եմ ամեն shell-ում։ Շաբաթներ անց, երբ պրոֆիլի փոփոխությունը ինչ-որ բան կոտրում է, այդ ֆայլը տարբերությունն է պրոֆիլը վրիպազերծելու և սեփական հիշողությունը վրիպազերծելու միջև։
Ընտրեք ներքին կամ միայն հոսթի այն սեգմենտի համար, որը չպետք է արտահոսի
Միայն հոսթի ռեժիմը վիրտուալ ադապտեր է ստեղծում հենց հոսթի վրա, սովորաբար vboxnet0, և հոսթին հասցե է տալիս հյուրի սեգմենտում։ Դա հարմար է կառավարման համար և մահացու՝ մեկուսացման թեստի համար, որովհետև հոսթն այժմ կարող է ուղղակիորեն հասնել հյուրին, և հոսթի կողմի յուրաքանչյուր ծառայություն դառնում է հնարավոր ուղի։ Ներքին ռեժիմն ընդհանրապես հոսթի ադապտեր չունի։ Երկու ռեժիմները հեշտությամբ շփոթվում են ցանցի կարգավորումների պանելում, այնպես որ ստուգեք փաստաթղթավորված տարբերությունը, ոչ թե պիտակը (տես VirtualBox ցանցի մանրամասներ էջը)։
Այն հյուրի համար, որը պետք է օգտագործի թունելը, ներքինն ավելի անվտանգ լռելյայն է, դարպասը՝ միակ ելքը։ Եթե պահում եք միայն հոսթի ռեժիմը, վերաբերվեք հոսթի ադապտերին որպես կառավարման ուղի և բարձրաձայն ասեք դա՝ հոսթը կարող է հասնել հյուրին, իսկ հյուրը չպետք է կարողանա հոսթն օգտագործել որպես ելք։
VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0Մեկուսացումը, որը կարող եք ապացուցել, այն մեկուսացումն է, որը դուք կարգավորել եք։ Մեկ ներքին ադապտեր, դարպասի վրա լռելյայն երթուղի և NAT ադապտեր չունեցող հյուրը դարպասը շրջանցող ուղի չունի։ Միայն հոսթի ադապտեր և NAT ադապտեր ունեցող հյուրը երկու ուղի ունի, և դրանցից միայն մեկն է այն, ինչ դուք ուզում էիք փորձարկել։
Ուղղորդեք և թարգմանեք դարպասի վրա, ապա ստիպեք այն փակ ձախողվել
VirtualBox-ը սեգմենտների միջև չի փոխանցում. դա անում է հյուրը։ Երբ VPN սերվերի VM-ը դարպասի հետևում է, միացրեք փոխանցումը և թարգմանեք հաճախորդի երթևեկությունը, երբ այն դուրս է գալիս դեպի սերվեր:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADEԱյդ կանոնով սերվերը տեսնում է դարպասի LAN հասցեն՝ հաճախորդի փոխարեն, և հենց այդպես է իրական հաճախորդը՝ օպերատորի NAT-ի հետևում, երևում ցանցի գլխին։ Պահեք sysctl արժեքը /etc/sysctl.d/-ում, իսկ կանոնը՝ այն firewall ծառայությունում, որն օգտագործում է տարածումը, այլապես վերագործարկումը աննկատ կվերադարձնի լաբորատորիան ուղղորդված, բայց չթարգմանված վիճակի։
Փոխանցումը լիազորում չէ։ ACCEPT-ի լռելյայն FORWARD քաղաքականության ներքո հյուրը, որի լռելյայն երթուղին մատնանշում է դարպասին, դուրս է գալիս այն ինտերֆեյսով, որը կընտրի ուղղորդման աղյուսակը՝ թունելով կամ առանց դրա։ Եթե դարպասն ունի նաև NAT ադապտեր փաթեթների տեղադրման համար, այդ ադապտերը գործող չգաղտնագրված ելք է այն պահին, երբ թունելն ընկնում է, և ձեր միայն-VPN թեստը երբեք միայն-VPN թեստ չի եղել։
Երբ սերվերը հեռու է, և թունելը դարպասն ինքն է ավարտում, նույն որոշումը մատնանշում է թունելի ինտերֆեյսին, ոչ թե ինտերնետին հասնող NIC-ին:
iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTԹունելի սեփական արտաքին փոխադրումը և արտաբանդային կառավարման երթուղին առանձին պահեք փոխանցվող երթևեկությունից։ Եթե դարպասը վերանորոգելու միակ ճանապարհը ձեր վրիպազերծած թունելով անցնելն է, լաբորատորիան դառնում է արգելափակման վարժություն։ Սերիական կոնսոլը, միայն հոսթի կառավարման ադապտերը կամ հայտնի լավ վիճակի պահապատճենը ավելի էժան են, քան կոտրված երթուղիչը ձեռքով վերականգնելը։
Ստուգեք ուղին հյուրից, ոչ թե հոսթից
Աշխատեք դեպի դուրս։ Հաստատեք, որ հաճախորդը հասնում է դարպասի WAN հասցեին, ապա սերվերին դարպասի միջով, ապա որ VPN պորտին միացումը դուրս է գալիս և վերադառնում։ Դարպասի երկու ինտերֆեյսների վրա գրավումը ցույց է տալիս՝ պատասխանը գալի՞ս է և արդյոք այն գցվում է վերադարձի ուղու վրա, ինչը միայն հաճախորդի վրա գրավումը չի կարող տարբերել:
tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194Ապա ապացուցեք ելքը։ Հյուրից հարցրեք հասցեների արտացոլման ծառայությանը, թե ինչ աղբյուր է տեսնում, և համեմատեք դարպասի սեփական ելքի հասցեի հետ՝ եթե պատասխանը համընկնում է հոսթի հասցեին, ապա թունելի շուրջը ուղի գոյություն ունի։ Ստուգեք, թե հյուրն իրականում որ լուծիչն է օգտագործում, և IPv6-ը ստուգեք առանձին, քանի որ այն սեգմենտը, որտեղ IPv6-ը միացված է, մինչ թունելը կրում է միայն IPv4, արտահոսում է ըստ նախագծի, ոչ թե պատահաբար։
Վերջում դիտավորյալ կոտրեք այն։ Կանգնեցրեք թունելը կամ արգելափակեք նրա արտաքին պորտը և հյուրից նոր միացում բացեք։ Այն պետք է ձախողվի, և պատճառը պետք է լինի այնպիսին, որը կարող եք անվանել՝ երթուղի չկա, մերժման կանոն կա, կամ լուծիչը մեռած է։ Վերագործարկեք թունելը և հաստատեք, որ հյուրը վերականգնվում է առանց ցանցը վերակառուցելու։ Եթե Hamachi-ի կամ ZeroTier-ի նման mesh VPN-ը կիսում է լաբորատորիան, հիշեք, որ կամուրջային ադապտերը հետևում է ադապտերի անվանը, ոչ թե mesh-ին, այնպես որ կամուրջը պետք է վերաուղղորդվի այն բանից հետո, երբ հաճախորդը տեղադրի իր սեփական վիրտուալ ադապտերը։
VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>Հյուրի թունելը հոսթի հետ կիսելը արտացոլում է խնդիրը։ Հոսթի լռելյայն երթուղին հյուրին ուղղելը աշխատում է, և հյուրի ներսում proxy-ն նույնպես. հոսթի միջով NAT-ը չի կրում հյուրի թունելը հոսթի սկսած երթևեկության համար։ Պահեք սեգմենտների անունները և firewall-ի կանոնները մեկ տեղում, պահապատճեն վերցրեք աշխատող վիճակից և գրանցեք այն աղբյուրի հասցեն, որը դիտարկել է սերվերը։ Այնուհետև հաջորդ պրոֆիլի փոփոխությունը կարժենա մեկ սկրիպտի գործարկում՝ վերակառուցված լաբորատորիայի փոխարեն։