Интеграция защищенной сети Azure Stack Hub

Статья
07/12/2023

В этом разделе рассматривается интеграция сети Azure Stack.

Подключение границы (исходящей канал)

Планирование интеграции сети — важное условие для успешного развертывания и работы интегрированных систем Azure Stack, а также для управления ими. Планирование подключений к пограничной сети начинается с решения о том, будет ли использоваться динамическая маршрутизация по протоколу BGP. Для этого требуется назначить 16-разрядный номер автономной системы BGP (общедоступный или частный) или использовать статическую маршрутизацию, при которой пограничным устройствам назначается статический маршрут по умолчанию.

Для стоечных коммутаторов (TOR) на физических интерфейсах требуется настроить каналы исходящей связи уровня 3 с IP-адресами типа "точка — точка" (сети с префиксом /30). Не поддерживается использование каналов исходящей связи уровня 2 для стоечных коммутаторов, обслуживающих операции Azure Stack.

Маршрутизация BGP

Использование такого протокола динамической маршрутизации как BGP гарантирует, что система всегда учитывает изменения в сети и упрощает администрирование. Чтобы обеспечить повышенную безопасность, можете установить пароль для пиринга BGP между TOR и границей.

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

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

Чтобы пользовательский трафик немедленно и прозрачно восстанавливался после сбоя, между устройствами TOR можно настроить VPC или MLAG. Это позволит использовать для узлов агрегирование каналов в нескольких стойках. Можно также настроить протокол HSRP или VRRP, обеспечивающий сетевую избыточность в IP-сетях.

Статическая маршрутизация

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

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

Пограничное устройство должно быть настроено со статическими маршрутами, указывающими на каждый из четырех IP-адресов P2P, заданных между TOR и border для трафика, предназначенного для любой сети в Azure Stack, но для работы требуется только внешняя или общедоступная сеть ВИРТУАЛЬНЫх IP-адресов. Для первоначального развертывания потребуется задать статические маршруты к BMC и внешним сетям. Операторы могут решить оставить статические маршруты на пограничном устройстве для доступа к ресурсам управления, которые находятся в сети BMC и инфраструктуры. Добавление статических маршрутов в сеть инфраструктуры коммутаторов и сеть управления коммутаторами является необязательным.

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

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

* Сеть BMC является необязательной после развертывания.

** Сеть инфраструктуры коммутаторов является необязательной, так как вся сеть может быть включена в сеть управления коммутаторами.

Сеть управления коммутаторами является обязательной и может быть добавлена отдельно от сети инфраструктуры коммутаторов.

Прозрачный прокси-сервер

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

Решение Azure Stack не поддерживает обычные веб-прокси.

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

Перехват трафика SSL не поддерживается и может привести к сбоям службы при обращении к конечным точкам. Максимальное поддерживаемое время ожидания для связи с конечными точками, требуемыми для использования удостоверения, — 60 секунд с тремя повторными попытками.

DNS

В этом разделе рассматривается конфигурация системы доменных имен (DNS).

Настройка условного перенаправления DNS

Это применяется только к развертываниям AD FS.

Чтобы включить разрешение имен с помощью имеющейся инфраструктуры DNS, настройте условное перенаправление.

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

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

Откройте сеанс Windows PowerShell с повышенными правами (запуск от имени администратора) и подключитесь к IP-адресу привилегированной конечной точки. Используйте учетные данные для проверки подлинности администратора облака.
```
\$cred=Get-Credential Enter-PSSession -ComputerName \<IP Address of ERCS\> -ConfigurationName PrivilegedEndpoint -Credential \$cred 
```
После подключения к привилегированной конечной точке выполните следующую команду PowerShell. Замените предоставленные примеры значений именем домена и IP-адресами DNS-серверов, которые необходимо использовать.
```
Register-CustomDnsServer -CustomDomainName "contoso.com" -CustomDnsIPAddresses "192.168.1.1","192.168.1.2" 
```

Разрешение имен DNS Azure Stack извне

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

Получение сведений о внешней конечной точке DNS-сервера

Чтобы интегрировать развертывание Azure Stack с инфраструктурой DNS, необходимы следующие сведения:

полные доменные имена DNS-серверов;
IP-адреса DNS-серверов.

