Развертывание защищенной сети в Azure Stack Hub

  • Статья

В этом разделе рассматриваются разрешения на доступ к коммутаторам TOR, назначениям IP-адресов и другим задачам развертывания сети.

Планирование развертывания конфигурации

В следующих разделах рассматриваются разрешения и назначения IP-адресов.

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

Для защиты решения Azure Stack мы реализовали списки управления доступом (ACL) на коммутаторах TOR. В этом разделе описывается реализация этой безопасности. В таблице ниже показаны источники и назначения каждой сети в решении Azure Stack:

A diagram of access control lists on the TOR switches

В приведенной ниже таблице сопоставляются ссылки ACL с сетями Azure Stack.

BMC Mgmt Виртуальная машина развертывания, интерфейс BMC, NTP-сервер HLH и IP-адреса DNS-сервера, включенные в качестве разрешения на основе протокола и порта.
HLH Internal Accessible (PDU) Трафик ограничен коммутатором BMC
HLH External Accessible (OEM Tool VM) ACL разрешает доступ за пределами пограничного устройства.
Switch Mgmt Выделенные интерфейсы управления коммутаторами.
Позвоночник Mgmt Выделенные интерфейсы управления позвоночником.
Azure Stack Службы инфраструктуры Azure Stack и виртуальные машины, ограниченная сеть
Инфраструктура
Azure Stack Конечная точка Azure Stack, сервер консоли аварийного восстановления
Инфраструктура
Public (PEP/ERCS)
Tor1, Tor2 RouterIP Интерфейс замыкания на себя коммутатора, используемого для пиринга BGP между подсистемой балансировки нагрузки и коммутатором или маршрутизатором.
Память Частные IP-адреса, не перенаправленные за пределы региона
Внутренние ВИРТУАЛЬНЫЕ IP-адреса Частные IP-адреса, не перенаправленные за пределы региона
Public-VIPs Адресное пространство сети клиента, управляемое сетевым контроллером.
Общедоступные виртуальные IP-адреса администратора Небольшое подмножество адресов в пуле клиентов, необходимых для взаимодействия с Internal-VIPs и инфраструктурой Azure Stack
Клиент или Интернет Определяемая клиентом сеть. С точки зрения Azure Stack 0.0.0.0 является пограничным устройством.
0.0.0.0
Запретить Клиент может обновить это поле, чтобы разрешить дополнительные сети для включения возможностей управления.
Разрешение Разрешить трафик включен, но доступ по протоколу SSH отключен по умолчанию. Клиент может включить службу SSH.
Нет маршрута Маршруты не распространяются за пределами среды Azure Stack.
Список ACL мультиплексора Используются списки управления доступом мультиплексов Azure Stack.
Н/Д Не является частью ACL виртуальной локальной сети.

Назначения IP-адресов

На листе развертывания вам будет предложено указать следующие сетевые адреса для поддержки процесса развертывания Azure Stack. Группа развертывания использует средство "Лист развертывания" для разбиения IP-сетей во все небольшие сети, необходимые системе. Подробные описания каждой сети см. в разделе "NETWORK DESIGN AND INFRASTRUCTURE" выше.

В этом примере мы заполним вкладку "Сеть Параметры" листа развертывания со следующими значениями:

  • Сеть BMC: 10.193.132.0 /27

  • Внутренние ВИРТУАЛЬНЫе IP-адреса частной сети & служба хранилища: 11.11.128.0 /24

  • Сеть инфраструктуры: 12.193.130.0 /24

  • Сеть общедоступного виртуального IP-адреса: 13.200.132.0 /24

  • Переключение сети инфраструктуры: 10.193.132.128 /26

При запуске функции Generate средства "Лист развертывания" она создает две новые вкладки в электронной таблице. Первая вкладка — это сводка подсети, и она показывает, как суперсети были разделены для создания всех сетей, необходимых системе. В нашем примере ниже есть только подмножество столбцов, найденных на этой вкладке. Фактический результат содержит дополнительные сведения о каждой сети, указанной ниже.

