VirtualBox VPN laboratorija: tarpinė VM prieš tik hosto tinklą

Turite nuspręsti, kiek technikos vertas jūsų VPN laboratorija. Maršrutizuota tarpinė VM tarp dviejų VirtualBox segmentų atkuria adresų vertimą, grįžimo kelią ir ugniasienės padėtį, už kurios sėdi tikras klientas. Vienas tik hosto segmentas duoda vienas kontroliuojamas duris ir nieko daugiau. Tarpinės versija kainuoja tris svečius ir maršrutizavimo lentelę, kurią prižiūrite; tik hosto versija kainuoja vieną svečią ir vieną politiką. Trys klausimai jas skiria, o trečiasis nusprendžia, ar jūsų testas apskritai gali praeiti.

Atsakykite į tris klausimus, prieš ką nors klonuodami

Pradėkite nuo to, ką turi stebėti VPN serveris. Jei serveris turi matyti šaltinio adresą, kuris nėra testinio svečio, kažkas turi versti tarp jų, ir tas kažkas turi būti maršrutizatorius, kurį kontroliuojate. Tik hosto tinklas duoda hostui adapterį svečio segmente, o ne vertėją. Kai svečiui tada reikia pasiekti ką nors išorėje, prijungiate NAT adapterį, o pats VirtualBox NAT variklis perrašo šaltinį jūsų nepaklausęs.

Toliau paklauskite, ar svečias gali pasiekti ką nors kitaip nei per tunelį. Šis atsakymas pasirenka vidinį arba tik hosto, ir būtent šį klausimą dauguma laboratorijų aprašymų praleidžia. Galiausiai paklauskite, kas turi įvykti, kai tunelis krenta, nes tai lemia politiką, o ne topologiją, o laboratorija, kuri įrodo tik laimingą kelią, beveik nieko neišbandė.

Sujunkite tris vaidmenis vidiniais tinklais

Naudokite tris svečius ir du pavadintus segmentus, o tarpinė tebūna vienintelė mašina, turinti adapterį abiejuose:

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

Vidiniam tinklui nėra atskiro kūrimo žingsnio. Eilutė --intnet1 yra segmentas: dvi mašinos jį dalijasi tik jei pavadinimas sutampa tiksliai, ir niekas hoste prie jo neprijungta. Būtent ši paskutinė savybė yra priežastis, kodėl laboratorija švariai kartojasi, nes hosto maršrutai, jo paties VPN klientas ir ugniasienė negali atsitiktinai pasiekti svečių. Vidiname segmente taip pat nėra DHCP serverio, jei jo nepridėsite, todėl statiniai adresai yra trumpiausias kelias.

Duokite klientui tik jo WAN adresą, o numatytasis šliuzas turi rodyti į šliuzo WAN adresą. Serveris gauna LAN adresą ir naudoja šliuzo LAN adresą kaip savo numatytąjį šliuzą. Svečias, laikantis du adresus viename segmente arba turintis paklydusį maršrutą į kitą segmentą, turi kelią aplink maršrutizatorių, ir žemiau esantys testai jums meluos.

Prie VM pavadinimų laikau tekstinį failą su keturiais adresais ir dviem segmentų pavadinimais, ir įklijuoju jį į kiekvieną shell. Po savaičių, kai profilio pakeitimas ką nors sugadina, tas failas yra skirtumas tarp profilio derinimo ir savo atminties derinimo.

Pasirinkite vidinį arba tik hosto segmentą tam segmentui, kuris neturi nutekėti

Tik hosto režimas sukuria virtualų adapterį pačiame hoste, paprastai vboxnet0, ir duoda hostui adresą svečio segmente. Tai patogu administruoti ir mirtina izoliacijos testui, nes hostas dabar gali pasiekti svečią tiesiogiai, ir kiekviena hosto pusės paslauga tampa galimu keliu. Vidiniam režimui hosto adapterio visai nėra. Du režimus lengva supainioti tinklo nustatymų skydelyje, todėl tikrinkite dokumentuotą skirtumą, o ne etiketę (žrėkite VirtualBox tinklo informacija puslapį).

Svečiui, kuris privalo naudoti tunelį, vidinis režimas yra saugesnis numatytasis, o šliuzas yra vienintelė išeitis. Jei paliekate tik hosto, traktuokite hosto adapterį kaip valdymo kelią ir pasakykite tai garsiai: hostas gali pasiekti svečią, o svečias neturi galėti naudoti hosto kaip išėjimo.

VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0