Полные доменные имена DNS-серверов Azure Stack имеют следующий формат:

<NAMINGPREFIX-ns01>.<РЕГИОН>.<EXTERNALDOMAINNAME>

<NAMINGPREFIX-ns02>.<РЕГИОН>.<EXTERNALDOMAINNAME>

При использовании примеров значений полные доменные имена для DNS-серверов будут такими:

azs-ns01.east.cloud.fabrikam.com

azs-ns02.east.cloud.fabrikam.com

Эти сведения доступны на портале администрирования, но также создаются в конце всех развертываний Azure Stack в файле с именем AzureStackStampInformation.json. Этот файл находится в папке C:\CloudDeployment\logs виртуальной машины Развертывания. Если вы не знаете, какие значения были использованы для развертывания Azure Stack, эти значения можно получить здесь.

Если виртуальная машина развертывания больше недоступна или недоступна, вы можете получить значения, подключився к привилегированной конечной точке и запустив командлет Get-AzureStackStampInformation PowerShell. Дополнительные сведения см. в статье Использование привилегированной конечной точки в Azure Stack.

Настройка условного перенаправления в Azure Stack

Наиболее простой и безопасный способ интеграции Azure Stack с инфраструктурой DNS — это добиться условного перенаправления зоны с сервера, на котором размещена родительская зона. Рекомендуется использовать этот метод, если у вас есть прямой контроль над DNS-серверами, на которых размещается родительская зона внешнего пространства имен DNS Azure Stack.

Если вы не знаете, как выполнять условную пересылку с помощью DNS, см. следующую статью TechNet: Назначение условного сервера пересылки для доменного имени или документацию по решению DNS.

Условное перенаправление не может быть использовано в сценариях, в которых внешняя зона DNS Azure Stack указана в качестве дочернего домена корпоративного доменного имени. Необходимо настроить делегирование DNS.

Пример

Корпоративное доменное имя DNS: contoso.com
Имя внешнего dns-домена Azure Stack: azurestack.contoso.com

Изменение IP-адресов DNS-сервера пересылки

IP-адреса DNS-сервера пересылки устанавливаются во время развертывания Azure Stack. Однако если по какой-либо причине необходимо обновить IP-адреса сервера пересылки, можно изменить значения, подключився к привилегированной конечной точке и запустив Get-AzSDnsForwarder и Set-AzSDnsForwarder [-IPAddress] <IPAddress[]>] командлеты PowerShell. Дополнительные сведения см. в статье Использование привилегированной конечной точки в Azure Stack.

Делегирование внешних зон DNS в Azure Stack

Для разрешения имен DNS извне развертывания Azure Stack необходимо настроить делегирование DNS.

У каждого регистратора есть собственные средства управления DNS для изменения записей серверов имен домена. На странице управления DNS регистратора замените записи NS для зоны на созданные в Azure Stack.

Большинству регистраторов DNS требуется предоставить как минимум два DNS-сервера для выполнения делегирования.

Брандмауэр

Для ролей инфраструктуры в Azure Stack настраиваются виртуальные IP-адреса (VIP). Эти виртуальные IP-адреса выделяются из пула общедоступных IP-адресов. Каждый виртуальный IP-адрес защищается списком управления доступом (ACL) на уровне программно определяемой сети. Для дополнительной защиты решения списки управления доступом применяются и на физических коммутаторах (стоечные коммутаторы и BMC). Для каждой конечной точки создается DNS-запись во внешней зоне DNS, которая указывается во время развертывания. Например, порталу пользователя назначается запись узла DNS портала. <регион>.<полное доменное имя>.

На следующей схеме с архитектурой показаны несколько уровней сети и списков управления доступом.

На схеме архитектуры показаны различные уровни сети и списки управления доступом

URL-адреса и порты

Чтобы службы Azure Stack (порталы, Azure Resource Manager, DNS и т. д.) стали доступны для внешних сетей, необходимо разрешить входящий трафик к этим конечным точкам для определенных URL-адресов, портов и протоколов.

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

Исходящий обмен данными

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

Примечание

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

