Общие сведения о защищенной сети Azure Stack Hub

Общие сведения о проектировании сети

Проектирование физической сети

Для поддержки операций и служб решение Azure Stack Hub требует отказоустойчивой и высокодоступной физической инфраструктуры. Каналы исходящей связи от коммутаторов ToR к пограничным коммутаторам ограничены носителями SFP+ или SFP28 и скоростями 1 ГБ, 10 ГБ или 25 ГБ. Обратитесь к поставщику оборудования OEM, чтобы получить сведения о доступности.

На следующей схеме представлена рекомендуемая схема для azure Stack Hub с прочным форматом.

Azure Stack Hub ruggedized physical network

Проектирование логической сети

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

  • виртуальные локальные сети (VLAN)
  • IP-подсети
  • Пары IP-подсети и виртуальной ЛС

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

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

Логическая сеть Описание Размер
Общедоступный виртуальный IP-адрес (VIP) Azure Stack Hub, защищенный, использует в общей сложности 31 адреса из этой сети. Восемь общедоступных IP-адресов используются для небольшого набора защищенных служб Azure Stack Hub, а остальные используются виртуальными машинами клиента. Если вы планируете использовать службу приложений и поставщики ресурсов SQL, потребуется еще 7 адресов. Оставшиеся 15 IP-адресов зарезервированы для будущих служб Azure. /26 (62 узла)-
/22 (1022 узла)

Рекомендуется —  /24 (254 узла)
Инфраструктура коммутаторов IP-адреса типа "точка —точка" для целей маршрутизации, выделенные интерфейсы управления коммутаторами и петлевые адреса, назначенные коммутатору. /26
Инфраструктура Используется для взаимодействия с защищенными внутренними компонентами Azure Stack Hub. /24
Private Используется для сети хранения, частных виртуальных IP-адресов, контейнеров инфраструктуры и других внутренних функций. /20
Контроллер управления основной платой (BMC) Используется для взаимодействия с контроллерами управления базовой доской на физических узлах. /26

Сетевая инфраструктура

Сетевая инфраструктура для Azure Stack Hub с защищенной структурой состоит из нескольких логических сетей, настроенных на коммутаторах. На следующей схеме показаны эти логические сети и то, как они интегрируются с коммутаторами верхнего уровня (TOR), контроллером управления базовой доской и пограничными коммутаторами (сеть клиента).

Схема логической сети в Azure Stack Hub:

Azure Stack Hub ruggedized logical network

Сеть BMC

Эта сеть предназначена для подключения всех контроллеров управления основной платой (также называются BMC или служебными процессорами) к сети управления. Например: iDRAC, iLO, iBMC и т. д. Для взаимодействия с любым узлом BMC используется только одна учетная запись BMC. Узел жизненного цикла оборудования (HLH) (при наличии) размещается в этой сети и может предоставлять предназначенное для изготовителей оборудования программное обеспечение для обслуживания или мониторинга оборудования.

Также в HLH размещена виртуальная машина для развертывания (DVM). DVM используется во время защищенного развертывания Azure Stack Hub и удаляется после завершения развертывания. DVM требует доступа к Интернету в сценариях подключенного развертывания для тестирования, проверки и доступа к нескольким компонентам. Эти компоненты могут находиться в корпоративной сети и за ее пределами (например, NTP, DNS и Azure). Дополнительные сведения о требованиях к подключению см. в разделе NAT в интеграции с защищенным брандмауэром Azure Stack Hub.

Частная сеть

Сеть /20 (4096 IP-адресов узлов) является частной для региона Azure Stack Hub с прочным регионом. Он не расширяется за пределы устройств переключения границ в защищенном регионе Azure Stack Hub. Эта сеть делится на несколько подсетей, например:

  • служба хранилища сети: сеть /25 (128 IP), используемая для поддержки использования трафика хранилища локальных дисковых пространств и SMB и динамической миграции виртуальных машин.
  • Внутренняя виртуальная IP-сеть: сеть /25, выделенная для виртуальных IP-адресов только для внутренних виртуальных IP-адресов для программной подсистемы балансировки нагрузки.
  • Сеть контейнеров: сеть /23 (512 IP),выделенная для внутреннего трафика между контейнерами, на которых выполняются службы инфраструктуры

