Dela en VPN-session från värden med en VMware-gäst

En tunneladapter går inte in i en brygga, och Windows 10 dirigerar inte mellan subnät. Ett host-only-segment med NAT bär gästen.

Din virtuella maskin når inte ett internt system som fungerar perfekt på värden, och värden är ansluten genom en klient som äger routingtabellen. Brygga den virtuella adaptern till tunneln verkar självklart och misslyckas av två separata skäl. Det som fungerar är översättning på ett segment som båda maskinerna äger. Priset är verkligt: varje gäst förlorar sin egen identitet på företagsnätet.

Två skäl till att bryggan inte kan fungera

Klientens adapter bär vanligtvis en enda adress, ofta en /32, och klienten skriver om värdens rutter så att vanlig utgående trafik föredrar tunneln. Program på värden lyder tabellen och når det privata systemet. En bryggad gäst läser aldrig tabellen, eftersom dess ramar lämnar genom en switch under IP-lagret.

Att sätta tunneladaptern i en brygga skulle lösa vägen i teorin, och drivrutinen accepterar det inte. Windows 10 tillåter också bara en bryggenhet och håller tillbaka den routingroll som skulle låta en arbetsstation vidarebefordra mellan två subnät. Det som återstår är källöversättning. Få gästens trafik att se ut som om den kommer från värden, och värdens egna beslut bär den in i tunneln utan att gästen behöver en rutt den inte kan ha.

Skapa ett segment som värden äger

I redigeraren för virtuella nätverk lägger du till ett host-only-nätverk som VMnet3 på ett prefix som du inte dirigerar någon annanstans, till exempel 172.28.90.0/24. Värden tar 172.28.90.1 på den adaptern och gästen ansluts till samma switch. Stäng av hypervisorns DHCP på det segmentet så att en enda adresstjänst äger det.

Bekräfta att Windows ser gränssnittet innan du bygger något ovanpå det, eftersom hela designen hänger på att adaptern är vanlig:

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

En host-only-adapter visas där som vilken fysisk som helst. Det är just skillnaden mot tunneladaptern, som inte kan anslutas till något.

Översätt gästens prefix

Öppna en session med förhöjda rättigheter och översätt prefixet. Kontrollera först vad som redan finns, eftersom container-runtimes och hypervisorer installerar sina egna översättningar och att radera fel förstör en annan produkt.

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

Konfigurera sedan gästen med en statisk adress i det prefixet, 172.28.90.1 som dess gateway och de resolveradresser som tunneln ger värden. Översättning vidarebefordrar paket och lär gästen ingenting om DNS, så en gäst som lämnas på den lokala routern löser offentliga namn och misslyckas på varje internt.

Kontrollera första hoppet, sedan priset

Testa den närmaste gränsen innan du testar ett program. Ett spår som stannar vid värdens gateway betyder att översättning inte sker, medan ett som stannar bortom värden betyder att tunneln är nere eller att den andra sidan avvisade den översatta adressen.

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

Jämför med värdens egen åtkomst till samma mål medan tunneln är uppe. Om värden lyckas och gästen inte, ligger felet i översättningen eller i gästens gateway-inställning, inte i anslutningen.

Acceptera sedan bytet. Företagssystem ser nu en adress för varje gäst, så enhetscertifikat och tillståndskontroller per enhet kan inte skilja dem åt, och vissa policyer förbjuder det helt. Bestäm också dropbeteendet, eftersom översatt trafik kan falla igenom till den vanliga internetvägen när tunneln sviktar, om du inte blockerar det prefixet i värdens brandvägg.

Relaterade artiklar