VirtualBox VPN-lab: gateway-VM mot berre verts-nettverk

Du må avgjere kor mykje maskineri VPN-laben din fortener. Ein rutet gateway-VM mellom to VirtualBox-segment attskapar adresseomsetjinga, returvegen og brannmurposisjonen som ein ekte klient sit bak. Eitt enkelt berre-vert-segment gir deg éi kontrollert dør og ingenting anna. Gateway-versjonen kostar tre gjester og ein rutetabell du vedlikeheld; berre-vert-versjonen kostar éi gjest og éin policy. Tre spørsmål skil dei, og det tredje avgjer om testen din i det heile kan bestå.

Svar på tre spørsmål før du klonar noko

Start med kva VPN-tenaren må observere. Viss tenaren må sjå ei kildeadresse som ikkje er testgjesta si, må noko omsetje mellom dei, og det noko må vere ein ruter du kontrollerer. Berre-vert-nettverk gir verten ein adapter på segmentet til gjesta, ikkje ein omsetjar. Når gjesta deretter treng å nå noko utanfor, koplar du til ein NAT-adapter, og VirtualBox sin eigen NAT-motor skriv om kjelda utan å spørje deg.

Spør deretter om gjesta får nå noko som helst utanom gjennom tunnelen. Det svaret vel internt eller berre-vert, og det er spørsmålet dei fleste labskildringar hoppar over. Til slutt, spør kva som må skje når tunnelen fell, fordi det avgjer policy og ikkje topologi, og ein lab som berre beviser den lukkelege vegen, har testa nesten ingenting.

Kople dei tre rollene med interne nettverk

Bruk tre gjester og to namngitte segment, med gatewayen som den einaste maskina som har ein adapter på begge:

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

Det er ikkje noko eige opprettingstrinn for eit internt nettverk. Strengen i --intnet1 er segmentet: to maskiner deler det berre viss namnet stemmer nøyaktig, og ingenting på verten er knytt til det. Den siste eigenskapen er grunnen til at laben blir gjenteken reint, sidan rutene til verten, den eigen VPN-klienten hans og brannmuren ikkje kan nå gjestene ved eit uhell. Eit internt segment har heller ingen DHCP-tenar med mindre du legg til ein, så statiske adresser er den kortaste vegen.

Gi klienten berre WAN-adressa si, med ein standardgateway som peikar på WAN-adressa til gatewayen. Tenaren får ei LAN-adresse og brukar LAN-adressa til gatewayen som standardgatewayen sin. Ei gjest som held to adresser på eitt segment, eller har ein vill rute til det andre segmentet, har ein veg rundt ruteren, og testane nedanfor vil lyge for deg.

Eg har ei tekstfil ved sida av VM-namna med dei fire adressene og dei to segmentnamna, og limer henne inn i kvart skal. Veker seinare, når ei profilendring øydelegg noko, er den fila skilnaden mellom å feilsøkje profilen og å feilsøkje mi eiga hukommelse.

Vel internt eller berre-vert for segmentet som ikkje må lekkje

Berre-vert-modus opprettar ein virtuell adapter på verten sjølv, vanlegvis vboxnet0, og gir verten ei adresse på segmentet til gjesta. Det er praktisk for administrasjon og fatalt for ein isolasjonstest, fordi verten no kan nå gjesta direkte og kvar teneste på vertssida blir ein mogleg veg. Intern modus har ingen vertsadapter i det heile. Dei to modusane blir lett forveksla i nettverksinnstillingspanelet, så kontroller den dokumenterte skilnaden i staden for etiketten (sjå sida VirtualBox-nettverksdetaljar).

For ei gjest som må bruke tunnelen, er internt det tryggare standardvalet, med gatewayen som einaste utveg. Viss du held på berre-vert, handsam vertsadapteren som ein administrasjonsveg og sei det høgt: verten får nå gjesta, og gjesta må ikkje kunne bruke verten som utgang.

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