Размер частной сети составляет /20 (4096 IP-адресов) пространства частных IP-адресов. Эта сеть является частной для защищенной системы Azure Stack Hub. Он не направляется за пределы устройств переключения границ в защищенной системе Azure Stack Hub и может использоваться повторно в нескольких защищенных системах Azure Stack Hub. Хотя сеть является частной для Azure Stack Hub, она не должна перекрываться с другими сетями в центре обработки данных. Для получения рекомендаций по пространству частных IP-адресов рекомендуется использовать RFC 1918.

Пространство частных IP-адресов /20 делится на несколько сетей, что позволяет защищенной системной инфраструктуре Azure Stack Hub выполняться в контейнерах в будущих выпусках. Дополнительные сведения см. в заметках о выпуске 1910. Это новое пространство частных IP-адресов позволяет выполнять текущие усилия по сокращению необходимого маршрутизируемого ПРОСТРАНСТВА IP-адресов перед развертыванием.

Защищенная сеть инфраструктуры Azure Stack Hub

Сеть /24 предназначена для внутренних защищенных компонентов Azure Stack Hub для обмена данными между собой. Эта подсеть может быть маршрутизируемой за пределами защищенного решения Azure Stack Hub в центр обработки данных. В этой подсети не рекомендуется использовать общедоступные или маршрутизируемые в Интернете IP-адреса. Эта сеть объявлена на границе, но большинство ip-адресов защищены контроль доступа Списки (ACL). IP-адреса, разрешенные для доступа, находятся в небольшом диапазоне, эквивалентном размеру сети /27. Службы размещения IP-адресов, такие как привилегированная конечная точка (PEP) и azure Stack Hub с защищенным резервным копированием.

Открытая сеть VIP

Сеть общедоступного виртуального IP-адреса назначается сетевому контроллеру в Azure Stack Hub, защищенному. Это не логическая сеть на коммутаторах. SLB использует пул адресов и назначает сети типа /32 для рабочих нагрузок клиента. В таблице маршрутизации коммутаторов эти /32 IP-адреса объявляются как доступный маршрут через протокол BGP. Эта сеть содержит общедоступные адреса, доступные извне. Инфраструктура Azure Stack Hub резервирует первые 31 адреса из этой общедоступной виртуальной виртуальной сети, а остальная часть используется виртуальными машинами клиента. Размер сети в этой подсети может варьироваться от минимум /26 (64 узла) до максимального значения /22 (1022 узла). Рекомендуется запланировать сеть /24.

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

Сеть /26 — это подсеть, содержащая маршрутизируемый IP-адрес /30 (два IP-адреса узла) и замыкания на себя. Это выделенные подсети /32 для управления коммутаторами в полосе и идентификатора маршрутизатора BGP. Этот диапазон IP-адресов должен быть маршрутизируемым за пределами защищенного решения Azure Stack Hub в центре обработки данных. IP-адреса могут быть частными или общедоступными.

Сеть управления коммутаторами

Сеть /29 (шесть IP-адресов узлов) предназначена для подключения портов управления коммутаторов. Эта сеть обеспечивает внеполосный доступ к развертыванию, управлению и устранению неполадок. Она вычисляется на основе сети инфраструктуры коммутаторов, упомянутой выше.

Общие сведения о проектировании DNS

Чтобы получить доступ к защищенным конечным точкам Azure Stack Hub (портал, администрирование, управление, администрирование) за пределами Azure Stack Hub, защищенных, необходимо интегрировать защищенные службы DNS Azure Stack Hub с DNS-серверами, на которых размещены зоны DNS, которые вы хотите использовать в Azure Stack Hub.

Защищенное пространство имен DNS в Azure Stack Hub

При развертывании Azure Stack Hub требуется предоставить некоторые важные сведения, связанные с DNS.

Поле Описание Пример
Регион Географическое расположение развернутого развертывания Azure Stack Hub. восточный
Имя внешнего домена Имя зоны, которую вы хотите использовать для развертывания в Azure Stack Hub. cloud.fabrikam.com
Имя внутреннего домена Имя внутренней зоны, которая используется для служб инфраструктуры в Azure Stack Hub. Она интегрирована со службой каталогов и является частной (недоступной за пределами защищенного развертывания Azure Stack Hub). azurestack.local
DNS-серверы пересылки DNS-серверы, используемые для пересылки ЗАПРОСОВ DNS, зон DNS и записей, размещенных за пределами Azure Stack Hub, в корпоративной интрасети или общедоступном Интернете. Значение сервера пересылки DNS можно изменить с помощью командлета Set-AzSDnsForwarder после развертывания.
Префикс имени (необязательно) Префикс именования, который должен иметь имена экземпляров экземпляров роли инфраструктуры Azure Stack Hub. Если этот параметр не указан, значение по умолчанию — azs. Azs

