Использует ли виртуальная машина Hyper-V VPN хоста? Зависит от коммутатора

Установите VPN-клиент на хосте Hyper-V, откройте там браузер, и адрес выхода меняется; откройте ту же страницу внутри виртуальной машины, и она может показать старый адрес или вообще ничего. Обычный вывод — виртуальная машина сломана или нужно включить раздельное туннелирование. Ни то, ни другое не следует. VPN-клиент — не свойство машины; это набор маршрутов, виртуальный адаптер и часто фильтр, привязанный к конкретным интерфейсам. Встретится ли трафик гостя когда-нибудь с этим механизмом, зависит от виртуального коммутатора, который использует гость.

Миф, изложенный прямо

Верят, что установленный на хосте VPN защищает всю машину, включая виртуальные машины, потому что виртуальная машина — это всего лишь процесс на этой машине. Это удобная вера, ведь антивирус и брандмауэры хоста обычно ведут себя именно так. Сетевые пути — нет.

Кадр гостя затрагивает стек VPN хоста, только если хост маршрутизирует или фильтрует его. Перепишите это предложение на стикер, потому что каждый случай ниже — его вариация.

Три типа коммутатора, три пути

Внешний коммутатор привязывает виртуальный адаптер к физической сетевой карте, и гость отправляет кадры через эту привязку со своим MAC-адресом. Гость становится равноправным участником физической сети, со своей арендой DHCP, шлюзом и DNS-серверами. Маршрут VPN хоста по умолчанию живёт в стеке хоста и не двигает эти кадры, потому что они мостятся, а не маршрутизируются через хост. Поэтому же внешний коммутатор поверх Wi-Fi-адаптера — плохая идея: большинство беспроводных драйверов не переносят кадры для второго MAC-адреса.

Внутренний коммутатор соединяет гостей с виртуальным адаптером хоста. Сам по себе он не даёт выхода в интернет; объект NAT на хосте обеспечивает трансляцию, как описано в руководстве Hyper-V по NAT. Теперь пакеты гостя действительно попадают в маршрутизацию и путь NAT хоста, поэтому маршруты и фильтры VPN-клиента снова важны. Это та схема, в которой виртуальная машина действительно следует за VPN хоста и в которой kill switch может полностью отрезать гостя.

У частного коммутатора нет адаптера хоста и нет вышестоящего канала. Гости общаются друг с другом и ни с чем больше, поэтому если у виртуальной машины на частном коммутаторе нет интернета, причина — отсутствующий маршрутизатор, а VPN ни при чём.

Коммутатор по умолчанию — отдельная схема

Windows поставляет коммутатор по умолчанию, который сочетает внутренний коммутатор с NAT и DNS-прокси. Его подсеть выбирает хост, она может измениться после перезагрузок и не является тем же объектом, что сеть NAT, созданная вами. Перестраивать его как лабораторную сеть — так люди и получают два NAT и гостя, у которого всё ещё нет маршрута.

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

Четыре факта, которые решают вопрос

Соберите это до любых изменений: тип коммутатора и его вышестоящий канал, адаптер, подключённый к виртуальной машине, собственный адрес, шлюз и DNS гостя, а также состояние NAT и маршрута по умолчанию на хосте. Команды только для чтения: Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat, и Get-NetRoute -DestinationPrefix 0.0.0.0/0; а внутри гостя ipconfig /all даёт остальное.

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

Тест внутри гостя — единственное доказательство, которое имеет значение. Проверьте адрес выхода из гостя, разрешите внутреннее имя, переподключите VPN и повторите. Результат браузера хоста ничего из этого не заменяет.

Чего стоит миф

Люди отключают kill switch, добавляют статические маршруты или удаляют и создают коммутаторы заново только чтобы тест прошёл. Каждый обход меняет режим отказа: гость может выйти в интернет путём, которого никто не планировал, или хост может потерять связь, когда внешний коммутатор заново привязывает физическую карту.

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

Долговечный ответ — одна строка на каждую виртуальную машину в описи: какой коммутатор она использует и какой компонент даёт ей шлюз. Когда это записано, следующее изменение VPN — это справка, а не день догадок.