VirtualBox VPN laboratorija: prolazna VM naspram mreže samo za hosta

Trebate odlučiti koliko mašinerije zaslužuje vaša VPN laboratorija. Rutirana prolazna VM između dva VirtualBox segmenta reprodukuje prevođenje adresa, povratni put i položaj firewalla iza kojeg sjedi stvarni klijent. Jedan segment samo za hosta daje vam jedna kontrolisana vrata i ništa više. Verzija s prolazom košta tri gosta i tablicu rutiranja koju održavate; verzija samo za hosta košta jednog gosta i jednu politiku. Tri pitanja ih razdvajaju, a treće odlučuje može li vaš test uopće proći.

Odgovorite na tri pitanja prije nego što bilo šta klonirate

Počnite od toga šta VPN server mora promatrati. Ako server mora vidjeti izvornu adresu koja nije adresa testnog gosta, nešto mora prevoditi između njih, a to nešto mora biti ruter koji kontrolišete. Mreža samo za hosta daje hostu adapter na segmentu gosta, a ne prevodilac. Kada gost zatim treba doći do bilo čega izvana, priključite NAT adapter, a VirtualBoxov vlastiti NAT mehanizam prepisuje izvor bez pitanja.

Zatim pitajte smije li gost doći do bilo čega osim kroz tunel. Taj odgovor bira internu ili samo za hosta, i to je pitanje koje većina opisa laboratorija preskoči. Na kraju pitajte šta se mora dogoditi kada tunel padne, jer to određuje politiku, a ne topologiju, a laboratorija koja dokazuje samo sretan put nije testirala gotovo ništa.

Povežite tri uloge internim mrežama

Koristite tri gosta i dva imenovana segmenta, s prolazom kao jedinom mašinom koja ima adapter na oba:

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

Nema posebnog koraka stvaranja za internu mrežu. Niz u --intnet1 je segment: dvije mašine ga dijele samo ako se ime tačno poklapa, i ništa na hostu nije priključeno na njega. To posljednje svojstvo je razlog zašto se laboratorija čisto ponavlja, jer rute hosta, njegov vlastiti VPN klijent i njegov firewall ne mogu slučajno doći do gostiju. Interni segment također nema DHCP server osim ako ga dodate, pa su statične adrese najkraći put.

Dajte klijentu samo njegovu WAN adresu, s podrazumijevanim prolazom koji pokazuje na WAN adresu prolaza. Server dobija LAN adresu i koristi LAN adresu prolaza kao svoj podrazumijevani prolaz. Gost koji drži dvije adrese na jednom segmentu ili ima zalutalu rutu prema drugom segmentu ima put oko rutera, i testovi ispod će vam lagati.

Držim tekstualnu datoteku pored imena VM-ova s četiri adrese i dva imena segmenata i lijepim je u svaki shell. Sedmicama kasnije, kada promjena profila nešto pokvari, ta datoteka je razlika između otklanjanja greške u profilu i otklanjanja greške u vlastitom pamćenju.

Odaberite internu ili samo za hosta za segment koji ne smije procuriti

Način samo za hosta stvara virtualni adapter na samom hostu, obično vboxnet0, i daje hostu adresu na segmentu gosta. To je zgodno za administraciju i kobno za test izolacije, jer host sada može doći do gosta direktno i svaka usluga na strani hosta postaje mogući put. Interni način uopće nema adapter hosta. Dva načina se lako pobrkaju u panelu mrežnih postavki, pa provjerite dokumentovanu razliku, a ne oznaku (pogledajte stranicu detalji umrežavanja u VirtualBoxu).

Za gosta koji mora koristiti tunel, interni je sigurniji podrazumijevani izbor, s prolazom kao jedinim izlazom. Ako zadržite samo za hosta, tretirajte adapter hosta kao put za upravljanje i recite to naglas: host smije doći do gosta, a gost ne smije moći koristiti host kao izlaz.

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

