Администрирование и настройка VMware NSX-T Data Center 3.1

Программно-определяемая организация виртуальных сетей NSX-T – чрезвычайно важный элемент экосистемы VMware и в прошлой статье «VMware NSX-T Data Center 3.1: Разворот с нуля» рассказывались базовые принципы ее разворота. Мы узнали каковы требования к совместимости с другими компонентами среды, о минимальных ее параметрах для эффективной работы и существующих лимитах, а также познакомились с системой нужных для нее портов и другими полезными при построении вещами. Кроме того, рассмотрели процедуры разворота кластеров уровня управления, Edge и транспортных нод, транспортных зон в разрезе распространенных гипервизоров.

Сегодня же мы изучим проблему настройки VIP, научимся создавать и конфигурировать сегменты трафика, шлюзы, а также виртуальные свитчи N-VDS, рассмотрим процесс назначения профилей аплинков, маршрутизации, политик и основных функций безопасности, включать нужные службы и многое другое. И, наконец, узнаем, как использовать мониторинг для отслеживания состояния виртуальных сетей в целом и их компонентов.

Для более глубокого понимания того, о чем ниже будет вестись речь, обязательно советуем ознакомиться с еще одной нашей статьей из цикла о NSX-T – «Дизайн VMware NSX-T Data Center 3.1», и обязательно построить базу нашей будущей системы по рекомендациям из «VMware NSX-T Data Center 3.1: Разворот с нуля».

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

Об UI NSX и режимах работы NSX-T Data Center 3.1

После установки NSX-T Data Center 3.1 нам будет доступен пользовательский интерфейс Manager. В нем можно переключаться между режимами «Policy» и «Manager», делать всевозможные настройки и строить структуру виртуальных сетей по своему усмотрению. Переключение осуществляется кнопками в верхней части правого рабочего поля:

Режим «Policy»

Этот режим является дефолтным для новых инсталляций, он поддерживается федерацией и рекомендован для настройки NSX-T Data Center. Однако ряд функций не доступны в «Policy». Когда идет первый разворот NSX-T, в UI все делается именно в нем, а режим «UI Mode» подсвечивается скрытым. Чтобы сделать его видимым, заходим на вкладку «System» и в левой панели ищем под «Settings» – «User Interface Settings»:

В средах с объектами, созданными под режимом «Manager» (апгрейды с прошлых версий, клауд-платформы и др.), режим «UI Mode» подсвечен по умолчанию в верхнем правом углу интерфейса.

Режим «Manager»

Режим «Manager» работает с объектами, недоступными для «Policy», с созданными под «Advanced Network» и «Security» до апгрейда до NSX-T Data Center 3.0, а также при интеграции NSX в cloud-платформы (vRealize Automation, VMware Integrated OpenStack и т.п.).

Вкладка «Home»

Здесь можно увидеть общие сведения о виртуальной сети на вкладке «Overview», выведены «Alarms» со значком степени внимания для быстрого к ним доступа, а также приведены панели мониторинга по направлениям «System», «Networking & Security», «Compliance Report» и «Custom» на вкладке «Monitoring Dashboards». Предупреждениям и мониторингу ниже будет посвящен отдельный раздел.

Вкладка «Networking» Manager UI

В этой вкладке настраиваются самые разнообразные функции сети. В том числе коммутация, маршрутизация и службы L3 (NAT, VPN, балансировщик нагрузки и т.д.). В режиме «Policy» она выглядит так:

А в «Manager» так:

То, что в «Policy» названо «Segments», в «Manager» показано как «Logical Switches» в левой панели. Шлюзы Т0 и Т1 в «Policy» – это логические маршрутизаторы в «Manager» («Tier-0 Gateways» и «Tier-1 Gateways» – это «Tier-0 Logical Routers» и «Tier-1 Logical Routers»).

Второй раздел сверху в левой панели вкладки «Networking» – «Network Topology» – позволяет просмотреть, какую именно в итоге всех нижеследующих в теме организации виртуальной сети действий топологию удалось построить. И выглядеть ее визуализация при этом может, например, вот так:

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

Вкладка «Security» Manager UI

Здесь создаются политики файервола и политики безопасности конечных точек (снова два представления для режимов «Policy» и «Manager»):

Вкладка «Inventory» Manager UI

Во вкладке «Inventory» доступна информация о сервисах, группах, контекстных профилях, виртуальных машинах, контейнерах, физических серверах и назначенных тегах:

Вкладка «Plan & Troubleshoot» Manager UI

Эта вкладка предоставляет функционал NSX Intelligence для планирования и проведения в жизнь политик безопасности в крупных проектах виртуализации:

С целью мониторинга и траблшутинга можно выбирать инструменты «IPFIX», «Port Mirroring», «Traceflow» и «Consolidated Capacity».

Вкладка «System» Manager UI

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

А теперь уделим внимание каждому из основных компонентов пользовательского интерфейса NSX-T: сетевому устройству, безопасности, работе с инвентарем, мониторингу и планированию, а также системе.

Организация виртуальной сети

В этом разделе мы будем учиться строить полную топологию сети: создавать пул IP-адресов, сегменты, шлюзы Т1 и Т0, связывая их между собой, включать функции BFD, ECMP и Allow AS-In, настраивать карты маршрутов и их агрегацию, многоадресную пересылку, изучим реализацию логического соединения мостами, а также включение служб NAT, DHCP, DNS, Load Balancer, IPSec VPN на шлюзах и многие другие полезные аспекты.

Создание пула IP-адресов

Как мы уже знаем, каждая транспортная нода имеет свою туннельную конечную точку (ТЕР), и каждый ТЕР требует свой IP-адрес. Чтобы назначить адреса для ТЕР, следует создать 1+ пул IP-адресов. В случае ESXi-гипервизоров это делается по всем ТЕР (так как их может быть больше одного) или же для единственного ТЕР, если мы говорим о KVM-транспортных нодах.

Каждый такой пул можно настраивать вручную, но, если используются разные виды хостов (ESXi и KVM), для IP-пулов их ТЕР следует выбирать различные подсети. Кроме того, если речь идет о KVM, к связанному дефолтному шлюзу обязательно создается статический маршрут.

Добавить новый IP-пул можно на вкладке «Networking», выбрав в левой панели в секции «IP Management» – «IP Address Pools», и нажав на кнопку «Add IP Address Pool» сверху в рабочем поле справа:

Создание сегментов на уровне менеджмента и контроля

Если вы прочитали статью «Дизайн VMware NSX-T Data Center 3.1», понятие сегментов виртуальной сети для вас не является новым. Это своеобразное представление L2 широковещательного домена на всех транспортных нодах, благодаря которому прикрепленные к одному сегменту виртуальные машины могут общаться между собой, в т. ч. и разнесенные по разным TN. Кроме того, важно напомнить, что каждый сегмент назначен определенному виртуальному сетевому идентификатору (VNI – аналог ID VLAN).

Сегмент создается в оверлейной или базирующейся на VLAN TZ, и его конфигурацию можно менять как через пользовательский интерфейс NSX, так и с помощью API. Все оверлейные сегменты создаются как непрозрачные сетевые объекты, видимые в vSphere.

Создать новый сегмент сети можно, если на вкладке «Networking» в левой панели под «Connectivity» кликнуть на «Segments», и затем найти в верхней части над списком готовых сегментов кнопку «Add Segment»:

Если ее нажать, появится комплекс информативных полей, в которых следует задать:

имя нового сегмента,
статус подключения (выбирается из выпадающего списка: None/Tier-0 Gateway/Tier-1 Gateway),
принадлежность к TZ,
подсеть и шлюз, либо же устанавливается настройка по DHCP,
административный статус (включается ползунком),

Опционально задается L2 VPN (если таковые сессии для этого шлюза существуют, идентификатор VPN-туннеля при задании проставляется автоматически), VLAN и имя домена, прокси метаданных, связка адресов, политика тиминга для аплинков, пул IP-адресов и режим репликации.

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

Присоединение ВМ к сегменту

В случае vSphere виртуальная машина может быть присоединена к сегменту сети путем редактирования ее настроек:

В соответствующем окне в поле «Network adapter 1» из выпадающего списка выбирается имя нужного сегмента.

Если речь идет о KVM-машине в редактировании сегмента вручную создаются логические порты и добавляются UUID ВМ:

Из CLI запускается команда:

virsh dumpxml <VM_name> | grep interfaceid

где <VM_name> – это UUID нужной виртуалки;

В пользовательском интерфейсе NSX добавляется порт сегмента путем конфигурирования UUID, типа присоединения и другими настройками:

Важным параметром здесь является тип порта, который выбирается из выпадающего списка «Type». Насчет него есть несколько полезных замечаний. Если речь не о VMware HCX или контейнерах, просто оставляем это поле пустым. Если это контейнер на ВМ, выбираем «Child», и тогда в текстовом поле «Context ID» нужно проставить ID родительского виртуального интерфейса (VIF). В случае, когда разговор о bare-metal сервере или контейнере, выбираем «Static», а в «Context ID» вписывается уже ID транспортной ноды.

Чтобы понять логику переноса виртуальной машины с моста Linux на логический коммутатор NSX рассмотрим случай с Ubuntu, как самый показательный:

Важно! Предварительно нужно отдельно сформировать хотя бы один логический свитч и присоединить созданную на KVM ВМ к существующему мосту Linux.

Инсталлируем UUID-пакет Ubuntu с целью генерации UUID для логических портов командой:

apt-get -y install uuid

Запускаем команду «virsh list», чтобы получить список работающих в системе ВМ;
Выключаем машину, которую планируем перенести;
Вводим в командную строку команду «uuid» для создания рандомного UUID и сохраняем полученный номер в текстовый файл;
Редактируем ВМ, запустив команду:

virsh edit <vm-name>

Находим секцию с интерфейсом Ethernet этой ВМ и переделываем ее по такому подобию:

</interface>

