Windows Server 2012 и Hyper-V  —  фундаментальные строительные блоки частного «облака» Microsoft. Вместе с новейшей серверной операционной системой Microsoft поставляется гипервизор Hyper-V 3.0, в котором произошли многочисленные изменения. Hyper-V 3.0 может стать первой платформой виртуализации Microsoft, по своим достоинствам вполне сопоставимой с VMware vSphere.

Среди изменений Hyper-V  —  несколько новых функций, направленных на повышение безопасности. Виртуализация сети Network Virtualization  —  первый шаг Microsoft к централизованно программируемым сетям Software-Defined Networking (SDN). В SDN управление сетевым трафиком возлагается на программы, исполняемые не на физическом оборудовании сети. В результате мы получаем более гибкое управление и точную настройку сети. С точки зрения безопасности, благодаря SDN и виртуализации сети компании и поставщики услуг «облака» могут надежнее изолировать виртуальные машины на сетевом уровне.

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

Определение виртуализации сети

Благодаря виртуализации сети возможности изолирования виртуальных машин расширяются с узла на сетевой уровень. Изоляция  —  необходимое условие многоабонентских «облачных» решений, в которых приложения и службы различных компаний или подразделений размещаются в одном физическом сервере и сетевой инфраструктуре. Например, поставщик «облака», который размещает службы для компаний Apple и Samsung, наверняка не заинтересован в том, чтобы сотрудники Apple заглядывали в виртуальные машины и сеть Samsung, и наоборот.

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

Hyper-V поддерживает использование виртуальных локальных сетей VLAN для создания изолированных виртуальных сетей с момента выхода Windows Server 2008, но масштабируемость и гибкость виртуальных локальных сетей ограничены. Виртуальные локальные сети поддерживают лишь определенное число изолированных сетей клиентов. Основная причина в том, что коммутаторы, как правило, поддерживают не более 1000 идентификаторов VLAN из теоретического максимума 4096. По данным Microsoft, виртуализация сети обеспечивает функционирование более 16 млн виртуальных сетей.

Кроме того, виртуальным локальным сетям не хватает гибкости. Они плохо приспособлены для динамической «облачной» среды, в которой виртуальные машины клиентов регулярно появляются и исчезают в центре обработки данных и перемещаются между физическими серверами в целях балансировки нагрузки и управления вычислительными ресурсами. Управление VLAN отличается сложностью и требует изменения конфигурации на уровне коммутатора при перемещениях виртуальных машин на другой уровень. Операционная система Server 2012 также совместима с частными виртуальными локальными сетями PVLAN благодаря расширению на уровне виртуального коммутатора Hyper-V. PVLAN увеличивают уровень изоляции между виртуальными машинами, но не решают проблему сложности управления VLAN на виртуальных и физических сетевых устройствах. С этой проблемой можно справиться только с помощью виртуализации сетей.

Внутренний механизм виртуализации сетей

Для виртуализации сети каждой виртуальной машине назначается два IP-адреса. Один IP-адрес видим для виртуальных машин и имеет значение только в контексте данной виртуальной или централизованно программируемой сети клиентов. Этот адрес называется адресом клиента Customer Address (CA). Второй IP-адрес имеет значение только в контексте физической сети. Этот адрес называется адресом поставщика Provider Address (PA). Разделение на CA и PA приносит ряд преимуществ.

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

Виртуализация сети также обеспечивает динамическую миграцию виртуальных машин между физическими серверами в различных подсетях без перерывов в обслуживании. Если у виртуальных машин два IP-адреса, то можно изменить PA, не затрагивая CA. Пользователь или приложение, установившие связь с виртуальной машиной с использованием CA, не столкнутся с перебоями соединения и не заметят физического перемещения виртуальных машин в другую подсеть.

