Совместное использование VPN-сеанса хоста с гостем VMware

Туннельный адаптер не входит в мост, а Windows 10 не маршрутизирует между подсетями. Сегмент host-only с NAT несёт гостя.

Ваша виртуальная машина не может достучаться до внутренней системы, которая безупречно работает на хосте, а хост подключён через клиент, владеющий таблицей маршрутизации. Соединить виртуальный адаптер с туннелем через мост кажется очевидным и срывается по двум отдельным причинам. Работает трансляция на сегменте, которым владеют обе машины. Цена реальна: каждый гость теряет собственную личность в корпоративной сети.

Две причины, почему мост не может работать

Адаптер клиента обычно несёт один адрес, часто /32, и клиент переписывает маршруты хоста так, что обычный исходящий трафик предпочитает туннель. Приложения на хосте подчиняются этой таблице и добираются до частной системы. Гость за мостом вовсе не читает таблицу, потому что его кадры выходят через коммутатор ниже уровня IP.

Помещение туннельного адаптера в мост теоретически решило бы путь, но драйвер этого не примет. Windows 10 также разрешает только одно мостовое устройство и не даёт роли маршрутизации, которая позволила бы рабочей станции пересылать между двумя подсетями. Остаётся трансляция источника. Сделайте так, чтобы трафик гостя выглядел исходящим от хоста, и решения самого хоста проводят его в туннель без необходимости для гостя в маршруте, которого у него не может быть.

Создайте сегмент, которым владеет хост

В редакторе виртуальной сети добавьте сеть host-only, например VMnet3, на префиксе, который вы нигде больше не маршрутизируете, скажем 172.28.90.0/24. Хост берёт 172.28.90.1 на этом адаптере, а гость подключается к тому же коммутатору. Отключите DHCP гипервизора на этом сегменте, чтобы им владела одна служба адресов.

Убедитесь, что Windows видит интерфейс, прежде чем что-то поверх него строить, потому что вся схема зависит от того, что этот адаптер обычный:

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

Адаптер host-only появляется там как любой физический. Именно в этом отличие от туннельного адаптера, который нельзя ни к чему подключить.

Переведите префикс гостя

Откройте сеанс с повышенными правами и переведите префикс. Сначала проверьте, что уже существует, потому что среды выполнения контейнеров и гипервизоры ставят свои трансляции, а удаление неверной ломает другой продукт.

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

Затем настройте гостя со статическим адресом в этом префиксе, 172.28.90.1 в качестве шлюза и адресами распознавателя, которые туннель даёт хосту. Трансляция пересылает пакеты и ничему не учит гостя про DNS, поэтому гость, оставленный на локальном маршрутизаторе, разрешает публичные имена и терпит неудачу на каждом внутреннем.

Проверьте первый прыжок, затем цену

Проверьте ближайшую границу прежде чем проверять приложение. Трасса, которая останавливается на шлюзе хоста, означает, что трансляция не происходит, а та, что останавливается дальше хоста, означает, что туннель лежит или удалённая сторона отказала в транслированном адресе.

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

Сравните с собственным доступом хоста к тому же назначению, пока туннель поднят. Если у хоста получается, а у гостя нет, неисправность в трансляции или в настройке шлюза гостя, а не в соединении.

Затем примите этот обмен. Корпоративные системы теперь видят один адрес на каждого гостя, поэтому сертификаты устройств и проверки состояния отдельных устройств не могут их различить, а некоторые политики прямо это запрещают. Решите и поведение при сбросе, потому что транслированный трафик может провалиться на обычный интернет-путь при отказе туннеля, если вы не заблокируете этот префикс в брандмауэре хоста.

Похожие статьи