Dele en VPN-økt fra verten med en VMware-gjest

Den virtuelle maskinen din når ikke et internt system som fungerer perfekt på verten, og verten er koblet til gjennom en klient som eier rutetabellen. Bru vertens virtuelle adapter til tunnelen virker opplagt og feiler av to separate grunner. Det som virker, er oversettelse på et segment begge maskinene eier. Prisen er reell: hver gjest slutter å ha sin egen identitet på bedriftsnettet.

To grunner til at broen ikke kan virke

Klientens adapter har vanligvis én adresse, ofte en /32, og klienten skriver om vertens ruter slik at vanlig utgående trafikk foretrekker tunnelen. Programmer på verten adlyder tabellen og når det private systemet. En broet gjest leser aldri tabellen, fordi rammene dens går ut gjennom en svitsj under IP-laget.

Å sette tunneladapteren inn i en bro ville løse veien i teorien, og driveren godtar det ikke. Windows 10 tillater også bare én broenhet og holder tilbake ruteroilen som ville la en arbeidsstasjon videresende mellom to subnett. Det som gjenstår, er kildeoversettelse. Få trafikken til gjesten til å se ut som den kommer fra verten, og vertens egne beslutninger bærer den inn i tunnelen uten at gjesten trenger en rute den ikke kan ha.

Lag et segment verten eier

I editoren for virtuelt nettverk legger du til et host-only nettverk som VMnet3 på et prefiks du ikke ruter noe annet sted, for eksempel 172.28.90.0/24. Verten tar 172.28.90.1 på den adapteren, og gjesten kobles til samme svitsj. Slå av hypervisor-DHCP på det segmentet slik at én adressetjeneste eier det.

Bekreft at Windows ser grensesnittet før du bygger noe oppå det, fordi hele designet avhenger av at adapteren er vanlig:

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

En host-only-adapter vises der som enhver fysisk. Det er nettopp forskjellen fra tunneladapteren, som ikke kan kobles til noe.

Oversett prefikset til gjesten

Åpne en økt med forhøyede rettigheter og oversett prefikset. Sjekk først hva som allerede finnes, fordi container-runtime og hypervisorer installerer sine egne oversettelser, og å slette feil ødelegger et annet produkt.

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

Konfigurer deretter gjesten med en statisk adresse i det prefikset, 172.28.90.1 som gateway og resolveradressene tunnelen gir verten. Oversettelse videresender pakker og lærer gjesten ingenting om DNS, så en gjest som blir stående på den lokale ruteren løser opp offentlige navn og feiler på hvert internt.

Sjekk første hopp, deretter prisen

Test den nærmeste grensen før du tester et program. Et spor som stopper ved vertens gateway, betyr at oversettelse ikke skjer, mens et som stopper utenfor verten betyr at tunnelen er nede eller at den fjerne siden avviste den oversatte adressen.

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

Sammenlign med vertens egen tilgang til samme mål mens tunnelen er oppe. Hvis verten lykkes og gjesten ikke, ligger feilen i oversettelsen eller i gjestens gateway-innstilling, ikke i forbindelsen.

Godta så byttet. Bedriftssystemer ser nå én adresse for hver gjest, så enhetssertifikater og tilstandskontroller per enhet kan ikke skille dem, og enkelte retningslinjer forbyr det helt. Bestem også dropatferden, siden oversatt trafikk kan falle gjennom til den vanlige internettveien når tunnelen svikter, med mindre du blokkerer det prefikset i vertens brannmur.