Полное доменное имя (FQDN) развертывания и конечных точек Azure Stack Hub — это сочетание параметра Region и параметра внешнего доменного имени. Используя значения из примеров в предыдущей таблице, полное доменное имя для этого развертывания Azure Stack Hub будет следующим: east.cloud.fabrikam.com

Таким образом примеры некоторых конечных точек для этого развертывания будут выглядеть как следующие URL-адреса:

  • https://portal.east.cloud.fabrikam.com
  • https://adminportal.east.cloud.fabrikam.com

Чтобы использовать это пример пространства имен DNS для развертывания azure Stack Hub с использованием защищенного развертывания, требуются следующие условия:

  • Зона fabrikam.com зарегистрирована с помощью регистратора доменных имен, внутреннего корпоративного DNS-сервера или обоих. Регистрация зависит от требований к разрешению имен.
  • Дочерний домен cloud.fabrikam.com должен находиться в зоне fabrikam.com.
  • DNS-серверы, на которых размещены зоны fabrikam.com и cloud.fabrikam.com, можно получить из развертывания Azure Stack Hub с защищенным доступом.

Чтобы разрешить DNS-имена для защищенных конечных точек и экземпляров Azure Stack Hub за пределами Azure Stack Hub, необходимо интегрировать DNS-серверы. Включая серверы, на которых размещена внешняя зона DNS для Azure Stack Hub, с DNS-серверами, на которых размещена родительская зона, которую вы хотите использовать.

Метки DNS-имен

Azure Stack Hub в защищенном режиме поддерживает добавление метки DNS-имени в общедоступный IP-адрес, чтобы разрешить разрешение имен для общедоступных IP-адресов. Метки DNS — это удобный способ доступа пользователей к приложениям и службам, размещенным в Azure Stack Hub, по имени. Метка DNS-имени использует пространство имен, которое немного отличается от конечных точек инфраструктуры. После предыдущего примера пространства имен пространство имен для меток DNS-имен будет следующим: *.east.cloudapp.cloud.fabrikam.com.

Если клиент указывает Myapp в поле DNS-имени ресурса общедоступного IP-адреса, он создает запись A для myapp в зоне east.cloudapp.cloud.fabrikam.com на защищенном внешнем DNS-сервере Azure Stack Hub. Полученное полное доменное имя будет следующим: myapp.east.cloudapp.cloud.fabrikam.com.

Если вы хотите использовать эту функцию и использовать это пространство имен, необходимо интегрировать DNS-серверы. Включая серверы, на которых размещена внешняя зона DNS для Azure Stack Hub, и DNS-серверы, на которых размещена родительская зона, которую вы также хотите использовать. Это пространство имен отличается от пространства имен, используемого для конечных точек служб azure Stack Hub, поэтому необходимо создать дополнительное делегирование или правило условной пересылки.

Дополнительные сведения о том, как работает метка DNS-имени, см. в разделе "Использование DNS" в Azure Stack Hub с использованием защищенного домена.

Разрешение и делегирование

Существует два следующих типа DNS-серверов.

  • Полномочный DNS-сервер содержит зоны DNS. Он отвечает на запросы DNS для записей только в этих зонах.
  • Рекурсивный DNS-сервер не содержит зоны DNS. Он отвечает на все запросы DNS, вызывая полномочные DNS-серверы для сбора необходимых данных.

Защищенный Azure Stack Hub включает как полномочные, так и рекурсивные DNS-серверы. Рекурсивные серверы используются для разрешения имен всего, кроме внутренней частной зоны, и внешней общедоступной зоны DNS для развертывания Azure Stack Hub.

Разрешение внешних DNS-имен из azure Stack Hub с использованием защищенного домена