Помимо адресов CA и PA, при виртуализации сети используется третий важный компонент: идентификатор виртуальной подсети VSID. Каждая виртуальная подсеть при виртуализации сети уникально идентифицируется посредством VSID. С помощью идентификаторов VSID узлы Hyper-V отмечают трафик из различных виртуальных подсетей соответствующими тегами и различают трафик виртуальных машин с одинаковыми CA. Программная логика виртуализации сети инкапсулирует VSID, CA и PA в каждый сетевой пакет.

Чтобы распространить конкретные сети клиентов на несколько виртуальных подсетей (и таким образом IP-подсетей), идентификаторы VSID можно сгруппировать в одну сеть клиентов, которая уникально идентифицируется с использованием идентификатора домена маршрутизации RDID. В этих ситуациях изоляция виртуализации сети будет применяться на уровне определенных сетей клиентов. В этом еще одно отличие между виртуальными сетями Network Virtualization и традиционными VLAN: сети VLAN могут быть связаны только с одной IP-подсетью.

Виртуализация сети требует только узла Hyper-V Server 2012. При виртуализации сети гостевой операционной системе в виртуальной машине неизвестно, что ее IP-адрес виртуализован. С точки зрения виртуальных машин все связи устанавливаются с использованием CA. Это также означает, что виртуальная машина, которая является частью сети на основе Network Virtualization, может работать с любой операционной системой: не только Windows 8 и Server 2012, но и более старыми версиями Windows и других операционных систем.

На экране 1 показаны принципы организации виртуализации сети. В сущности, виртуализация сети реализуется как новый сетевой драйвер (ms_netwnv), который может быть привязан к физическим сетевым адаптерам на каждом физическом сервере и виртуальном сервере Server 2012. Новый виртуальный коммутатор Hyper-V, к которому мы еще вернемся в данной статье, вызывает этот сетевой драйвер для инкапсуляции и деинкапсуляции сетевых пакетов при сетевой виртуализации.

 

Реализация виртуализации сети в качестве драйвера сетевого фильтра
Экран 1. Реализация виртуализации сети в качестве драйвера сетевого фильтра

Транспортировка и маршрутизация при виртуализации сети

Для транспортировки и маршрутизации IP-пакетов с виртуализованными адресами CA через физическую сеть могут использоваться два механизма. В основе первого из них лежит протокол туннелирования Generic Routing Encapsulation (GRE), определенный в документах RFC 2784 и 2890. В этом контексте GRE используется для инкапсуляции сетевых пакетов, формируемых виртуальной машиной (с адресом CA), в пакеты, формируемые узлом (с адресом PA). Совместно с другими компаниями, занимающимися «облачными» технологиями (HP, Intel, Emulex, Dell и другими), Microsoft представила в комитет IETF проект, цель которого  —  сделать стандартом разновидность GRE для Network Virtualization (под названием NVGRE).

Второй механизм, переопределение IP-адреса, можно сравнить с преобразованием сетевых адресов Network Address Translation (NAT). Этот механизм переопределяет пакеты с виртуализованными адресами CA в пакеты с PA, которые можно маршрутизировать по физической сети.

На момент подготовки данной статьи переопределение IP-адреса больше подходит для виртуальных машин с высокими требованиями к пропускной способности (10 Гбит/с) благодаря использованию механизмов разгрузки сетевого адаптера на аппаратном уровне, таких как разгрузка больших пакетов large send offload (LSO) и очередь виртуальных машин virtual machine queue (VMQ). Существенный недостаток переопределения IP-адреса заключается в необходимости одного уникального PA для каждого CA виртуальной машины. В противном случае было бы невозможно распознавать и маршрутизировать сетевые пакеты, исходящие и поступающие в виртуальные машины разных клиентов с перекрывающимися IP-адресами.

Для GRE требуется только один PA на узел, поэтому Microsoft рекомендует использовать NVGRE при переопределении IP-адресов для виртуализации сети. NVGRE можно реализовать, не внося изменений в архитектуру физического сетевого коммутатора. Туннели NVGRE завершаются на узлах Hyper-V и выполняют всю инкапсуляюцию и деинкапсуляюцию сетевого трафика GRE.

