Обзор сетевой архитектуры сред службы приложений

Важно!

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

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

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

Общий поток сетевого трафика

Когда среда службы приложений (ASE) использует общедоступный виртуальный IP-адрес для приложений, на него поступает весь входящий трафик. Сюда входит трафик HTTP и HTTPS для приложений, а также прочий трафик FTP, удаленной отладки и операций управления Azure. Полный список всех портов (обязательных и необязательных) для общедоступного виртуального IP-адреса см. в статье Как управлять входящим трафиком в среде службы приложений.

Кроме того, среда службы приложений поддерживают работающие приложения, которые привязаны только к внутреннему адресу виртуальной сети, также называемому адресом внутреннего балансировщика нагрузки (ILB). В ASE с поддержкой ILB весь трафик HTTP и HTTPS для приложений и вызовы удаленной отладки поступают на адрес ILB. В наиболее распространенных конфигурациях ASE с внутренним балансировщиком нагрузки трафик FTP или FTPS также будет поступать на адрес ILB. Тем не менее операции управления Azure по-прежнему будут поступать через порты 454 и 455 на общедоступный виртуальный IP-адрес ASE с внутренним балансировщиком нагрузки.

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

General Network Flows

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

Важно!

Согласно схеме сети, "Другие ресурсы компьютера" развертываются в другой подсети по сравнению со средой службы приложений. Развертывание ресурсов в одной подсети со средой службы приложений заблокирует подключения среды службы приложений к этим ресурсам (за исключением определенной маршрутизации внутри среды службы приложений). Вместо этого выполните развертывание в другую подсеть (в той же виртуальной сети). После этого среда службы приложений сможет выполнить подключение. Никаких дополнительных настроек не требуется.

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

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

Дополнительную информацию о разрешении исходящего подключения к Интернету в среде службы приложений см. в статье о работе с Express Route. Метод, описанный в статье, применяется также при работе с подключением «сеть — сеть» и при использовании принудительного туннелирования.

Исходящие сетевые адреса

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

Если вызываемая конечная точка расположена за пределами топологии виртуальной сети, используемый исходящий адрес (также называемый исходящим адресом NAT) является общедоступным виртуальным IP-адресом Среды службы приложений. Этот адрес можно найти в пользовательском интерфейсе портала для Среды службы приложений в разделе "Свойства".

Outbound IP Address

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

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

Но поскольку Среда службы приложений всегда расположена в подсети, внутренний IP-адрес вычислительного ресурса, в котором работает приложение, будет всегда находиться в диапазоне CIDR подсети. Поэтому при использовании детальных списков управления доступом или групп безопасности сети для защиты доступа к другим конечным точкам в виртуальной сети необходимо предоставить доступ к подсети, содержащей среду службы приложений.

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

Outbound Network Addresses

Расшифровка схемы выше.

  • Так как общедоступный виртуальный IP-адрес среды службы приложений — 192.23.1.2, он является исходящим IP-адресом, используемым при отправке вызовов к конечным точкам в «Интернете».
  • Диапазон CIDR подсети, содержащей среду службы приложений — 10.0.1.0/26. Другие конечные точки в пределах инфраструктуры той же виртуальной сети будут «видеть» вызовы из приложений как исходящие из какого-то адреса в этом диапазоне.

Вызовы между средами службы приложений

Более сложный сценарий может наблюдаться в случае, если несколько сред службы приложений развернуты в одной и той же виртуальной сети, при этом из одной среды службы приложений в другую выполняются исходящие вызовы. Такие типы вызовов между разными средами службы приложений также рассматриваются как «интернет-вызовы».

На схеме ниже показан пример многоуровневой архитектуры с приложениями в одной Среде службы приложений (например, веб-приложениями Front Door), которые обращаются к приложениям во второй Среде службы приложений (например, внутренним приложениям API серверной части, которые не должны быть доступны из Интернета).

Calls Between App Service Environments

В приведенном выше примере среда службы приложений «ASE 1» имеет исходящий IP-адрес 192.23.1.2. Если приложение, запущенное в этой среде службы приложений, выполняет исходящий вызов приложения, запущенного во второй среде службы приложений («ASE 2»), которая расположена в той же виртуальной сети, то исходящий вызов будет считаться «обращением к Интернету». В результате сетевой трафик, поступающий во вторую Среду службы приложений, будет выглядеть так, как будто он поступает с IP-адреса 192.23.1.2 (т. е. с адреса, не входящего в диапазон адресов подсети первой Среды службы приложений).

Даже несмотря на то, что вызовы между различными средами службы приложений считаются вызовами "через Интернет", если обе среды службы приложений находятся в одном регионе Azure, сетевой трафик будет оставаться в региональной сети Azure и физически не будет проходить через общедоступный Интернет. В итоге вы можете использовать сетевую группу безопасности в подсети второй среды службы приложений, чтобы разрешить только входящие вызовы с адреса первой среды службы приложений (исходящий IP-адрес которой 192.23.1.2). Тем самым вы обеспечите защищенный обмен данными между средами службы приложений.

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

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