Del en VPN-session fra værten med en VMware-gæst

Din virtuelle maskine kan ikke nå et internt system, der fungerer perfekt på værten, og værten er forbundet gennem en klient, der ejer routingtabellen. Bro den virtuelle adapter til tunnelen virker indlysende og fejler af to separate grunde. Oversættelse på et segment, som begge maskiner ejer, er det, der virker. Prisen er reel: hver gæst mister sin egen identitet på virksomhedsnetværket.

To grunde til at broen ikke kan virke

Klientens adapter bærer normalt én adresse, ofte en /32, og klienten omskriver værtens ruter, så almindelig udgående trafik foretrækker tunnelen. Programmer på værten adlyder den tabel og når det private system. En broet gæst læser slet ikke tabellen, fordi dens rammer forlader gennem en switch under IP-laget.

At sætte tunneladapteren ind i en bro ville løse vejen i teorien, og driveren accepterer det ikke. Windows 10 tillader også kun én broenhed og tilbageholder den routingrolle, der ville lade en arbejdsstation videresende mellem to undernet. Det, der er tilbage, er kildeoversættelse. Få gæstens trafik til at se ud, som om den kommer fra værten, og værtens egne beslutninger bærer den ind i tunnelen, uden at gæsten behøver en rute, den ikke kan have.

Opret et segment, som værten ejer

I virtual network-editoren tilføjer du et host-only-netværk som VMnet3 på et præfiks, du ikke ruter andre steder, for eksempel 172.28.90.0/24. Værten tager 172.28.90.1 på den adapter, og gæsten tilsluttes den samme switch. Slå hypervisorens DHCP fra på det segment, så én adressetjeneste ejer det.

Bekræft, at Windows kan se grænsefladen, før du bygger noget oven på den, for hele designet afhænger af, at den adapter er almindelig:

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 netop forskellen fra tunneladapteren, som ikke kan tilsluttes noget.

Oversæt gæstens præfiks

Åbn en session med forhøjede rettigheder, og oversæt præfikset. Kontroller først, hvad der allerede findes, fordi container-runtimes og hypervisorer installerer deres egne oversættelser, og sletning af den forkerte ødelægger et andet produkt.

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

Konfigurer derefter gæsten med en statisk adresse i det præfiks, 172.28.90.1 som dens gateway og de resolveradresser, tunnelen giver værten. Oversættelse videresender pakker og lærer gæsten intet om DNS, så en gæst, der efterlades på den lokale router, opløser offentlige navne og fejler på hvert internt.

Kontroller første hop, derefter prisen

Test den nærmeste grænse før du tester et program. Et spor, der stopper ved værtens gateway, betyder, at oversættelse ikke sker, mens et, der stopper ud over værten, betyder, at tunnelen er nede, eller at den fjerne side afviste den oversatte adresse.

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

Sammenlign med værtens egen adgang til samme destination, mens tunnelen er oppe. Hvis værten lykkes, og gæsten ikke gør, ligger fejlen i oversættelsen eller i gæstens gatewayindstilling, ikke i forbindelsen.

Acceptér så byttet. Virksomhedssystemer ser nu én adresse for hver gæst, så enhedscertifikater og tilstandskontroller per enhed kan ikke skelne dem, og nogle politikker forbyder det helt. Beslut også dropadfærden, da oversat trafik kan falde igennem til den almindelige internetvej, når tunnelen svigter, medmindre du blokerer det præfiks i værtens firewall.