Стойки Тип подсети имя; Подсеть IPv4 IPv4-адреса
Рамка Ссылка P2P P2P_Border/Border1_To_Rack1/TOR1 10.193.132.128/30 4
Рамка Ссылка P2P P2P_Border/Border1_To_Rack1/TOR2 10.193.132.132/30 4
Рамка Ссылка P2P P2P_Border/Border2_To_Rack1/TOR1 10.193.132.136/30 4
Рамка Ссылка P2P P2P_Border/Border2_To_Rack1/TOR2 10.193.132.140/30 4
Рамка Ссылка P2P P2P_Rack1/TOR1_To_Rack1/BMC 10.193.132.144/30 4
Рамка Ссылка P2P P2P_Rack1/TOR2_To_Rack1/BMC 10.193.132.148/30 4
Rack1 Замыкание на себя Loopback0_Rack1_TOR1 10.193.132.152/32 1
Rack1 Замыкание на себя Loopback0_Rack1_TOR2 10.193.132.153/32 1
Rack1 Замыкание на себя Loopback0_Rack1_BMC 10.193.132.154/32 1
Rack1 Ссылка P2P P2P_Rack1/TOR1-ibgp-1_To_Rack1/TOR2-ibgp-1 10.193.132.156/30 4
Rack1 Ссылка P2P P2P_Rack1/TOR1-ibgp-2_To_Rack1/TOR2-ibgp-2 10.193.132.160/30 4
Rack1 Виртуальная локальная сеть BMCMgmt 10.193.132.0/27 32
Rack1 Виртуальная локальная сеть SwitchMgmt 10.193.132.168/29 8
Rack1 Виртуальная локальная сеть CL01-RG01-SU01-служба хранилища 11.11.128.0/25 128
Rack1 Виртуальная локальная сеть CL01-RG01-SU01-Infra 12.193.130.0/24 256
Rack1 Другое CL01-RG01-SU01-VIPS 13.200.132.0/24 256
Rack1 Другое CL01-RG01-SU01-InternalVIPS 11.11.128.128/25 128

На второй вкладке используется IP-адрес и показано, как используются IP-адреса :

Сеть BMC

Для суперсети для сети BMC требуется как минимум сеть /26. Шлюз использует первый IP-адрес в сети, а затем устройства BMC в стойке. Узел жизненного цикла оборудования имеет несколько адресов, назначенных этой сети, и его можно использовать для развертывания, мониторинга и поддержки стойки. Эти IP-адреса распределены по 3 группам: DVM, InternalAccessible и ExternalAccessible.

  • Стойка: Rack1
  • Имя: BMCMgmt
Кому назначено Адрес IPv4
Сеть 10.193.132.0
Шлюз 10.193.132.1
HLH-BMC 10.193.132.2
AzS-Node01 10.193.132.3
AzS-Node02 10.193.132.4
AzS-Node03 10.193.132.5
AzS-Node04 10.193.132.6
ExternalAccessible-1 10.193.132.19
ExternalAccessible-2 10.193.132.20
ExternalAccessible-3 10.193.132.21
ExternalAccessible-4 10.193.132.22
ExternalAccessible-5 10.193.132.23
InternalAccessible-1 10.193.132.24
InternalAccessible-2 10.193.132.25
InternalAccessible-3 10.193.132.26
InternalAccessible-4 10.193.132.27
InternalAccessible-5 10.193.132.28
CL01-RG01-SU01-DVM00 10.193.132.29
HLH-OS 10.193.132.30
Широковещательное 10.193.132.31

Сетевое хранилище

Сеть служба хранилища является частной сетью и не предназначена для маршрутизации за пределы стойки. Это первая половина суперсети частной сети, и она используется коммутатором, распределенным, как показано в таблице ниже. Шлюз является первым IP-адресом в подсети. Вторая половина, используемая для внутренних ВИРТУАЛЬНЫх IP-адресов, — это частный пул адресов, управляемых SLB Azure Stack, не отображается на вкладке "Использование IP-адресов". Эти сети поддерживают Azure Stack и существуют списки управления доступом на коммутаторах TOR, которые препятствуют объявлению этих сетей и (или) доступу за пределами решения.

  • Стойка: Rack1
  • Имя: CL01-RG01-SU01-служба хранилища
Назначено Адрес IPv4
Сеть 11.11.128.0
Шлюз 11.11.128.1
TOR1 11.11.128.2
TOR2 11.11.128.3
Широковещательное 11.11.128.127

Сеть инфраструктуры Azure Stack

