VMware гост в режим на мост загуби мрежата си след OpenVPN

Гост, който преди час беше в мост и достъпен, сега получава изчакване за всичко, и никой не е редактирал настройките му. На хоста интернетът все още работи през тунела. Двата факта заедно сочат далеч от VPN и към хипервизора, защото хостът и гостът вече не използват един и същ път. Достатъчен е един нов виртуален адаптер, за да го предизвика.

Гостът не се промени, мостът се промени

Инсталирането на клиента OpenVPN в Windows добавя виртуален мрежов адаптер, към който услугата се обвързва, когато се вдигне тунел. За операционната система той изглежда като обикновен интерфейс със състояние на връзката и често със собствени адреси. Това е достатъчно VMware да го третира като кандидат за мост.

VMnet0 по подразбиране е зададен на Автоматично, което означава, че хипервизорът избира адаптер на хоста всеки път, когато прави мост. Новоинсталиран виртуален адаптер влиза в този набор и ако бъде избран, всеки кадър, който гостът изпраща, отива към тунелно устройство вместо към физическия порт на комутатора.

Закрепете моста или маршрутизирайте госта

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

Решете това първо, защото двата отговора водят до различна работа. Обръщането на реда дава правилно закрепен мост, свързан с гост, който никога не е трябвало да бъде в мост.

За първия клон отворете Virtual Network Editor на хоста, изберете VMnet0 и заменете Автоматично с физическия адаптер. Ако има няколко адаптера, използвайте списъка с автоматични настройки и премахнете отметката от всичко, което никога не бива да носи трафик на госта: устройството OpenVPN TAP или Wintun, както и адаптерите Hyper-V, WSL, Docker и loopback. Оставете отбелязани и кабелния, и безжичния физически адаптер на лаптоп, иначе гостът губи моста си следващия път, когато потребителят го постави в док станцията.

Три условия, които решават избора

Дали мостът е изобщо подходящ зависи от това за какво е гостът. Ако гостът трябва да се появи като собствен хост в LAN, със собствен адрес и собствена входяща достъпност, мостът е правилният модел и закрепването е цялата поправка. Ако на госта му трябва само изходящ достъп, мрежа само за хоста или NAT е по-проста и устойчива на смени на адаптера.

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

VMware Player няма редактор на мрежата в интерфейса си, затова хост, който изпълнява само Player, се нуждае от самостоятелния редактор или инсталация на Workstation, за да стигне до тези настройки. Това ограничение понякога само решава подхода.

Прочетете резултата отвътре в госта

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

ipconfig /all
ip addr
ip route

Прочетете две полета в този изход и засега игнорирайте останалото. Шлюзът трябва да бъде рутерът на LAN, а описанието на адаптера трябва да посочва устройството VMware Ethernet, а не тунел. Самоназначен адрес в 169.254.0.0/16 означава, че нито един DHCP сървър не е отговорил, и точно така изглежда мост към тунелен адаптер от страната на госта.

Още едно разграничение си струва, преди да промените нещо друго. Гост, който стига до рутера, но не до интернет, има работещ мост и проблем по-нагоре. Гост, който получава адрес в обхвата на тунела, все още е свързан с грешното устройство. Изключването на TAP адаптера не е решение за нито един от двата случая, защото услугата OpenVPN се нуждае от него.