Чтобы разрешить DNS-имена конечных точек за пределами azure Stack Hub с защищенным (например, www.bing.com), необходимо предоставить DNS-серверы для azure Stack Hub, защищенные для пересылки ЗАПРОСОВ DNS, для которых azure Stack Hub не является заслуживающим доверия. DNS-серверы, для которых Azure Stack Hub перенаправляют запросы, необходимые в листе развертывания (в поле DNS-пересылки). Для обеспечения отказоустойчивости укажите по крайней мере два сервера в этом поле. Без этих значений развертывание в Azure Stack Hub завершается сбоем. После развертывания значения DNS-сервера пересылки можно изменить с помощью командлета Set-AzSDnsForwarder.

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

Рекомендуется использовать устройство брандмауэра для защиты azure Stack Hub. Брандмауэры могут помочь в защите от распределенных атак, например отказ в обслуживании (DDOS), обнаружение вторжений и проверка содержимого. Тем не менее они могут ограничивать пропускную способность для служб хранилища Azure, например для больших двоичных объектов, таблиц и очередей.

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

Конечные точки Azure Resource Manager (для администратора), портала администрирования и Key Vault (для администратора) необязательно публиковать для внешнего доступа. Например, как поставщик услуг, вы можете ограничить область атаки, только администрируя Azure Stack Hub, защищенный из вашей сети, а не из Интернета.

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

Преобразование сетевых адресов

Преобразование сетевых адресов (NAT) — это рекомендуемый метод, позволяющий виртуальной машине развертывания получать доступ к внешним ресурсам во время развертывания. Кроме того, для виртуальных машин консоли аварийного восстановления (ERCS) или привилегированной конечной точки (PEP) во время регистрации и устранения неполадок.

NAT также может быть альтернативой общедоступным IP-адресам во внешней сети или общедоступным виртуальным IP-адресам. Однако делать это не рекомендуется, так как это ограничивает возможности взаимодействия с пользователем клиента и увеличивает сложность. Возможен один вариант: NAT типа "1 к 1", при котором по-прежнему требуется один общедоступный IP-адрес для каждого IP-адреса пользователя в пуле. Другой вариант — "многие к 1", при котором для каждого виртуального IP-адреса пользователя требуется правило NAT для всех портов, которые может применять пользователь.

Ниже приведены некоторые недостатки использования NAT для общедоступных виртуальных IP-адресов.

  • Накладные расходы при управлении правилами брандмауэра, так как пользователи управляют собственными конечными точками и правилами публикации в программно-определяемом стеке сети (SDN). Пользователи должны связаться с оператором Azure Stack Hub, чтобы опубликовать виртуальные IP-адреса и обновить список портов.
  • Использование NAT ухудшает взаимодействие с пользователем, но дает оператору полный контроль над публикацией запросов.
  • Для гибридных облачных сценариев с Azure следует учитывать, что Azure не поддерживает настройку VPN-туннеля к конечной точке, использующей NAT.

Перехват SSL

В настоящее время рекомендуется отключить перехват SSL (например, разгрузку расшифровки) во всем защищенном трафике Azure Stack Hub. Если она поддерживается в будущих обновлениях, будет предоставлено руководство по включению перехвата SSL для azure Stack Hub с поддержкой защищенного шифрования.

Сценарий брандмауэра для пограничного развертывания

В пограничном развертывании azure Stack Hub выполняется развертывание непосредственно за пограничным маршрутизатором или брандмауэром. В этих сценариях брандмауэр поддерживается над границей (сценарий 1), где он поддерживает конфигурации брандмауэра "активный — активный — активный" и "активный — пассивный". Он также может выступать в качестве пограничного устройства (сценарий 2), где он поддерживает только конфигурацию брандмауэра "активный — активный". Сценарий 2 зависит от равенства затрат с несколькими путями (ECMP) с BGP или статической маршрутизацией для отработки отказа.

Общедоступные маршрутизируемые IP-адреса указываются для пула общедоступных ВИРТУАЛЬНЫх IP-адресов из внешней сети во время развертывания. В целях безопасности общедоступные маршрутизируемые IP-адреса не рекомендуется использовать в любой другой сети в пограничном сценарии. Этот сценарий позволяет пользователю работать в полностью контролируемой облачной среде как в обычном общедоступном облаке типа Azure.

Azure Stack Hub ruggedized edge firewall scenario

Сценарий с брандмауэром в сети периметра или корпоративной интрасети

