Сведения о конфигурации сети для Среды службы приложений для Power Apps с Azure ExpressRoute

  • Статья

Важно!

Эта статья посвящена Среде службы приложений версии 1. 31 августа 2024 года будет прекращена поддержка Среды службы приложений версии 1. Имеется новая версия среды службы приложений, которая проще в использовании и которая работает на более мощной инфраструктуре. Чтобы узнать больше о новой версии, начните с изучения статьи Введение в Среду службы приложений. Если вы используете Среду службы приложений версии 1, выполните действия, описанные в этой статье, чтобы перейти на новую версию.

По состоянию на 29 января 2024 г. вы больше не можете создавать новые ресурсы Среда службы приложений версии 1 с помощью любого из доступных методов, включая шаблоны ARM/Bicep, портал Azure, Azure CLI или REST API. Необходимо выполнить миграцию в Среда службы приложений версии 3 до 31 августа 2024 г., чтобы предотвратить удаление ресурсов и потерю данных.

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

Среду службы приложений Azure можно создать, используя такие сценарии:

  • Виртуальные сети Azure Resource Manager.
  • Классическая модель развертывания виртуальной сети.
  • Виртуальные сети, использующие диапазоны общедоступных адресов, либо адресные пространства RFC1918 (т. е. частные адреса).

Примечание.

Хотя эта статья относится к веб-приложениям, она также применима к приложениям API и мобильным приложениям.

Необходимое сетевое подключение

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

Для правильной работы Среде службы приложений требуются следующие параметры сетевого подключения:

  • Исходящие сетевые подключения к конечным точкам службы хранилища Azure по всему миру на порту 80 и порту 443. Эти конечные точки расположены в том же регионе, что и Среда службы приложений, а также в других регионах Azure. Конечные точки службы хранилища Azure разрешаются в следующих DNS-доменах: table.core.windows.net, blob.core.windows.net, queue.core.windows.net и file.core.windows.net.

  • Исходящее сетевое подключение к службе файлов Azure через порт 445.

  • Исходящие сетевые подключения к конечным точкам Базы данных SQL Azure, которые находятся в одном регионе со Средой службы приложений. Конечные точки Базы данных SQL разрешаются в домене database.windows.net, который требует открытого доступа к портам 1433, 11000-11999 и 14000-14999. Дополнительные сведения об использовании портов Базы данных SQL версии 12 см. в статье Порты для ADO.NET 4.5, отличные от порта 1433.

  • Исходящее сетевое подключение к конечным точкам плоскости управления Azure (как классическая модель развертывания Azure, так и конечные точки Azure Resource Manager). Подключение к этим конечным точкам включает домены management.core.windows.net и management.azure.com.

  • Исходящие сетевые подключения к доменам ocsp.msocsp.com, mscrl.microsoft.com и crl.microsoft.com. Подключение к этим доменам необходимо для включения поддержки функций протокола TLS.

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

  • Исходящий доступ через порт 53 необходим для обмена данными с DNS-серверами.

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

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

  • Необходимо предоставить разрешения для входящих сетевых подключений на нужных портах для Среды службы приложений. Дополнительные сведения см. в статье Как управлять входящим трафиком в Среде службы приложений.

Чтобы выполнить требования DNS, убедитесь в создании допустимой инфраструктуры DNS и ее поддержании для виртуальной сети. Если после создания Среды службы приложений меняется конфигурация DNS, разработчики могут принудительно задать выбор новой конфигурации DNS в Среде службы приложений. Вы можете активировать последовательную перезагрузку среды, используя значок Перезапуск в разделе "Управление Средой службы приложений" на портале Azure. Перезагрузка заставляет среду выбрать новую конфигурацию DNS.

Чтобы выполнить требования к входящему сетевому доступу, настройте группу безопасности сети (NSG) в подсети Среды службы приложений. Группа безопасности сети обеспечивает требуемый доступ для управления входящим трафиком в Среду служб приложений .

Исходящие сетевые подключения

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

В типовой клиентской конфигурации определяется собственный основной маршрут (0.0.0.0/0), который направляет исходящий интернет-трафик в локальную среду. Этот поток трафика всегда нарушает Среду службы приложений. Этот исходящий трафик заблокирован локально или транслирован с помощью NAT в нераспознаваемый набор адресов, которые больше не относятся к различным конечным точкам Azure.

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

