Как настроить виртуальный коммутатор в Hyper-v 3.0 в Windows Server 2012R2

Продолжая цикл статей посвященный виртуализации, сегодня мы поговорим о настройке сети в Hyper-V. Основное внимание мы уделим теории, а именно разберем как устроены виртуальные сети и как они взаимодействуют с реальными. Потому что, как показывает практика, многие администраторы, в отсутствие простых и понятных материалов по данному вопросу, вынуждены осваивать настройку сети в Hyper-V методом «научного тыка».

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

За настройку сетей в Hyper-V отвечает Диспетчер виртуальных коммутаторов, если мы откроем его, то увидим следующую картину:

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

Внешняя сеть

Самый распространенный тип сети, который позволяет виртуальным машинам взаимодействовать с внешними сетями и хостом. При ее создании необходимо выбрать один из физических сетевых адаптеров, через который данная виртуальная сеть будет соединяться с внешними сетями.

Как мы уже писали, основу виртуальной сети составляет виртуальный коммутатор. При создании внешней сети, Hyper-V создает виртуальный коммутатор, к которому через виртуальные сетевые адаптеры (vNIC) подключаются как виртуальные машины, так и хост. Физический адаптер отключается от хоста и по сути становится физическим портом виртуального коммутатора, через который он подключается к внешней сети.

В этом нетрудно убедиться, после создания внешней сети на хосте появляется Адаптер Ethernet для виртуальной сети Hyper-V, на который переносятся все настройки с физического адаптера.

А в свойствах физического адаптера остался только Расширяемый виртуальный сетевой коммутатор в Hyper-V.

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

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

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

Внутренняя сеть

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

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

Внутренняя сеть c NAT

Данная возможность появилась начиная с Windows Server 2016, Hyper-V Server 2016 и Windows 10. Подробнее читайте в нашей статье: Настраиваем сеть NAT в Hyper-V

Частная сеть

Частная сеть отличается от внутренней тем, что виртуальный коммутатор может быть подключен только к виртуальным машинам и изолирован от хоста.

Данный вид сетей может быть использован также в учебных и исследовательских целей, а также для создания изолированных участков сети, например DMZ.

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

Как видим, Hyper-V дает в руки администратора весьма гибкий и мощный инструмент, позволяющий создавать весьма сложные сетевые конфигурации и управлять ими.

В настройке сети на «виртуальной машине» (далее по тексту принято сокращение «ВМ»), а также в добавлении виртуального свитча в оснастке Hyper-V нет ничего сложного, хотя даже для продвинутых пользователей иногда процедура может выглядеть немного запутанной.

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

Содержание

Архитектура Hyper-V

«Виртуальные сети» (сокращенно: «ВС») в Hyper-V называют виртуальными коммутаторами, к которым подключаются не только сетевые интерфейсы ВМ, но и физические сетевые интерфейсы сервера.

Существуют 3 вида «ВС». Схематично они представлены на рисунке ниже.

Майкрософт сравнительно недавно предусмотрела в «Windows Server 2008 R2» создание ВС «External» с изоляцией от хостовой системы. Осуществляется процесс просто. Следует убрать отметку из графы «Allow management operating system to share this network adapter».

При этом отключаются все ранее созданные подключения, и параметры прописываются для новой ВМ.

Необходимо отметить, что в Hyper-V имеется поддержка VLAN (IEEE 802.1Q).

После настройки коммутаторов, достаточно в свойствах ВМ установить отметку «Enable VLAN Identification» и указать VLAN ID.

Приятной новинкой, внедренной специалистами из Майкрософт в Виндовс Server 2008 R2, является поддержка виртуальных очередей VMQ.

Это сделало возможным перенаправление на процессор сетевого адаптера значительной доли нагрузки на обработку пакетов, которые направляются на ВМ с хостовой ОС. Сетевой адаптер с поддержкой VMQ может сам производить обработку пакетов и далее сохранять информацию в памяти ВМ.

Процедура настройки