В развертывании корпоративной интрасети или периметра azure Stack Hub выполняется развертывание в многозонном брандмауэре или между пограничным брандмауэром и внутренним брандмауэром корпоративной сети. Затем его трафик распределяется между защищенной сетью периметра и незащищенными зонами, как описано ниже.

  • Безопасная зона: внутренняя сеть, использующая внутренние или корпоративные маршрутизируемые IP-адреса. Безопасная сеть может быть разделена. Он может иметь исходящий доступ к Интернету через NAT брандмауэра. Обычно он доступен из центра обработки данных через внутреннюю сеть. Все защищенные сети Azure Stack Hub должны находиться в защищенной зоне, за исключением пула общедоступных ВИРТУАЛЬНЫх IP-адресов внешней сети.
  • Зона периметра. Сеть периметра обычно развертывается для внешних или интернет-приложений, таких как веб-серверы. Обычно он отслеживается брандмауэром, чтобы избежать таких атак, как DDoS и вторжение (взлом), при этом разрешен указанный входящий трафик из Интернета. В зоне периметра должен находиться только пул общедоступных виртуальных IP-адресов внешней сети Azure Stack Hub.
  • Незащищенная зона. Внешняя сеть, Интернет. Развертывание Azure Stack Hub в небезопасной зоне не рекомендуется.

Perimeter network firewall scenario

Общие сведения о проектировании VPN

Хотя VPN является концепцией пользователя, существует ряд важных соображений, которые необходимо знать владельцу решения и оператору.

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

VPN-шлюз — это тип шлюза виртуальной сети, который отправляет зашифрованный трафик через общедоступное подключение. VPN-шлюзы можно использовать для безопасной отправки трафика между виртуальной сетью в Azure Stack Hub с защищенной и виртуальной сетью в Azure. Вы также можете безопасно отправлять трафик между виртуальной сети и другой сетью, подключенной к VPN-устройству.

При создании шлюза виртуальной сети нужно указать тип шлюза, который вы хотите использовать. Azure Stack Hub, защищенный, поддерживает один тип шлюза виртуальной сети: тип VPN .

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

Прежде чем создавать и настраивать VPN-шлюзы для azure Stack Hub, защищенные, ознакомьтесь с рекомендациями по использованию защищенных сетей Azure Stack Hub. Вы узнаете, как конфигурации для Azure Stack Hub отличаются от azure.

В Azure пропускная способность для выбранного номера SKU VPN-шлюза должна разделяться между всеми подключениями к шлюзу. Однако в Azure Stack Hub в защищенном режиме значение пропускной способности номера SKU VPN-шлюза применяется к каждому ресурсу подключения, подключенного к шлюзу. Пример:

  • В Azure номер SKU "Базовый" VPN-шлюза может включать приблизительно 100 Мбит/с суммарной пропускной способности. Если создать два подключения к этому VPN-шлюзу, для одного из которых используется 50 Мбит/с пропускной способности, то для другого будет доступно 50 Мбит/с.
  • В Azure Stack Hub с защищенной пропускной способностью выделяется каждое подключение к базовому номеру SKU VPN-шлюза 100 Мбит/с.

Типы VPN

При создании шлюза виртуальной сети для конфигурации VPN-шлюза необходимо указать тип VPN. Выбор типа VPN зависит от топологии подключений, которую вы хотите создать. Тип VPN может также зависеть от используемого оборудования. Для конфигураций "сеть — сеть" требуется VPN-устройство. Некоторые VPN-устройства поддерживают только определенный тип VPN.

Важно!

В настоящее время Azure Stack Hub поддерживает только тип VPN на основе маршрутов. Если ваше устройство поддерживает только vpn на основе политик, подключения к этим устройствам из azure Stack Hub не поддерживаются. Кроме того, в настоящее время Azure Stack Hub не поддерживает использование селекторов трафика на основе политик для шлюзов на основе маршрутов, так как пользовательские конфигурации политики IPSec/IKE не поддерживаются.

  • PolicyBased: VPN на основе политик шифруют и направляют пакеты через туннели IPsec на основе политик IPsec. Политики настраиваются с помощью сочетаний префиксов адресов между локальной сетью и защищенной виртуальной сетью Azure Stack Hub. Политика (или селектор трафика) обычно представляет собой список доступа в конфигурации VPN-устройства. PolicyBased поддерживается в Azure, но не в Azure Stack Hub.
  • RouteBased: VPN на основе маршрутов используют маршруты, настроенные в таблице IP-пересылки или маршрутизации. Маршруты направляют пакеты в соответствующие интерфейсы туннеля. Затем интерфейсы туннелей шифруют пакеты в туннели или расшифровывают их из туннелей. Политика или селектор трафика для VPN RouteBased настраиваются как "любой к любому" (или используют подстановочные знаки). По умолчанию их нельзя изменить. Значением для типа VPN RouteBased является RouteBased.