Для суперсети инфраструктуры требуется сеть /24, и это по-прежнему будет /24 после запуска средства "Лист развертывания". Шлюз будет первым IP-адресом в подсети.

  • Стойка: Rack1
  • Имя: CL01-RG01-SU01-Infra
Назначено Адрес IPv4
Сеть 12.193.130.0
Шлюз 12.193.130.1
TOR1 12.193.130.2
TOR2 12.193.130.3
Широковещательное 12.193.130.255

Сеть инфраструктуры коммутаторов

Сеть инфраструктуры разбивается на несколько сетей, используемых инфраструктурой физического коммутатора. Это отличается от инфраструктуры Azure Stack, которая поддерживает только программное обеспечение Azure Stack. Инфраструктура коммутатора поддерживает только инфраструктуру физического коммутатора. Ниже перечислены сети, поддерживаемые инфраструктурой.

имя; Подсеть IPv4
P2P_Border/Border1_To_Rack1/TOR1 10.193.132.128/30
P2P_Border/Border1_To_Rack1/TOR2 10.193.132.132/30
P2P_Border/Border2_To_Rack1/TOR1 10.193.132.136/30
P2P_Border/Border2_To_Rack1/TOR2 10.193.132.140/30
P2P_Rack1/TOR1_To_Rack1/BMC 10.193.132.144/30
P2P_Rack1/TOR2_To_Rack1/BMC 10.193.132.148/30
Loopback0_Rack1_TOR1 10.193.132.152/32
Loopback0_Rack1_TOR2 10.193.132.153/32
Loopback0_Rack1_BMC 10.193.132.154/32
P2P_Rack1/TOR1-ibgp-1_To_Rack1/TOR2-ibgp-1 10.193.132.156/30
P2P_Rack1/TOR1-ibgp-2_To_Rack1/TOR2-ibgp-2 10.193.132.160/30
SwitchMgmt 10.193.132.168/29

  • Точка — точка — точка (P2P): эти сети позволяют подключаться между всеми коммутаторами. Размер подсети — это сеть /30 для каждой P2P. Самый низкий IP-адрес всегда назначается вышестоящему устройству (North) в стеке.

  • Замыкания на себя: эти адреса — это сети /32, назначенные каждому коммутатору, используемому в стойке. Пограничные устройства не назначаются замыкания на себя, так как они не должны быть частью решения Azure Stack.

  • Switch Mgmt или Switch Management: эта сеть /29 поддерживает выделенные интерфейсы управления коммутаторами в стойке. IP-адреса назначаются следующим образом. Эту таблицу также можно найти на вкладке "Использование IP-адресов" листа развертывания:

  • Стойка: Rack1

  • Имя: SwitchMgmt

Назначено Адрес IPv4
Сеть 10.193.132.168
Шлюз 10.193.132.169
TOR1 10.193.132.170
TOR2 10.193.132.171
Широковещательное 10.193.132.175

Подготовка среды

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

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

Ниже приведены шаги по обновлению образа контейнера:

  1. Загрузка образа контейнера

  2. Замените образ контейнера в следующем расположении.

Создание конфигурации

Здесь мы рассмотрим шаги по созданию JSON-файлов и файлов конфигурации сетевого коммутатора:

  1. Открытие листа развертывания

  2. Заполнение всех обязательных полей на всех вкладках

  3. Вызовите функцию Generate на листе развертывания.
    Будут созданы две дополнительные вкладки, отображающие созданные IP-подсети и назначения.

  4. Просмотрите данные и после подтверждения вызовите функцию Export.
    Вам будет предложено указать папку, в которой будут сохранены JSON-файлы.

  5. Выполните контейнер с помощью Invoke-SwitchConfigGenerator.ps1. Для выполнения этого скрипта требуется консоль PowerShell с повышенными привилегиями и требуются следующие параметры.

    • ContainerName — имя контейнера, создающего конфигурации коммутатора.

    • ConfigurationData — путь к файлу ConfigurationData.json, экспортируемом из листа развертывания.

    • OutputDirectory — путь к выходному каталогу.

    • Вне сети — сигнализирует о том, что скрипт выполняется в автономном режиме.

    C:\\WINDOWS\\system32\> .\\Invoke-SwitchConfigGenerate.ps1 -ContainerName generalonrampacr.azurecr.io/master -ConfigurationData .\\ConfigurationData.json -OutputDirectory c:\\temp -Offline

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

