Laboratoryo ng VPN sa VirtualBox: VM gateway o network na host-only
Pumili sa pagitan ng naka-rutang VM gateway at segment na host-only para sa isang VPN laboratoryo sa VirtualBox, at gawing mabigo nang sarado ang bisita kapag bumagsak ang tunnel.
Kailangan mong magpasya kung gaano karaming makinarya ang karapat-dapat sa iyong VPN laboratoryo. Ang isang naka-rutang VM gateway sa pagitan ng dalawang segment ng VirtualBox ay muling gumagawa ng pagsasalin ng address, ang daan pabalik at ang posisyon ng firewall kung saan nakaupo ang isang tunay na kliyente. Ang isang segment na host-only ay nagbibigay sa iyo ng isang kontroladong pinto at wala nang iba. Ang bersyon na may gateway ay nangangailangan ng tatlong bisita at isang routing table na ikaw ang nag-aalaga; ang bersyon na host-only ay nangangailangan ng isang bisita at isang patakaran. Tatlong tanong ang naghihiwalay sa kanila, at ang pangatlo ang nagpapasya kung ang iyong pagsubok ay makakapasa talaga.
Sagutin ang tatlong tanong bago ka mag-clone ng kahit ano
Magsimula sa kung ano ang dapat obserbahan ng VPN server. Kung kailangang makita ng server ang isang source address na hindi sa test bisita, may dapat magsalin sa pagitan nila, at ang dapat na iyon ay isang router na ikaw ang may kontrol. Ang host-only networking ay nagbibigay sa host ng adapter sa segment ng bisita, hindi tagasalin. Kapag kailangang maabot ng bisita ang isang bagay sa labas, magkokonekta ka ng NAT adapter, at ang sariling NAT engine ng VirtualBox ay muling nagsusulat ng source nang hindi ka tinatanong.
Susunod, itanong kung maaaring maabot ng bisita ang anumang bagay maliban sa pamamagitan ng tunnel. Ang sagot na iyon ang pumipili ng panloob o host-only, at ito ang tanong na nilalaktawan ng karamihan ng mga sulatin sa laboratoryo. Sa huli, itanong kung ano ang dapat mangyari kapag bumagsak ang tunnel, dahil iyon ang nagpapasya ng patakaran at hindi topolohiya, at ang laboratoryong nagpapatunay lamang ng masayang daan ay halos walang nasubukan.
| 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 |
Ikonekta ang tatlong papel gamit ang mga panloob na network
Gumamit ng tatlong bisita at dalawang pinangalanang segment, at ang gateway ang tanging makina na may adapter sa dalawa:
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
Walang hiwalay na hakbang sa paggawa para sa isang panloob na network. Ang string sa --intnet1 ang segment: dalawang makina lamang ang nagbabahagi nito kung eksaktong tugma ang pangalan, at walang anuman sa host ang konektado dito. Ang huling katangiang ito ang dahilan kung bakit malinis na nauulit ang laboratoryo, dahil ang mga ruta ng host, ang sarili nitong VPN client at ang firewall nito ay hindi makakaabot sa mga bisita nang aksidente. Ang panloob na segment ay walang DHCP server maliban kung magdagdag ka, kaya ang mga static na address ang pinakamaikling daan.
Bigyan ang kliyente ng tanging WAN address nito, na ang default gateway ay tumuturo sa WAN address ng gateway. Ang server ay makakakuha ng LAN address at gagamitin ang LAN address ng gateway bilang default gateway nito. Ang bisitang may dalawang address sa isang segment, o may ligaw na ruta patungo sa kabilang segment, ay may daan sa paligid ng router, at magsisinungaling sa iyo ang mga pagsubok sa ibaba.
May hawak akong text file sa tabi ng mga pangalan ng VM na may apat na address at dalawang pangalan ng segment, at ipinapasok ko ito sa bawat shell. Makalipas ang mga linggo, kapag may nasira ang pagbabago ng profile, ang file na iyon ang pagkakaiba ng pag-debug ng profile at pag-debug ng sarili kong memorya.
Pumili ng panloob o host-only para sa segment na hindi dapat tumulo
Ang host-only mode ay gumagawa ng virtual adapter sa host mismo, kadalasan ay vboxnet0, at nagbibigay sa host ng address sa segment ng bisita. Ito ay maginhawa para sa administrasyon at nakamamatay para sa pagsubok ng paghihiwalay, dahil maaaring maabot ng host ang bisita nang direkta at bawat serbisyo sa panig ng host ay nagiging posibleng daan. Ang panloob na mode ay walang adapter ng host. Ang dalawang mode ay madaling mapagkamalan sa panel ng mga setting ng network, kaya suriin ang nakadokumentong pagkakaiba at hindi ang label (tingnan ang pahina ng mga detalye ng networking ng VirtualBox).
Para sa bisitang kailangang gumamit ng tunnel, ang panloob ang mas ligtas na default, at ang gateway ang tanging labasan. Kung panatilihin mo ang host-only, ituring ang adapter ng host bilang daan ng pamamahala at sabihin ito nang malakas: maaaring maabot ng host ang bisita, at ang bisita ay hindi dapat makagamit ng host bilang labasan.
VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0
Ang paghihiwalay na mapapatunayan mo ay ang paghihiwalay na iyong isinaayos. Ang bisitang may isang panloob na adapter, default na ruta sa gateway at walang NAT adapter ay walang daang lumalampas sa gateway. Ang bisitang may host-only adapter at NAT adapter ay may dalawang daan, at isa lamang sa kanila ang nais mong subukan.
I-route at isalin sa gateway, pagkatapos ay gawin itong mabigo nang sarado
Hindi nagpapasa ang VirtualBox sa pagitan ng mga segment; ang bisita ang gumagawa niyon. Kapag ang VM ng VPN server ay nasa likod ng gateway, paganahin ang pagpapasa at isalin ang trapiko ng kliyente habang lumalabas patungo sa server:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
Sa tuntuning iyon, nakikita ng server ang LAN address ng gateway sa halip na ng kliyente, at ganoon ang hitsura ng tunay na kliyente sa likod ng NAT ng operator sa isang head-end. I-save ang halaga ng sysctl sa /etc/sysctl.d/ at ang tuntunin sa serbisyo ng firewall na ginagamit ng distribusyon, kung hindi ay tahimik na ibabalik ng reboot ang laboratoryo sa naka-route ngunit hindi isinaling kalagayan.
Ang pagpapasa ay hindi awtorisasyon. Sa ilalim ng default na patakarang FORWARD na may halagang ACCEPT, ang bisitang ang default na ruta ay tumuturo sa gateway ay lumalabas sa interface na pinipili ng routing table, may tunnel o wala. Kung ang gateway ay mayroon ding NAT adapter para sa pag-install ng pakete, ang adapter na iyon ay gumaganang hindi naka-encrypt na labasan sa sandaling bumagsak ang tunnel, at ang iyong pagsubok na VPN lamang ay hindi kailanman naging pagsubok na VPN lamang.
Kapag ang server ay malayo at ang gateway mismo ang nagtatapos ng tunnel, ang parehong pasya ay tumuturo sa interface ng tunnel, hindi sa NIC na umaabot sa internet:
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
Panatilihing hiwalay sa ipinapasang trapiko ang sariling panlabas na transportasyon ng tunnel at isang ruta ng pamamahala sa labas ng banda. Kung ang tanging paraan upang ayusin ang gateway ay sa pamamagitan ng tunnel na dine-debug mo, ang laboratoryo ay nagiging pagsasanay sa pagkakandado. Ang isang serial console, isang host-only na adapter ng pamamahala o isang snapshot ng kilalang mabuting kalagayan ay mas mura kaysa sa manu-manong pagbawi ng sirang router.
I-verify ang daan mula sa bisita, hindi mula sa host
Magtrabaho pakanlabas. Kumpirmahin na naaabot ng kliyente ang WAN address ng gateway, pagkatapos ang server sa pamamagitan ng gateway, pagkatapos na ang koneksyon sa port ng VPN ay lumalabas at bumabalik. Ang pagkuha sa parehong interface ng gateway ay nagpapakita kung dumarating ang sagot at itinatapon sa daan pabalik, na hindi matukoy ng pagkuha sa kliyente lamang:
tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194
Pagkatapos ay patunayan ang labasan. Itanong mula sa bisita sa isang serbisyo ng pagsasalamin ng address kung anong source ang nakikita nito at ihambing sa sariling labas na address ng gateway; kung tugma ang sagot sa address ng host, may daang lumalampas sa tunnel. Suriin kung aling resolver ang talagang ginagamit ng bisita, at suriin ang IPv6 nang hiwalay, dahil ang segment kung saan bukas ang IPv6 habang ang tunnel ay nagdadala lamang ng IPv4 ay tumutulo ayon sa disenyo at hindi nagkataon.
Sa huli, sirain ito nang sadya. Itigil ang tunnel, o harangin ang panlabas na port nito, at magbukas ng bagong koneksyon mula sa bisita. Dapat itong mabigo, at ang dahilan ay dapat isang bagay na kaya mong pangalanan: walang ruta, isang tuntunin ng pagtanggi o isang patay na resolver. I-restart ang tunnel at kumpirmahin na gumagaling ang bisita nang hindi binubuo muli ang network. Kung ang isang mesh VPN tulad ng Hamachi o ZeroTier ay nagbabahagi ng laboratoryo, tandaan na ang naka-bridge na adapter ay sumusunod sa pangalan ng adapter, hindi sa mesh, kaya kailangang ituro muli ang tulay pagkatapos i-install ng kliyente ang sarili nitong virtual adapter.
VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>
Ang pagbabahagi ng tunnel ng bisita sa host ay sumasalamin sa problema. Gumagana ang pagturo ng default na ruta ng host sa bisita, at gumagana rin ang proxy sa loob ng bisita; ang NAT sa pamamagitan ng host ay hindi nagdadala ng tunnel ng bisita para sa trapikong sinimulan ng host. I-save ang mga pangalan ng segment at mga tuntunin ng firewall sa isang lugar, kumuha ng snapshot ng gumaganang kalagayan, at itala ang source address na naobserbahan ng server. Ang susunod na pagbabago ng profile ay gagastos ng isang pagtakbo ng script sa halip na isang muling itinayong laboratoryo.