Добавляем логический порт в NSX. Удобнее пользоваться граф-интерфейсом NSX (идем в «Switching» – имя логического свитча – «Related» – «Ports» – «Add», и заполняем там поля имени, описания (опционально), логический свитч проставляется автоматически, тип присоединения «VIF» и ID присоединения – это UUID, который использовался в настройках ВМ);
Вводим «virsh start <vm-name>», чтобы запустить ВМ, после чего она присоединится к логическому свитчу.

Аплинки сегментов

Восходящие каналы сегментов должны ассоциироваться с аплинками Т0-шлюза. Каждый шлюз Т0 должен обладать множеством uplink-подключений, в зависимости от требований и дизайна конфигурации. Просмотреть по ним статистику, связанные группы и настройки, сделанные путем задания профиля аплинка (будем рассматривать ниже, когда поговорим о вкладке «System») можно прямо на вкладке «Networking», если кликнуть в секции «Connectivity» на «Segments» и зайти там на первую вкладку «Segments»:

Настройка профилей сегментов

Чтобы каждый раз вручную не создавать сегмент со всеми его настройками, можно применять удобную систему шаблонов – профиль сегмента. Создается он в «Networking», на второй после «Segments» вкладке «Segment profiles». Если там нажать кнопку «Add Segment Profile», покажется выпадающий список из доступных типов создания профиля. Это может быть:

Spoof Guard (предотвращает спуфинг NIC путем аутентификации адресов IP и MAC ВМ),
IP Discovery (изучает MAC и IP-адреса виртуальной машины, используя снупинг DHCP и ARP или VMware Tools),
MAC Discovery (поддерживает изучение MAC и изменения MAC-адресов),
Segment Security (предоставляет stateless-безопасность L2 или L3 путем проверки входящего в сегмент трафика и сопоставления IP и MAC-адресов, а также протоколов с набором разрешенных адресов и протоколов. Неавторизированные пакеты сразу сбрасываются),
QoS (предоставляет высокое качество и производительность выделенной сети для предпочитаемого трафика):

Для удобства предлагается несколько дефолтных профилей сегментов (в соответствии с перечисленными типами):

Их нельзя редактировать или удалить.

Настройки каждого типа профиля имеют свои отличия. Например, если выбрать в типе «IP Discovery», получим окно вида:

Spoofguard-профиль выглядит так:

а «MAC Discovery»:

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

Применение профилей сегментов к сегментам

В процессе создания или редактирования свойств сегмента, к нему можно применить конфигурацию того или иного профиля с помощью нижнего одноименного блока в настройках:

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

Важно! Сегмент или порт сегмента могут быть ассоциированы только с одним профилем сегмента каждого типа.

Создание шлюза Т1

Создание шлюза Т1 – шаг, без которого не может обойтись ни одна виртуальная сеть. Оно доступно, аналогично, на вкладке «Networking», где в левой панели в секции «Connectivity» нужно найти «Tier-1 Gateways». Кликнув на него, откроется список уже созданных Т1, и если нужно добавить новый, вверху правой части UI следует нажать на кнопку «Add Tier-1 Gateway»:

Важно! Если не планируется настраивать stateful-службы, в выделенном зеленым пункте не выбираем ничего. Будут присутствовать только DR-компоненты. Важно для повышения защиты и экономии ресурсов.

Появится окно, в котором нужно как-то назвать наш новый шлюз Т1, выбрать для него соответствующий Т0, а также привязать теги, если это необходимо, назначить сервисные интерфейсы и статические маршруты – опять-таки при необходимости. Сделанные настройки сохраняются кнопкой «Save», которая и инициирует создание нового Т1-шлюза.

Подключение сегментов к шлюзу Т1

Подключение сегмента к шлюзу Т1 выполняется в разделе левой панели «Segments» вкладки «Networking», где в столбце «Connectivity» выбирается созданный нами шлюз:

Важно отметить, что в процессе подключения сегмента к шлюзу обязательно следует настроить IP-адрес шлюза или подсети (указывается в столбце «Subnets» правее).

Создание шлюза Т0

Чтобы создать шлюз Т0, на вкладке «Networking» в секции левой панели «Connectivity» выбираем «Tier-0 Gateways» и в открывшемся рабочем поле правой части UI нажимаем вверху слева на кнопку «Add Gateway». Она представляет собой выпадающее меню из двух пунктов, в котором нас интересует именно «Tier-0»:

Появится окно настроек, в котором указывается имя нового Т0, выбирается для него режим НА, а если этот шлюз конфигурируется с аплинками, то в зеленой выделенной области обязательно нужно указать кластер Edge:

Также там можно задать теги, если используем. После заполнения верхней части, нажимаем на кнопку «Save», после чего вылетит сообщение, в котором, чтобы продолжить настройку, жмем «YES»:

Теперь окно создания Т0-шлюза станет выглядеть так:

И в первую очередь здесь надо заняться установкой интерфейсов, нажав на кнопку «Set» в соответствующем блоке. Откроется окно вида:

В котором можно выбрать из существующих интерфейсов сопоставления, используемых сегментами аплинков, или создать новый кнопкой «Add Interface».

Второй важный пункт – «Routing». В нем, если нажать напротив «Static Routes» на «Set», можно настроить статические маршруты:

В появившемся окне, если нажать вверху на кнопку «Add Static Route», можно добавить статические маршруты для шлюза Т0. Кроме того доступна настройка следующих прыжков путем нажатия на «Set Next Hops» справа от существующего статического маршрута:

Там, чтобы задать следующий прыжок, нужно снова-таки кликнуть на кнопку «Add Next Hop» в верхней части уже этого окна, и прописать его IP, сопоставление с профилем аплинка, а также дистанцию. Кнопка «Add» слева внизу этих данных добавит новосозданный прыжок к списку уже существующих, а общая «Apply» справа внизу окна – позволит применить сделанные в отношении следующих прыжков настройки ко всему статическому маршруту Т0.

Если же нужна динамическая маршрутизация, в секции «BGP» ниже настраиваем все необходимые параметры:

По умолчанию на шлюзах Т0 BGP включено. Если же по какой-то причине ранее эту опцию отключали, но сейчас важно ее снова активировать, перемещаем ползунок на «On», вводим Local AS и после этого настраивается BGP-окружение после нажатия на кнопку «Set» справа от «BGP Neighbors»:

Как мы видим, здесь можно указать IP-адрес окружения, включить или выключить BFD, а также фильтр маршрута, еще обязательно проставляется удаленное AS-число и адрес источника, чтобы установить сессию пиринга с окружением путем использования конкретно этого адреса.

Важно! Если в поле «Source address» ничего не указать, шлюз автоматически выберет IP-адрес по своему усмотрению.

Все соображения насчет упоминаемых в этих двух секциях характеристик подробнейшим образом рассматривались в «Дизайн VMware NSX-T Data Center 3.1».

Редактирование списка IP-префиксов

Список IP-префиксов содержит IP сетей с масками подсети, которые разрешены или запрещены, исходя из их совпадения. Эти списки применяются в фильтрах BGP и в картах маршрутов с указанием входящего или исходящего направления. Количество доступных при конфигурировании шлюза Т0 списков префиксов показывается в окне его настроек в секции «Routing»:

Отредактировать этот список, разрешив или запретив определенные сетевые префиксы, можно, нажав на цифру на предыдущей схеме, после чего появится окно «Set IP Prefix List». Там не только меняются списки уже существующих префиксов, но и назначаются новые по кнопке «Add IP Prefix List». В поле с настройками списка задается его имя, а если нажать на кнопку «Set»:

появится окно «Set Prefixes», где можно изменить настройки имеющегося префикса, либо же добавить новый по кнопке «Add Prefix»:

Там вводится сеть в формате CIDR, устанавливается диапазон числа IP-адресов в le- или ge-модификаторах, а также выбирается из выпадающего меню опция «Deny» или «Permit».

Конфигурирование списков Community

Списки Community настраиваются в секции «Routing» на Т0 шлюзе (вторая колонка – «Community Lists» – кликнуть на «Set»). Они представляют собой группу сообществ BGP и конфигурируются на карте маршрутов как критерий соответствия для:

Определения объявляемых, принимаемых или фильтруемых маршрутов;
Набора BGP-атрибутов для маршрутов.

Вообще же «community» – это BGP-атрибут, который используется в тегировании специфических наборов маршрутов, разделяющих следующие общие свойства, например, идентификацию 4-байтными значениями. Кроме того, существуют некоторые предопределенные сообщества (INTERNET, NO_ADVERTISE, NO_EXPORT и NO_EXPORT_SUBCONFED).

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

Добавить новый список Сommunity можно в окне «Сommunity List», нажав на кнопку «Add Сommunity List». В соответствующих полях вводится имя такого списка, а рядом можно либо выбрать из предустановленных сообществ (см. выше), либо указать внизу числовое значение, используемое в ваших собственных политиках, где знаки до двоеточия – это AS-число, а после – выбранное значение. В правом нижнем углу будет номер карты маршрутов, где используется этот список сообщества:

Соединение шлюзов Т1 и Т0

После успешного создания шлюза Т0, настало время назначить связанный с ним Т1. Это делается в разделе «Tier-1 Gateways» секции «Connectivity» вкладки «Networking», если открыть на редактирование созданный нами ранее шлюз Т1. Сверху справа под «Linked Tier-0 Gateway» из выпадающего списка выбирается нужный Т0, после чего настройка сохраняется кнопкой «Save»:

Включение объявления маршрутов на Т1-шлюзе

Важным шагом в организации шлюзов виртуальных сетей является включение объявления маршрута на шлюзе Т1 для тенантов, распространяющегося и на шлюз Т0. Эта процедура гарантирует, что определенные для сегментов тенанта сети доступны и для подключенного Т0, и последний, в свою очередь, объявляет их соответствующим образом.

Для этого заходим в редактирование Т1 и находим там секцию «Route Advertisment», где выставляем все необходимые параметры:

Конфигурирование перераспределения маршрутов на Т0 при динамической маршрутизации

Чтобы зафиксировать факт перераспределения маршрутов на Т0 в случае динамической маршрутизации, заходим в редактирование настроек этого шлюза и ищем последнюю секцию «Route Re-distribution». Если напротив нее нажать на «Set»:

появится окно следующего вида:

В котором, в свою очередь, нужно кликнуть на кнопку «Add Route Re-distribution», после чего откроется окно, собственно, настроек перераспределения:

Показанные здесь характеристики являются вполне жизнеспособными для общих случаев применения. Если нужна разработка чего-то экзотического, стоит углубиться в изучение «Дизайн VMware NSX-T Data Center 3.1», чтобы понять, какие именно параметры нужны в каждом конкретном случае. Сохраняем произведенную конфигурацию кнопкой «Apply».

Включение BFD

В теме выше про создание шлюза Т0, мы упоминали, что можно включить в назначении BGP-окружения BFD. Если ползунок на нем перевести в активное положение, внизу в секции «Timers & Password» станут доступными поля с указанием интервала BFD (минимального времени, после которого локальное устройство маршрутизации должно получить ответ от окружения) и BFD-Multiplier – количества раз, которые шлюз ждет входящих сообщений BFD, до того, как сделает заключение, что окружение является неактивным:

Также BFD можно включить не на каждом BGP-окружении, а глобально на шлюз.

Чтобы понимать, зачем нужна эта функция, как она работает и на что оказывает влияние, стоит ознакомиться с соответствующим разделом «Дизайн VMware NSX-T Data Center 3.1».

Включение параметра Allow AS-In

Аналогично BFD, в процессе конфигурирования окружения BGP можно включить функцию Allow AS-In специальным ползунком в соответствующей колонке:

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

Карты маршрутов

Карты маршрутов определяют, какой маршрут из указанного протокола маршрутизации может быть перераспределен в целевой процесс маршрутизации. Назначаются они тоже в настройках Т0, в секции «Routing»:

Если нажать здесь на «Set», появится окно с установкой карт маршрутов, где можно добавить новую карту, кликнув на кнопку «Add Route Map», а также установить критерий соответствия напротив уже существующей и атрибуты BGP, нажав на «Set»:

В поле «Match Criteria» выбирается из выпадающего списка тип критерия, по которому будет производится проверка на соответствие IP-адреса – по IP-префиксу, либо же по «Community List». А правее назначается BGP Weight, Local Preference, AS Path Prepend, MED и Community.

Карты маршрутов могут поддерживаться глобально, назначаясь на весь Т0, либо же по каждому окружению (BGP-пир). Во втором случае, когда указываются BGP Neighbors, в «Route Filter» нужно нажать на «Set», после чего вылетит соответствующее окно для установки фильтра маршрутов, и уже в нем в колонках «Out Filter» «In Filter», если кликнуть на «Configure», можно применить соответствующие фильтры к BGP-окружению (карты маршрутов либо пользовательские списки префиксов):

Настройка агрегации маршрутов

Агрегация маршрутов – это функция BGP, позволяющая объединить несколько указанных маршрутов в один с целью сокращения размера таблиц маршрутизации, количества маршрутов, в целом, и улучшения вычисления наилучшего пути.

На Т0 можно настроить агрегацию маршрутов в секции BGP, нажав на кнопку «Set» в соответствующей строке:

В появившемся окне, кликнув на «Add prefix», можно ввести нужный префикс, и в колонке «Summary-Only» обязательно следует выбрать из выпадающего списка «Yes».

Включение ECMP

О том, что такое ECMP и зачем вообще нужна равностоимостная мультипасовость, можно узнать в нашей статье «Дизайн VMware NSX-T Data Center 3.1». Эта функция очень важна для виртуальных сетей, поэтому немного поговорим о том, как ее включать. Делается это очень просто – в настройке Т0, однако исключительно в том случае, когда включается BGP, и в именно его секции, передвинув соответствующий ползунок в положение «On»:

Выбор режимов Failover

В упомянутой статье достаточно было сказано о НА и защите рабочих процессов сети от простоев в результате сбоев и разных ивентов. На практике же воплощение этих идей сводится к выбору режима НА «Active Active» или «Active Standby» и режима аварийного переключения – «Non Preemptive» либо «Preemptive». Делается это в настройках шлюза Т0 прямо напротив и под его именем:

Настройка многоадресной пересылки

О multicast и ее протоколах всю необходимую информацию можно найти в «Дизайн VMware NSX-T Data Center 3.1». Сейчас же рассмотрим конкретно настройку многоадресной пересылки в разрезе используемых протоколов.

IGMP

Отслеживание IGMP (протокола L2) может использоваться в процессе заполнения таблиц многоадресной пересылки. В этом случае соответствующий трафик транслируется не на все линки.

Для удобства многократного последующего применения можно настроить профиль многоадресного IGMP. Для этого на вкладке «Networking» ищем внизу на левой панели секцию «Settings» и кликаем на «Networking Settings» под ней. В открывшейся рабочей области UI справа находим вкладку «Multicast Profiles», где можно выбрать тип профиля (у нас сейчас IGMP), и если нажать на кнопку «Add IGMP Profile», создадим новый профиль IGMP:

Здесь можно задавать параметры:

Query Interval (интервал времени между общими запросами, дефолтное значение – 30 сек.);
Query Max Response Time (максимальное время ответа на запрос. Чем выше значение – тем менее прерывистым будет трафик, и оно может быть меньше интервала запроса. По умолчанию – 10 сек.);
Last Member Query Interval (интервал времени между сообщениями запроса от членов определенной группы. Чем меньше значение – тем быстрее будет обнаружена потеря последнего члена группы. По дефолту – 10 сек.);
Robustness Variable (переменная, позволяющая настроить ожидаемую потерю пакетов в очереди. Чем выше прогноз на потери, тем большей она должна быть. По умолчанию значение – 2).

PIM

PIM-протоколы (L3) используются в многоадресной маршрутизации и имеют два режима: PIM Sparse (многоадресный трафик не направляется к какому бы то ни было интерфейсу, пока не будет получен соответствующий запрос во избежание потоковой рассылки и использует точку рандеву (RP)) и PIM Bootstrap (протокол настройки RP в спарс-режиме).

По аналогии с IGMP, для PIM также можно настроить профиль многоадресной пересылки. С этой целью также проходим на вкладку «Multicast Profiles» в UI, но в типе профиля выбираем уже «PIM Profile». Добавляется новый профиль кнопкой «Add PIM Profile»:

Здесь указывается единственный параметр «Static RP Address» для точки RP, если Bootstrap пока не сконфигурирован.

Просто так PIM не заработает – его нужно включить в интерфейсах аплинков. Для этого на вкладке «Networking» в секции «Connectivity» кликаем на «Tier-0 gateways», выбираем нужный Т0 и в окне «Set Interfaces» (о назначении интерфейсов см. выше) редактируем интерфейс аплинка путем перевода ползунка на PIM в активное положение:

Кроме того, нужно включить многоадресную пересылку и на сегментах нисходящего канала шлюзов Т0. Для этого заходим на вкладку «Segments» и открываем на редактирование нужный сегмент, где внизу списка свойств будет строка «Multicast Routing», и переводим ползунок на ней в активное положение («Enabled»).

Профили многоадресной пересылки могут участвовать в конфигурировании Т0, для чего в секции «Multicast» настроек ставим ползунок в активное состояние и выбираем из списков созданных профилей в соответствующих полях («IGMP Profile» и «PIM Profile»):

Важно отметить, что, если указываете профиль PIM, следует обязательно заполнить строку «Replication Multicast Range», где вписывается диапазон адресов группы, используемый в репликации адресов многоадресной группы тенантов при оверлее.

Логическое соединение мостами в NSX-T Data Center

О мостах в NSX-T все необходимые знания можно почерпнуть из статьи «Дизайн VMware NSX-T Data Center 3.1». А целью этого раздела будет практическое применение этих знаний.

Создание профиля Edge Bridge

С целью спецификации вовлеченных в соединение мостом Edge-нод используется соответствующий профиль моста, и таких профилей в виртуальных сетях можно создавать множество. Для этого на вкладке «Networking» в секции «Connectivity» нажимаем на «Segments», а затем в рабочем поле UI справа ищем вкладку «Edge Bridge Profiles». Новый профиль добавляется кнопкой «Add Edge Bridge Profile», после чего заполняем все поля в этом окне:

Помимо имени нового профиля обязательно указывается кластер, участвующий в соединении мостом, а также основная нода и нода, которая используется в процессе бэкапирования в Edge-кластере. Также выбирается режим аварийного переключения («Preemptive» или «Nonpreemptive») и опционально задается описание этого профиля. Еще можно назначить теги, а сохраняются все произведенные настройки кнопкой «Save».

Создание сегмента на основе L2-моста

Такой сегмент обеспечит L2-соединение для оверлея ВМ вне NSX-T Data Center, и создается он по стандартной схеме (см. выше в разделе про сегменты), но в процессе конфигурирования следует прикрепить к нему профиль Edge Bridge. Для этого в полях колонок «Connectivity» и «Transport Zone» выбираем «None» и требуемую оверлейную TZ, соответственно:

Затем нужно нажать на «Set» напротив «Edge Bridges», после чего в появившемся окне «Bridge to L2-Bridging» выбрать соответствующий профиль Edge-моста и указать используемый физический порт (идентифицированный VLAN-TZ), а также VLAN ID.

Конфигурирование служб в виртуальных сетях

Как известно, виртуальные сети обладают довольно широкими возможностями в плане предоставления самых разнообразных внутренних служб, касающихся как преобразования IP-адресов, предоставления услуг DHCP и DNS, так и балансировки нагрузки, IPSec VPN. Рассмотрим процедуры их включения и настройки по порядку.

Включение служб NAT на шлюзах