По возможности используйте следующую конфигурацию.

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

Объединенный эффект этой конфигурации состоит в том, что UDR уровня подсети имеет приоритет над принудительным туннелированием ExpressRoute. Доступ в Интернет, исходящий из App Service Environment, гарантирован.

Важно!

Маршруты, указанные в UDR, должны быть достаточно конкретными, чтобы иметь приоритет над всеми маршрутами, объявленными в конфигурации ExpressRoute. В примере, описанном в следующем разделе, используется широкий диапазон адресов 0.0.0.0/0. Этот диапазон может быть случайно заменен объявлениями маршрутов с более узкими диапазонами адресов.

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

Базовые сведения об определяемых пользователем маршрутах см. в статье Маршрутизация трафика в виртуальной сети.

Чтобы узнать, как создавать и настраивать определяемые пользователем маршруты, см. статью Маршрутизация сетевого трафика с помощью таблицы маршрутов при использовании PowerShell.

Конфигурация UDR

В этом разделе показан пример настройки UDR для Среды службы приложений.

Необходимые компоненты

  • Скачайте Azure PowerShell со страницы загрузок Azure. Выберите загрузку с датой июнь 2015 г. или позже. В программе командной строки>Windows PowerShell выберите Установить, чтобы установить последние командлеты PowerShell.

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

Важно!

Разверните Среду службы приложений только после выполнения шагов настройки. Эти шаги гарантируют наличие исходящего сетевого подключения до развертывания Среды службы приложений.

Шаг 1. Создание таблицы маршрутов

Создайте таблицу маршрутов с именем DirectInternetRouteTable в регионе Azure западная часть США, как показано в этом фрагменте кода.

New-AzureRouteTable -Name 'DirectInternetRouteTable' -Location uswest

Шаг 2. Создание маршрутов в таблице

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

Настройте исходящий доступ в Интернет. Задайте маршрут 0.0.0.0/0, как показано в этом фрагменте кода:

Get-AzureRouteTable -Name 'DirectInternetRouteTable' | Set-AzureRoute -RouteName 'Direct Internet Range 0' -AddressPrefix 0.0.0.0/0 -NextHopType Internet

0.0.0.0/0 — широкий диапазон адресов. Диапазон переопределяется диапазонами адресов, объявленными ExpressRoute, которые являются более конкретными. UDR с маршрутом 0.0.0.0/0 следует использовать вместе с конфигурацией ExpressRoute, которая также объявляет лишь 0.0.0.0/0.

В качестве альтернативы можно загрузить поточный полный список диапазонов CIDR, используемый Azure. XML-файл для всех диапазонов IP-адресов Azure доступен в Центре загрузки Майкрософт.

Примечание.

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

Один UDR имеет верхний предел по умолчанию – 100 маршрутов. Вам необходимо "суммировать" диапазоны IP-адресов Azure, чтобы они не превышали 100 маршрутов. Маршруты, определенные UDR, должны быть конкретнее маршрутов, которые объявляются вашим соединением ExpressRoute.

Шаг 3. Связывание таблицы с подсетью

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

Set-AzureSubnetRouteTable -VirtualNetworkName 'YourVirtualNetworkNameHere' -SubnetName 'ASESubnet' -RouteTableName 'DirectInternetRouteTable'

Шаг 4. Тестирование и подтверждение маршрута

После того как таблица маршрутов привязана к подсети, проверьте и подтвердите маршрут.

Разверните виртуальную машину в подсети и убедитесь, что следующие утверждения верны:

  • Исходящий трафик на конечные точки Azure и другие, описанные в этой статье, не проходит по кругу ExpressRoute. Если исходящий трафик из подсети принудительно туннелируется локально, то создание Среды службы приложений всегда завершается ошибкой.
  • Все поиски DNS конечных точек, описанных в этой статье, разрешаются правильно.

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

Теперь вы готовы к развертыванию Среды службы приложений!

Следующие шаги

Сведения о том, как начать работу со средами службы приложений для Power Apps, см. в статье Общие сведения о Среде службы приложения.