Гость 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 он нужен.