Настройка VPN-шлюза

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

Настройки

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

В этой статье подробно описываются:

  • типы шлюзов, типы VPN и типы подключений;
  • подсети шлюзов, локальные сетевые шлюзы и другие параметры ресурсов, которые стоит рассмотреть.

Схемы топологий подключения

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

  • доступная модель развертывания;
  • доступные средства настройки;
  • ссылки, по которым можно перейти непосредственно к соответствующей статье (если она есть).

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

Подключение типа "сеть — сеть" и многосайтовое подключение (через VPN-туннель IPsec/IKE)

Подключение типа сайт — сайт

Подключение типа сеть — сеть (S2S) через VPN-шлюз — это подключение через туннель VPN по протоколу IPsec/IKE (IKEv2). Для этого типа подключения требуется локальное VPN-устройство, которому назначен общедоступный IP-адрес. Это устройство не может быть за пределами NAT. Подключения типа "сеть — сеть" можно использовать для распределенных и гибридных конфигураций.

Многосайтовые подключения

Многосайтовое подключение является вариантом подключения типа "сеть — сеть". В шлюзе виртуальной сети создается несколько VPN-подключений, как правило, к разным локальным сайтам. При работе с несколькими подключениями следует использовать VPN на основе маршрутов (динамический шлюз для работы с классическими виртуальными сетями). Так как каждая виртуальная сеть может иметь только один VPN-шлюз, доступную пропускную способность шлюза используют все подключения.

Номера SKU шлюза

При создании шлюза виртуальной сети для azure Stack Hub, защищенного, необходимо указать номер SKU шлюза, который вы хотите использовать. Поддерживаются следующие номера SKU VPN-шлюзов:

  • Basic
  • Standard
  • высокопроизводительная

При выборе более высокого номера SKU шлюза выделяется больше ЦП и пропускная способность сети для шлюза. В результате шлюз сможет поддерживать более высокую пропускную способность для виртуальной сети.

Azure Stack Hub не поддерживает SKU шлюза ценовой категории "Ультра", который используется исключительно с Express Route.

При выборе номера SKU учитывайте следующие факторы.

  • Защищенный Azure Stack Hub не поддерживает шлюзы на основе политик.
  • BGP не поддерживается в SKU "Базовый".
  • Конфигурации сосуществующего шлюза ExpressRoute-VPN не поддерживаются в azure Stack Hub с прочным подключением.

Доступность шлюза

Сценарии высокого уровня доступности можно настроить только на SKU подключения шлюза высокой производительности . В отличие от Azure, которая обеспечивает доступность с помощью конфигураций "активный", "активный", "активный" и "активный" и "пассивный" Azure Stack Hub поддерживает только конфигурацию "активный— пассивный".

Отработка отказа

В Azure Stack Hub есть три виртуальных машины инфраструктуры мультитенантного шлюза. Две из этих виртуальных машин работают в активном режиме, а третья — в избыточном. Активные виртуальные машины позволяют создавать на них VPN-подключения, а избыточная виртуальная машина принимает VPN-подключения только в случае отработки отказа. Если активная виртуальная машина шлюза становится недоступной, VPN-подключение через некоторое время после утраты связи (несколько секунд) выполняет отработку отказа на избыточную виртуальную машину.

Расчетная суммарная пропускная способность в зависимости от SKU

В следующей таблице приведены типы шлюзов с приблизительной суммарной пропускной способностью в зависимости от SKU шлюза.

Пропускная способность VPN-шлюза (1) Максимальное число туннелей IPsec для VPN-шлюза (2)
Номер SKU "Базовый"(3) 100 Мбит/с 20
SKU "Стандартный" 100 Мбит/с 20
SKU с высокой производительностью 200 Мбит/с 10

Примечания к таблице

(1) — пропускная способность VPN не является гарантированной пропускной способностью для локальных подключений через Интернет. Это максимально возможное значение пропускной способности.
(2) — максимальное число туннелей — это общее количество единиц развертывания azure Stack Hub для всех подписок.
(3) — маршрутизация BGP не поддерживается для номера SKU "Базовый".

Важно!