Назначение	URL-адрес назначения	Протокол	порты;	Исходная сеть
Идентификация	Azure login.windows.net login.microsoftonline.com graph.windows.net https://secure.aadcdn.microsoftonline-p.com www.office.com ManagementServiceUri = https://management.core.windows.net ARMUri = https://management.azure.com https://.msftauth.net https://.msauth.net https://.msocdn.com Azure для государственных организаций* https://login.microsoftonline.us/ https://graph.windows.net/ Azure China 21Vianet https://login.chinacloudapi.cn/ https://graph.chinacloudapi.cn/ Azure для Германии https://login.microsoftonline.de/ https://graph.cloudapi.de/	HTTP HTTPS	80 443	Общедоступный виртуальный IP-адрес — /27 Открытая сеть инфраструктуры
Синдикация Marketplace	Azure https://management.azure.com https://.blob.core.windows.net https://.azureedge.net Azure для государственных организаций https://management.usgovcloudapi.net/ https://.blob.core.usgovcloudapi.net/ Azure China 21Vianet* https://management.chinacloudapi.cn/ http://*.blob.core.chinacloudapi.cn	HTTPS	443	Общедоступный виртуальный IP-адрес — /27
Обновления и исправления	https://*.azureedge.net https://aka.ms/azurestackautomaticupdate	HTTPS	443	Общедоступный виртуальный IP-адрес — /27
Регистрация	Azure https://management.azure.com Azure для государственных организаций https://management.usgovcloudapi.net/ Azure China 21Vianet https://management.chinacloudapi.cn	HTTPS	443	Общедоступный виртуальный IP-адрес — /27
Использование	Azure https://.trafficmanager.net Azure для государственных организаций* https://.usgovtrafficmanager.net Azure China 21Vianet* https://*.trafficmanager.cn	HTTPS	443	Общедоступный виртуальный IP-адрес — /27
Защитник Windows	.wdcp.microsoft.com .wdcpalt.microsoft.com .wd.microsoft.com .update.microsoft.com *.download.microsoft.com https://www.microsoft.com/pkiops/crl https://www.microsoft.com/pkiops/certs https://crl.microsoft.com/pki/crl/products https://www.microsoft.com/pki/certs https://secure.aadcdn.microsoftonline-p.com	HTTPS	80 443	Общедоступный виртуальный IP-адрес — /27 Открытая сеть инфраструктуры
NTP.	(IP-адрес NTP-сервера, предоставленный для развертывания)	UDP	123	Общедоступный виртуальный IP-адрес — /27
DNS	(IP-адрес DNS-сервера, предоставленный для развертывания)	TCP UDP	53	Общедоступный виртуальный IP-адрес — /27
Список отзыва сертификатов	(URL-адрес сертификата для точек распространения списков отзыва)	HTTP	80	Общедоступный виртуальный IP-адрес — /27
LDAP	Лес AD DS для интеграции Graph	TCP UDP	389	Общедоступный виртуальный IP-адрес — /27
LDAP SSL	Лес AD DS для интеграции Graph	TCP	636	Общедоступный виртуальный IP-адрес — /27
LDAP GC	Лес AD DS для интеграции Graph	TCP	3268	Общедоступный виртуальный IP-адрес — /27
LDAP GC SSL	Лес AD DS для интеграции Graph	TCP	3269	Общедоступный виртуальный IP-адрес — /27
AD FS	Конечная точка метаданных AD FS для интеграции AD FS	TCP	443	Общедоступный виртуальный IP-адрес — /27
Служба сбора журналов диагностики	URL-адрес SAS для больших двоичных объектов, предоставленный службой хранилища Azure	HTTPS	443	Общедоступный виртуальный IP-адрес — /27

Входящий обмен данными

Набор виртуальных IP-адресов инфраструктуры требуется для публикации конечных точек Azure Stack во внешних сетях. В таблице конечных точек (VIP) для каждой конечной точки указаны назначение, используемый порт и протокол. Конечные точки, необходимые для поставщиков дополнительных ресурсов, например для поставщика ресурсов SQL, описаны в документации по развертыванию соответствующих ресурсов.

Здесь не указаны виртуальные IP-адреса для внутренней инфраструктуры, так как они не используются для публикации Azure Stack. Виртуальные IP-адреса пользователей являются динамическими и определяются самими пользователями без контроля со стороны оператора Azure Stack.