VirtualBox VPN labor: lüüs-VM versus ainult hosti võrk

Peate otsustama, kui palju masinavärki teie VPN-labor väärib. Marsruuditud lüüs-VM kahe VirtualBoxi segmendi vahel taastoodab aadressitõlke, tagasitee ja tulemüüri positsiooni, mille taga istub päris klient. Üksainus ainult hosti segment annab teile ühe kontrollitud ukse ja mitte midagi muud. Lüüsi versioon maksab kolm külalist ja marsruutimistabeli, mida te hooldate; ainult hosti versioon maksab ühe külalise ja ühe poliitika. Kolm küsimust eraldavad neid ja kolmas otsustab, kas teie test saab üldse läbida.

Vastake kolmele küsimusele, enne kui midagi kloonite

Alustage sellest, mida VPN-server peab vaatlema. Kui server peab nägema lähteaadressi, mis ei ole testkülalise oma, peab miski nende vahel tõlkima ja see miski peab olema ruuter, mida te kontrollite. Ainult hosti võrk annab hostile adapteri külalise segmendis, mitte tõlkija. Kui külaline peab seejärel midagi väljaspool kättesaama, kinnitate NAT-adapteri ja VirtualBoxi enda NAT-mootor kirjutab lähtekoha ümber ilma teilt küsimata.

Järgmisena küsige, kas külaline tohib midagi kätte saada muul viisil kui tunnelit mööda. See vastus valib sisemise või ainult hosti, ja see on küsimus, mille enamik laborikirjeldusi vahele jätab. Lõpuks küsige, mis peab juhtuma, kui tunnel langeb, sest see otsustab poliitika, mitte topoloogia, ja labor, mis tõestab ainult õnnelikku teed, ei ole peaaegu midagi testinud.

Ühendage kolm rolli sisemiste võrkudega

Kasutage kolme külalist ja kahte nimetatud segmenti, kusjuures lüüs on ainus masin, millel on adapter mõlemas:

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

Sisemise võrgu jaoks ei ole eraldi loomise sammu. String --intnet1 sees on segment: kaks masinat jagavad seda ainult siis, kui nimi kattub täpselt, ja miski hostil ei ole sellega ühendatud. Just see viimane omadus on põhjus, miks labor puhtalt kordub, sest hosti marsruudid, tema enda VPN-klient ja tema tulemüür ei saa külalisteni kogemata jõuda. Sisemisel segmendil pole ka DHCP-serverit, kui te seda ei lisa, seega staatilised aadressid on lühim tee.

Andke kliendile ainult tema WAN-aadress, kusjuures vaikelüüs osutab lüüsi WAN-aadressile. Server saab LAN-aadressi ja kasutab lüüsi LAN-aadressi oma vaikelüüsina. Külaline, kes hoiab ühes segmendis kahte aadressi või omab eksinud marsruuti teise segmenti, on leidnud tee ümber ruuteri, ja allolevad testid valetavad teile.

Hoian VM-i nimede kõrval tekstifaili nelja aadressi ja kahe segmendi nimega ning kleebin selle igasse shelli. Nädalaid hiljem, kui profiilimuudatus midagi katki teeb, on see fail vahe profiili silumise ja omaenda mälu silumise vahel.

Valige segment, mis ei tohi lekkida, kas sisemine või ainult hosti oma

Ainult hosti režiim loob virtuaalse adapteri hostil endal, tavaliselt vboxnet0, ja annab hostile aadressi külalise segmendis. See on haldamiseks mugav ja isolatsioonitesti jaoks hukatuslik, sest host pääseb nüüd külalisele otse ligi ja iga hostipoolne teenus muutub võimalikuks teeks. Sisemisel režiimil ei ole hosti adapterit üldse. Kahte režiimi on võrgu seadete paneelil lihtne segi ajada, seega kontrollige dokumenteeritud erinevust, mitte silti (vt lehte VirtualBoxi võrgu üksikasjad).

Külalise jaoks, kes peab tunnelit kasutama, on sisemine turvalisem vaikevalik, kusjuures lüüs on ainus väljapääs. Kui jätate ainult hosti, käsitlege hosti adapterit haldustee ja öelge seda valjusti: host võib külaliseni jõuda ja külaline ei tohi saada hosti väljapääsuna kasutada.

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