Недостаток GRE состоит в невозможности задействовать механизмы разгрузки сетевого адаптера на аппаратном уровне. Поэтому, если вы планирует использовать NVGRE для виртуализации сети с высокой пропускной способностью, рекомендуется подождать выпуска сетевых адаптеров с функцией разгрузки NVGRE. Microsoft ожидает, что такие платы для Server 2012 появятся в продаже в 2013 году. При использовании GRE не забудьте о брандмауэрах, в которых по умолчанию могут быть заданы правила для блокирования GRE. Всегда проверяйте, разрешен ли туннельный трафик GRE (IP Protocol 47) в брандмауэре.

Реализация Network Virtualization

Процесс реализации и настройки Network Virtualization в Hyper-V 3.0 отличается от настройки частных локальных сетей в Hyper-V. Частные локальные сети можно настроить из диспетчера Hyper-V в настройках сетевого адаптера виртуальных машин. Настройка виртуализации сети не является частью настройки виртуальных машин и не может быть выполнена из диспетчера Hyper-V. Это объясняется тем, что виртуализация сети основывается на определенных политиках, применяемых на уровне виртуального коммутатора узла Hyper-V.

Чтобы определить политики виртуализации сети локально на узле, необходимо использовать сценарии Windows PowerShell. Для централизованного определения политик можно задействовать графический интерфейс диспетчера Microsoft System Center Virtual Machine Manager (VMM) с пакетом обновления 1 (SP1). VMM  —  унифицированное решение Microsoft для управления виртуальными машинами. В крупной среде Network Virtualization настоятельно рекомендуется использовать VMM. VMM может запускать нужные команды PowerShell от имени пользователя и применять политики виртуализации сети на узле Hyper-V через локальные агенты узла System Center. Важное ограничение, существующее на данный момент, заключается в том, что графический интерфейс VMM можно использовать только для задания политик переопределения IP-адресов. Чтобы назначить политики NVGRE, необходимо задействовать сценарии PowerShell. Начинающие пользователи могут освоить приемы настройки Network Virtualization через PowerShell с помощью примера сценария на PowerShell в демонстрационном пакете Simple Hyper-V Network Virtualization Demo, подготовленном компанией Microsoft (http://gallery.technet.microsoft.com/scriptcenter/Simple-Hyper-V-Network-d3efb3b8).

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

Шлюзы Network Virtualization поставляются в различных конструктивных вариантах. Они могут быть построены на шлюзе VPN, который формирует VPN-соединение, чтобы связать две виртуальные сети через физическую сеть. Для этой цели можно использовать сервер Server 2012, на котором выполняется служба маршрутизации RRAS. Функциональность шлюза Network Virtualization может быть предоставлена и выделенным сетевым устройствам (например, коммутаторам, сетевым устройствам), которые действуют как шлюз маршрутизации для виртуализации сети. На данный момент шлюзовые устройства Network Virtualization выпускаются или готовятся к выпуску компаниями F5 Networks и nAppliance Networks. Настроить шлюзы Network Virtualization можно с помощью PowerShell. Начинающим полезно познакомиться с примером сценария в статье Microsoft «Simple Hyper-V Network Virtualization Script with Gateway» (http://gallery.technet.microsoft.com/scriptcenter/Simple-Hyper-V-Network-6928e91b).

К счастью, существуют расширения VMM SP1 для централизованного и автоматического управления политиками шлюза Network Virtualization. При создании или обновлении виртуальной машины VMM может автоматически обновить топологию маршрутизации каждого устройства шлюза Network Virtualization. Дополнительные сведения о шлюзах Network Virtualization можно найти в статье Microsoft «Hyper-V Network Virtualization Gateway Architectural Guide» (http://technet.microsoft.com/en-us/library/jj618319.aspx).

Гораздо более подробная общая информация о виртуализации сети приведена в статье Microsoft «Microsoft Windows Server 2012 Hyper-V Network Virtualization Survival Guide» (http://social.technet.microsoft.com/wiki/contents/articles/11524.windows-server-2012-hyper-v-network-virtualization-survival-guide.aspx). Хорошую сводку шагов для настройки виртуализации сети можно найти в блоге Microsoft TechNet «Step-by-Step: Hyper-V Network Virtualization» (http://blogs.technet.com/b/keithmayer/archive/2012/10/08/gettingstartedwithhypervnetworkvirtualization.aspx).

Расширяемый виртуальный коммутатор

В Hyper-V 3.0 появились важные изменения в архитектуре виртуального коммутатора (теперь именуемого расширяемым коммутатором). Этот виртуальный сетевой коммутатор уровня 2 может быть настроен на каждом узле Hyper-V и находится на перекрестке сетевого трафика между виртуальными машинами, между виртуальными машинами и узлом Hyper-V и трафиком с внешними компьютерами. Расширяемый коммутатор  —  компонент Hyper-V, который применяет политики виртуализации сети и располагает другими интересными функциями, относящимися к безопасности.

Партнеры Microsoft могут расширять возможности коммутаторов с использованием платформы Windows Filtering Platform (WFP) или фильтров network device interface specification (NDIS) для мониторинга и изменения сетевых пакетов, авторизации соединений или фильтрации трафика. Благодаря новой архитектуре расширяемый коммутатор поможет применить политики безопасности и изолирования при подключении виртуальных машин к сети. Виртуальный коммутатор  —  идеальное место для проверки данных, пересылаемых между виртуальными машинами, при поиске опасных программ. Классические средства противодействия вредоносному программному обеспечению и несанкционированному доступу обычно не проверяют этот трафик с его помощью и анализируют только трафик между физическими узлами. Некоторые партнеры Microsoft уже работают с расширяемыми коммутаторами: компания sFlow со своим расширением для мониторинга; 5nine, которая выпустила расширение виртуального брандмауэра; NEC, подготовившая расширение для мониторинга на основе OpenFlow. OpenFlow  —  важный открытый протокол для сетей SDN.

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

Еще одна мощная функция расширяемого коммутатора  —  политики изоляции на основе списков контроля доступа ACL, которые можно определить и применять на виртуальных портах расширяемого коммутатора. В сущности, в этих политиках перечислены правила разрешения и запрета, которые изолируют виртуальные машины и не позволяют им связываться с другими виртуальных машин в зависимости от IP- или MAC-адресов. Политики изоляции расширяемого коммутатора можно определить и из диспетчера VMM.

Наконец, в расширяемом коммутаторе реализованы такие новые функции безопасности, как DHCP Guard, разгрузка операций IPsec Task Offload, задачи IPsec и защита от подделки протокола разрешения адресов Address Resolution Protocol (ARP). С помощью DHCP Guard можно запретить виртуальным машинам работать в качестве сервера DHCP. DHCP Guard отвергает любые пакеты, отправляемые виртуальными машинами, которые указывали бы, что это сервер DHCP. DHCP Guard  —  свойство, которое можно настроить для любого сетевого адаптера виртуальной машины. Сделать это можно из диспетчера Hyper-V, в разделе дополнительных параметров сетевого адаптера в свойствах виртуальных машин, как показано на экране 2. Рекомендуется включить этот режим при создании «золотого» образа виртуальных машин.

 

Включение DHCP Guard
Экран 2. Включение DHCP Guard

Разгрузка операций IPsec позволяет Hyper-V передать обработку, связанную с IPsec, в сетевой адаптер. Это возможно только в том случае, если сетевой адаптер поддерживает данную функцию. Разгрузка операций IPsec позволяет сократить рабочую нагрузку на процессор узла Hyper-V, связанную с использованием алгоритмов шифрования IPsec. Можно также включить этот режим из диспетчера Hyper-V: используйте раздел Hardware Acceleration в параметрах сетевого адаптера в свойствах виртуальных машин, как показано на экране 3.

 

Включение разгрузки операций IPsec
Экран 3. Включение разгрузки операций IPsec

Расширяемый коммутатор обеспечивает защиту от подмены ARP, чтобы вредоносные виртуальные машины не могли предпринять атаку типа man-in-the-middle. В ходе такой атаки вредоносная машина использует ложные сообщения ARP, чтобы связать фальшивые MAC-адреса с не принадлежащими ей IP-адресами. В результате обманутые машины могут отправлять сообщения вредоносной машине. Чтобы включить защиту от подмены ARP, необходимо оставить флажок Enable MAC address spoofing (включить спуфинг MAC-адресов) в изначальном состоянии (сброшен).

Чтобы упростить настройку расширяемого коммутатора и его расширений, Microsoft предоставляет команды PowerShell. Вы можете использовать их для создания автоматизированных сценариев для настройки, мониторинга и диагностики расширяемого коммутатора.

Упрощенное делегирование и расширение BitLocker

В Hyper-V 3.0 упрощено административное делегирование благодаря появлению локальной группы безопасности Hyper-V Administrators. Члены новой группы имеют полный доступ ко всем функциям Hyper-V. Администраторам следует использовать эту группу для управления доступом к Hyper-V вместо того, чтобы добавлять пользователей к локальной группе Administrators. Кроме того, новая группа отчасти заменяет диспетчер Windows Authorization Manager (AzMan), который в прошлом был единственным доступным способом организации административного делегирования в Hyper-V. Администраторы могут по-прежнему использовать AzMan для делегирования, требующего большего уровня детализации и выходящего за рамки назначения полной роли администратора Hyper-V.

Наконец, нужно указать, что в Server 2012 можно воспользоваться новыми функциями шифрования BitLocker на уровне томов для защиты конфиденциальности и целостности образов виртуальных машин, хранящихся в местах с ненадежной физической защитой. В Server 2012 технология BitLocker расширена для шифрования томов операционной системы и данных на дисках в отказоустойчивых кластерах, в том числе общих томах кластеров. Дополнительные сведения можно найти в статье «BitLocker в Windows 8», опубликованной в Windows IT Pro/RE № 10 за 2012 год.

Важные отличия от средств безопасности vSphere

Новые функции безопасности  —  важное отличие Hyper-V от ближайшего конкурента, VMware vSphere. Хороший пример  —  расширяемый коммутатор Hyper-V. VMware также предоставляет виртуальный сетевой коммутатор, но он доступен только в редакции высокого уровня vSphere Enterprise Plus, цена которой, естественно, выше. Коммутатор vSphere не открытый, не расширяемый и не располагает передовыми функциями защиты (например, DHCP Guard и списки ACL виртуального порта) коммутатора Hyper-V. Чтобы дополнить vSphere такими функциями, необходимо приобрести дополнительные программы, например компонент App комплекса VMware vCloud Networking and Security (vCNS).

То же справедливо и для компонента Hyper-V Network Virtualization. Чтобы получить аналогичную функциональность в среде vSphere, потребителям необходимо обратиться к комплексу vCNS, в котором реализована технология VXLAN. Для VXLAN требуется коммутатор vSphere Distributed Switch (VDS), который есть только в редакции высокого уровня vSphere. Ожидается, что VMware скоро реализует централизованно программируемые сети SDN благодаря приобретению компании Nicira.

Отменная гибкость

Таким образом, Hyper-V 3.0 располагает мощными новыми функциями безопасности, которые позволят повысить гибкость и управляемость многоабонентских «облаков» на основе Hyper-V. Пришло время поближе познакомиться с новым продуктом Hyper-V. Кроме того, обязательно изучите новые возможности VVM SP1, незаменимый инструмент для управления развертыванием Hyper-V.