Izolacija koju možete dokazati jest izolacija koju ste konfigurisali. Gost s jednim internim adapterom, podrazumijevanom rutom na prolazu i bez NAT adaptera nema put koji zaobilazi prolaz. Gost s adapterom samo za hosta i NAT adapterom ima dva puta, i samo je jedan od njih onaj koji ste htjeli testirati.

Rutirajte i prevodite na prolazu, pa ga natjerajte da se zatvori pri kvaru

VirtualBox ne prosljeđuje između segmenata; to radi gost. S VM-om VPN servera iza prolaza, uključite prosljeđivanje i prevodite klijentov saobraćaj dok izlazi prema serveru:

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

S tim pravilom server vidi LAN adresu prolaza umjesto klijentove, i tako stvarni klijent iza NAT-a operatera izgleda glavnom čvoru. Sačuvajte sysctl vrijednost u /etc/sysctl.d/, a pravilo u kojoj god usluzi firewalla distribucija koristi, inače restart tiho vraća laboratoriju u rutirano, ali neprevedeno stanje.

Prosljeđivanje nije autorizacija. Pod podrazumijevanom politikom FORWARD s vrijednošću ACCEPT, gost čija podrazumijevana ruta pokazuje na prolaz izlazi kroz interfejs koji tablica rutiranja odabere, tunel ili ne. Ako prolaz ima i NAT adapter za instalaciju paketa, taj adapter je radni nešifrovani izlaz u trenutku kada tunel padne, i vaš test samo za VPN nikada nije bio test samo za VPN.

Kada je server umjesto toga udaljen i prolaz sam završava tunel, ista odluka pokazuje na interfejs tunela, a ne na NIC koji doseže 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

Držite vlastiti vanjski transport tunela i vanpojasnu rutu upravljanja odvojeno od proslijeđenog saobraćaja. Ako je jedini način da popravite prolaz kroz tunel koji otklanjate, laboratorija postaje vježba zaključavanja. Serijska konzola, upravljački adapter samo za hosta ili snimka poznatog dobrog stanja jeftiniji su od ručnog oporavka pokvarenog rutera.

Provjerite put s gosta, a ne s hosta

Radite prema van. Potvrdite da klijent doseže WAN adresu prolaza, zatim server kroz prolaz, zatim da veza prema VPN portu izlazi i vraća se. Snimka na oba interfejsa prolaza pokazuje dolazi li odgovor i odbacuje li se na povratnom putu, što snimka samo na klijentu ne može razlikovati:

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

Zatim dokažite izlaz. Pitajte s gosta uslugu za odraz adresa koji izvor vidi i uporedite to s vlastitom izlaznom adresom prolaza; ako se odgovor poklapa s adresom hosta, postoji put oko tunela. Provjerite koji resolver gost zapravo koristi i provjerite IPv6 zasebno, jer segment u kojem je IPv6 uključen dok tunel nosi samo IPv4 curi po dizajnu, a ne slučajno.

Na kraju, pokvarite to namjerno. Zaustavite tunel ili blokirajte njegov vanjski port i otvorite novu vezu s gosta. Mora pasti, a razlog mora biti onaj koji možete imenovati: nema rute, postoji pravilo odbijanja ili je resolver mrtav. Ponovo pokrenite tunel i potvrdite da se gost oporavlja bez ponovne izgradnje mreže. Ako mesh VPN kao Hamachi ili ZeroTier dijeli laboratoriju, zapamtite da premosni adapter slijedi ime adaptera, a ne mesh, pa se most mora preusmjeriti nakon što klijent instalira vlastiti virtualni adapter.

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

Dijeljenje gostovog tunela s hostom preslikava problem. Usmjeravanje hostove podrazumijevane rute na gosta funkcioniše, kao i proxy unutar gosta; NAT kroz host ne nosi gostov tunel za saobraćaj koji je host pokrenuo. Sačuvajte imena segmenata i pravila firewalla na jednom mjestu, napravite snimku radnog stanja i zabilježite izvornu adresu koju je server promatrao. Sljedeća promjena profila tada košta jedno pokretanje skripte umjesto ponovno izgrađene laboratorije.