Сложности с Hyper-V при настройке сети на виртуальной машине в основном вызваны недопониманием принципов реализации ее функционирования.

Многие хорошо знакомы с работой на «Виртуал Сервер» или «Microsoft’s Virtual PC» и привыкли к тому, что они функционируют как простые программы Виндовс.

Иными словами, приложения располагаются поверх Windows и процессы обмена данными с оборудованием осуществляются посредством ОС. Однако в Hyper-V все работает кардинально по противоположному принципу и в результате ВМ обеспечиваются прямым доступом к оборудованию сервера, то есть, минуя родительскую ОС.

Это обстоятельство накладывает некоторые нюансы на процедуру настройки доступа к сети ВМ Hyper-V из сетей.

Рассмотрим процесс на конкретном примере со следующими сетевыми параметрами: главный IP-адрес: ___.189.53.206/30; доп.адрес: ___.91.26.173/32; сервер с 2-мя интерфейсами (при этом задействован лишь 1-ый, а 2-ой отключен).

Далее всю процедуру исполняем только с LAN1.

Теперь можно приступить к настройке 2-х ВМ:

1. Внешней;
2. Внутренней.

1-ая ВМ получит связь с внешним миром через сетевую карту с доступом во всемирную патину, а 2-ая послужит как коммутатор корневого сервера с виртуальным хостом.

Чтобы создать эти ВМ потребуется войти в главную консоль управления Hyper-V, запустить диспетчер виртуальных сетей.

Установить отметки, как показано на скриншоте выше для создания 1-ой ВМ. Далее создать 2-ую, как изображено на рисунке ниже.

Подготовительные мероприятия на этом этапе завершены, но перед тем как настраивать сети, следует убедиться, что все исполнено корректно. От этого зависит успешность процедуры в целом.

Важное отступление: Во время создания 1-го ВМ будут разорваны все подключения, поэтому рекомендуется предусмотреть дополнительное соединение с сервером, например, IPMI, IP-KVM либо прямой физический доступ.

В окне сетевых подключений должна отображаться следующая картина, как показано на скриншоте ниже.

В параметрах коммутатора (2-ой ВМ) указать IP-адрес. В результате этот ВМ на физическом сервере станет работать как шлюз.

Уже можно констатировать приятный факт, что ввод параметров сетевых интерфейсов на корневом сервере окончен.

Затем надо произвести настройки «RRAS», чтобы обеспечить перенаправление трафика к ВМ и обратно. С этой целью в меню «Диспетчера сервера» потребуется присвоить роль для «Службы политики сети и доступа».

По умолчанию она «Остановлена» и следует ее настроить.

Отобразится мастер, указания которого требуется пошагово исполнить.

Установить отметку в графу «Особая конфигурация».

Поставить галочки в два поля, как сделано на иллюстрации выше.

Клацнуть «Готово».

Кликнуть «Запустить службу». Далее проверить корректность выполненной работы через меню диспетчера.

Служба полностью подготовлена и необходимо перейти к перенаправлению трафика к ВМ. Для этого создается промежуточный интерфейс, вызвав контекстное меню от «Преобразования сетевых адресов».

Клацнуть строчку «Новый интерфейс» и применить внешний интерфейс.

Войти в закладку «Преобразование сетевых адресов (NAT)» и поставить галочки в графах, указанных на следующем скриншоте:

Перейти в закладку «Пул адресов» и указать доп. адреса. От них запросы станут поступать на внутренние адреса ВМ.

Далее еще рекомендуется добавить резервный для внутреннего адреса ВМ, как показано на рисунке ниже.

В свойствах ввести параметры сети где расположен шлюз.

В результате ВМ получила выход во всемирную паутину. Чтобы удостовериться в этом, достаточно заглянуть в меню «Центра управления сетями и общим доступом».

Примечание: Если соединение с глобалкой отсутствует, то проблема быстро решается простым изменением параметров Брадмауэра на серверах.

Еще убедиться в правильности можно через любой интернет-сервис.