Izoliacija, kurią galite įrodyti, yra izoliacija, kurią sukonfigūravote. Svečias su vienu vidiniu adapteriu, numatytuoju maršrutu prie šliuzo ir be NAT adapterio neturi kelio, kuris apeitų šliuzą. Svečias su tik hosto adapteriu ir NAT adapteriu turi du kelius, ir tik vienas jų yra tas, kurį norėjote išbandyti.

Maršrutizuokite ir verskite šliuze, o tada priverskite jį užsidaryti gedimo atveju

VirtualBox nepersiunčia tarp segmentų; tai daro svečias. Kai VPN serverio VM yra už šliuzo, įjunkite persiuntimą ir verskite kliento srautą, kai jis išeina link serverio:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Su šia taisykle serveris mato šliuzo LAN adresą vietoj kliento, ir būtent taip tikras klientas už operatoriaus NAT atrodo tinklo galvai. Išsaugokite sysctl reikšmę /etc/sysctl.d/ faile, o taisyklę toje ugniasienės tarnyboje, kurią naudoja distribucija, kitaip perkrovimas tyliai grąžins laboratoriją į maršrutizuotą, bet neišverstą būseną.

Persiuntimas nėra autorizacija. Pagal numatytąją FORWARD politiką su reikšme ACCEPT svečias, kurio numatytasis maršrutas rodo į šliuzą, išeina per tą sąsają, kurią pasirinks maršrutizavimo lentelė, su tuneliu ar be jo. Jei šliuzas taip pat turi NAT adapterį paketų diegimui, tas adapteris yra veikianti nešifruota išeitis tą akimirką, kai tunelis krenta, ir jūsų tik-VPN testas niekada nebuvo tik-VPN testas.

Kai serveris yra atokiai ir tunelį užbaigia pats šliuzas, tas pats sprendimas rodo į tunelio sąsają, o ne į NIC, kuris pasiekia 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

Laikykite paties tunelio išorinį transportą ir užjuostį valdymo maršrutą atskirai nuo persiunčiamo srauto. Jei vienintelis būdas sutaisyti šliuzą yra per tunelį, kurį derinate, laboratorija tampa užsirakinimo pratimu. Nuosekli konsolė, tik hosto valdymo adapteris arba žinomos geros būsenos momentinė kopija yra pigesni nei rankinis sulūžusio maršrutizatoriaus atkūrimas.

Patikrinkite kelią iš svečio, o ne iš hosto

Dirbkite į išorę. Patvirtinkite, kad klientas pasiekia šliuzo WAN adresą, tada serverį per šliuzą, tada kad ryšys į VPN prievadą išeina ir grįžta. Fiksavimas abiejose šliuzo sąsajose parodo, ar atsakymas atvyksta ir ar metamas grįžimo kelyje, ko fiksavimas tik kliente negali atskirti:

tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194

Tada įrodykite išėjimą. Paklauskite iš svečio adresų atspindžio tarnybos, kokį šaltinį ji mato, ir palyginkite su pačiu šliuzo išėjimo adresu; jei atsakymas sutampa su hosto adresu, egzistuoja kelias aplink tunelį. Patikrinkite, kurį resolverį svečias iš tikrųjų naudoja, ir IPv6 patikrinkite atskirai, nes segmentas, kuriame IPv6 įjungtas, o tunelis neša tik IPv4, nuteka pagal projektą, o ne atsitiktinai.

Galiausiai tyčia jį sulaužykite. Sustabdykite tunelį arba užblokuokite jo išorinį prievadą ir atidarykite naują ryšį iš svečio. Jis turi nepavykti, o priežastis turi būti tokia, kurią galite įvardyti: nėra maršruto, yra atmetimo taisyklė arba resolveris miręs. Paleiskite tunelį iš naujo ir patvirtinkite, kad svečias atsigauna neperstatant tinklo. Jei mesh VPN, pavyzdžiui, Hamachi arba ZeroTier, dalijasi laboratorija, atminkite, kad tiltu sujungtas adapteris seka adapterio pavadinimą, o ne mesh, todėl tiltą reikia nukreipti iš naujo, kai klientas įdiegia savo virtualų adapterį.

VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>

Dalijimasis svečio tuneliu su hostu atspindi problemą. Nukreipti hosto numatytąjį maršrutą į svečią veikia, ir proxy svečio viduje taip pat; NAT per hostą neneša svečio tunelio srautui, kurį pradėjo hostas. Išsaugokite segmentų pavadinimus ir ugniasienės taisykles vienoje vietoje, paimkite veikiančios būsenos momentinę kopiją ir užrašykite šaltinio adresą, kurį stebėjo serveris. Tada kitas profilio pakeitimas kainuos vieną scenarijaus paleidimą, o ne perstatytą laboratoriją.