На шлюзах Т0 и Т1 можно настроить службы SNAT и DNAT с целью замены приватного адреса или порта публичными для покидающих сеть пакетов, а также для перенаправления входящих пакетов с публичных адресов на порты или приватные IP виртуальной сети.

Включаются они в разделе «NAT» секции левой панели «Network Services» вкладки «Networking»:

Здесь вверху выбирается шлюз, к которому будут применены создаваемые правила SNAT и DNAT, кнопкой «Add NAT Rule» можно добавить новое правило, прописав соответствующий тип службы, соответствие источнику и назначению, задав адрес трансляции и к чему оно применяется. Здесь же можно в любой момент его включить или выключить.

Чтобы отключить SNAT, нужно настроить правило «No SNAT» на шлюзе Т0 или Т1, указав для него IP источника и обозначив применение по направлению outbound-трафика:

Аналогично для отключения DNAT: настроить правило «No DNAT» на Т0 или Т1 шлюзе, указав для него входящее направление и IP назначения:

Также можно использовать Reflexive NAT, когда шлюз Т0 работает в режиме active-active и нельзя настроить stateful-NAT:

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

Важно! Оба диапазона, и источника, и трансляции, должны быть одинакового размера.

Настройка правил NAT64

На вкладке «Networking» в разделе «NAT» секции левой панели «Network Services» можно настроить правила NAT64, если в правой верхней части открывшегося рабочего поля UI в строке «View» из выпадающего меню выбрать «NAT64»:

По аналогии с SNAT и DNAT в таблице показаны источник и назначение для каждого правила, IPv4-адрес пула трансляции и к чему они применяются – к тегам или интерфейсам.

Здесь можно добавить новое NAT64-правило с помощью кнопки «ADD NAT64 RULE», где в появившемся окне задать имя, действие с данным правилом NAT64 (единственное доступное – трансляция IPv6-адресов в IPv4), источник в виде диапазона адресов или IPv6-адреса в CIDR-формате, назначение – диапазон IPv6 или IPv6-адрес в CIDR-формате, «Translated» – пул адресов или IPv4-адрес для IPv6-адресов источника, и к чему применяется правило – интерфейсы или теги. Опционально можно обозначить соответствующий сервис и порт трансляции.

Включение службы DHCP и DNS

Как мы знаем, служба DHCP помогает автоматизировать назначение IP-адресов, адресов шлюза, адресов серверов DNS и другой информации этого рода без вмешательства администратора, также она используется для интеграции с OpenStack. Логический DHCP-сервер можно сконфигурировать для пула или сегмента, в результате чего vNIC, работающий на клиенте DHCP, подключается к этому сегменту и динамически получает IP-адрес. Доступно создание DHCP-кластера со множеством Edge-нод и включенным НА.

Создание профиля DHCP-сервера

Профиль DHCP-сервера после создания нужно присоединить к Т1/Т0 шлюзам для получения IP-адресов ВМ. С этой целью заходим на вкладку «Networking», нажимаем в левой панели на «DHCP» и в появившемся рабочем поле UI справа кликаем вверху на кнопку «ADD DHCP PROFILE»:

Здесь нужно задать название профиля, его тип («DHCP Server»), предоставить ему адрес и вписать его Edge-кластер. При необходимости можно отметить конкретные ноды Edge, нажав на «Set» напротив. По желанию назначаются и теги. Все настройки профиля сохраняются кнопкой «Save».

Профиль DHCP Relay добавляется аналогичным образом, но в колонке «Profile Type» выбирается «DHCP Relay».

Конфигурирование DHCP-сервера на Т1 шлюзе

Для того, чтобы настроить DHCP-сервер на Т1 шлюзе, следует открыть на редактирование Т1 и найти справа пункт «IP Address Management»:

Если кликнуть на значение этого поля (подсвечено синим, как ссылка), откроется окно вида:

где нужно выбрать в поле «Type» – «DHCP Server», и тогда на следующей строчке можно будет из выпадающего списка назначить подходящий профиль DHCP. Сохраняем настройки «Save».

Настройка сервера DHCP Relay происходит аналогично, но в окне «Set IP Address Management» в поле «Type» выбирается из выпадающего меню «DHCP Relay» и ниже обозначается соответствующий профиль.

На шлюзе Т1 можно настраивать как локальный, так и удаленный DHCP-сервер:

Настройка конфигурации DHCP на сегменте

Открываем на редактирование «Segments» и в первой одноименной вкладке заходим в редактирование нужного сегмента. В его настройках справа будет кликабельное поле «Set DHCP Config» – на него и нажимаем, после чего выпадет окно, в котором нужно выбрать тип DHCP (поле «DHCP Type») из выпадающего списка, профиль DHCP, а также перевести ползунок на «DHCP Config» в активное положение, вписать соответствующий адрес DHCP-сервера и диапазон адресов:

Служба DNS

DNS представляет собой приложение, имплементирующее сервис для преобразования имени компьютера в IP-адрес и наоборот. NSX-T Data Center позволяет настраивать шлюзы Т1 и Т0 как сервера пересылки в режиме ретрансляции DNS.

Для этого создается служба DNS-пересылки на вкладке «Networking» в разделе «DNS» секции «IP Management» левой панели:

Добавление нового DNS-сервиса производится кнопкой «Add DNS Service» вверху рабочего поля UI, и в открывшемся поле надо вписать имя будущей службы, шлюз, на котором она настраивается, ее IP и зону по умолчанию. Если до этого зоны специально не создавались, выпадающий список на этом пункте будет пустым и следует нажать ниже на «Add New Default Zone», чтобы инициировать ее добавление. В появившемся окне нужно заполнить следующие поля:

имя зоны,
домен (по дефолту это «ANY»),
IP-адрес восходящего DNS-сервера,
IP источника,
описание (опционально),
теги.

Также в настройке службы DNS в поле «FQDN Zones» надо нажать на вертикальные точки сбоку, чтобы появилась опция «Add New FQDN Zone», после чего в новом соответствующем окне прописывается имя сервера DNS-пересылки, домен (его FQDN), IP-адрес восходящего DNS-сервера, IP источника и опционально – описание и теги:

Конфигурирование балансировщика нагрузок

Вся теория, касающаяся Load Balancing, доходчиво и подробно изложена в статье «Дизайн VMware NSX-T Data Center 3.1». Сегодня же мы рассмотрим, как ее применять на практике и настраивать в собственных виртуальных сетях балансировщик нагрузки.

Чтобы он заработал, следует вначале его создать, затем назначить виртуальный сервер, сконфигурировать профили, собрать сервер-пул и настроить мониторы. Собственно, этим и займемся по порядку.

Создание Load Balancer

На вкладке «Networking» в секции левой панели «Network Services» ищем раздел «Load Balancing». После нажатия на него в правой части UI откроется новое рабочее поле и нужно зайти на первую его вкладку – «LOAD BALANCERS», а затем вверху кликнуть на кнопку «ADD LOAD BALANCER»:

Здесь указывается имя балансировщика нагрузки, размер разворота (Small/Medium/Large/Extra Large), а также шлюз Т1, к которому планируется прикрепить эту службу. В секции «Virtual Servers», как мы видим, пока пусто, но, мы исправим этот недочет прямо сейчас.

Создание виртуальных серверов Load Balancer

В упомянутой выше секции «Virtual Servers» поля настроек нового Load Balancer кликаем на «Set Virtual Servers», чтобы создать необходимые этой функции виртуальные серверы:

В первую очередь, нужно определиться с подходящим протоколом:

L4 TCP (приложения работающие на TCP с требованиями к балансировке нагрузки L4);
L4 UDP (приложения работающие на UDP с требованиями к балансировке нагрузки L4);
L7 HTTP (приложения HTTP и HTTPS, где load balancer должен работать на параметрах L7).

Когда один из этих протоколов будет выбран, в поле настроек мы задаем:

Если речь о L4-виртуальных серверах – имя, виртуальный IP-адрес, диапазон поддерживаемых портов, сервер-пул и профиль приложения (заполняется по дефолту, опираясь на специфику типа протокола):

Если речь о L7-виртуальных серверах – имя, виртуальный IP-адрес, диапазон поддерживаемых портов, сервер-пул и профиль приложения (заполняется по дефолту, опираясь на специфику типа протокола), Persistence-профиль (опции Disabled/Source IP/Cookie), конфигурация SSL, правила Load Balancer:

Правила LB L7 назначаются в секции «Load Balancer Rules» настроек балансировщика нагрузки:

в разрезе каждой фазы работы функции. Для установки конкретных напротив каждой строки нужно нажать на «Set».

Настройка профилей приложений

На вкладке «Profiles» раздела «Load Balancing» можно задавать различные типы профилей, но сейчас нас конкретно интересуют профили приложений, поэтому вверху в «Select Profile Type» выбираем из выпадающего меню «Application». Здесь мы увидим табличку с дефолтными профилями («default-http-lb-app-profile» для L7, «default-tcp-lb-app-profile» и «default-udp-lb-app-profile» для L4 TCP и UDP, соответственно). Также можно создавать свои собственные пользовательские профили кнопкой «Add Application Profile»:

Создание пула сервера

В процессе создания LB мы говорили о том, что требуется назначить для него конкретный сервер-пул. Это делается прямо из конфигурации балансировщика, кликом на соответствующую ссылку, после чего появится такое окно:

где, традиционно, задаем его имя, а также указываем алгоритм (Round Robin/Weighted Round Robin/Least Connection/Weighted Least Connection/IP Hash – доводы в пользу каждого можно почитать в «Дизайн VMware NSX-T Data Center 3.1»), опционально задаем описание, но, самое важное – выбираем его членов по активной ссылке «Select Members» справа и задаем режим трансляции SNAT. Первый момент проиллюстрирован на скриншоте выше: выбираются члены пула из числа готовых в табличке, либо же создаются новые кнопкой «Add Member».