Между двумя развернутными развертываниями Azure Stack Hub можно создать только одно VPN-подключение типа "сеть — сеть". Это связано с ограничением платформы, в соответствии с которым разрешается создавать только одно VPN-подключение с использованием одного и того же IP-адреса. Так как Azure Stack Hub использует многотенантный шлюз, который использует один общедоступный IP-адрес для всех VPN-шлюзов в защищенной системе Azure Stack Hub, между двумя защищенными системами Azure Stack Hub может быть только одно VPN-подключение между двумя защищенными системами Azure Stack Hub.

Это ограничение также относится к созданию нескольких VPN-подключений "сеть — сеть" к любому VPN-шлюзу, который использует один IP-адрес. Azure Stack Hub не поддерживает создание нескольких ресурсов шлюза локальной сети с использованием одного IP-адреса.**

Параметры IPsec/IKE

При настройке VPN-подключения в Azure Stack Hub в защищенном режиме необходимо настроить подключение в обоих концах. Если вы настраиваете VPN-подключение между azure Stack Hub и аппаратным устройством, это устройство может запросить дополнительные параметры. Например, коммутатор или маршрутизатор, который выступает в качестве VPN-шлюза.

В отличие от Azure, которая поддерживает несколько предложений в качестве инициатора и ответчика, Azure Stack Hub по умолчанию поддерживает только одно предложение. Если вам нужно использовать разные параметры IPSec/IKE для работы с VPN-устройством, доступны дополнительные параметры для настройки подключения вручную.

Параметры этапа 1 IKE (главный режим)

Свойство Значение
Версия IKE IKEv2
Группа Диффи — Хелмана ECP384
Метод проверки подлинности Общий ключ
Алгоритмы шифрования и хэширования AES256, SHA384
Срок действия SA (время) 28 800 сек

Параметры этапа 2 IKE (быстрый режим)

Свойство Значение
Версия IKE IKEv2
Алгоритмы хэширования шифрования & (шифрование) GCMAES256
Алгоритмы хэширования шифрования & (проверка подлинности) GCMAES256
Срок действия SA (время) 27 000 секунд
Срок действия SA (килобайты) 33 553 408
Полная безопасность пересылки (PFS) ECP384
Обнаружение неиспользуемых одноранговых узлов Поддерживается

Настройка настраиваемых политик подключения IPSec/IKE

Стандарт протоколов IPsec и IKE поддерживает широкий набор алгоритмов шифрования в разных комбинациях. Чтобы узнать, какие параметры поддерживаются в Azure Stack Hub для удовлетворения требований к соответствию или безопасности, см. параметры IPsec/IKE.

Эта статья содержит инструкции по созданию и настройке политики IPsec/IKE, а также ее применению к новому или существующему подключению.

Рекомендации

Учитывайте следующие рекомендации при использовании этих политик:

  • Политика IPsec/IKE поддерживается только номерами SKU шлюзов уровня Стандартный и Высокопроизводительный (на основе маршрутов).
  • Можно указать только одну комбинацию политик для каждого подключения.
  • Вам следует указать все алгоритмы и параметры для IKE (основной режим) и IPsec (быстрый режим). Указать частичную спецификацию политики невозможно.
  • Ознакомьтесь со спецификациями поставщиков VPN-устройств, чтобы убедиться, что политика поддерживается на локальных VPN-устройствах. Если политики несовместимы, невозможно будет установить подключения типа "сеть — сеть".

Рабочий процесс для создания и настройки политики IPsec/IKE

В этом разделе описывается рабочий процесс создания и обновления политики IPsec/IKE для VPN-подключений типа "сеть — сеть":

  1. Создание виртуальной сети и VPN-шлюза.
  2. Создание шлюза локальной сети для распределенного подключения.
  3. Создание политики IPsec/IKE с выбранными алгоритмами и параметрами.
  4. Создание VPN-подключения типа "сеть — сеть" с использованием политики IPsec/IKE.
  5. Добавление, обновление и удаление политики IPsec/IKE для существующего подключения.

Поддерживаемые алгоритмы шифрования и сильные стороны ключей

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