Задуманное успешно реализовано на практике, вот так просто можно применять несколько различных сетей на единственном реальном сервере, то есть физическом (сколько их пожелает создать администратор, столько же создается и коммутаторов).

А если требуется настроить сети на Линуксе, которая запущена под Hyper-V?

Многие сталкиваются с проблемой во время установки Ubuntu на ВМ Майкрософт Hyper-V. Сложность заключается в том, что Линукс просто иногда не способен при этом увидеть сетевую карту. Очевидно, что сеть в таком случае функционировать не будет.

Сложность может быть устранена следующей «уловкой»: в Параметрах ВМ указать одну из «древних» сетевых карт. ОС такую картуувидит сразу, то есть возникшая сложность устраниться быстро.

Но есть один недостаток этой маленькой хитрости. Часто процессор ВМ будет полностью загружен, а данное обстоятельство повлечет замедленное функционирование системы.

Заключение

Отдельные пользователи пренебрегают этапом настроек по «Преобразованию сетевых адресов (NAT)», который описан в инструкции выше. Однако этот механизм обеспечивает доступ ВМ к сети через объединение IP основной электронно-вычислительной машины с портом через внутренний коммутатор Hyper-V. В итоге приобретаются несколько следующих преимуществ:

1. Применяется внутренний коммутатор, что понижает загрузку сета электронно-вычислительной машины;
2. Несколько ВМ могут размещать программы, требующие внутренние порты связи, просто соотнося их с индивидуальными внешними интерфейсами;
3. Экономятся IP по причине сопоставления внешнего IP и порта со значительно увеличенным перечнем внутренних IP.

