Управление узлами Hyper-V при соединении через DirectAccess

  • Article

С выходом Windows 7 и Windows Server 2008 R2 нам была представлена технология Direct Access, позволяющая получать доступ к корпоративной сети без создания виртуальных частных сетей (VPN) или использования служб Удалённого рабочего стола (Remote Desktop). Подробнее о Direct Access можно почитать на блоге моего коллеги — эта технология заслуживает, по меньшей мере, внимательного изучения.

Прошёл год с выхода новой ОС, и теперь всё чаще мои заказчики начинают её использовать. Начинают, конечно же, с подразделений IT, с администраторов. Какой доступ требуется администратору из дома в корпоративную сеть? Почта обычно доступна и без таких модных технологий. Работать с документами и порталами? Из дома? Извините! Для меня DirectAccess дает возможность при необходимости запустить консоль администрированя той или иной службы для настройки и исправления возникающих проблем. Ну и, естественно, меня интересует консоль Hyper-V Manager для управления узлами виртуализации — на которых, собственно, и развёрнута вся корпоративня инфраструктура.

Тут, однако, есть тонкий момент. Настроив DirectAccess и проверив, что контроллеры домена мне доступны, что я получаю доступ к файловым серверам, что я могу «удалённым рабочим столом» зайти на серверы виртуализации, — я считаю задачу выполненной. Но в один «прекрасный» день я пробую соединиться с узлами виртуализации из консоли Hyper-V Manager — и... не могу этого сделать. Давайте разберемся, в чем же дело, и что необходимо настроить дополнительно.

Консоль Hyper-V Manager работает с узлами виртуализации при помощи двусторонних (bi-directional) запросов к WMI. При установки консоли Hyper-V Manager (из Windows 7 Remote Server Administration Tools) во встроенном брандмауэре создаются три специальных исключения. Да, три правила, даже на клиентской ОС!

  1. Hyper-V Management Clients - WMI (Async-In)
  2. Hyper-V Management Clients - WMI (DCOM-In)
  3. Hyper-V Management Clients - WMI (TCP-In)

Эти три правила разрешают входящий трафик RPC и DCOM, необходимый для управления узлами виртуализации и виртуальными машинами Hyper-V.

Вкупе с использованием DirectAccess возникает следующая проблема.

  • Данные правила блокируют трафик, обозначенный как NAT Traversal.
  • DirectAccess и есть технология NAT.

Для того, чтобы исправить это досадное недоразумение, нам потребуется слегка видоизменить обозначенные выше правила брандмауэра. Для этого из Administrative Tools откроем оснастку Windows Firewall with Advanced Security.

Выберем список правил, разрешающих входящий трафик, и найдем те, которые отвечают за Hyper-V.

Откроем первое из этих правил.

В закладке Advanced заметим, что Edge Traversal запрещен, блокируя трафик NAT.

Изменим это значение на Allow Edge Traversal и применим аналогичные настройки для двух оставшихся правил.

Следует понимать, что для работы Hyper-V Manager через DirectAccess потребуется, чтобы узел виртуализации мог разрешить адрес IPv6 вашего компьютера по его имени (ведь DirectAccess использует только IPv6). Чтобы проверить это, убедитесь в том, что с сервера виртуализации команда ping на имя вашего удаленного ПК должна отрабатывать на его адрес IPv6. Обычно это не является проблемой при правильно настроенном DNS. Если ваш сервер DNS не поддерживает записи AAA IPv6, вы можете вручную добавить соотношение имени и адреса IPv6 в файл hosts на узлах виртуализации.

Надеюсь, что кому-то это поможет. Помните, что DirectAccess доступен только в редакциях Enterprise и Ultimate Windows 7 и работает по IPv6.