Udostępnianie sesji VPN hosta gościowi VMware

Adapter tunelu nie dołącza do mostu, a Windows 10 nie routuje między podsieciami. Segment host-only z NAT przenosi gościa.

Twoja maszyna wirtualna nie dociera do systemu wewnętrznego, który działa bezbłędnie na hoście, a host jest połączony przez klienta, który posiada tablicę routingu. Mostkowanie wirtualnego adaptera do tunelu wygląda oczywiście i zawodzi z dwóch osobnych powodów. Działa tłumaczenie w segmencie, który posiadają obie maszyny. Koszt jest realny: każdy gość traci własną tożsamość w sieci korporacyjnej.

Dwa powody, dla których most nie może działać

Adapter klienta zwykle niesie jeden adres, często /32, a klient przepisuje trasy hosta tak, że zwykły ruch wychodzący preferuje tunel. Aplikacje na hoście słuchają tej tablicy i docierają do systemu prywatnego. Zmostkowany gość w ogóle nie czyta tablicy, bo jego ramki wychodzą przez przełącznik poniżej warstwy IP.

Umieszczenie adaptera tunelu w moście rozwiązałoby ścieżkę teoretycznie, a sterownik tego nie przyjmie. Windows 10 pozwala też tylko na jedno urządzenie mostu i odmawia roli routingu, która pozwoliłaby stacji roboczej przekazywać między dwiema podsieciami. Co zostaje, to tłumaczenie źródła. Spraw, by ruch gościa wyglądał jak pochodzący od hosta, a decyzje samego hosta niosą go do tunelu, bez potrzeby trasy, której gość mieć nie może.

Utwórz segment, który posiada host

W edytorze sieci wirtualnej dodaj sieć host-only, na przykład VMnet3, na prefiksie, którego nigdzie indziej nie routujesz, na przykład 172.28.90.0/24. Host bierze 172.28.90.1 na tym adapterze, a gość podłącza się do tego samego przełącznika. Wyłącz DHCP hypervisora w tym segmencie, aby jedna usługa adresowa go posiadała.

Potwierdź, że Windows widzi interfejs, zanim cokolwiek na nim zbudujesz, bo cały projekt zależy od tego, że ten adapter jest zwyczajny:

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

Adapter host-only pojawia się tam jak każdy fizyczny. Właśnie tym różni się od adaptera tunelu, którego nie można do niczego podłączyć.

Przetłumacz prefiks gościa

Otwórz sesję z podniesionymi uprawnieniami i przetłumacz prefiks. Najpierw sprawdź, co już istnieje, bo środowiska uruchomieniowe kontenerów i hypervisory instalują własne tłumaczenia, a usunięcie niewłaściwego psuje inny produkt.

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

Następnie skonfiguruj gościa ze statycznym adresem w tym prefiksie, 172.28.90.1 jako jego bramą i adresami resolvera, które tunel daje hostowi. Tłumaczenie przekazuje pakiety i nie uczy gościa niczego o DNS, więc gość pozostawiony na lokalnym routerze rozwiązuje nazwy publiczne i zawodzi na każdej wewnętrznej.

Sprawdź pierwszy skok, potem koszt

Przetestuj najbliższą granicę przed testowaniem aplikacji. Ślad, który zatrzymuje się na bramie hosta, oznacza, że tłumaczenie nie zachodzi, a ten, który zatrzymuje się za hostem, oznacza, że tunel leży albo druga strona odrzuciła przetłumaczony adres.

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

Porównaj z własnym dostępem hosta do tego samego celu, gdy tunel jest aktywny. Jeśli hostowi się udaje, a gościowi nie, usterka leży w tłumaczeniu lub w ustawieniu bramy gościa, nie w połączeniu.

Potem zaakceptuj tę wymianę. Systemy korporacyjne widzą teraz jeden adres dla każdego gościa, więc certyfikaty urządzeń i kontrole stanu poszczególnych urządzeń nie mogą ich odróżnić, a niektóre zasady wprost tego zabraniają. Zdecyduj też o zachowaniu przy odrzuceniu, bo przetłumaczony ruch może przy awarii tunelu przejść na zwykłą ścieżkę internetową, chyba że zablokujesz ten prefiks na zaporze hosta.

Powiązane artykuły