VirtualBox VPN-lab: gateway-VM kontra netværk kun for værten

Du skal beslutte, hvor meget maskineri dit VPN-lab fortjener. En routet gateway-VM mellem to VirtualBox-segmenter genskaber adresseoversættelsen, returvejen og den firewallposition, som en rigtig klient sidder bag. Et enkelt segment kun for værten giver dig én kontrolleret dør og intet andet. Gateway-versionen koster tre gæster og en routingtabel, du vedligeholder; versionen kun for værten koster én gæst og en politik. Tre spørgsmål skiller dem, og det tredje afgør, om din test overhovedet kan bestå.

Besvar tre spørgsmål, før du kloner noget

Start med, hvad VPN-serveren skal observere. Hvis serveren skal se en kildeadresse, som ikke er testgæstens, skal noget oversætte mellem dem, og det noget skal være en router, du kontrollerer. Netværk kun for værten giver værten en adapter på gæstens segment, ikke en oversætter. Når gæsten derefter skal nå noget udenfor, tilslutter du en NAT-adapter, og VirtualBox' egen NAT-motor omskriver kilden uden at spørge dig.

Spørg derefter, om gæsten må nå noget som helst undtagen gennem tunnelen. Det svar vælger internt eller kun for værten, og det er det spørgsmål, de fleste lab-beskrivelser springer over. Spørg til sidst, hvad der skal ske, når tunnelen falder, for det afgør politik frem for topologi, og et lab, der kun beviser den lykkelige vej, har testet næsten intet.

Forbind de tre roller med interne netværk

Brug tre gæster og to navngivne segmenter, med gatewayen som den eneste maskine, der 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

Der er ikke noget separat oprettelsestrin til et internt netværk. Strengen i --intnet1 er segmentet: to maskiner deler det kun, hvis navnet stemmer nøjagtigt, og intet på værten er knyttet til det. Den sidste egenskab er grunden til, at lab'et gentages rent, da værtens ruter, dens egen VPN-klient og dens firewall ikke kan nå gæsterne ved et uheld. Et internt segment har heller ingen DHCP-server, medmindre du tilføjer en, så statiske adresser er den korteste vej.

Giv klienten kun sin WAN-adresse, med en standardgateway, der peger på gatewayens WAN-adresse. Serveren får en LAN-adresse og bruger gatewayens LAN-adresse som sin standardgateway. En gæst, der holder to adresser på ét segment, eller har en vildfaren rute til det andet segment, har en vej uden om routeren, og testene nedenfor vil lyve for dig.

Jeg har en tekstfil ved siden af VM-navnene med de fire adresser og de to segmentnavne og indsætter den i hvert shell. Uger senere, når en profilændring brækker noget, er den fil forskellen mellem at fejlfinde profilen og at fejlfinde min egen hukommelse.

Vælg internt eller kun for værten til det segment, der ikke må lække

Tilstanden kun for værten opretter en virtuel adapter på værten selv, normalt vboxnet0, og giver værten en adresse på gæstens segment. Det er bekvemt til administration og fatalt for en isolationstest, fordi værten nu kan nå gæsten direkte, og hver tjeneste på værtssiden bliver en mulig vej. Intern tilstand har slet ingen værtadapter. De to tilstande forveksles let i netværksindstillingspanelet, så kontroller den dokumenterede forskel i stedet for etiketten (se siden netværksdetaljer for VirtualBox).

For en gæst, der skal bruge tunnelen, er internt det sikrere standardvalg, med gatewayen som den eneste udvej. Hvis du beholder kun for værten, skal du behandle værtadapteren som en administrationsvej og sige det højt: værten må nå gæsten, og gæsten må ikke kunne bruge værten som udgang.

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

Den isolation, du kan bevise, er den isolation, du har konfigureret. En gæst med én intern adapter, en standardrute ved gatewayen og ingen NAT-adapter har ingen vej, der springer gatewayen over. En gæst med en adapter kun for værten og en NAT-adapter har to veje, og kun én af dem er den, du ville teste.

Rout og oversæt på gatewayen, og få den derefter til at fejle lukket

VirtualBox videresender ikke mellem segmenter; det gør gæsten. Med VPN-server-VM'en bag gatewayen skal du aktivere videresendelse og oversætte klientens trafik, når den forlader mod serveren:

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

Med den regel ser serveren gatewayens LAN-adresse i stedet for klientens, og sådan ser en rigtig klient bag en udbyder-NAT ud for et hovedende. Gem sysctl-værdien i /etc/sysctl.d/ og reglen i den firewalltjeneste, distributionen bruger, ellers returnerer en genstart stille lab'et til en routet men uoversat tilstand.

Videresendelse er ikke autorisation. Under standardpolitikken FORWARD med værdien ACCEPT forlader en gæst, hvis standardrute peger på gatewayen, gennem det interface, routingtabellen vælger, tunnel eller ej. Hvis gatewayen også har en NAT-adapter til pakkeinstallation, er den adapter en fungerende ukrypteret udgang i det øjeblik, tunnelen falder, og din kun-VPN-test var aldrig en kun-VPN-test.

Når serveren i stedet er ekstern, og gatewayen selv afslutter tunnelen, peger samme beslutning på tunnelinterfacet, ikke på det NIC, der når internettet:

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 ydre transport og en out-of-band-administrationsrute adskilt fra videresendt trafik. Hvis den eneste måde at reparere gatewayen på er gennem den tunnel, du fejlfinder, bliver lab'et en udelukkelsesøvelse. En seriel konsol, en administrationsadapter kun for værten eller et snapshot af en kendt god tilstand er billigere end at gendanne en ødelagt router i hånden.

Verificér vejen fra gæsten, ikke fra værten

Arbejd udad. Bekræft, at klienten kan nå gatewayens WAN-adresse, derefter serveren gennem gatewayen, derefter at en forbindelse til VPN-porten forlader og vender tilbage. En optagelse på begge gatewayinterfaces viser, om svaret ankommer og droppes på returvejen, hvilket en optagelse kun på klienten ikke kan skelne:

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

Bevis derefter udgangen. Spørg fra gæsten en adresseafspejlingstjeneste, hvilken kilde den ser, og sammenlign det med gatewayens egen udgangsadresse; hvis svaret matcher værtens adresse, findes der en vej uden om tunnelen. Kontroller, hvilken resolver gæsten faktisk bruger, og kontroller IPv6 for sig selv, fordi et segment, hvor IPv6 er aktiveret, mens tunnelen kun bærer IPv4, lækker ved design og ikke ved et uheld.

Til sidst, bræk det med vilje. Stop tunnelen, eller bloker dens ydre port, og åbn en ny forbindelse fra gæsten. Den skal fejle, og årsagen skal være en, du kan navngive: ingen rute, en afvisningsregel eller en død resolver. Genstart tunnelen, og bekræft at gæsten kommer sig uden at genopbygge netværket. Hvis et mesh-VPN som Hamachi eller ZeroTier deler lab'et, så husk, at en brokoblet adapter følger adapternavnet, ikke meshet, så broen skal omdirigeres, efter klienten installerer sin egen virtuelle adapter.

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

At dele en gæsts tunnel med værten spejler problemet. At pege værtens standardrute på gæsten virker, og en proxy inde i gæsten gør også; NAT gennem værten bærer ikke gæstens tunnel for trafik, som værten startede. Gem segmentnavnene og firewallreglerne på ét sted, tag et snapshot af den fungerende tilstand, og registrér den kildeadresse, serveren observerede. Den næste profilændring koster så et scriptkørsel i stedet for et genopbygget lab.