Споделяне на VPN сесия на хоста с гостуваща машина VMware

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

Две причини мостът да не може да работи

Адаптерът на клиента обикновено носи един адрес, често /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"

Сравнете със собствения достъп на хоста до същата дестинация, докато тунелът е активен. Ако хостът успее, а гостът не, дефектът е в транслацията или в настройката на шлюза на госта, не във връзката.

После приемете размяната. Корпоративните системи сега виждат един адрес за всеки гост, така че сертификатите на устройствата и проверките на състоянието по устройство не могат да ги различат, а някои политики го забраняват напълно. Решете и поведението при отпадане, тъй като транслираният трафик може да падне към обичайния интернет път, когато тунелът се провали, освен ако не блокирате този префикс във файъруола на хоста.