Интеграция защищенной сети Azure Stack Hub
В этом разделе рассматривается интеграция сети 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-адреса в следующей таблице для исходящего взаимодействия при развертывании в режиме подключения.
Перехват трафика SSL не поддерживается и может привести к сбоям службы при обращении к конечным точкам. Максимальное поддерживаемое время ожидания для связи с конечными точками, требуемыми для использования удостоверения, — 60 с.
Примечание
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.
Примечание
IKEv2 для VPN — это стандартное решение для VPN-подключения IPsec, которое использует порты UDP 500 и 4500, а также TCP-порт 50. Брандмауэры не всегда открывают эти порты, поэтому VPN-подключение IKEv2 может не иметь возможности проходить через прокси-серверы и брандмауэры.
Конечная точка (виртуальный IP-адрес) | Запись A на узле DNS | Протокол | порты; |
---|---|---|---|
AD FS | Adfs. <регион>.<Полное доменное имя> | HTTPS | 443 |
Портал (для администратора) | Adminportal. <регион>.<Полное доменное имя> | HTTPS | 443 |
Adminhosting | *.adminhosting.<регион>.<Полное доменное имя> | HTTPS | 443 |
Azure Resource Manager (для администратора) | Управление администрированием. <регион>.<Полное доменное имя> | HTTPS | 443 |
Портал (для пользователя) | Портал. <регион>.<Полное доменное имя> | HTTPS | 443 |
Azure Resource Manager (для пользователя) | Управления. <регион>.<Полное доменное имя> | HTTPS | 443 |
График | График. <регион>.<Полное доменное имя> | HTTPS | 443 |
Список отзыва сертификатов | Crl.region<.<>Полное доменное имя> | HTTP | 80 |
DNS | *. <регион>.<Полное доменное имя> | TCP или UDP | 53 |
Hosting | *.Хостинг.<регион>.<Полное доменное имя> | HTTPS | 443 |
Хранилище ключей (для пользователя) | *.Хранилища. <регион>.<Полное доменное имя> | HTTPS | 443 |
Хранилище ключей (для администратора) | *.adminvault. <регион>.<Полное доменное имя> | HTTPS | 443 |
Очередь службы хранилища | *.Очереди. <регион>.<Полное доменное имя> | HTTP HTTPS |
80 443 |
Таблица службы хранилища | *.Таблице. <регион>.<Полное доменное имя> | HTTP HTTPS |
80 443 |
Большой двоичный объект хранилища | *.Blob. <регион>.<Полное доменное имя> | HTTP HTTPS |
80 443 |
Поставщик ресурсов SQL | sqladapter.dbadapter. <регион>.<Полное доменное имя> | HTTPS | 44300–44304 |
Поставщик ресурсов MySQL | mysqladapter.dbadapter. <регион>.<Полное доменное имя> | HTTPS | 44300–44304 |
Служба приложений | *.appservice. <регион>.<Полное доменное имя> | TCP | 80 (HTTP) 443 (HTTPS) 8172 (MSDeploy) |
*.scm.appservice. <регион>.<Полное доменное имя> | TCP | 443 (HTTPS) | |
api.appservice. <регион>.<Полное доменное имя> | TCP | 443 (HTTPS) 44300 (Azure Resource Manager) |
|
ftp.appservice. <регион>.<Полное доменное имя> | TCP, UDP | 21, 1021, 10001-10100 (FTP) 990 (FTPS) |
|
VPN-шлюзы; | Сведения см. в статье VPN-шлюз: вопросы и ответы. | ||
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по