VirtualBox NAT of bridge: waar de VPN van de VM eindigt

Er komen twee verschillende vragen tegelijk op wanneer een virtuele machine een VPN-client draait, en ze hebben verschillende antwoorden. De eerste is of een tunnel in de gast de host beschermt, de tweede of een tunnel op de host de gast dekt. De adaptermodus beslist beide, meer dan de VPN-software zelf. Een NAT-adapter maakt de host het zichtbare eindpunt, terwijl een bridge-adapter de gast met een eigen adres op het net zet.

Wie de versleutelde sessie werkelijk beëindigt

Een versleutelde sessie hoort bij de machine die hem beëindigt, en dat is de gast wanneer de client in de VM draait. Alleen verkeer dat de virtuele adapter van de gast binnenkomt, gaat door die tunnel, en de hypervisor leidt nooit uit zichzelf een andere machine door de gast. Daarom kan de gast een werkende tunnel houden terwijl de host open surft. Het omgekeerde is niet symmetrisch, en juist die asymmetrie is het deel dat de meeste handleidingen fout hebben.

Wiens adres het buitenste net ziet, is de vraag die de adaptermodus beantwoordt. Zodra dat vaststaat, houdt dekking op een beleidsvraag te zijn en wordt het een mechanische. Alles hieronder volgt uit die twee feiten.

NAT herschrijft de gast tot hij op de host lijkt

Bij NAT herschrijft de hypervisor elk pakket van de gast naar het adres van de host voordat het de eerste switch bereikt. Dat verkeer wordt daarna aan de eigen netwerkstack van de host gegeven, waar het zijn routetabel volgt, inclusief een standaardroute die eigendom is van een tunnel op de host. Een NAT-gast wordt dus zonder enige configuratie door een tunnel op de host gedekt, wat het tegenovergestelde is van wat het geval gast naar host suggereert.

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

Een gast die zijn eigen client draait, beëindigt die tunnel in de gast, en het versleutelde verkeer verlaat die daarna via dezelfde herschrijving, zodat toepassingen op de host hun eigen pad en hun eigen uitgangsadres houden. VirtualBox bezit in deze modus ook de naamresolutie en stuurt zoekopdrachten van de gast door zijn eigen motor, tenzij --natdnshostresolver1 is ingeschakeld. Inschakelen geeft de opzoekingen van de gast aan de resolver van de host, wat de resolutie corrigeert wanneer het beeld van de host zelf klopt en eveneens een resolver overdraagt die misschien alleen binnen een tunnel bestaat. De VM moet uitgeschakeld zijn voordat de instelling verandert, en de instelling hoort bij de adapter en niet bij de software van de gast.

Bridge geeft de gast een eigen lease en een eigen blootstelling

Bridge geeft de frames van de gast door aan het fysieke segment, dus DHCP geeft hem een lease en het net behandelt hem als een aparte host. Elke gebrugde gast kan een onafhankelijke tunnel met eigen standaardroute houden, en de tabel van de host verandert nooit. De prijs is blootstelling: de gast antwoordt op broadcasts, verschijnt in naburige tabellen en valt onder poortbeveiliging van de switch en isolatie van draadloze clients. Een tunnel op de host dekt deze opstelling ook niet, omdat frames van de gast nooit door de stack van de host gaan.

Dat verschil met het NAT-geval is het waard ronduit te zeggen in plaats van het als implicatie te laten staan. Een gebrugde gast heeft zijn eigen client en zijn eigen inloggegevens nodig zodra zijn verkeer een tunnel moet gebruiken. Waar de gast onzichtbaar moet blijven voor het lokale net, is NAT of een alleen intern net met gecontroleerde routering het betere ontwerp.

Waarom de gast niet de gateway van de host kan zijn

Het uitlenen van de tunnel van een gast aan de host heeft geen ondersteunde schakelaar in een van de twee grote hypervisors. De host heeft geen route naar de tunnel van de gast en geen vertaalregel die daarheen wijst, dus verkeer van gast en host blijft gescheiden stromen met gescheiden eigenaren. Die richting faalt ongeacht de adaptermodus.

De bruikbare vervangers zijn doorsturingen en proxy's. Een lokale SSH-doorsturing laat de host verbinden met zijn eigen loopback terwijl de gast de stroom de tunnel in draagt, wat TCP-diensten dekt zonder een tweede client te installeren. Het eigen IP-verkeer van de host in plaats daarvan de tunnel van de gast laten gebruiken vraagt een router in de gast plus een uitdrukkelijke route op de host en vertaling op de host. Dat is een klein netwerkontwerp en geen vinkje, en het vraagt een plan voor de terugweg. Wanneer de gast alleen bestaat om de client te draaien, zet de client op de host en schrap de extra hop.

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

Resolvers en routes steken de grens niet over

DNS volgt de adapter die de optie heeft ontvangen, dus een gast erft de tunnelresolver van de host niet en een host leert nooit de server die naar de gast is geduwd. Geduwde dhcp-option DNS-waarden gelden voor de interface die ze heeft aangenomen, en daarom kan een gebrugde gast zonder client geen interne namen oplossen. Een NAT-gast gebruikt meestal de DNS-afhandeling van de hypervisor, en het verschil is te zien in één opdracht per omgeving.

# 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

Lees de resolver en de route in de gast voordat je aanneemt dat een van beide de host volgt. Voeg de tunnelresolver toe aan de eigen adapter van de gast wanneer interne namen daar moeten worden opgelost, en controleer daarna met een naam die alleen achter de tunnel bestaat. Noteer de adaptermodus, de eigenaar van de tunnel en de bron van de resolver voor elke VM, want die drie feiten beantwoorden bijna elke latere vraag. Andere hypervisors hernoemen de modi en laten het principe intact.