Получилось так, что на днях пришлось побороться с проблемой одного из моих клиентов. Сервер клиента расположен в польском Дата-центре ATMAN. Несмотря на то, что этот Дата-центр крупный, цивилизованный и в 2013 году номинирован на звание лучшего в мире, в его работе тоже есть свои глюки, которые специалисты ATMAN объясняют спецификой построения инфраструктуры для борьбы с DDOS. Если описывать вкратце — ATMAN распределяет дополнительные сетевые адреса из других под-сетей, что накладывает определенные ограничения на их использование. В том случае, о котором сейчас идет речь, необходимо использовать их не в качестве псевдонимов на сетевом интерфейсе рядом с основным адресом, а в качестве основных IP для виртуальных машин под управлением Hyper-V. Я попытался найти решение аналогичной проблемы в поисковиках, но не нашел и поэтому решил написать краткую инструкцию для тех, кто может столкнуться с подобной проблемой в будущем. В нашем примере будут использованы такие сетевые настройки: Основной IP: ***.189.53.206/30 Дополнительный IP: ***.91.26.173/32 Сервер имеет два сетевых интерфейса, но используется только один. Все операции буду выполняться именно с ним.Рис.1. Для удобства стандартные имена были изменены на LAN1 (используется для доступа к сети) и LAN2 (отключен).Рис.2. Основной интерфейс настраиваем согласно предоставленным ДЦ данными. Далее, необходимо настроить два виртуальных маршрутизатора — первый имеет тип «Внешний» с выходом во внешний мир, второй «Внутренний» для коммутации корневого сервера с виртуальным хостом. Оба виртуальных коммутатора необходимо создать в диспетчере виртуальных сетей консоли управления Hyper-V.Рис.3. Для внешнего интерфейса необходимо использовать сетевую карту с доступом в интернет.Рис.4. Для внутреннего виртуального коммутатора используются настройки, как показано на этом рисунке. На этом подготовка новых сетевых интерфейсов закончена. У нас должно получиться такое:Рис.5. Два дополнительных интерфейса – внешний и внутренний При создании внешнего интерфейса произойдет разрыв всех соединений. Убедитесь в том, что у Вас есть другой доступ к серверу (IP-KVM, IPMI или непосредственно физический). В нашем случае мне повезло и ДЦ дает IPMI по умолчанию. В настройках внутреннего интерфейса (Internal) укажите настройки схожие с теми, что используются тут, в нашем случае это 192.168.0.1. Этот интерфейс на физическом сервере будет выступать в роли шлюза для виртуальных машин.Рис.6. Настройки для внутреннего виртуального коммутатора. Дальнейшие настройки сетевых интерфейсов на корневом сервере завершены. Далее необходимо настроить службу RRAS для перенаправления трафика к виртуальным машинам и обратно. Для реализации этого необходимо установить роль «Службы политики сети и доступа» в оснастке Диспетчера сервера. Думаю, что расписывать этот процесс нет необходимости – Вы же уже установили роль Hyper-V ранее Рис.7. Установленная роль RRAS. После завершения установки данной роли она находится в статусе «Остановлена». По этому, ее нужно изначально настроить перед запуском.Рис.8. Начальная настройка службы. Перед Вами откроется окно мастера настройки службы. Выполняйте все действия, как показано на рисунках.Рис.9. Окно мастера настройки службы.Рис.10. Выбор особой конфигурации для нашего случая.Рис.11. Выбираем только преобразование адресов и маршрутизацию локальной сети.Рис.12. Завершающий этап настройки. Нажимаем «Готово».Рис.13. Соглашаемся на предложение запустить новую службу. После этого мы увидим в Диспетчере сервера развернутое дерево элементов этой самой службы RRAS.Рис.14. Служба готова к настройке. Для перенаправления трафика к виртуальной машине нужно создать интерфейс через который будут проходить все запросы. ПКМ на элементе «Преобразование сетевых адресов» выбираем пункт «Новый интерфейс».Рис.15. Создание нового интерфейса. В окне выбора интерфейсов нам необходимо использовать внешний сетевой интерфейс. Внутрений используется только для связи корневого сервера с виртуальными машинами.Рис.16. Выбор интерфейса для преобразования сетевых адресов. В свойствах внешнего интерфейса нам необходимо включить преобразование адресов, как показано ниже:Рис.17. Включение преобразования адресов. Далее, добавляем пул адресов, это наши дополнительные адреса запросы от которых будут перенаправляться на внутренние адреса виртуальных машин. ВАЖНО: не указывайте маску 255.255.255.255 для этих целей, работать это не будет. В нашем случае мы имеем три дополнительных адреса, маска указана /24 (особой роли это не играет). Теперь необходимо зарезервировать дополнительный адрес за внутренним у виртуальной машины. Делается все это очень просто.Рис.19. Резервирование адресов для виртуальных машин. В сетевых настройках указываем данные из той подсети, в которой находится шлюз. В нашем случае внутренняя подсеть вида 192.168.0.0/24, дополнительный адрес ***.91.26.173 мы закрепили за внутренним 192.168.0.3. Настройки сети виртуальной машины выглядят таким образом:Рис.20. Сетевые настройки виртуальной машины. Если все настроено правильно, то в центре управления сетями виртуальной машины получим такой вид (машина имеет доступ к интернету). В ином случае – проверьте настройки Брендмауэра на серверах.Рис.21. Центр управления сетями виртуальной машины. Любым сервисом проверяем корректность наших глобальных настроек. Результат: запрос с виртуальной машины должен показать нам именно внешний адрес, который был зарезервирован нами ранее:Рис.22. Результат теста на сайте 2ip.ru. На виртуальной машине, для проверки перенаправления портов, трафика, мигрантов и прочего, была установлена роль IIS. С любого ПК в браузере обращаемся к данному адресу, если видим «заглушку» веб-сервера – все прошло отлично, поставленную задачу мы решили. Таким образом, мы можем использовать множество разных подсетей на одном физическом сервере. С той лишь разницей, что для разных внутренних подсетей необходимо будет создавать отдельные виртуальные коммутаторы. Спасибо за внимание.,Используемые источники:

• https://interface31.ru/tech_it/2014/01/nastraivaem-set—v-hyper-v.html
• https://nastrojkin.ru/network/lan/hyper-v-nastrojka-seti.html
• https://habr.com/post/202594/