Настройка шлюза Hyper-V Network Virtualization на базе Windows Server 2012 R2
В нескольких предыдущих постах, посвященных технологии виртуализации сети (Hyper-V Network Virtualization, HNV), идёт речь об архитектуре, настройках, а также новых возможностях HNV в Windows Server 2012 R2. Данная заметка посвящена самой сложной теме – построении HNV-шлюза на базе Windows Server 2012 R2 для предоставления виртуализованным сетевым сегментам доступа во внешний мир.
В большинстве случаев виртуальным машинам (ВМ), развернутым в виртуализованных сетях, необходимо взаимодействие с внешним миром – для связи с другими объектами ЦОД-а, для выхода в Интернет, для доступа к корпоративной сети компании, которая расположила в ЦОД-е эти самые ВМ и пр. Применительно к технологии HNV внешним миром является все что угодно, находящееся за пределами виртуализованной сети. И прежде чем двигаться дальше, необходимо лишний раз определиться с терминологией, которая за два года существования HNV слегка видоизменилась.
Терминология
Определяющим понятием HNV является сеть заказчика (Customer Network), обладающая уникальным идентификатором Routing Domain ID (RDID). Это и есть та самая виртуализованная сеть. Для Customer Network существует несколько синонимов, в зависимости от того, каким инструментом вы пользуетесь:
- в VMM это VM Network;
- в PowerShell это Routing Domain;
- во многих статьях и блогах это Tenant или Tenant Virtual Network.
Но все эти термины суть Customer Network. Каждая сеть заказчика состоит из одной или более виртуальных подсетей (Virtual Subnet), и у каждой виртуальной подсети есть свой уникальный 24-битный идентификатор VSID. Маршрутизация пакетов между ВМ, принадлежащими одной сети заказчика, осуществляется автоматически, независимо от того, расположены ли эти машины в одной виртуальной подсети или в разных, на одном физическом хосте, или на разных. Если нужна связь с внешним миром, то есть необходимо передать пакеты за пределы Customer Network, то должен быть настроен HNV-шлюз (HNV Gateway, HNVGW).
Варианты реализации шлюза
HNV-шлюз может представлять собой либо готовое аппаратное решение, либо хост на базе Windows Server 2012 R2. На текущий момент на рынке доступны три аппаратных решения:
- от nAppliance
- от Iron Networks
- от F5
В этом посте сделан упор на создание HNV-шлюза на базе Windows Server 2012 R2, при этом управление HNV в лабораторной сети, в том числе настройка шлюза, будет осуществляться с помощью System Center 2012 R2 Virtual Machine Manager (VMM). Используя далее сокращение VMM, предполагается именно версию R2, если явно не указано иное.
Строго говоря, HNV – это технология Windows Server 2012 и выше, и она может быть настроена без VMM, просто с помощью командлетов PowerShell — примеры соответствующих скриптов без использования и с использованием HNV-шлюза. Но в реальных сценариях для управления HNV применяется VMM, который берет на себя роль централизованного хранения и распространения политик HNV.
Архитектура шлюза
Архитектурно HNV-шлюз на базе Windows Server 2012 R2 представляет собою физический хост, на котором запущена одна или несколько ВМ, выполняющих маршрутизацию пакетов из виртуализованных сетей во внешний мир и обратно. Обратите внимание, это именно физический хост. Реализовать HNV-шлюз просто в виде виртуалки не получится уже хотя бы потому, что для инкапсуляции пакетов (см. пост о концепции HNV) необходима роль Hyper-V, а вложенную виртуализацию Hyper-V пока не поддерживает.
Справедливости ради стоит отметить, что технически шлюз можно построить и на базе Windows Server 2012. Но при этом, во-первых, шлюз с Windows Server 2012 потребует запуска стольких ВМ, сколько у вас Customer Networks, и масштабирование такого решения затруднительно. Во-вторых, для управления таким шлюзом с помощью VMM необходимо будет написать провайдер для VMM. Использование же Windows Server 2012 R2 + System Center 2012 R2 Virtual Machine Manager – это практически готовый HNV-шлюз «из коробки». В Windows Server 2012 R2 реализован мультитенантный шлюз, позволяющий задействовать одну ВМ для маршрутизации трафика различных виртуализованных сетей, а в System Center 2012 R2 Virtual Machine Manager уже встроен провайдер для управления таким шлюзом.
Какие варианты работы HNV-шлюза существуют? Таковых два.
Private Cloud (Routing)
Первый вариант реализует маршрутизацию трафика из Customer Network в сеть ЦОД-а, причем маршрутизация может быть как прямой, так и c трансляцией адресов (NAT).
https://habrastorage.org/getpro/habr/post_images/f90/a66/116/f90a661162f1bef54150bccc5b629eee.gif
На рисунке изображена прямая маршрутизация, которая имеет смысл, если пространства CA-адресов разных тенантов (Customer Networks) не пересекаются и им нужен доступ в корпоративную сеть. Или, как на рисунке, есть только один тенант с несколькими подсетями. Для частного облака, когда тенанты, например, представляют собой виртуализованные сети различных департаментов крупного предприятия, вполне возможный вариант.
При использовании NAT каждому тенанту HNV-шлюз ставит в соответствие выделенный IP-адрес на своем внешнем интерфейсе, и все пакеты от виртуальных машин тенанта отправляются во внешний мир с этим выделенным IP в поле «IP-адрес отправителя».
Hybrid Cloud (Site to site VPN)
Второй вариант предполагает построение туннеля типа «сеть-сеть» от HNV-шлюза до необходимой точки, например, через Интернет до корпоративной сети заказчика.
https://habrastorage.org/getpro/habr/post_images/eca/fa3/ee6/ecafa3ee63dd2cb53372bf6908385483.png
Это как раз типовой хостерский сценарий, когда ВМ заказчика располагаются в ЦОД-е хостера и связываются через VPN с сетью заказчика. Технология HNV при этом позволяет заказчику сохранить настройки IP и не бояться за работоспособность софта внутри ВМ, а хостеру –расположить у себя виртуалки с нужными заказчику IP, изолируя эти виртуалки от других ВМ и не настраивая VLAN-ы.
Завершая архитектурный раздел поста, отметим, в чем же заключается мультитенантность шлюза на базе Windows Server 2012 R2.
Представьте себе, что в ЦОД-е виртуализованы сети двух заказчиков, Contoso и Woodgrove, использующие абсолютно одинаковые CA-пространства: 10.0.0.0/24. Как «развести» пакеты этих заказчиков на HNV-шлюзе? Первое возможное решение – создать на шлюзе для каждого заказчика свою ВМ и указать ее в настройках соответствующей сети заказчика в качестве default gateway. Таким образом, пакеты, направленные во внешний мир из Contoso, всегда будут приходить на сетевой интерфейс одной ВМ шлюза, пакеты из Woodgrove – на интерфейс второй ВМ и т. д. Как упоминалось, шлюз на базе Windows Server 2012 именно такой подход и использовал бы.
https://habrastorage.org/getpro/habr/post_images/3c9/0fc/804/3c90fc804c61a78496594b0c7ef52a82.png
В Windows Server 2012 R2 для маршрутизации появилась возможность использовать так называемые ячейки (compartments). В виртуальной машине для каждого тенанта создается некий объект «ячейка» (compartment), в которую включаются виртуальные сетевые интерфейсы, IP-адреса, таблица маршрутизации, ARP-таблица и пр. Элементы одной ячейки изолированы от элементов другой ячейки. Маршрутизация пакетов от Contoso, таким образом, осуществляется в рамках соответствующей ячейки и не пересекается, не влияет на маршрутизацию пакетов Woodgrove в другой ячейке, даже если записи в таблицах маршрутизации этих ячеек выглядят одинаково. Такой подход позволяет использовать одну ВМ для маршрутизации пакетов разных тенантов без каких-либо конфликтов.
https://habrastorage.org/getpro/habr/post_images/435/3a4/da0/4353a4da02237aa34da66859ba6e5f81.png
Как видно на рис. выше, существует ячейка по умолчанию (default compartment), которая включает в себя сетевые настройки, задаваемые при создании ВМ, и две ячейки для тенантов, появившиеся в процессе настройки HNV-шлюза.
Создание шлюза
Подкрепившись теорией, перейдем непосредственно к созданию шлюза. Для простоты рассматривается вариант шлюза без кластеризации, хотя понятно, что в реальном ЦОД-е такой важный элемент виртуализации предполагает работу в режиме высокой доступности. Детальный документ о том, как сделать HNV-шлюз высокодоступным можно найти здесь.
Основные шаги по созданию шлюза включают в себя следующее:
- настройка логических сетей и сетей ВМ;
- настройка хоста для роли шлюза
- подготовка ВМ для шлюза
- добавление шлюза в VMM
- настройка шлюза для конкретных сетей ВМ
Настройка логических сетей и сетей ВМ
Этот пункт довольно подробно описан в одном из постов, поэтому будет показано лишь то, как логические и виртуальные сети выглядят в лабораторном ЦОД-ике Contoso.
https://habrastorage.org/getpro/habr/post_images/033/572/0b5/0335720b5bd1ce2064e95845fdbc822c.png
Для задачи нужны три логические сети: внешний сегмент (Contoso_External_LN01), сеть для управления шлюзом (Contoso_Management_LN01) и сеть (Contoso_HNV_LN01), поверх которой собственно создаются виртуализованные сети. IP-пул сети Contoso_HNV_LN01 задает PA-пространство, а в свойствах этой сети обязательно должен быть помечен чекбокс, разрешающий использование технологии HNV.
https://habrastorage.org/getpro/habr/post_images/cdd/172/bd2/cdd172bd2659ffb899fc408da69cd917.png
Сети ВМ (VM Networks, они же сети заказчиков, они же Customer Networks) выглядят так:
https://habrastorage.org/getpro/habr/post_images/6d9/d71/6a3/6d9d716a382334c51dcc2d9a1e6c1585.png
Две сети ВМ для компаний Adatum и Fabrikam используют пересекающееся адресное пространство (10.30.1.0/24). В колонке Gateway Connection видно, что пока ни одна из сетей ВМ не использует шлюз.
Настройка хоста для роли шлюза
В общем-то любой хост с Windows Server 2012 R2, которым управляет VMM, можно настроить в качестве HNV-шлюза. У этого хоста должно быть несколько физических сетевых интерфейсов, смотрящих в нужные сегменты (внешний, сегмент управления, сегмент HNV). Однако из архитектурной части поста следует, что собственно маршрутизацией пакетов в шлюзе занимается ВМ. Поэтому сколько физических сетевушек должно быть в хосте, выполняющем роль шлюза, определяется вопросами производительности, надежности (можно использовать тиминг, например) и, конечно, логикой того, как и куда требуется отправлять пакеты. Конкретно в лаборатории хост-шлюз содержит всего один физический сетевой интерфейс, и этого вполне хватает для экспериментов.
Но в любом случае, в свойствах хоста, выбранного на роль шлюза, следует установить вот этот чекбокс
https://habrastorage.org/getpro/habr/post_images/801/aed/597/801aed597d9c678647db3b19c7850e06.png
Он предотвратит запуск на шлюзе любых «рядовых» ВМ, предполагающих использование HNV. В реальной ситуации вы вообще вряд ли будете запускать на шлюзе еще что-то, кроме компонент самого шлюза.
Подготовка ВМ для шлюза
Теперь поговорим о той самой ВМ, которая будет осуществлять маршрутизацию пакетов с помощью compartments. Проще всего развернуть ее с помощью сервисного шаблона (service template). В этом случае можно сразу же сказать VMM, чтобы при развертывании ВМ в ней была поднята служба RRAS, чтобы для высокой доступности таких машин было поднято две на кластере и пр. Но, во-первых, мы договорились сделать все руками, чтобы лучше понять, что происходит, во-вторых, сервисные шаблоны не поддерживают ВМ второго поколения, которые разворачиваются, да и работают пошустрее.
Поэтому я создал шаблон ВМ второго поколения на базе VHDX с образом Windows Server 2012 R2. В этом процессе нет ничего необычного, покажу лишь сетевые настройки в шаблоне.
https://habrastorage.org/getpro/habr/post_images/32d/e49/b13/32de49b1389d67c81d47b0bd9408ce13.png
Вы видите три виртуальных сетевых адаптера (vNIC): один подключен ко внешней сети (см. рис.), второй к сети управления, третий можно в шаблоне оставить в состоянии Not Connected, а в процессе или сразу после развертывания ВМ, подключить его через виртуальный коммутатор (Hyper-V Extensible Switch) к сети, в которой используется HNV. Обычно при описании шлюза эту сеть называют Backend.
Разворачиваем теперь ВМ на основе этого шаблона на хост, который мы выбрали и настроили в качестве шлюза в предыдущем пункте. Обратите внимание на имя, которые вы дадите этой ВМ. Оно понадобится впоследствии при конфигурации шлюза.
После того, как ВМ развернута, зайдем в нее, подключим сетевой адаптер к Backend-сети, отключим Firewall и для удобства переименуем сетевые адаптеры так, чтобы имена отражали их предназначение, например
https://habrastorage.org/getpro/habr/post_images/40c/0f9/54c/40c0f954cd5a33dc0ccecadb903b564a.png
Теперь в ВМ (GatewayVM01) необходимо установить роль Remote Access. Делается это стандартно через Server Manager, Manage -> Add Roles and Features. Нажимаем Next, пока не дойдем до выбора роли, выбираем Remote Access, затем снова Next, пока не дойдем до Role Services, где помечаем две службы
https://habrastorage.org/getpro/habr/post_images/7ce/dca/c75/7cedcac752a43047f661c74df0661cef.png
Жмем до упора Next и Install. После завершения установки нажимаем Open the Getting Started Wizard
https://habrastorage.org/getpro/habr/post_images/b84/8a4/acb/b848a4acba9fd96cf754fa63068a32dd.png
и в окне открывшегося мастера выбираем Deploy VPN only.
https://habrastorage.org/getpro/habr/post_images/4d6/0c4/0d1/4d60c40d1c69101fdbcccd563a2c6e4c.png
В итоге, откроется хорошо знакомая консоль RRAS, из которой видно, что служба пока не сконфигурирована.
https://habrastorage.org/getpro/habr/post_images/f39/9a0/174/f399a0174fb5edb0ab9bb64b4357eab2.png
Тем самым произведена настройка хоста и соответствующей ВМ, и теперь все готово, чтобы добавить эту «заготовку» в качестве HNV-шлюза в консоль VMM для последующей конфигурации.
Добавление шлюза в VMM
В консоли VMM переходим в раздел Fabric, нажимаем Add Resources и выбираем Network Service. На первой странице мастера даем шлюзу осмысленное имя и описание
https://habrastorage.org/getpro/habr/post_images/628/fa7/197/628fa7197b4625f8174fc415f051be04.png
Затем выбираем Microsoft в качестве производителя и Microsoft Windows Server Gateway в спис��е моделей
https://habrastorage.org/getpro/habr/post_images/b6e/5f9/b4e/b6e5f9b4e15425a67cbaad5d538fd484.png
На странице Credentials необходимо выбрать Run As account для доступа к устройству. Эта запись должна иметь административные права на ВМ шлюза. В нашем случае ВМ не включалась в домен, поэтому указываем запись с паролем локального администратора. Если в VMM такой записи нет, ее тут же можно создать.
https://habrastorage.org/getpro/habr/post_images/877/078/87e/87707887e3fbf70fca905199960424da.png
Самый, пожалуй, интересный параметр – строка подключения (Connection String), в которой с помощью трех параметров VMHost, GatewayVM и BackendSwitch необходимо указать имя хоста и ВМ «заготовки» и имя виртуального коммутатора на хосте, через который ВМ подключается к Backend-сети. Обратите внимание, что в строке подключения нет пробелов, разделителем служит точка с запятой (;).
https://habrastorage.org/getpro/habr/post_images/dfc/e30/ef3/dfce30ef3edc668b23d6c4e84bd7983b.png
Кроме трех перечисленных выше существует еще несколько параметров, описание которых можно найти здесь (см. п.16). В частности, DirectRoutingMode=True настроит шлюз на работу в режиме прямой маршрутизации.
При заданной выше строке подключения сертификаты не используются, поэтому на странице Certificates просто нажимаем Next.
На странице Provider нажимаем кнопку Test и убеждаемся, что все тесты проходят без ошибок.
https://habrastorage.org/getpro/habr/post_images/bca/348/e85/bca348e850e436817fba422a8db8a0db.png
На странице Host Group указываем, какие хостовые группы могут пользоваться данным шлюзом
https://habrastorage.org/getpro/habr/post_images/a10/f8a/3be/a10f8a3bef87119e1a6a1a4376ffeee1.png
Проверяем настройки на станице Summary, и если все правильно, жмем Finish.
https://habrastorage.org/getpro/habr/post_images/474/71e/a88/47471ea885510d59c026cb846024ae20.png
Проверьте, что соответствующие задачи в разделе Jobs успешно завершены. Остается настроить сетевые интерфейсы только что созданного HNV-шлюза. В разделе Fabric -> Networking -> Network Service консоли VMM щелкните правой кнопкой мыши по шлюзу, выберите Properties и перейдите на закладку Connectivity. Здесь нужно включить Front End Connection и Back End Connection и выбрать правильные сетевые адаптеры ВМ и соответствующие сайты логических подсетей.
https://habrastorage.org/getpro/habr/post_images/0f0/434/6a5/0f04346a5ae82b01361dce13a388f7d2.png
Вот теперь VMM знает, какие адаптеры ВМ шлюза для каких целей предназначены, и должным образом сконфигурирует службу RRAS внутри этой ВМ. Когда отработают job-ы, в консоли RRAS ВМ шлюза вы увидите, что служба запущена и работает как мультитенантный шлюз.
https://habrastorage.org/getpro/habr/post_images/e9c/bae/aca/e9cbaeacac3ba17f046de5640ff389cd.png
Дело за малым, настроить требуемые сети ВМ на использование созданного HNV-шлюза.
Настройка шлюза для конкретных сетей ВМ
В консоли VMM переходим в раздел VMs and Services, щелкаем VM Networks, выбираем нужную сеть ВМ и нажимаем кнопку Properties. Идем на закладку Connectivity и разрешаем использование HNV-шлюза этой сетью. Для сети Fabrikam, например, включаем NAT
https://habrastorage.org/getpro/habr/post_images/8ac/431/3ac/8ac4313acf3a35f3aaba8ddbd25894d2.png
VMM автоматически выделит из IP-пула логической сети, ассоциированной с внешним интерфейсом HNV-шлюза, адрес, в который будут транслироваться адреса отправителей всех пакетов из сети Fabrikam. Но вы можете вручную выбрать IP из пула, указав его в поле IP address
https://habrastorage.org/getpro/habr/post_images/d59/268/12c/d5926812cadde5684d8bc4330edb40bb.png
Закрыв окно свойств, в нижней части консоли VMM можно увидеть, какой конкретно внешний адрес используется для данной сети ВМ
https://habrastorage.org/getpro/habr/post_images/073/d46/649/073d46649542acfcea5f1c2cb945fa5e.png
Аналогично поступаем для сети Adatum и всех других виртуализованных сетей, которым нужен внешний доступ с поддержкой NAT.
Теперь давайте посмотрим, как настраивается подключение ко внешнему миру через VPN, то есть реализуем сценарий Hybrid Cloud (Site to site VPN). При этом я предполагаю, что VPN-устройство в корпоративной сети уже настроено, использует протокол IKEv2 и аутентификацию на основе Preshared Key, что типично для туннелей «сеть-сеть», и его внешний IP нам известен.
В свойствах той же сети ВМ Fabrikam на уже знакомой закладке Connectivity помечаем самый верхний чекбокс
https://habrastorage.org/getpro/habr/post_images/8ca/a6d/70e/8caa6d70e54039c0e01ede11119bee64.png
При этом в окне свойств сети ВМ появляется новая закладка VPN Connections, где нужно кнопкой Add добавить VPN-подключение, указать его имя и IP-адрес VPN-устройства, до которого строится туннель
https://habrastorage.org/getpro/habr/post_images/0e0/d77/d64/0e0d77d64839281a392360d59d495d1c.png
В разделе Authentication указываем подготовленную запись Run As account с прописанным Preshared Key,
https://habrastorage.org/getpro/habr/post_images/439/80c/b95/43980cb95b892b9ffd106174397a00b8.png
и в разделе Routes прописываем нужные маршруты, например
https://habrastorage.org/getpro/habr/post_images/4af/2a8/e8e/4af2a8e8e276e57e7685e47a051e9135.png
Как вы могли обратить внимание, для динамического обновления маршрутов реализована поддержка BGP.
Можно посмотреть на расширенные настройки в Advanced, скажем поменять VPN-протокол или параметры шифрования, но если ничего этого не требуется, то жмем ОК. В нижней части консоли VMM для настроенной сети ВМ теперь будет отображаться что-то вроде
https://habrastorage.org/getpro/habr/post_images/6e8/e6c/4e2/6e8e6c4e2301ac73cbafe0a3ffcd2059.png
Как только из любой ВМ, запущенной в виртуализованной сети Fabrikam, попробуем сделать ping на адрес из подсети, указанной с настройках VPN-туннеля, например, 10.30.50.101, HNV-шлюз поднимет туннель и установит связь с заданным VPN-устройством, а через него с корпоративной сетью
https://habrastorage.org/getpro/habr/post_images/4e1/ffc/a57/4e1ffca57be939c24b5f1e0c3c1c20bb.png
Дело сделано!
Если информации из этого поста оказалось недостаточно, можете воспользоваться подробным пошаговым руководством для создания лабораторного стенда.
Автор — Александр Шаповал.