C:\WINDOWS\system32> .\Invoke-SwitchConfigGenerate.ps1 -ContainerName generalonrampacr.azurecr.io/master -ConfigurationData .\ConfigurationData.json -OutputDirectory c:\temp -Offline                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         
Seconds : 2
Section : Validation
Step    : WindowsRequirement
Status  : True
Detail  : @{CurrentImage=10.0.18363.0}


Seconds : 2
Section : Validation
Step    : DockerService
Status  : True
Detail  : @{Status=Running}


Seconds : 9
Section : Validation
Step    : DockerSetup
Status  : True
Detail  : @{CPU=4; Memory=4139085824; OS=Docker Desktop; OSType=linux}


Seconds : 9
Section : Validation
Step    : DockerImage
Status  : True
Detail  : @{Container=generalonrampacr.azurecr.io/master:1.1910.78.1}


Seconds : 10
Section : Run
Step    : Container
Status  : True
Detail  : @{ID=2a20ba622ef9f58f9bcd069c3b9af7ec076bae36f12c5653f9469b988c01706c; ExternalPort=32768}


Seconds : 38
Section : Generate
Step    : Config
Status  : True
Detail  : @{OutputFile=c:\temp\N22R19.zip}


Seconds : 38
Section : Exit
Step    : StopContainer
Status  : True
Detail  : @{ID=2a20ba622ef9f58f9bcd069c3b9af7ec076bae36f12c5653f9469b988c01706c}

Настраиваемая конфигурация

Для конфигурации коммутатора Azure Stack можно изменить несколько параметров среды. Вы можете определить, какие параметры можно изменить в шаблоне. В этой статье описывается каждый из этих настраиваемых параметров и объясняется, как изменения могут повлиять на Azure Stack. Эти параметры охватывают обновление паролей, сервер системного журнала, мониторинг SNMP, аутентификацию и список управления доступом.

При развертывании решения Azure Stack изготовитель оборудования создает конфигурацию коммутатора и применяет ее к точкам выхода TOR и контроллеру BMC. Изготовитель оборудования использует средство автоматизации Azure Stack для проверки правильности настройки требуемых конфигураций на этих устройствах. Конфигурация основывается на данных из листа сведений о развертывании Azure Stack.

Примечание

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

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

Обновление пароля

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

Сервер системного журнала

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

Мониторинг SNMP

Оператор может настроить протокол SNMP версии 2 или 3 для мониторинга сетевых устройств и отправки ловушек в приложение мониторинга сети в центре обработки данных. Из соображений безопасности следует использовать протокол SNMP версии 3, так как он более надежный, чем протокол версии 2. Обратитесь к поставщику оборудования от изготовителя оборудования, чтобы получить сведения о MIB и обязательной конфигурации. В разделе Обновления списка управления доступом ознакомьтесь с общими сведениями о настройке разрешений на доступ для управления коммутатором.

Аутентификация

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

Обновления списка управления доступом

Оператор может изменить некоторые списки управления доступом (ACL), чтобы разрешить доступ к интерфейсам управления сетевыми устройствами и узлу жизненного цикла оборудования (HLH) из доверенного диапазона номеров сети центра обработки данных. Оператор может выбрать, какой компонент будет доступен и откуда. С помощью списка управления доступом оператор может разрешить виртуальным машинам управления Jumpbox в определенном диапазоне номеров сети доступ к интерфейсу управления коммутатором, а также ОС и BMC узла жизненного цикла оборудования (HLH).

Дополнительные сведения см. в списке управления доступом физического коммутатора.

TACACS, RADIUS и Системный журнал

Решение Azure Stack не будет отправлено с решением TACACS или RADIUS для управления доступом устройств, таких как коммутаторы и маршрутизаторы, а также решение системного журнала для записи журналов коммутаторов, но все эти устройства поддерживают эти службы. Чтобы помочь интегрироваться с существующим сервером TACACS, RADIUS и /или Syslog в вашей среде, мы предоставим дополнительный файл с конфигурацией сетевого коммутатора, который позволит инженеру на сайте настроить коммутатор в соответствии с потребностями клиента.

Дальнейшие действия

Сетевая интеграция