VirtualBox VPN-lab: gateway-VM kontra endast-värd-nätverk

Du måste bestämma hur mycket maskineri din VPN-lab förtjänar. En routad gateway-VM mellan två VirtualBox-segment återskapar adressöversättningen, returvägen och brandväggspositionen som en riktig klient sitter bakom. Ett enda endast-värd-segment ger dig en kontrollerad dörr och ingenting annat. Gateway-versionen kostar tre gäster och en routingtabell du underhåller; endast-värd-versionen kostar en gäst och en policy. Tre frågor skiljer dem, och den tredje avgör om ditt test ens kan gå igenom.

Svara på tre frågor innan du klonar något

Börja med vad VPN-servern måste observera. Om servern måste se en källadress som inte är testgästens, måste något översätta mellan dem, och det något måste vara en router du kontrollerar. Endast-värd-nätverk ger värden en adapter på gästens segment, inte en översättare. När gästen sedan behöver nå något utanför kopplar du in en NAT-adapter, och VirtualBox egen NAT-motor skriver om källan utan att fråga dig.

Fråga sedan om gästen får nå något annat än genom tunneln. Det svaret väljer internt eller endast värd, och det är frågan de flesta labbeskrivningar hoppar över. Fråga till sist vad som måste hända när tunneln faller, eftersom det avgör policy och inte topologi, och en lab som bara bevisar den lyckliga vägen har testat nästan ingenting.

Koppla de tre rollerna med interna nätverk

Använd tre gäster och två namngivna segment, med gatewayen som den enda maskinen som har en adapter på båda:

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 finns inget separat skapandesteg för ett internt nätverk. Strängen i --intnet1 är segmentet: två maskiner delar det bara om namnet stämmer exakt, och ingenting på värden är kopplat till det. Just den sista egenskapen är anledningen till att labben upprepas rent, eftersom värdens rutter, dess egen VPN-klient och dess brandvägg inte kan nå gästerna av misstag. Ett internt segment har inte heller någon DHCP-server om du inte lägger till en, så statiska adresser är den kortaste vägen.

Ge klienten bara sin WAN-adress, med en standardgateway som pekar på gatewayens WAN-adress. Servern får en LAN-adress och använder gatewayens LAN-adress som sin standardgateway. En gäst som håller två adresser på ett segment, eller har en vilsekommen rutt till det andra segmentet, har en väg runt routern, och testerna nedan kommer att ljuga för dig.

Jag har en textfil bredvid VM-namnen med de fyra adresserna och de två segmentnamnen, och klistrar in den i varje skal. Veckor senare, när en profiländring bryter något, är den filen skillnaden mellan att felsöka profilen och att felsöka mitt eget minne.

Välj internt eller endast värd för segmentet som inte får läcka

Endast-värd-läget skapar en virtuell adapter på värden själv, vanligtvis vboxnet0, och ger värden en adress på gästens segment. Det är bekvämt för administration och ödesdigert för ett isoleringstest, eftersom värden nu kan nå gästen direkt och varje tjänst på värdsidan blir en möjlig väg. Internt läge har ingen värdadapter alls. De två lägena förväxlas lätt i nätverksinställningspanelen, så kontrollera den dokumenterade skillnaden i stället för etiketten (se sidan VirtualBox-nätverksdetaljer).

För en gäst som måste använda tunneln är internt det säkrare standardvalet, med gatewayen som enda utväg. Om du behåller endast värd, behandla värdadaptern som en administrationsväg och säg det högt: värden får nå gästen, och gästen får inte kunna använda värden som utgång.

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

Den isolering du kan bevisa är den isolering du konfigurerade. En gäst med en intern adapter, standardrutt vid gatewayen och ingen NAT-adapter har ingen väg som kringgår gatewayen. En gäst med en endast-värd-adapter och en NAT-adapter har två vägar, och bara en av dem är den du menade att testa.

Routa och översätt på gatewayen, och få den sedan att misslyckas stängt

VirtualBox vidarebefordrar inte mellan segment; det gör gästen. Med VPN-server-VM:en bakom gatewayen aktiverar du vidarebefordran och översätter klientens trafik när den lämnar mot servern:

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

Med den regeln ser servern gatewayens LAN-adress i stället för klientens, och så ser en riktig klient bakom en leverantörs-NAT ut för en huvudände. Spara sysctl-värdet i /etc/sysctl.d/ och regeln i den brandväggstjänst som distributionen använder, annars återför en omstart labben tyst till ett routat men oöversatt tillstånd.

Vidarebefordran är inte auktorisering. Under standardpolicyn FORWARD med värdet ACCEPT lämnar en gäst vars standardrutt pekar på gatewayen genom det gränssnitt som routingtabellen väljer, med eller utan tunnel. Om gatewayen också har en NAT-adapter för paketinstallation är den adaptern en fungerande okrypterad utgång i samma ögonblick som tunneln faller, och ditt endast-VPN-test var aldrig ett endast-VPN-test.

När servern i stället är avlägsen och gatewayen själv avslutar tunneln, pekar samma beslut på tunnelgränssnittet, inte på NIC:en som når 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

Håll tunnelns egen yttre transport och en out-of-band-administrationsrutt åtskilda från vidarebefordrad trafik. Om det enda sättet att reparera gatewayen är genom tunneln du felsöker, blir labben en utelåsningsövning. En seriell konsol, en endast-värd-administrationsadapter eller en ögonblicksbild av ett känt gott tillstånd är billigare än att återställa en trasig router för hand.

Verifiera vägen från gästen, inte från värden

Arbeta utåt. Bekräfta att klienten når gatewayens WAN-adress, sedan servern genom gatewayen, sedan att en anslutning till VPN-porten lämnar och kommer tillbaka. En avlyssning på båda gatewaygränssnitten visar om svaret anländer och släpps på returvägen, vilket en avlyssning bara på klienten inte kan skilja:

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

Bevisa sedan utgången. Fråga från gästen en adressreflektionstjänst vilken källa den ser och jämför det med gatewayens egen utgångsadress; om svaret stämmer med värdens adress finns en väg runt tunneln. Kontrollera vilken resolver gästen faktiskt använder, och kontrollera IPv6 separat, eftersom ett segment där IPv6 är aktiverat medan tunneln bara bär IPv4 läcker enligt design och inte av misstag.

Bryt det slutligen med flit. Stoppa tunneln, eller blockera dess yttre port, och öppna en ny anslutning från gästen. Den måste misslyckas, och orsaken måste vara en du kan namnge: ingen rutt, en avvisningsregel eller en död resolver. Starta om tunneln och bekräfta att gästen återhämtar sig utan att bygga om nätverket. Om ett mesh-VPN som Hamachi eller ZeroTier delar labben, kom ihåg att en bryggad adapter följer adapternamnet, inte meshet, så bryggan måste riktas om efter att klienten installerat sin egen virtuella adapter.

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

Att dela en gästs tunnel med värden speglar problemet. Att peka värdens standardrutt på gästen fungerar, och en proxy inne i gästen också; NAT genom värden bär inte gästens tunnel för trafik som värden startade. Spara segmentnamnen och brandväggsreglerna på ett ställe, ta en ögonblicksbild av det fungerande tillståndet och registrera källadressen som servern observerade. Nästa profiländring kostar då en skriptkörning i stället för en återuppbyggd lab.