VirtualBox NAT eller brygga: var VM:ens VPN slutar

Två olika frågor kommer samtidigt varje gång en virtuell maskin kör en VPN-klient, och de har olika svar. Den första är om en tunnel inne i gästen skyddar värden, och den andra är om en tunnel på värden täcker gästen. Adapterläget avgör båda, mer än VPN-programvaran själv. En NAT-adapter gör värden till den synliga slutpunkten, medan en bryggadapter sätter gästen på nätet med sin egen adress.

Vem som faktiskt avslutar den krypterade sessionen

En krypterad session tillhör maskinen som avslutar den, och det är gästen när klienten körs inuti VM:en. Bara trafik som går in i gästens virtuella adapter passerar den tunneln, och hypervisorn dirigerar aldrig själv en annan maskin genom gästen. Därför kan gästen hålla en fungerande tunnel medan värden surfar öppet. Det omvända är inte symmetriskt, och just den asymmetrin är den del som de flesta guider får fel.

Vems adress det yttre nätet ser är frågan som adapterläget besvarar. När det är avgjort slutar täckning att vara en politisk fråga och blir en mekanisk. Allt nedan följer av de två fakta.

NAT skriver om gästen tills den liknar värden

Med NAT skriver hypervisorn om varje paket från gästen till värdens adress innan det når den första switchen. Den trafiken lämnas sedan till värdens egen nätverksstack, där den följer värdens routingtabell, inklusive en standardrutt som ägs av en tunnel på värden. En NAT-gäst täcks därför av en tunnel på värden helt utan konfiguration, vilket är motsatsen till vad fallet gäst till värd antyder.

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

En gäst som kör sin egen klient avslutar den tunneln inne i gästen, och den krypterade trafiken lämnar den sedan genom samma omskrivning, så värdens program behåller sin egen väg och sin egen utgångsadress. VirtualBox äger också namnmatchningen i detta läge och skickar gästens frågor genom sin egen motor om inte --natdnshostresolver1 är aktiverat. Att aktivera det överlämnar gästens sökningar till värdens matchare, vilket rättar matchningen när värdens egen bild är riktig och lika gärna överlämnar en matchare som kanske bara finns inne i en tunnel. VM:en måste vara avstängd innan inställningen ändras, och inställningen tillhör adaptern och inte gästens programvara.

Bryggan ger gästen sin egen lease och sin egen exponering

Bryggan skickar gästens ramar vidare till det fysiska segmentet, så DHCP ger den en lease och nätet behandlar den som en egen värd. Varje bryggad gäst kan hålla en oberoende tunnel med sin egen standardrutt, och värdens tabell ändras aldrig. Priset är exponering: gästen svarar på utsändningar, syns i grannars tabeller och hamnar under portskydd i switchen och isolering av trådlösa klienter. En tunnel på värden täcker inte heller den här ordningen, eftersom gästens ramar aldrig går genom värdens stack.

Den skillnaden mot NAT-fallet är värd att sägas rakt ut i stället för att lämnas som antydan. En bryggad gäst behöver sin egen klient och egna inloggningsuppgifter varje gång dess trafik måste använda en tunnel. Där gästen måste förbli osynlig för det lokala nätet är NAT eller ett rent internt nät med kontrollerad routing den bättre designen.

Varför gästen inte kan vara värdens gateway

Att låna ut en gästs tunnel till värden har ingen stödd växel i någon av de två stora hypervisorerna. Värden har ingen rutt in i gästens tunnel och ingen översättningsregel som pekar dit, så gästens och värdens trafik förblir åtskilda flöden med åtskilda ägare. Den riktningen misslyckas oavsett adapterläge.

De användbara ersättningarna är vidarebefordran och proxyservrar. En lokal SSH-vidarebefordran låter värden ansluta till sin egen loopback medan gästen bär strömmen in i tunneln, vilket täcker TCP-tjänster utan att installera en andra klient. Att låta värdens egen IP-trafik använda gästens tunnel i stället kräver en router inne i gästen plus en uttrycklig rutt på värden och översättning på värden. Det är en liten nätverksdesign och inte en kryssruta, och den behöver en plan för returvägen. När gästen bara finns för att köra klienten, sätt klienten på värden och ta bort det extra hoppet.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Matchare och rutter korsar inte gränsen

DNS följer adaptern som tog emot valet, så en gäst ärver inte värdens tunnelmatchare och en värd får aldrig veta servern som sköts till gästen. Påskjutna dhcp-option DNS-värden gäller för gränssnittet som tog emot dem, och därför kan en bryggad gäst utan klient inte matcha interna namn. En NAT-gäst brukar använda hypervisorns DNS-hantering i stället, och skillnaden syns i ett enda kommando per miljö.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

Läs matcharen och rutten inne i gästen innan du antar att någon av dem följer värden. Lägg till tunnelmatcharen på gästens egen adapter när interna namn måste matchas där, och kontrollera sedan med ett namn som bara finns bakom tunneln. Anteckna adapterläge, tunnelns ägare och matcharens källa för varje VM, eftersom de tre fakta besvarar nästan varje senare fråga. Andra hypervisorer byter namn på lägena och lämnar principen intakt.