Что же касается второй характеристики – режима трансляции SNAT – все будет зависеть от выбранной топологии, поэтому назначение этого режима является опциональным. Если же SNAT, все-таки требуется для получения LB трафика с назначенного клиенту сервера, его можно включить по каждому пулу серверов отдельно. И делается это в процессе создания пула сервера, выбором Automap/Disabled/IP Pool:

Первый вариант означает, что LB использует собственный IP интерфейса и временный порт для продолжения связи с клиентом, Disabled отключает SNAT вообще, а IP Pool позволяет пользователям указывать единственный диапазон IP-адресов с целью использования серверами для SNAT.

Настройка мониторов

Активные мониторы используются, чтобы удостовериться в доступности бекэнд-серверов. Проверка базируется на протоколах HTTP/HTTPS/ICMP/TCP/UDP. Выбираются или создаются активные мониторы на вкладке «Monitors» нашего раздела LB, где вверху обязательно указывается тип монитора (Active/Passive), причем протокол сразу определяется в выпадающем меню слева вверху таблички:

Пассивные мониторы проверяют наличие ошибок в процессе связи клиентов и помечают сервера, вызывающие постоянные сбои, как «Down». Количество сбоев при этом увеличивается в случае:

L7 VS – когда сбоит связь TCP или SSL;
L4 TCP VS – при ошибках связи TCP;
L4 UDP VS – ошибки ICMP.

Создаются пассивные мониторы по той же схеме:

IPSec VPN

Про IPSec VPN на шлюзах Т1 и Т0 можно почитать всю необходимую информацию в «Дизайн VMware NSX-T Data Center 3.1». Эта тема весьма обширна, но сегодня мы поговорим, конкретно, о методе Dead peer detection и непосредственной конфигурации службы IPSec VPN.

DPD

Метод DPD (Dead peer detection) используется для установки факта, живо ли соединение IPSec. Чтобы он заработал, необходимо создать новый профиль DPD, где прописывается количество секунд ожидания между попытками обнаружить связь с IPSec пиром. Для этого на вкладке «Networking» в секции «Network Services» нажимаем на раздел «VPN», после чего в рабочей области UI справа нужно зайти на вкладку «Profiles» и выбрать в типе профиля «DPD Profiles»:

NSX-T Data Center предлагает дефолтный профиль «nsx-default-l3vpn-dpd-profile», но, по желанию, можно создать и пользовательский, нажав на кнопку «Add DPD Profile» вверху слева. В нем назначается имя этому профилю, выбирается режим попыток (периодический или по требованию), интервалы между попытками в секундах и количество проверок, а также, опционально, описание и теги. Важно включить ползунок на «Admin Status».

Настройка службы IPSec VPN

Чтобы настроить IPSec VPN, на вкладке «Networking» в секции «Network Services» левой панели кликаем на «VPN», после чего в открывшемся рабочем поле UI справа заходим на первую вкладку раздела – «VPN SERVICES». Если нажать на «ADD SERVICE» будет доступен выбор из трех пунктов, и нужно остановиться на «IPsec». После этого откроется окно настроек:

где необходимо назвать нашу службу IPSec VPN, задать шлюз, на котором она будет работать, опционально привести описание и теги, выбрать из выпадающего списка уровень журнала («IKE Log Level») для сохранения логов и обязательно включить ползунком «Admin Status».

Для удобства добавления служб IPSec VPN рекомендуется настроить соответствующий профиль на вкладке «Profiles», хотя этот шаг и является необязательным, для чего в типе профиля выбирается «IPSec Profiles»:

Теперь попробуем создать L2 VPN сервер. Если в первой вкладке «VPN Services» раздела «VPN» при нажатии на «ADD SERVICE» выбрать «L2 VPN Server», его можно настроить в следующем окне:

И после этого обязательно нужно в окне настроек «L2 VPN Session» (как создавать новую сессию IPSec VPN см. ниже) добавить этот сервер.

Создание профиля IKE

После настройки службы IPSec рекомендуется сконфигурировать профиль IKE (нужно для сохранения логов для последующей фиксации ошибок и их исправления). Делается это в том же разделе «VPN» на вкладке «Profiles», но в типе профиля выбирается «IKE Profiles»:

Здесь непременно нужно придумать имя для будущего профиля, выбрать версию IKE (IKE V1/IKE V2/IKE FLEX) – зависит от производственных требований, алгоритм шифрования, Digest-алгоритм хэширования, используемый в процессе согласования IKE, криптографическую схему Diffie-Hellman для установки общей конспирации между одноранговым сайтом и инстансом NSX Edge, а также времени проведения ассоциаций по безопасности, после чего потребуется обновление.

Настройка IPSec VPN-сессий

Работа службы IPSec VPN невозможна без настройки IPSec-сессий. С этой целью заходим на вторую вкладку раздела «IPSec Sessions» и нажимаем на кнопку «Add IPSec Session», выбрав из выпадающего меню нужный тип VPN (Policy Based/Route Based):

В первом случае окно настроек будет выглядеть так:

и здесь задается имя, VPN Service (предустановлено после выбора конкретного типа сессии), Local Endpoint (ранее сконфигурированная конечная точка для этой сессии), Remote IP (IP-адрес удаленного шлюза с поддержкой IPSec для построения безопасного канала связи), режим аутентификации (если выбран PSK, ниже появится поле для ввода ключа «Pre-shared Key»), локальные и удаленные сети (трафик, который должен быть зашифрован при VPN-сессии), Remote ID (идентификатор удаленного пира для подтверждения аутентичности пиринга) и опционально теги.

Обратите внимание, что внизу окна настроек есть секция «Advanced Properties», позволяющая назначить предустановленные профили DPD, IKE и IPsec из выпадающих меню данной сессии, а также выбрать режим инициации связи:

Выбор «Route Based»-типа сессии IPSec VPN означает, что защищенное туннелирование для трафика будет основано на маршрутах, динамически получаемых через VTI по предпочитаемого протоколу (BGP). В этом случае окно настроек сессии:

В нем нужно задать имя сервиса, Local Endpoint, Remote IP, Compliance suite (набор требований по безопасности, к примеру, CNSA, FIPS, Foundation, PRIME или Suite-B), режим аутентификации (если PSK, то потребуется ввести ключ в поле «Pre-shared Key») и интерфейс туннеля (IP-адрес интерфейса локального виртуального туннеля VTI, создаваемого для этой сессии), Remote ID и теги, по желанию. Обязательно включить ползунок на «Admin Status».

Настройка локальных конечных точек IPSec

Упомянутые выше Local Endpoint требуют соответствующей настройки, что производится в том же разделе «VPN» на вкладке «LOCAL ENDPOINTS». Нажимаем в левой верхней части на «ADD LOCAL ENDPOINT» для определения локальной стороны IPSec-связи и задаем ее имя, конкретизируем ранее созданную службу VPN в колонке «VPN Service» из выпадающего списка, назначаем локальный IP-адрес и Local ID (обычно, идентификатор использует тот же локальный IP-адрес) и опционально – теги. Если используется аутентификация на основе сертификатов, в поле «Site Certificate» указывается соответствующая информация:

Настройка L2 VPN-сегментов

Расширение сегментов через L2 VPN-туннели нуждается в определенной идентификации. С этой целью создается новый сегмент либо же редактируются настройки уже имеющегося (о конфигурации сегментов в целом рассказывалось выше). Заходим в секцию левой панели «Connectivity» на вкладке «Networking», раздел «Segments» и в самую первую его одноименную вкладку, после чего открываем на редактирование нужный сегмент, либо же создаем новый соответствующей кнопкой:

Здесь обязательно назначаем предварительно сконфигурированную L2 VPN-сессию, идентификатор туннеля VPN и IP-адрес локального выходящего шлюза («Local Egress Gateway IP»). Остальные параметры ничем не отличаются от базовой настройки. Кстати, вторым способом назначения L2 VPN-сегментов, является работа с секцией «Segments» на странице конфигурации сессий – там если нажать на кликабельную ссылку напротив, получим окно вида:

где и прописываются все указанные выше параметры.

Настройка L2 VPN-клиента

Производится аналогично тому, как мы это делали в случае VPN-сервера. Но, когда нажимается кнопка «Add Services» на вкладке «VPN Services», выбирается из выпадающего списка «L2 VPN Client»:

Однако, перед тем, как приступить к созданию клиентской L2 VPN-сессии, следует получить или загрузить пир-код с имеющегося L2 VPN-сервера. Для этого на вкладке «L2 VPN Sessions» в строке нужной сессии справа ищем кликабельную ссылку «Download Config», нажав на которую получим окно с нужной нам информацией под «peer code» (второй вариант – сделать через вызов REST API):

Теперь этот код нужно внести в поле «Peer Configuration» в настройках сессии.

Безопасность в NSX-T Data Center 3.1

Как уже говорилось в статье «Дизайн VMware NSX-T Data Center 3.1», функции безопасности в NSX-T Data Center чрезвычайно индивидуальны, и их выбор и практическое применение зависит не только от принятой корпоративной политики, но и от конкретной спецификации виртуальной сети. Сегодня же мы рассмотрим, как настраивать некоторый самый распространенный и полезный функционал этой сферы.

Политики безопасности

Назначенные политики безопасности (перечень и количество) можно просмотреть на вкладке «Security» в самой верхней секции левой панели «Security Overview» – кликнуть на нее и тогда в правой части UI нажать на вкладку «Configuration»:

Здесь, как мы видим, представлена разбивка по следующим смысловым разделам политик:

Distributed Firewall (DFW),
Gateway,
Endpoint,
Network Introspection (отдельно для E-W и N-S),
Distributed IDS.

Политика DFW

Эта коллекция правил применяется к E-W-трафику. Доступ к ней осуществляется в секции «East West Security» левой панели. Если там кликнуть на раздел «Distributed Firewall», увидим соответствующее рабочее поле UI, в котором на вкладке «Category Specific Rules» можно группировать правила распределенного файервола:

Список доступных категорий:

Ethernet (все L2-политики. Правила имеют приоритет перед любыми L3-правилами),
Emergency (временные DFW-политики, используемые в экстренных ситуациях, например, при атаке на веб-сервер, блокировке и т.д.),
Infrastructure (политики, не относящиеся к приложениям, но к компонентам инфраструктуры – vCenter Server, ESXi-хостам и др.),
Environment (высокоуровневые группы политик, к примеру, запрет на коммуникацию продакшен-группы с тест-группой, запрет на общение между группой разработки и тестировщиками и т.п.),
Application (четкие и детальные правила для приложений, в т. ч. правила отношений между приложениями или их уровнями, правила между микросервисами и др.).

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

Важно! Нельзя перемещать политики и правила между разными категориями.

По этому разделу доступны сохранение и просмотр жизненного цикла всех сохраненных конфигураций (выпадающее меню «Actions» в правой верхней части UI):

Ниже этих опций можно редактировать общие настройки («General Settings») и назначать список исключений («Exclusion List»).

В списке политик можно выбирать, запретить ли в данный момент конкретное ее правило или разрешить (на скриншоте ниже, например, в контенте назначенной политики напротив одного ее правила из выпадающего списка выбрано «Allow», а может быть и «Drop» или «Reject»). Также ползунком в этой же строчке можно обозначить, учитывать ли ее вообще в процессе обеспечения безопасности.

Если мы хотим добавить новую политику, нам нужно встать на нужную категорию и нажать на кнопку «Add Policy»:

На пользовательской политике можно задавать определенные настройки, нажав на значок:

в ее строке. Появится окошко вида:

где можно включить или выключить «TCP Strict» (сбрасывание пакетов, для которых не установлено полное трехстороннее TCP), «Stateful» (выполнение stateful-проверки DFW и отслеживание статуса сетевых подключений: разрешаются пакеты, соответствующие активному подключению, а те, которые не соответствуют, подвергаются проверке на правила файервола) и «Locked» (полный блок политики в процессе работы над изменением настройки, чтобы пользователи не могли сделать никаких модификаций).

Второй полезной пиктограммкой возле настроек является настройка политики, как валидной только для специфического периода времени (значок часов). При нажатии на нее откроется окно «Time Window»:

где можно задать новые настройки периодизации кнопкой «Add New Time Window», поименовав ее как-то информативно, задав временную зону (UTC или локальную для определенной транспортной ноды), частоту применения (разовый случай – «One Time» или еженедельно – «Weekly»), конкретную дату и время начала и конца, а также, опционально, описание. Сохраняются настройки по кнопке «Save».

В определенной политике DFW можно добавить пользовательское правило, нажав слева от нее на три вертикальные точки и в выпадающем меню выбрав соответствующее действие («Add Rule»):

По каждому правилу указываются параметры:

имя,
источник (ранее определенные группы, IP/MAC или сам объект. Если ничего не назначить, значение параметра будет «Any»),
целевое назначение (ранее определенные группы, IP/MAC или сам объект. Если ничего не назначить, значение параметра будет «Any»),
сервисы (комбинация порта и протокола),
профили (можно использовать контекстные профили для определения контекстно-зависимых правил или правил L7),
к чему применяется,
действие (Allow/Drop/Reject):

Назначение сервисов для правила

В процессе настройки правил распределенного файервола можно указать один или более необходимых сервисов. Они содержат определение протокола или порт для трафика сети, и задаются в строке самого правила в колонке «Services»:

В окне «Set Services» можно добавить новую службу по кнопке «Add Service» обязательно указав для каждой комбинацию порта и протокола, по котором она и будет классифицировать трафик, однако следует заметить, что в списке присутствуют изначально несколько предустановленных служб, удалять или редактировать которые нельзя:

Назначение контекстного профиля для правила

Следующая после «Services» колонка «Profiles» дает возможность применять контекстный профиль к правилу DFW, чтобы включить L7 файервол:

В окне контекстного профиля можно добавить свой собственный новый, если нажать на кнопку «Add Context Profile», однако в изначально приведенном списке предустановленных профилей менять или удалять ничего нельзя:

Важно! L7-правила DFW могут определяться исключительно в stateful-политике.

В каждом контекстном профиле должно быть значение в колонке «Attributes». Его можно отредактировать/назначить, если кликнуть на него, после чего откроется окно «Set Attributes». Здесь в колонке «Attribute Type» можно выбрать либо «App Id», либо «Domain(FQDN) Name». В первом случае в выборе «Attribute Name/Values» будет доступен список из параметров, базирующихся на типе приложения (FTP/GITHUB/HTTP/HTTP2/IMAP и др.):

А во втором конкретный статический список доменных имен или FQDN:

Применение правил

Колонка «Applied To» очень важна для определения правила файервола, ведь с ее помощью достигается оптимизация использования ресурсов на хостах любого типа, а также определяется таргетированная политика к указанным зонам или тенантам, исключая ее использование теми, кого она не должна коснуться:

Конфигурация настроек правил DFW

В строке каждого правила есть очень полезная пиктограмма:

Кликнув на нее можно попасть в окно настроек «Settings», где включается запись в журнал (файл «/var/log/dfwpktlogs.log» для ESXi и KVM-хостов), направление пакета (IN/OUT/IN_OUT), когда он путешествует по сети, выбирается IP-протокол (IPv4/IPv6/IPV4-IPv6) и делаются информативные пометки:

Предустановленные категории файервола шлюза

Первая вкладка «Gateway Firewall» – «All Shared Rules» – представляет собой набор правил, которые работают для всех шлюзов, без исключений:

Все представленные здесь категории являются предустановленными и расположены они в порядке важности слева направо:

Emergency (используется для карантина и для разрешения правил);
System (генерируется автоматически для внутреннего трафика уровня управления, в т. ч. для правил BFD, VPN и др.);
Pre Rules (глобально для всех нод на шлюзе);
Local Gateway (специфичные для конкретной ноды шлюза);
Auto Service Rules (авто-подключаемые правила, применяемые к уровню данных);
Default (определяющие дефолтное поведение файервола шлюза).

Политики файервола шлюза в N-S-направлении

На вкладке «Security» в секции левой панели «North South Security», если нажать на «Gateway Firewall», то на вкладке открывшегося рабочего поля UI «Gateway Specific Rules» можно задавать политики шлюзов для N-S-трафика. Они могут применяться как к самим шлюзам Т0 и Т1, так и к их интерфейсам:

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

Если кликнуть на последнюю, перейдем в окно «Settings», где все аналогично рассмотренному выше случаю с DFW. По ней так же можно выбирать необходимое действие (Allow/Drop/Reject) для трафика, а нажав на вертикальные точки рядом с ее названием, получим выпадающее меню, благодаря которому можно делать разнообразные вещи: от разрешения на сохранение логов и включения/выключения всех правил под эту политику оптом, до удаления политики целиком, перемещения ее в списке вверх или вниз, и, самое главное, добавления в нее правила:

Процедура создания и настройки каждого конкретного правила аналогична тому, что делалось в отношении DFW. А когда вся конфигурация политик N-S-направления будет завершена, следует нажать кнопку «Publish» в правом верхнем углу UI, чтобы сделанные изменения возымели эффект.

Настройка системы обнаружения вторжений (IDS)

Сигнатура IDS включает данные, которые используются в процессе идентификации злоумышленника, который пытается оседлать известную уязвимость приложения или ОС. Существует сторонний репозиторий безопасности Trustwave, откуда NSX Manager ежедневно загружает сигнатуры IDS. Все сигнатуры классифицируются по степени серьезности: критической, высокой, средней и низкой. А вкладка «Security» в секции «East West Security» предлагает для этой опции отдельный раздел – «Distributed IDS».

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

Настраиваемые профили доступны на той же вкладке «Profiles», где можно добавлять новый IDS-профиль кнопкой «Add IDS Profile» и редактировать уже созданные:

Как мы видим, конкретный профиль имеет собственное имя, чтобы потом его можно было идентифицировать точно в процессе применения, опциональное описание, соответствующие теги, если это необходимо, и классы опасности, подлежащие включению в данный профиль, а также те, которые необходимо исключить («Severities to Include» и «Severities to Exclude»)

Также можно задавать политики IDS, являющиеся набором относящихся к ним правил. Правила же, в свою очередь, содержат инструкции, определяющие какой именно трафик будет анализироваться с указанием параметров: источники и назначения, службы, IDS-профиль, к чему применяется, доступные с ним действия):

Чтобы сконфигурировать распределенный IDS, следует зайти на него (см. в этой теме путь выше) и кликнуть на вкладку «Settings». Здесь будет показана версия сигнатур и время последнего раза их обновления:

Анализ URL

URL-анализ включается в «Security» в секции «North South Security» левой панели в одноименном разделе. Если на него зайдем в соответствующее рабочее поле UI с двумя вкладками: «URLs» и «Settings». Вот как раз на «Settings» нам нужно попасть и просто передвинуть ползунок напротив конкретного кластера или ноды в активное положение («Enabled»):

В колонках указывается «URL Data Version», «Connection Status», «URL Analysis State» дата последней синхронизации и профили, которые можно устанавливать конкретно для этого URL, нажав на «Set» напротив него. Попадем в окно «Select Context Profile»:

где задается имя профиля и опционально его описание, теги, а также можно назначить атрибут, кликнув на «Set»:

Чтобы анализ URL мог анализировать информацию домена, нужно настроить правило шлюза L7 для DNS-трафика. Это делается в «Gateway Firewall» на вкладке «Gateway Specific Rules»:

Первая вкладка «URL ANALYSIS» – «URLs» – показывает панель мониторинга анализа URL. Цветовая дифференциация различает URL высокого риска, подозрительные, среднего и малого риска, а также достойные полного доверия (от красного до зеленого).

Создание профиля сервиса

При развороте сервисов в виртуальных сетях очень полезными бывают профили, которые задаются в разделе «Network Introspection Settings» секции левой панели «Settings», кликнув на которую можно перейти на вкладку «Service Profiles» правой части UI:

где, нажав на «Add Service Profile» можно создать новый профиль службы.

Также доступно назначение цепочек сервисов на вкладке «Service Сhains» этого же раздела, в которой, если кликнуть на «Add Chain» можно создать новую цепь, указав ее имя, опционально описание, выбрав сервисный сегмент, к которому она принадлежит. Также важно назначить путь пересылки туда и обратно. В первом случае выбирается соответствующий профиль, а во втором – указывается галочкой, пользоваться тем же путем в обратном направлении («Inverse Forward Path») или нет:

В такую цепь можно добавлять множество сервисных профилей.

Защита конечной точки

На вкладке «Security» в секции «Endpoint Protection», если выбрать «Endpoint Protection Rules» и зайти на вкладку «Service Profiles», можно создать профиль сервиса (см. выше), чтобы назначить уровень защиты для группы или рабочих процессов. В этом помогают шаблоны, предоставляемые вендором, например, серебряный, золотой и платиновый уровень политики.

Каждый профиль обслуживает свой тип рабочего процесса.

Кроме этого можно устанавливать правила, ассоциированные с профилем сервиса для определенной ВМ или группы ВМ:

Управление инвентарем NSX-T

Одной из важнейших опций этой вкладки является создание групп – набора виртуальных машин, портов сегментов IP/MAC-адресов, AD пользовательских групп и физических серверов, к которому применяются политики безопасности:

Чтобы создать новую группу, следует на вкладке «Inventory» кликнуть в левой панели на «Groups», после чего в рабочей правой области UI нажать на кнопку «Add Group» слева вверху. В открывшемся поле вписывается имя новой группы и опционально – ее описание, назначаются, по желанию, теги, после чего обязательно нажимается на «Set Members», чтобы определить ее членов.

Важно! Если собираетесь создавать группу с AD-пользователями, предварительно нужно добавить AD-домен в NSX Manager путем захода на вкладку «System», где в секции левой панели «Configuration» следует нажать на «Identity Firewall AD», после чего кликнуть на «ADD ACTIVE DIRECTORY».

Выбор членов группы опирается на критерии членства, которые задаются в первой вкладке вылетевшего после нажатия на «Set Members» окна:

Здесь можно добавить новый критерий по кнопочке «+ Add Criteria», или же использовать уже существующие из приведенного списка. Каждый критерий может быть динамическим или статическим, и во втором случае он определяется выбором ВМ, VIF, сегмента, порта сегмента, набором IP/MAC, AD пользовательских групп, физических серверов и вложенных групп. Динамический же основан только на тегах, непосредственно на названиях ВМ, ОС или именах компьютеров для виртуальных машин. Все это выбирается из выпадающих меню в строке каждого критерия.

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

Функции вкладки «System»

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

Настройка VIP

Доступ к каждому компоненту NSX-T осуществляется по виртуальному IP-адресу и когда в прошлый раз мы учились разворачивать в статье «VMware NSX-T Data Center 3.1: Разворот с нуля», к примеру, ноды уровня управления из соответствующего кластера, для них он обязательно указывался в процессе. Этот адрес не назначается по дефолту, поэтому важно научиться его настраивать и менять, в случае необходимости.

С этой целью в окне «NSX Appliances» (вкладка «System», в левой панели под «Configuration» кликаем на «Appliances») ищем в правой его части кнопку «Set Virtual IP»:

Если ее нажать, вылетит окошко «Set Virtual IP», где в единственной его строчке и вводим новый адрес:

По кнопке «Save» именно он станет использоваться для доступа к NSX Appliance в GUI.

Конфигурирование свитчей транспортных нод

Каждая транспортная нода в транспортной зоне может настраиваться с N-VDS или VDS, независимо от типа среды, однако следует учитывать, что VDS поддерживается только vSphere 7.0 или свежее, а VDS v7 доступен только для NSX-T Data Center 3.0 и выше. Теоретические знания о сути, специфике и настройке N-VDS и VDS можно во всей полноте почерпнуть в статье «Дизайн VMware NSX-T Data Center 3.1», сейчас же займемся конкретной практикой. Заметим только, что VDS зависит от vCenter Server, а N-VDS – автономен от него.

ESXi-хосты под управлением vCenter Server могут настраиваться для использования VDS в процессе подготовки транспортной ноды.

Важно! В vCenter Server сегменты NSX Manager реализованы как распределенные порт-группы.

Что же касается KVM, N-VDS тут является, по сути, фактическим применением OVS (Open vSwitch).

Каждая транспортная зона сопоставляется (или прямо встраивается) с N-VDS/VDS путем использования поля «Switch Name», и каждая нода использует его для подключения к TZ:

Как создавать TZ мы рассказывали в статье «VMware NSX-T Data Center 3.1: Разворот с нуля». Теперь же поговорим конкретно о виртуальных коммутаторах.

Конфигурируются N-VDS или VDS в процессе инсталляции транспортной ноды (процедура аналогично подробно описана в вышеуказанной статье) кнопкой «+ Add Switch», при нажатии на которую соответствующее окно позволяет назвать новый виртуальный свитч, выбрать его тип (N-VDS/VDS) и режим работы:

Режимов работы всего два:

Standard (предоставление функционала пересылки для транспортных нод любого типа среды, не требующей какого-либо специализированного «железа»);
Enhanced Datapath (доступен только для ESXi-нод и отличается предоставлением Enhanced Networking Stack (ENS), целевого для приложений Network Functions Virtualization (NFV), для чего нужно гораздо более быстрые и производительные пути для данных).

Второй режим поддерживает базовые функции свитча, вроде vSphere vMotion, vSphere HA, vSphere DRS и др., DPDK для E-W-потоков в дата-центре, однако не подходит для общих приложений и развертываний с традиционными Edge-нодами (ВМ или bare-metal).

Если проскроллить окно создания, увидим вторую часть параметров:

Задание профилей Uplink

Как уже отмечалось в «Дизайн VMware NSX-T Data Center 3.1», профиль аплинка состоит из параметров, на которых строится работа сетевых адаптеров, включая настройку таких важнейших вещей, как соответствие политике тиминга, назначение Active/standby режимов функционирования, ID транспортной VLAN и MTU. Он задается по множеству транспортных нод и в процессе их создания на него обязательно ссылаются.

В системе содержатся дефолтные аплинк-профили, и ознакомиться с ними можно, зайдя на вкладку «System» и найдя в левой панели под «Fabric» подраздел «Profiles». Справа откроется рабочее поле, первая вкладка которого – «Uplink Profiles» и содержит искомую информацию:

Создать новый пользовательский профиль можно там же, нажав на кнопочку «+ Add» выше списка дефолтных профилей. После чего откроется окно вида:

где вписывается имя нового профиля, его описание (опционально), LAG и задается политика тиминга, а также указывается нужная VLAN и желаемое MTU. По кнопке «Add» у нас в списке профилей появится еще один.

Важно! Помните, что KVM-хосты поддерживают исключительно «Failover Order» тиминг-политику, и только один LAG в этом случае может быть создан со всеми pNIC. Кроме того, для ESXi-нод политики «Load Balanced Source» и «Load Balanced Source Mac» не позволяют работать с резервными аплинками. Все это подробно обсуждалось в статье «Дизайн VMware NSX-T Data Center 3.1».

Включение LLDP-профилей

Когда мы создавали транспортную ноду в «VMware NSX-T Data Center 3.1: Разворот с нуля», был доступен выбор из двух опций Link Layer Discovery Protocol (LLDP) – «Disabled» и «Enabled»:

Если LLDP включена, гипервизор хоста объявляет сетевую информацию одноранговым транспортным узлам. Вообще же LLDP – штука очень полезная, так как значительным образом упрощает использование инструментов управления сетью в мультивендорных средах и точно обнаруживает физические топологии сети с целью облегчения траблшутинга в корпоративных сетях.

Создание профилей NIOC

О Network I/O Control (NIOC) аналогично сказано было немало в «Дизайн VMware NSX-T Data Center 3.1», и хоть работает он исключительно с ESXi-хостами, достоин самого пристального внимания к своей персоне.

Вкратце напомним, что профиль NIOC занимается выделением пропускной способности для критически важных бизнес-приложений путем назначения параметров лимитирования и резервирования. В частности, для vSphere Fault Tolerance (NIOC версии 3), vSphere vMotion, виртуальных машин и др.

Создается же он на вкладке «System», где в левой панели под «Configuration» в секции «Fabric» заходим на «Profilies», и тогда в правой части UI в ряду вкладок кликаем на «NIOC Profilies», после чего нажимаем в верхней части экрана на «+»:

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

Окно добавления нового профиля NIOC выглядит так:

Здесь задается его имя и, опционально, описание, а также назначаются ресурсы для внутреннего трафика хоста. Эти ресурсы могут выбираться из предустановленного списка (FT/VR/iSCSI/NFS-трафик, управляющий, бэкапирования или виртуальной машины и т.д.), но можно и создать новый тип ресурсов кнопкой «+ Add» над табличкой. Кроме того, в этом же окне обязательно передвигается ползунок статуса профиля NIOC в активное положение (после, при необходимости, можно будет выключить, зайдя в редактирование соответствующего профиля по пиктограммке карандашика).

Профили транспортных нод

Для хостов ESXi как части vCenter Server в составе кластера vSphere при конфигурировании NSX-T Data Center доступно создание профилей транспортных нод. Дополнительными условиями являются готовые TZ и пулы IP-адресов (либо DHCP-сервер), а также добавление инстанса vCenter Server в NSX Manager. Это очень удобный шаблон, который применяется сразу к кластеру, но не с целью подготовки отдельных хостов. Там учитывается абсолютно все: от TZ и определения членов кластера, до конфигурации N-VDS, включая профиль аплинка, назначения IP, сопоставления pNIC с виртуальными интерфейсами аплинков и многое другое.