Isolatsioon, mida saate tõestada, on isolatsioon, mille te seadistasite. Külalisel, kellel on üks sisemine adapter, vaikemarsruut lüüsil ja ühtegi NAT-adapterit, ei ole ühtegi teed, mis lüüsist mööda läheks. Külalisel, kellel on ainult hosti adapter ja NAT-adapter, on kaks teed, ja ainult üks neist on see, mida te kavatsesite testida.

Marsruutige ja tõlkige lüüsil ning pange see siis rikke korral sulguma

VirtualBox ei edasta segmentide vahel; seda teeb külaline. Kui VPN-serveri VM on lüüsi taga, lubage edastamine ja tõlkige kliendi liiklust, kui see serveri poole lahkub:

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

Selle reegliga näeb server kliendi asemel lüüsi LAN-aadressi, ja just selline näeb päris klient operaatori NAT-i taga peakomponenti silmale. Salvestage sysctl väärtus /etc/sysctl.d/-sse ja reegel sellesse tulemüüriteenusesse, mida distributsioon kasutab, muidu tagastab taaskäivitus labori vaikselt marsruuditud, kuid tõlkimata olekusse.

Edastamine ei ole autoriseerimine. Vaikimisi FORWARD poliitika ACCEPT all lahkub külaline, kelle vaikemarsruut osutab lüüsile, läbi selle liidese, mille marsruutimistabel valib, tunneliga või ilma. Kui lüüsil on pakettide paigaldamiseks ka NAT-adapter, on see adapter töötav krüpteerimata väljapääs hetkel, mil tunnel langeb, ja teie ainult-VPN-test ei olnud kunagi ainult-VPN-test.

Kui server on hoopis kaugel ja tunnelit lõpetab lüüs ise, osutab sama otsus tunneliliidesele, mitte võrgukaardile, mis internetti jõuab:

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

Hoidke tunneli enda välist transporti ja välisriba haldusmarsruuti edastatavast liiklusest eraldi. Kui ainus viis lüüsi parandada on teie silutava tunneli kaudu, muutub labor lukustumisharjutuseks. Jadasadam, ainult hosti haldusadapter või teadaolevalt hea oleku tõmmis on odavam kui katkise ruuteri käsitsi taastamine.

Kontrollige teed külalisest, mitte hostist

Töötage väljapoole. Kinnitage, et klient jõuab lüüsi WAN-aadressini, seejärel serverini läbi lüüsi, seejärel et ühendus VPN-pordiga lahkub ja naaseb. Salvestus lüüsi mõlemal liidesel näitab, kas vastus saabub ja visatakse tagasiteel kõrvale, mida ainult kliendil tehtud salvestus eristada ei suuda:

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

Seejärel tõestage väljapääs. Küsige külalisest aadressi peegeldamise teenuselt, millist lähtekohta see näeb, ja võrrelge seda lüüsi enda väljumisaadressiga; kui vastus kattub hosti aadressiga, on tunnelist mööda minnes tee olemas. Kontrollige, millist resolverit külaline tegelikult kasutab, ja kontrollige IPv6 eraldi, sest segment, kus IPv6 on lubatud, samal ajal kui tunnel kannab ainult IPv4, lekib projekti järgi, mitte kogemata.

Lõpuks murdke see meelega. Peatage tunnel või blokeerige selle väline port ja avage külalisest uus ühendus. See peab ebaõnnestuma ja põhjus peab olema selline, mille saate nimetada: marsruut puudub, keeldumisreegel on või resolver on surnud. Taaskäivitage tunnel ja kinnitage, et külaline taastub ilma võrku ümber ehitamata. Kui mesh-VPN nagu Hamachi või ZeroTier jagab laborit, pidage meeles, et sillatud adapter järgib adapteri nime, mitte meshi, seega tuleb sild uuesti suunata pärast seda, kui klient paigaldab oma virtuaalse adapteri.

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

Külalise tunneli jagamine hostiga peegeldab probleemi. Hosti vaikemarsruudi suunamine külalisele töötab, samuti puhverserver külalise sees; NAT hosti kaudu ei kanna külalise tunnelit liikluse jaoks, mille algatas host. Salvestage segmendinimed ja tulemüürireeglid ühte kohta, tehke töötavast olekust tõmmis ja registreerige lähteaadress, mida server vaatles. Järgmine profiilimuudatus maksab siis ühe skriptikäivituse, mitte ümberehitatud labori.