IPsec/IKEv2 Параметры
Шифрование IKEv2 AES256, AES192, AES128, DES3, DES
Проверка целостности IKEv2 SHA384, SHA256, SHA1, MD5
Группа DH ECP384, ECP256, DHGroup14, DHGroup2048 (DHGroup2), DHGroup1, DHGroup1, нет
Шифрование IPsec GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, нет
Целостность IPsec GCMASE256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
Группа PFS PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, нет
Время существования QM SA (Необязательно — используются значения по умолчанию, если не заданы другие значения.)
Секунды (целое число; мин. 300/по умолчанию 27 000 секунд)
KBytes (целое число; мин. 1024/по умолчанию 102 400 000 КБ)
Селектор трафика Селекторы трафика на основе политик не поддерживаются в Azure Stack Hub с поддержкой защищенного трафика.

Ваша конфигурация локальных VPN-устройств должна совпадать со следующими алгоритмами и параметрами, указанными в политике Azure IPsec/IKE, или содержать их.

  • алгоритм шифрования IKE (основной режим или фаза 1);
  • алгоритм обеспечения целостности IKE (основной режим или фаза 1);
  • группа DH (основной режим или фаза 1);
  • алгоритм шифрования IKE (основной режим или фаза 2);
  • алгоритм обеспечения целостности IPsec (быстрый режим или фаза 2);
  • группа PFS (быстрый режим или фаза 2).
  • Время существования SA — это только локальные спецификации, они не должны соответствовать.

Если для шифрования IPsec используется алгоритм GCMAES, необходимо указать одинаковую длину алгоритма и ключа для проверки целостности IPsec. Например, для обоих можно использовать GCMAES128.

В приведенной выше таблице:

  • IKEv2 соответствует основному режиму или фазе 1;
  • IPsec соответствует быстрому режиму или фазе 2;
  • группа DH определяет группу Диффи — Хеллмана, которая используется в основном режиме или фазе 1;
  • группа PFS определяет группу Диффи — Хеллмана, которая используется в быстром режиме или фазе 2.
  • Время существования SA в основном режиме IKEv2 фиксируется на уровне 28 800 секунд на защищенных VPN-шлюзах Azure Stack Hub.

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

Группа Диффи-Хелмана DHGroup PFSGroup Длина ключа
1 DHGroup1 PFS1 MODP (768 бит)
2 DHGroup2 PFS2 MODP (1024 бит)
14 DHGroup14 PFS2048 MODP (2048 бит)
DHGroup2048
19 ECP256 ECP256 ECP (256 бит)
20 ECP384 ECP384 ECP (384 бит)
24 DHGroup24 PFS24 MODP (2048 бит)

Подключение Azure Stack Hub, защищенный в Azure с помощью Azure ExpressRoute

Обзор, предположения и предварительные требования

Служба Azure ExpressRoute позволяет расширять локальные сети до облака Майкрософт. Вы используете частное подключение, предоставленное поставщиком услуг подключения. ExpressRoute не является VPN-подключением через общедоступный Интернет.

Дополнительные сведения об Azure ExpressRoute см. в этой статье.

Предположения

В этой статье предполагается, что:

  • у вас есть опыт работы с Azure;
  • У вас есть базовое представление об Azure Stack Hub, защищенном.
  • у вас есть базовое представление о сетевых подключениях.

Предварительные требования

Чтобы подключить Azure Stack Hub с использованием ExpressRoute, необходимо выполнить следующие требования:

  • Канал ExpressRoute, подготовленный через поставщика услуг.
  • Подписка Azure, используемая при создании канала ExpressRoute и виртуальных сетей в Azure.
  • Маршрутизатор, поддерживающий:
    • VPN-подключения типа "сеть — сеть" между интерфейсом локальной сети и защищенным мультитенантным шлюзом Azure Stack Hub.
    • создание нескольких виртуальных виртуальных функций (виртуальная маршрутизация и пересылка) при наличии нескольких клиентов в защищенном развертывании Azure Stack Hub.
  • Маршрутизатор с:
    • портом WAN, подключенным к каналу ExpressRoute;
    • Порт локальной сети, подключенный к защищенному мультитенантной шлюзу Azure Stack Hub.

Сетевая архитектура ExpressRoute

На следующем рисунке показаны защищенные среды Azure Stack Hub и среды Azure после завершения настройки ExpressRoute с помощью примеров в этой статье:

ExpressRoute network architecture

На следующем рисунке показано, как несколько клиентов подключаются из защищенной инфраструктуры Azure Stack Hub через маршрутизатор ExpressRoute к Azure:

ExpressRoute network architecture multi-tenant