Важно! Профили транспортных нод не применяются к NSX Edge-транспортным нодам.

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

Добавляется новый профиль транспортной ноды там же, где мы создавали профили NIOC и аплинков (см. выше): на вкладке «System» в левой панели под «Configuration» в секции «Fabric» кликаем на «Profiles» и в верхних вкладках правой части UI ищем «Transport Node Profiles». Вверху открывшегося соответствующего перечня профилей будет кнопка, с помощью которой можно добавить новый. Если нажмем на нее, получим такое окно:

Как видим, тут задается имя нового профиля транспортной ноды и вносится новый виртуальный свитч (если это не было сделано отдельно – процесс полностью аналогичен тому, что описывался в подразделе «Конфигурация свитчей транспортных нод»). Удобно, что, если заранее отдельно не создавались профили NIOC и аплинков, и даже если не была создана соответствующая TZ, все это можно посоздавать прямо отсюда, нажав на синюю ссылку с текстом типа «OR Create New ***» под каждым выпадающим списком определенного параметра.

Также важно, что здесь можно указать профиль LLDP, политику тиминга для сопоставления свитчей, и добавить сопоставления сети для инсталляции или деинсталляции, при необходимости.

По кнопке «ADD» создается новый профиль транспортной ноды, а прикрепить его в процессе конфигурирования ESXi-хостов под управлением vCenter Server можно на уровне кластера.

Изменение резервирования ресурсов для ВМ NSX Edge

На вкладке «System» в секции левой панели «Nodes» для NSX Edge-транспортных нод предложена полезная в ряде случаев возможность поменять резервирование ресурсов под эту конкретную ВМ. Для этого нужно перейти на вкладку «Edge Transport Nodes» в правой части UI и в выпадающем меню «Actions» выбрать строку «Change Edge VM Resource Reservations»:

Вылетит соответствующее окно, в котором выставляется приоритетность резервирования CPU (Low/Normal/High/Extra High), процент резервирования памяти и резервирование CPU в мегагерцах. Подтверждаются изменения кнопкой «Save».

Изменение настроек Edge-ноды

Однажды развернутую в NSX Edge-ноду можно отредактировать в разрезе ее настроек, задав другую ее связку с доменными именами, DNS и NTP-серверами, а также отключив (что крайне не рекомендуется) доступ по SSH:

Замена сертификатов

После установки NSX-T Data Center для кластера управляющих нод назначаются самоподписанные сертификаты. С целью увеличения безопасности, рекомендуется заменить их CA-подписанными. Более того – использовать разные для каждой ноды. Для этого заходим под правами администратора на инстанс NSX Manager, во вкладке «System» в левой панели ищем «Settings», под которыми будет раздел «Certificates». Если мы нажмем на него, в правом поле отразятся текущие настройки, и в верхней части слева будет выпадающее меню «Import», в котором нужно выбрать «Import Certificate»:

В появившемся окне вводим детали сертификата, после чего по кнопке «Import» они загрузятся.

Чтобы поменять сертификаты VIP Manager-кластера, из браузера заходим под учетной записью администратора на https://<nsx-manager-ip-address>, выбираем на вкладке «System» в левой панели под «Settings» – «Certificates» и в колонке «ID» кликаем на номер сертификата, который хотим использовать, после чего копируем его из всплывающего окна. Предварительно надо убедиться, что параметр «Service Certificate» в процессе импорта был выставлен на «No».

Втором методом является использование вызовов API. Чтобы заменить сертификат одной Manager-ноды, вводим POST вызов API:

https://<nsx-mgr>/api/v1/node/services/http?action=apply_certificate

А для VIP Manager-кластера, соответственно, POST вызов API будет следующим:

https://<nsx-mgr>/api/v1/cluster/api-certificate?action=set_cluster_certificate

Разворот и регистрация сервисов

Все действия с сервисами доступны на вкладке «System» в разделе «Service Deployments» секции «Configuration» левой панели. В UI под сервисы отведены три вкладки: «Deployment», «Service Instances» и «Catalog». Последняя полезна, если нужно просмотреть список существующих партнерских служб. Сам же процесс регистрации производится через API или партнерский CLI:

Важно помнить, что при регистрации будет затребовано указание множества параметров, в т. ч. URL OVF, так что стоит запастись этими данными заранее.

Развернуть службу можно на первой вкладке «Deployment», где по кнопке «Deploy Service» начнется соответствующее конфигурирование, в процессе которого нужно указать имя разворачиваемого сервиса, точку присоединения, менеджер вычислений, кластер, хранилище данных и сети:

Успешно развернутая служба появится на вкладке «Catalog». После этого можно разворачивать инстанс сервиса, и только тогда стартует генерация трафика для него. Конкретные рекомендации свыше этого привести вряд ли удастся, так как очень многое зависит от специфики каждого партнерского сервиса, интегрируемого в NSX-T Data Center.

Единственное, что стоит отметить в E-W-разворотах обязательно следует в выпадающем меню «Service Segments» выбрать либо же создать новый служебный сегмент, ассоциированный с TZ и используемый на уровне сервиса. Тогда подключенные к этому сегменту ВМ получат защиту трафика. Кроме того, в выпадающем меню «Deployment Type» следует выбрать одну из таких опций:

Clustered (сервис для хоста(ов) кластера, привязанных к сервисной ВМ),
Host Based (сервис для всех хостов кластера).

Мониторинг в NSX-T Data Center 3.1

Система мониторинга в NSX-T предлагает постоянный мониторинг состояния и визуализацию топологии сети, объектов дата-центра и потоков трафика. Также она предоставляет рекомендации по планированию микросегментации, выдает необходимые для идентификации и предупреждения сбоев в среде сигналы для организации соответствующих событий. Она базируется на распределенном решении аналитики «NSX Intelligence».

Разворачиваться может только на ESXi-хостах под управлением vCenter Server и только в Enterprise Plus-классе лицензии. Аppliance NSX Intelligence должен обладать неизменяемым статическим IP-адресом и требует роль Enterprise Administrator для установки, настройки и использования.

Разворот NSX Intelligence осуществляется с помощью OVA-файла, загружаемого для версии 3.1 NSX-T Data Center со страницы:

следующим образом:

Заходим в NSX UI на вкладку «System», где в секции левой панели «Configuration» выбираем «Appliances» и нажимаем на большую кнопку в правой части интерфейса «ADD NSX INTELLIGENCE APPLIANCE»:

В появившемся окне вводим тип загрузки (например, «Upload OVA File»), кнопкой «Select» находим скаченный файл и нажимаем сбоку на кнопку «Upload», после чего придумываем имя хоста для нашего Appliance, прописываем IP, подсеть, шлюз, DNS и NTP-сервера, а также выбираем размер разворота (Small (для лабораторий и маленьких сред)/Large (для крупных производственных сред)):

Функционал NSX Intelligence

На вкладке «Plan & Troubleshoot» в секции левой панели «Discover & Plan», если нажать на раздел «Discover & Take Action» доступна вот примерно такого вида визуализация потокового трафика ВМ и групп безопасности:

где зелеными сплошными линиями будет показан разрешенный трафик, темно-серыми – заблокированный, а красным пунктиром – незащищенный.

Вторым разделом этой секции является «Recommendations» – он предлагает список рекомендаций по безопасности:

Здесь можно запускать неконкурентные рекомендации, включая или выключая флажок в колонке «Monitoring», а также задавать новые, нажав на кнопку «Start New Recommendation»:

где отмечается область применения этой рекомендации (до 100 ВМ, до 1 группы безопасности), режим ее вывода (Object Based/IP Based) и диапазон времени для анализа данных.

Инструменты мониторинга

Инструмент	Область применения	Авто-оповещение
Dashboard	Мониторинг	–
Logs	Troubleshooting	–
CLI	Troubleshooting	–
API	Конфигурирование, Troubleshooting	–
SNMP	Мониторинг, оповещение	+
Сигналы и события	Мониторинг, Troubleshooting	+

Доступ к панелям мониторинга («Monitoring Dashboards») существует прямо со вкладки «Home», где для этого есть соответствующая вкладка (правее «Alarms»):

Этот скриншот, например, иллюстрирует состояние транспортных нод соответствующей цветовой индикацией.

Сигналы NSX Intelligence

Создание предупреждений в NSX Intelligence базируется на использовании CPU, памяти, дисков и партиций, статусе нод (up/degraded/down) и в Health Status показывается так:

Настраивать определение сигналов можно на вкладке «Alarm Definitions» вкладки «Alarm», меняя их пороговые значения, чувствительность и тому подобные характеристики:

В самой же вкладке «Alarms» актуальные предупреждения будут демонстрироваться, например, вот так:

Доступен выбор статуса каждого сигнала (Open/Acknowledged/Suppressed/Resolved), нажав на кнопку «Action» вверху таблички с предупреждениями из выпадающего списка, стоя на каком-нибудь из них:

Сегодняшнее обсуждение обошло стороной такую интереснейшую тему, как VRF Lite – поистине выдающуюся возможность конфигурации множества инстансов маршрутизации без разворачивания дополнительных Т0-шлюзов и избегая применения громоздких MPLS/MP BGP-протоколов. Конечно, у нее есть и свои минусы – например, нельзя применять балансировщик нагрузки и VPN, однако технология эта весьма любима VMware, поэтому не уделить ей внимания мы не сможем. Правда, посвященный VRF Lite обстоятельный урок состоится в другой раз – уж больно объемен и серьезен этот предмет.

Также, несмотря на то, что в статьях «Дизайн VMware NSX-T Data Center 3.1» и «VMware NSX-T Data Center 3.1: Разворот с нуля» мы слегка коснулись темы Федерации в NSX-T, ее администрирование и настройку, думается, аналогично вынесем в отдельный полноценный гайд, ведь, хоть многие описанные выше фундаментальные принципы для нее остаются полезными, стоит разработать своеобразную автономную практическую шпаргалку для тех, кому придется все это организовывать с нуля в своей среде.

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