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

Du må bestemme hvor mye maskineri VPN-laben din fortjener. En rutet gateway-VM mellom to VirtualBox-segmenter gjenskaper adresseoversettelsen, returveien og brannmurposisjonen som en ekte klient sitter bak. Ett enkelt kun-vert-segment gir deg én kontrollert dør og ingenting annet. Gateway-versjonen koster tre gjester og en rutetabell du vedlikeholder; kun-vert-versjonen koster én gjest og én policy. Tre spørsmål skiller dem, og det tredje avgjør om testen din i det hele tatt kan bestå.

Svar på tre spørsmål før du kloner noe

Start med hva VPN-serveren må observere. Hvis serveren må se en kildeadresse som ikke er testgjestens, må noe oversette mellom dem, og det noe må være en ruter du kontrollerer. Kun-vert-nettverk gir verten en adapter på gjestens segment, ikke en oversetter. Når gjesten deretter trenger å nå noe utenfor, kobler du til en NAT-adapter, og VirtualBox' egen NAT-motor skriver om kilden uten å spørre deg.

Spør deretter om gjesten får nå noe som helst utenom gjennom tunnelen. Det svaret velger internt eller kun-vert, og det er spørsmålet de fleste labbeskrivelser hopper over. Til slutt, spør hva som må skje når tunnelen faller, fordi det avgjør policy og ikke topologi, og en lab som bare beviser den lykkelige veien, har testet nesten ingenting.

Koble de tre rollene med interne nettverk

Bruk tre gjester og to navngitte segmenter, med gatewayen som den eneste maskinen som har en 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 ikke noe eget opprettelsestrinn for et internt nettverk. Strengen i --intnet1 er segmentet: to maskiner deler det bare hvis navnet stemmer nøyaktig, og ingenting på verten er knyttet til det. Den siste egenskapen er grunnen til at laben gjentas rent, siden vertens ruter, dens egen VPN-klient og brannmuren ikke kan nå gjestene ved et uhell. Et internt segment har heller ingen DHCP-server med mindre du legger til en, så statiske adresser er den korteste veien.

Gi klienten bare sin WAN-adresse, med en standardgateway som peker på gatewayens WAN-adresse. Serveren får en LAN-adresse og bruker gatewayens LAN-adresse som sin standardgateway. En gjest som holder to adresser på ett segment, eller har en vill rute til det andre segmentet, har en vei rundt ruteren, og testene nedenfor vil lyve for deg.

Jeg har en tekstfil ved siden av VM-navnene med de fire adressene og de to segmentnavnene, og limer den inn i hvert skall. Uker senere, når en profilendring ødelegger noe, er den filen forskjellen mellom å feilsøke profilen og å feilsøke min egen hukommelse.

Velg internt eller kun-vert for segmentet som ikke må lekke

Kun-vert-modus oppretter en virtuell adapter på verten selv, vanligvis vboxnet0, og gir verten en adresse på gjestens segment. Det er praktisk for administrasjon og fatalt for en isolasjonstest, fordi verten nå kan nå gjesten direkte og hver tjeneste på vertssiden blir en mulig vei. Intern modus har ingen vertsadapter i det hele tatt. De to modusene forveksles lett i nettverksinnstillingspanelet, så kontroller den dokumenterte forskjellen i stedet for etiketten (se siden VirtualBox-nettverksdetaljer).

For en gjest som må bruke tunnelen, er internt det sikrere standardvalget, med gatewayen som eneste utvei. Hvis du beholder kun-vert, behandle vertsadapteren som en administrasjonsvei og si det høyt: verten får nå gjesten, og gjesten må ikke kunne bruke verten som utgang.

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

Isolasjonen du kan bevise, er isolasjonen du konfigurerte. En gjest med én intern adapter, standardrute ved gatewayen og ingen NAT-adapter har ingen vei som omgår gatewayen. En gjest med en kun-vert-adapter og en NAT-adapter har to veier, og bare én av dem er den du mente å teste.

Rut og oversett på gatewayen, og få den deretter til å feile lukket

VirtualBox videresender ikke mellom segmenter; det gjør gjesten. Med VPN-server-VM-en bak gatewayen, aktiver videresending og oversett klientens trafikk når den forlater mot serveren:

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

Med den regelen ser serveren gatewayens LAN-adresse i stedet for klientens, og slik ser en ekte klient bak en leverandør-NAT ut for et hodenett. Lagre sysctl-verdien i /etc/sysctl.d/ og regelen i den brannmurtjenesten distribusjonen bruker, ellers returnerer en omstart laben stille til en rutet men uoversatt tilstand.

Videresending er ikke autorisasjon. Under standardpolicyen FORWARD med verdien ACCEPT forlater en gjest hvis standardrute peker på gatewayen gjennom det grensesnittet rutetabellen velger, med eller uten tunnel. Hvis gatewayen også har en NAT-adapter for pakkeinstallasjon, er den adapteren en fungerende ukryptert utgang i det øyeblikket tunnelen faller, og din kun-VPN-test var aldri en kun-VPN-test.

Når serveren i stedet er ekstern og gatewayen selv avslutter tunnelen, peker samme beslutning på tunnelgrensesnittet, ikke 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

Hold tunnelens egen ytre transport og en ut-av-bånd-administrasjonsrute adskilt fra videresendt trafikk. Hvis den eneste måten å reparere gatewayen på er gjennom tunnelen du feilsøker, blir laben en utelåsingsøvelse. En seriell konsoll, en kun-vert-administrasjonsadapter eller et øyeblikksbilde av en kjent god tilstand er billigere enn å gjenopprette en ødelagt ruter for hånd.

Verifiser veien fra gjesten, ikke fra verten

Arbeid deg utover. Bekreft at klienten når gatewayens WAN-adresse, deretter serveren gjennom gatewayen, deretter at en forbindelse til VPN-porten forlater og kommer tilbake. En opptak på begge gatewaygrensesnittene viser om svaret ankommer og droppes på returveien, noe et opptak bare på klienten ikke kan skille:

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

Bevis deretter utgangen. Spør fra gjesten en adressespeilingstjeneste hvilken kilde den ser, og sammenlign det med gatewayens egen utgangsadresse; hvis svaret stemmer med vertens adresse, finnes det en vei rundt tunnelen. Kontroller hvilken resolver gjesten faktisk bruker, og kontroller IPv6 separat, fordi et segment der IPv6 er aktivert mens tunnelen bare bærer IPv4, lekker ved design og ikke ved et uhell.

Til slutt, bryt det med vilje. Stopp tunnelen, eller blokker dens ytre port, og åpne en ny forbindelse fra gjesten. Den må feile, og årsaken må være en du kan navngi: ingen rute, en avvisningsregel eller en død resolver. Start tunnelen på nytt og bekreft at gjesten kommer seg uten å bygge nettverket på nytt. Hvis et mesh-VPN som Hamachi eller ZeroTier deler laben, husk at en brokoblet adapter følger adapternavnet, ikke meshet, så broen må rettes på nytt etter at klienten installerer sin egen virtuelle adapter.

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

Å dele en gjests tunnel med verten speiler problemet. Å peke vertens standardrute på gjesten virker, og en proxy inne i gjesten gjør det også; NAT gjennom verten bærer ikke gjestens tunnel for trafikk verten startet. Lagre segmentnavnene og brannmurreglene på ett sted, ta et øyeblikksbilde av den fungerende tilstanden, og registrer kildeadressen serveren observerte. Den neste profilendringen koster da én skriptkjøring i stedet for en gjenoppbygd lab.