Een VPN-sessie van de host delen met een VMware-gast

Uw virtuele machine bereikt geen intern systeem dat op de host perfect werkt, en de host is verbonden via een client die de routingtabel bezit. De virtuele adapter aan de tunnel bruggen lijkt voor de hand liggend en mislukt om twee afzonderlijke redenen. Wat werkt, is vertaling op een segment dat beide machines bezitten. De prijs is echt: elke gast verliest zijn eigen identiteit op het bedrijfsnetwerk.

Twee redenen waarom de bridge niet kan werken

De adapter van de client draagt meestal één adres, vaak een /32, en de client herschrijft de routes van de host zodat gewoon uitgaand verkeer de tunnel verkiest. Applicaties op de host gehoorzamen die tabel en bereiken het privésysteem. Een gebrugde gast leest de tabel helemaal niet, omdat zijn frames via een switch onder de IP-laag naar buiten gaan.

De tunneladapter in een bridge zetten zou het pad in theorie oplossen, en de driver accepteert dat niet. Windows 10 staat ook maar één bridge-apparaat toe en onthoudt de routerol die een werkstation tussen twee subnetten zou laten doorsturen. Wat overblijft is bronvertaling. Laat het verkeer van de gast lijken te komen van de host, en de beslissingen van de host zelf dragen het de tunnel in zonder dat de gast een route nodig heeft die hij niet kan hebben.

Maak een segment dat de host bezit

Voeg in de editor voor virtuele netwerken een host-only netwerk zoals VMnet3 toe op een prefix die u nergens anders routeert, bijvoorbeeld 172.28.90.0/24. De host neemt 172.28.90.1 op die adapter en de gast hangt aan dezelfde switch. Schakel de DHCP van de hypervisor op dat segment uit zodat één adresdienst het bezit.

Controleer of Windows de interface ziet voordat u er iets op bouwt, want het hele ontwerp hangt ervan af dat die adapter gewoon is:

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetIPAddress -AddressFamily IPv4 | Where-Object PrefixLength -eq 24

Een host-only adapter verschijnt daar als elke fysieke. Dat is precies het verschil met de tunneladapter, die aan niets kan worden gekoppeld.

Vertaal het prefix van de gast

Open een verhoogde sessie en vertaal het prefix. Controleer eerst wat al bestaat, want container-runtimes en hypervisors installeren hun eigen vertalingen en de verkeerde verwijderen breekt een ander product.

Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, Active
New-NetNat -Name "LabGuestEgress" -InternalIPInterfaceAddressPrefix 172.28.90.0/24

Configureer de gast daarna met een statisch adres in dat prefix, 172.28.90.1 als gateway en de resolveradressen die de tunnel de host geeft. Vertaling stuurt pakketten door en leert de gast niets over DNS, dus een gast die op de lokale router blijft, lost openbare namen op en faalt op elke interne.

Controleer de eerste hop, dan de prijs

Test de dichtstbijzijnde grens voordat u een applicatie test. Een trace die bij de gateway van de host stopt, betekent dat er geen vertaling plaatsvindt, terwijl een die voorbij de host stopt betekent dat de tunnel down is of dat de andere kant het vertaalde adres weigerde.

tracert -d 172.20.31.10
nslookup intranet.corp.example
Get-NetNatSession -NatName "LabGuestEgress"

Vergelijk met de eigen toegang van de host tot dezelfde bestemming terwijl de tunnel omhoog is. Als de host slaagt en de gast niet, zit de fout in de vertaling of in de gateway-instelling van de gast, niet in de verbinding.

Accepteer dan de ruil. Bedrijfssystemen zien nu één adres voor elke gast, dus apparaatcertificaten en postuurcontroles per apparaat kunnen ze niet onderscheiden, en sommige beleidsregels verbieden dit ronduit. Bepaal ook het dropgedrag, want vertaald verkeer kan bij het falen van de tunnel doorvallen naar het gewone internetpad, tenzij u dat prefix in de firewall van de host blokkeert.