Спільний доступ до 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"

Порівняйте з власним доступом хоста до того самого призначення, поки тунель піднятий. Якщо у хоста виходить, а в гостя ні, несправність у трансляції або в налаштуванні шлюзу гостя, а не в з’єднанні.

Потім прийміть цей обмін. Корпоративні системи тепер бачать одну адресу на кожного гостя, тому сертифікати пристроїв і перевірки стану окремих пристроїв не можуть їх розрізнити, а деякі політики прямо це забороняють. Вирішіть і поведінку скидання, бо трансльований трафік може провалитися на звичайний інтернет-шлях при відмові тунелю, якщо ви не заблокуєте цей префікс у брандмауері хоста.

Схожі статті