Isolasjonen du kan bevisa, er isolasjonen du konfigurerte. Ei gjest med éin intern adapter, standardrute ved gatewayen og ingen NAT-adapter har ingen veg som går utanom gatewayen. Ei gjest med ein berre-vert-adapter og ein NAT-adapter har to vegar, og berre éin av dei er den du meinte å teste.

Rut og omset på gatewayen, og få han deretter til å feile lukka

VirtualBox vidaresender ikkje mellom segment; det gjer gjesta. Med VPN-tenar-VM-en bak gatewayen, slå på vidaresending og omset trafikken til klienten når han forlèt mot tenaren:

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

Med den regelen ser tenaren LAN-adressa til gatewayen i staden for klienta si, og slik ser ein ekte klient bak ein leverandør-NAT ut for eit hodenett. Lagre sysctl-verdien i /etc/sysctl.d/ og regelen i den brannmurtenesta distribusjonen brukar, elles returnerer ein omstart laben stille til ein ruta men uomsett tilstand.

Vidaresending er ikkje autorisasjon. Under standardpolicyen FORWARD med verdien ACCEPT forlèt ei gjest kva standardrute peikar på gatewayen gjennom det grensesnittet rutetabellen vel, med eller utan tunnel. Viss gatewayen også har ein NAT-adapter for pakkeinstallasjon, er den adapteren ein fungerande ukryptert utgang i det augneblunken tunnelen fell, og berre-VPN-testen din var aldri ein berre-VPN-test.

Når tenaren i staden er ekstern og gatewayen sjølv avsluttar tunnelen, peikar same avgjerd på tunnelgrensesnittet, ikkje på NIC-en som når internett:

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

Hald den eigne ytre transporten til tunnelen og ein administrasjonsveg utanfor bandet skilde frå vidaresend trafikk. Viss den einaste måten å reparere gatewayen på er gjennom tunnelen du feilsøkjer, blir laben ei utelåsingsoppgåve. Ein seriell konsoll, ein berre-vert-administrasjonsadapter eller eit augneblinksbilete av ein kjend god tilstand er billegare enn å gjenopprette ein øydelagd ruter for hand.

Verifiser vegen frå gjesta, ikkje frå verten

Arbeid deg utover. Stadfest at klienten når WAN-adressa til gatewayen, deretter tenaren gjennom gatewayen, deretter at ei sambinding til VPN-porten forlèt og kjem tilbake. Eit opptak på begge gateway-grensesnitta viser om svaret kjem og blir droppa på returvegen, noko eit opptak berre på klienten ikkje kan skilje:

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

Bevis deretter utgangen. Spør frå gjesta ein adressespeglarteneste kva kjelde han ser, og samanlikn det med den eigne utgangsadressa til gatewayen; viss svaret stemmer med adressa til verten, finst det ein veg rundt tunnelen. Kontroller kva resolver gjesta faktisk brukar, og kontroller IPv6 separat, fordi eit segment der IPv6 er aktivert medan tunnelen berre ber IPv4, lek ved design og ikkje ved eit uhell.

Til slutt, bryt det med vilje. Stopp tunnelen, eller blokker den ytre porten hans, og opne ei ny sambinding frå gjesta. Ho må feile, og årsaka må vere ei du kan namngje: inga rute, ein avvisingregel eller ein daud resolver. Start tunnelen på nytt og stadfest at gjesta kjem seg utan å byggje nettverket på nytt. Viss eit mesh-VPN som Hamachi eller ZeroTier deler laben, hugs at ein brusambanda adapter følgjer adapternamnet, ikkje meshet, så brua må rettast på nytt etter at klienten installerer sin eigen virtuelle adapter.

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

Å dele tunnelen til ei gjest med verten speglar problemet. Å peike standardruta til verten på gjesta verkar, og ein proxy inne i gjesta gjer det også; NAT gjennom verten ber ikkje tunnelen til gjesta for trafikk verten starta. Lagre segmentnamna og brannmurreglane på éin stad, ta eit augneblinksbilete av den fungerande tilstanden, og registrer kildeadressa tenaren observerte. Den neste profilendringa kostar då éi skriptkøyring i staden for ein gjenoppbygd lab.