параметры сети Функции Azure

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

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

Функция План потребления Flex План потребления План категории "Премиум" Выделенный план/ASE Приложения-контейнеры1
Ограничения для входящего доступа ✅ ✅ ✅ ✅ ✅ 2
Частные конечные точки (входящий трафик) ✅ ❌ ✅ ✅ ❌
Конечные точки службы (входящий трафик) ✅ ❌ ✅ ✅ ✅
Интеграция виртуальной сети (исходящий трафик) ✅ ❌ ✅ ✅ 3 ✅
Гибридные подключения ❌ ❌ ✅ (только Windows) ✅ (только Windows) ✅ (только Windows)
  1. Дополнительные сведения см. в разделе Networking в среде Контейнеры приложений Azure.
  2. Управляется через конфигурацию входящего трафика в среде Container Apps.
  3. План Выделенный/ASE также поддерживает интеграцию виртуальной сети, необходимую для шлюза.

Ресурсы для быстрого старта

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

Ограничения входящего доступа

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

Примечание.

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

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

При запуске Container Apps управление входящим доступом осуществляется через конфигурацию входящего трафика среды приложений-контейнеров, а не через ограничения доступа к службе приложений. Дополнительные сведения см. в разделе IP ограничения в Контейнеры приложений Azure.

Частные конечные точки (входящий трафик)

Частный конечный узел Azure — это сетевой интерфейс, который подключает вас частным и безопасным образом к службе с использованием Приватный канал Azure. Частная конечная точка использует частный IP-адрес из виртуальной сети, эффективно предоставляя доступ к службе из виртуальной сети.

Вы можете использовать частную конечную точку для функций, размещенных в планах Flex Consumption, Elastic Premium и Выделенной (службы приложений).

Если вы хотите выполнять вызовы к частным конечным точкам, необходимо убедиться, что запросы DNS перенаправляются на частную конечную точку. Можно принудительно применить это поведение одним из следующих способов.

  • Интеграция с приватными зонами Azure DNS. Если в виртуальной сети нет настраиваемого DNS-сервера, это выполняется автоматически.
  • Управляйте частной конечной точкой на DNS-сервере, который используется вашим приложением. Чтобы управлять частной конечной точкой, необходимо знать адрес конечной точки и использовать запись A для ссылки на конечную точку, которую вы пытаетесь достичь.
  • Настройте собственный DNS-сервер для пересылки в частные зоны Azure DNS.

Дополнительные сведения см. в статье using Private Endpoints for веб-приложения.

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

Конечные точки службы (входящий трафик)

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

  1. Настройте интеграцию вашего приложения-функции с региональной виртуальной сетью для подключения к определенной подсети.
  2. Перейти в целевую службу и настроить конечные точки службы для подсети интеграции.

Дополнительные сведения см. в статье Конечные точки служб для виртуальной сети.

Использование конечных точек служб

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

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

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

Снимок экрана области

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

Сведения о настройке конечных точек службы см. в статье Establish Функции Azure доступ к частному сайту.

Интеграция виртуальной сети (исходящий трафик)

В этом разделе описаны функции, поддерживаемые Функциями для управления исходящими данными из приложения.

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

Функции Azure поддерживает интеграцию региональной виртуальной сети, которая является рекомендуемой. Сведения о настройке интеграции виртуальной сети см. в статье Осуществление интеграции виртуальной сети.

Функции Azure поддерживает два типа интеграции виртуальной сети:

Сведения о настройке интеграции виртуальной сети см. в статье Осуществление интеграции виртуальной сети.

Интеграция региональной виртуальной сети (исходящий трафик)

Использование интеграции c региональной виртуальной сетью позволяет приложению получить доступ к следующим ресурсам:

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

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

  • Группы безопасности сети (NSG). Можно блокировать исходящий трафик с помощью NSG, размещенного в подсети интеграции. Правила для входящих подключений не применяются, так как вы не можете использовать интеграцию с виртуальной сетью для предоставления входящего доступа к своему приложению.
  • Таблицы маршрутов (UDR). Можно поместить таблицу маршрутов в подсеть интеграции для отправки исходящего трафика.

Примечание.

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

Интеграция с региональной виртуальной сетью не может использовать порт 25.

Соображения по плану Flex Consumption:

  • Приложение и виртуальная сеть должны находиться в одном регионе.
  • Убедитесь, что поставщик ресурсов Майкрософт.App Azure включен для вашей подписки, следуя этим инструкциям. Это необходимо для делегирования подсети. Портал Azure и Azure CLI применяют эту регистрацию при создании приложения Flex Consumption, поскольку интеграция с виртуальной сетью может быть включена в любой момент после создания вашего приложения.
  • Делегирование подсети, необходимое при выполнении в плане Flex Consumption, Майкрософт.App/environments. Это отличается от планов Elastic Premium и выделенных планов (Служба приложений), которые имеют другое требование делегирования.
  • Вы можете запланировать использование не более 40 IP-адресов для одного функционального приложения, даже если оно масштабируется более чем на 40. Например, если у вас есть 15 приложений функций Flex Consumption, интегрированных в одну подсеть, необходимо спланировать использование 15x40 = 600 IP-адресов, используемых в большинстве случаев. Это ограничение подлежит изменению и не применяется.
  • Подсеть не может использоваться для других целей (например, частных сетей или конечных точек служб, или делегирована другой хостинг-платформе или службе). Хотя вы можете совместно использовать одну подсеть с несколькими приложениями Flex Consumption, сетевые ресурсы используются в этих приложениях-функциях, что может привести к тому, что одно приложение влияет на производительность других пользователей в одной подсети.
  • Вы не можете совместно использовать одну подсеть между средой "Приложения контейнеров" и приложением Flex Consumption.
  • План потребления Flex в настоящее время не поддерживает подсети с именами, которые содержат символы подчеркивания (_).

Рекомендации по планам Эластичный Premium, Выделенные (Служба приложений) и Приложения контейнеров:

  • Эта функция доступна для Elastic Premium и App Service Premium V2 и Premium V3. Она также доступна в варианте "Стандарт", но только в новых средах развертывания Службы приложений. Если вы используете более старое развертывание, вы можете использовать функцию только из плана службы приложений Premium версии 2. Если вы хотите проверить, можете ли вы использовать эту функцию в стандартном плане, создайте приложение в плане "Премиум V3" Службы приложений. Эти планы поддерживаются только в новейших развертываниях. После этого при необходимости вы можете уменьшить масштаб.
  • Изолированные приложения тарифного плана, размещенные в Среда службы приложений, не могут использовать эту функцию.
  • Приложение и виртуальная сеть должны находиться в одном регионе.
  • Для этой функции требуется подсеть, которая имеет значение /28 или больше в виртуальной сети Azure Resource Manager.
  • Несколько планов службы приложений могут использовать подсеть интеграции.
  • Можно выполнить до двух интеграций региональной виртуальной сети на один план Службы приложений. Несколько приложений в рамках плана службы приложений могут использовать одну интеграцию с подсетью.
  • Выбранную подсеть нельзя использовать в других целях (например, с частными конечными точками или конечными точками службы) либо делегировать любому другому плану размещения или службе.
  • Вы можете совместно использовать одну подсеть с несколькими приложениями в плане службы приложений. Так как сетевые ресурсы совместно используются во всех приложениях, одно приложение-функция может повлиять на производительность других пользователей в одной подсети.
  • Невозможно удалить виртуальную сеть с интегрированным приложением. Перед удалением виртуальной сети необходимо удалить интеграцию.
  • Невозможно изменить подписку приложения или плана, пока есть приложение, использующее интеграцию с региональной виртуальной сетью.

Включение интеграции с виртуальной сетью

  1. В вашем приложении-функции в портале Azure выберите в разделе Настройки пункт Сетевые подключения. Затем в разделе виртуальная сеть Integration выберите Не настроено, чтобы добавить.

  2. Выберите Добавить интеграцию виртуальной сети.

    Снимок экрана: страница интеграции с виртуальной сетью, в которой можно включить интеграцию виртуальной сети в приложении.

  3. Раскрывающийся список содержит все виртуальные сети Azure Resource Manager в вашей подписке в том же регионе. Выберите виртуальную сеть, интеграцию с которой вы хотите выполнить.

    Выберите виртуальную сеть

    • Планы размещения Flex Consumption и Elastic Premium поддерживают только интеграцию региональной виртуальной сети. Если виртуальная сеть находится в том же регионе, создайте новую подсеть или выберите пустую существующую подсеть.

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

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

Если вы предпочитаете маршрутизировать только частный трафик (RFC1918 трафик), выполните действия, описанные в этой статье Службы приложений.

подсети;

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

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

План размещения Интеграция с виртуальной сетью Минимальный размер подсети Рекомендуемый размер подсети Делегирование подсети
Потребление Flex Поддерживается /27 /27 (одно приложение), /26 (несколько приложений) Microsoft.App/environments
Elastic Premium (Windows) Поддерживается /28 /24 Microsoft.Web/serverFarms
Elastic Premium (Linux) Поддерживается /28 /26 Microsoft.Web/serverFarms
Выделенный режим (Служба приложений) Поддерживается /28 /26 или больше Microsoft.Web/serverFarms
Контейнерные приложения Управляется средой См. сетевое взаимодействие контейнерных приложений См. сетевое взаимодействие контейнерных приложений Microsoft.App/environments
Consumption Не поддерживаются N/A N/A N/A

Убедитесь, что вы выбрали план размещения в верхней части статьи для получения сведений о соответствующем плане.

При запуске в Контейнеры приложений Azure интеграция виртуальной сети осуществляется через среду приложений контейнеров. Размер и конфигурация подсети определяются средой "Приложения контейнеров", а не приложением-функцией напрямую. Дополнительные сведения см. в разделе Networking в среде Контейнеры приложений Azure.

В планах Elastic Premium и Dedicated (App Service) каждый запущенный экземпляр приложения-функции использует один IP-адрес из подсети. При масштабировании вверх или вниз необходимое адресное пространство может временно удвоиться для того чтобы обеспечить переход. Если несколько приложений используют одну подсеть, общее использование IP-адресов — это сумма всех экземпляров в этих приложениях, плюс временное удвоение во время событий масштабирования.

Сценарии потребления IP-адресов

Scenario Использование IP-адресов
Одно приложение, один экземпляр Один IP-адрес
Одно приложение, пять инстанций Пять IP-адресов
Одно приложение, масштабирование от пяти до десяти экземпляров До 20 IP-адресов (временные во время операции масштабирования)
Три приложения, пять инстанций 15 IP-адресов

Рекомендации по диапазону CIDR

Размер блока CIDR Макс. доступных адресов Максимальная горизонтальная масштабируемость (экземпляры)1
/28 11 5
/27 двадцать семь 13 (тринадцать)
/26 59 29
/25 123 612
/24 251 1253
  1. Предполагается, что вам нужно увеличить или уменьшить размер или номер SKU в какой-либо момент.
  2. Хотя число IP-адресов поддерживает 61 экземпляр, отдельные приложения в выделенном плане имеют максимум 30 экземпляров.
  3. Хотя количество IP-адресов позволяет использовать до 125 экземпляров, отдельные приложения в плане Elastic Premium могут содержать максимум 100 экземпляров.

Дополнительные рекомендации

  • Чтобы избежать проблем с емкостью подсети для планов Functions Elastic Premium, следует использовать /24 с 256 адресами для Windows и /26 с 64 адресами для Linux. При создании подсетей на портале Azure в рамках интеграции с виртуальной сетью требуется минимальный размер /24 и /26 для Windows и Linux соответственно.
  • Каждый план службы приложений может поддерживать до двух подсетей, которые можно использовать для интеграции виртуальной сети. Несколько приложений из одного плана Служба приложений могут присоединиться к одной подсети, но приложения из другого плана не могут использовать ту же подсеть.

В плане Flex Consumption исходящий сетевой трафик из экземпляров функциональных приложений направляется через общие шлюзы, посвященные одной подсети. По крайней мере 27 общих шлюзов (27 IP-адресов) используются для каждой подсети независимо от количества интегрированных приложений. Если подсеть используется для слишком большого количества экземпляров или для приложений, выполняющих интенсивные операции ввода-вывода, могут возникнуть проблемы с емкостью сети, такие как повышенная задержка и время ожидания. Горизонтальное масштабирование приложений не будет затронуто.

Внимание

Интегрирование функциональных приложений Flex Consumption с подсетью размером менее /27 или интеграция нескольких приложений с подсетью размером /27 снижает доступную пропускную способность исходящей сети для них. Если вы планируете это сделать, проведите нагрузочное тестирование приложений с рабочими нагрузками в масштабе рабочего окружения, чтобы убедиться, что не возникали ограничения по емкости сети.

Рекомендации по диапазону CIDR

Размер блока CIDR Адреса, доступные для использования Максимальное число экземпляров Recommendation
/27 двадцать семь 1 000 Рекомендуется для приложения с одной функцией
/26 59 1,000+ Рекомендуется для нескольких приложений или при масштабировании более 1000 экземпляров*

* Обратитесь в группу продуктов, чтобы запросить увеличение максимального числа экземпляров.

Группы безопасности сети

Группы безопасности сети можно использовать для управления трафиком между ресурсами в виртуальной сети. Например, можно создать правило безопасности, которое блокирует исходящий трафик приложения от достижения ресурса в виртуальной сети или выхода из сети. Эти правила безопасности применяются к приложениям, которые настроили интеграцию виртуальной сети. Чтобы заблокировать трафик на общедоступные адреса, необходимо включить интеграцию виртуальной сети и route All. Правила для входящих подключений в группе безопасности сети не применяются к вашему приложению, так как интеграция с виртуальной сетью влияет только на трафик, исходящий из приложения.

Чтобы управлять входящим трафиком к приложению, используйте функцию ограничения доступа. Группа безопасности сети (NSG), применяемая к подсети интеграции, действует независимо от любых маршрутов, применяемых к этой подсети. Если ваше функциональное приложение интегрировано с включенной поддержкой Route All, и если у вас нет маршрутов, влияющих на трафик общедоступного адреса в вашей подсети интеграции, весь ваш исходящий трафик по-прежнему подчиняется сетевым группам безопасности, назначенным вашей подсети интеграции. Если параметр Route All отключен, действие групп безопасности сети будет распространяться только на трафик RFC1918.

Маршруты

Таблицы маршрутов можно использовать для маршрутизации исходящего трафика из приложения в нужное место. По умолчанию таблицы маршрутов влияют только на трафик, направленный на адреса по RFC1918. Если включена функция Route All , все исходящие вызовы затрагиваются. При отключении функции "Route All", ваши таблицы маршрутов влияют только на частный трафик (RFC1918). Маршруты, настроенные в подсети интеграции, не повлияют на ответы на входящие запросы приложений. Местами назначения часто являются брандмауэры и шлюзы.

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

Маршруты протокола BGP также влияют на трафик приложения. Если у вас есть маршруты BGP, например для шлюза ExpressRoute, они повлияют на исходящий трафик приложения. По умолчанию маршруты BGP влияют только на трафик на частные адреса (RFC1918). Если ваше приложение функций интегрировано с виртуальной сетью и в нем включено Route All, весь исходящий трафик может быть затронут вашими маршрутами BGP.

Ограничения исходящих IP-адресов

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

Если вы интегрируете приложение-функцию в план Elastic Premium или план Служба приложений с виртуальной сетью, приложение по-прежнему может выполнять исходящие вызовы в Интернет по умолчанию. Интеграция приложения-функции с виртуальной сетью с включенной функцией Route All позволяет принудительно отправлять весь исходящий трафик в виртуальную сеть, где правила группы безопасности сети можно использовать для ограничения трафика. Для гибкого потребления весь трафик уже направляется через виртуальную сеть, и маршрут всё не нужен.

Сведения об управлении исходящим IP-адресом с помощью виртуальной сети см. в статье Tutorial: управление исходящим IP-адресом Функции Azure с помощью шлюза NAT виртуальной сети Azure.

частные зоны Azure DNS

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

Автоматизация

Следующие API позволяют программно управлять интеграцией региональных виртуальных сетей.

  • Azure CLI. Используйте команды az functionapp vnet-integration для добавления, перечисления или удаления интеграции региональной виртуальной сети.
  • ARM templates: интеграция региональной виртуальной сети может быть включена с помощью шаблона Azure Resource Manager. Полный пример см. в этом шаблоне быстрого запуска функций.

Гибридные подключения

Hybrid Connections — это функция Azure Relay, которую можно использовать для доступа к ресурсам приложений в других сетях. Они обеспечивают доступ из вашего приложения к конечной точке приложения. Она не может быть использована для доступа к приложению.

Как и в Функции Azure, каждое гибридное подключение сопоставляется с одним узлом TCP и сочетанием портов. Это означает, что конечная точка гибридного подключения может быть размещена в любой операционной системе и приложении, пока вы предоставляете доступ к TCP-порту прослушивания. Гибридные подключения не учитывают используемый протокол приложения и не обращают внимания на то, к чему вы подключаетесь. Они просто предоставляют доступ к сети.

Дополнительные сведения см. в App Service documentation for Hybrid Connections (Документация по Службе приложений для гибридных подключений). Эти же шаги конфигурации поддерживают Функции Azure.

Внимание

Гибридные подключения поддерживаются только в том случае, если приложение-функция работает на Windows. Приложения Linux не поддерживаются.

Подключение к службам Azure через виртуальную сеть

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

Ограничьте доступ к учетной записи хранения, разрешив подключаться только из виртуальной сети.

Примечание.

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

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

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

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

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

Использование ссылок на Key Vault

Ссылки Azure Key Vault можно использовать для использования секретов из Azure Key Vault в приложении Функции Azure без каких-либо изменений кода. Azure Key Vault — это служба, которая обеспечивает централизованное управление секретами с полным контролем над политиками доступа и журналом аудита.

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

Триггеры виртуальной сети (без HTTP)

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

Примечание.

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

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

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

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

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

  1. На портале Azure перейдите к приложению-функции.

  2. В разделе "Параметры" выберите "Конфигурация", а затем на вкладке "Параметры среды выполнения" установите для параметра "Мониторинг масштаба среды выполнения" значение "Вкл.".

  3. Нажмите кнопку "Сохранить", чтобы обновить конфигурацию приложения-функции и перезапустить приложение.

VNETToggle

Совет

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

Поддержка динамического мониторинга триггеров виртуальной сети недоступна в среде выполнения Функций версии 1.x.

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

Расширение (минимальная версия) Только мониторинг масштабирования среды выполнения Масштабирование на основе целевого объекта
Майкрософт.Azure. WebJobs.Extensions.CosmosDB > 3.0.5 > 4.1.0
Майкрософт.Azure. WebJobs.Extensions.DurableTask > 2.0.0 Н/Д
Майкрософт.Azure. WebJobs.Extensions.EventHubs > 4.1.0 > 5.2.0
Майкрософт.Azure. WebJobs.Extensions.ServiceBus > 3.2.0 > 5.9.0
Майкрософт.Azure. WebJobs.Extensions.Storage > 3.0.10 > 5.1.0*

* Только хранилище очередей.

Внимание

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

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

Например, предположим, что вы хотите настроить Azure Cosmos DB принимать трафик только из виртуальной сети. В этом случае функциональное приложение необходимо развернуть в плане службы приложений, который обеспечивает интеграцию с этой виртуальной сетью. Интеграция позволяет ресурсу Azure Cosmos DB запускать функцию.

Тестирование частных конечных точек

При тестировании функций в приложении-функции с частными конечными точками необходимо выполнить тестирование из одной виртуальной сети, например на виртуальной машине в этой сети. Чтобы использовать параметр Code + Test на портале на этой виртуальной машине, необходимо добавить следующие источники CORS в приложение-функцию:

  • https://functions-next.azure.com
  • https://functions-staging.azure.com
  • https://functions.azure.com
  • https://portal.azure.com

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

  1. Перейдите к приложению-функции и выберите "Параметры>сети". В разделе "Доступк общедоступной сети" > входящего трафика выберите "Включено" без ограничений доступа.

  2. Убедитесь, что для общедоступного сетевого доступа задано значение "Включено" из выбора виртуальных сетей и IP-адресов.

  3. Добавьте правило в разделе "Доступ к сайту" и правила:

    1. Выберите Service Tag в качестве типа параметров источника и AzureCloud в качестве тега службы.

    2. Убедитесь, что действие разрешено, и задайте требуемое имя и приоритет.

Устранение неполадок

Эта функция просто настраивается, но это не гарантирует отсутствия проблем при ее использовании. При возникновении проблем с доступом к нужной конечной точке можно воспользоваться некоторыми служебными программами для проверки подключения из консоли приложения. Вы можете использовать две консоли: Одна из них — консоль Kudu, а другая — консоль на портале Azure. Чтобы открыть консоль Kudu из приложения, выберите последовательно пункты Инструменты>Kudu. Доступ к консоли Kudu можно также получить по адресу [sitename].scm.azurewebsites.net. После загрузки веб-сайта перейдите на вкладку Debug. Чтобы перейти к консоли, размещенной на портале, из приложения, перейдите к Azure Tools>Console.

Инструменты

В собственных приложениях Windows средства pingnslookup и tracert не будет работать через консоль из-за ограничений безопасности (они работают в контейнерах custom Windows). Для устранения этого недостатка добавлены два других инструмента. Для проверки работоспособности DNS добавлен инструмент с именем nameresolver.exe. Синтаксис:

nameresolver.exe hostname [optional: DNS Server]

Для проверки имен узлов, которые использует ваше приложение, можно использовать команду nameresolver. Таким образом можно обнаруживать ошибки в настройке DNS-сервера или проблемы с доступом к DNS-серверу. DNS-сервер, используемый приложением, можно посмотреть в консоли с помощью переменных среды WEBSITE_DNS_SERVER и WEBSITE_DNS_ALT_SERVER.

Примечание.

В настоящее время средство nameresolver.exe не работает в пользовательских контейнерах Windows.

Для проверки TCP-соединения с комбинацией "хост:порт", можно использовать следующий инструмент. Этот инструмент называется tcpping.exe и использует следующий синтаксис.

tcpping.exe hostname [optional: port]

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

Доступ для отладки к ресурсам, размещенным в виртуальной сети

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

  • Брандмауэр блокирует доступ. Если брандмауэр мешает, происходит истечение времени ожидания для протокола TCP. В этом случае тайм-аут TCP составляет 21 секунду. Проверьте подключение с помощью средства tcpping. Время ожидания для протокола TCP может быть превышено по многим другим причинам, но для начала проверьте брандмауэры.
  • Служба DNS недоступна. Время ожидания для DNS составляет 3 секунды на каждый DNS-сервер. Если у вас два DNS-сервера, то время ожидания составляет 6 секунд. Используйте средство nameresolver для проверки работы DNS. Инструмент nslookup нельзя использовать, так как он игнорирует настройки DNS для виртуальной сети. Если DNS-сервер недоступен, возможно, что он либо заблокирован брандмауэром или NSG, либо не работает.

Если эти рекомендации не помогут вам решить проблему, проверьте еще несколько факторов:

Интеграция региональной виртуальной сети

  • Ваш целевой адрес не соответствует требованиям RFC1918, а параметр Маршрутизировать весь трафик не включен?
  • Блокируется ли исходящий трафик из вашей подсети интеграции с помощью NSG?
  • Если вы используете Azure ExpressRoute или VPN, настроен ли локальный шлюз для маршрутизации трафика до Azure? Если вы можете обращаться к конечным точкам в виртуальной сети, но не в локальной сети, проверьте пути маршрутизации.
  • Имеются ли у вас достаточные разрешения для настройки делегирования в подсети интеграции? Во время настройки конфигурации интеграции региональной виртуальной сети ваша подсеть интеграции делегирована Майкрософт.Web/serverFarms. Интерфейс интеграции виртуальной сети автоматически делегирует подсеть программе Майкрософт.Web/serverFarms. Если у вашей учетной записи нет достаточных сетевых разрешений для настройки делегирования, вам следует обратиться к пользователю, который может задать в подсети интеграции атрибуты, необходимые для делегирования подсети. Чтобы вручную делегировать подсеть интеграции, перейдите в интерфейс подсети Azure Virtual Network и установите делегирование для Майкрософт.Web/serverFarms.

Интеграция с виртуальной сетью на базе шлюза

  • Находится ли диапазон адресов "точка — сеть" в диапазонах, предусмотренных требованиями RFC 1918 (10.0.0.0-10.255.255.255 / 172.16.0.0-172.31.255.255 / 192.168.0.0-192.168.255.255)?
  • Отображается ли на портале шлюз как работающий? Если шлюз не работает, перезапустите его.
  • Отображаются ли сертификаты как синхронизированные или можно предположить, что конфигурация сети была изменена? Если сертификаты не синхронизированы или вы предполагаете, что в конфигурацию виртуальной сети были внесены изменения, не синхронизированные с планами ASP, выберите Синхронизировать сеть.
  • Если вы подключаетесь через VPN-соединение, настроен ли локальный шлюз для маршрутизации трафика обратно до Azure? Если вы можете обращаться к конечным точкам в виртуальной сети, но не в локальной сети, проверьте пути маршрутизации.
  • Вы пытаетесь использовать шлюз совместного использования, поддерживающий и "точка-сеть", и ExpressRoute? Шлюзы с режимом сосуществования не поддерживаются при интеграции с виртуальной сетью.

Отладка сетевых проблем является сложной задачей, так как не видно, что блокирует доступ к определенной комбинации "узел: порт". К некоторым причинам относятся следующие:

  • На хосте включен брандмауэр, который блокирует доступ к порту приложения для диапазона IP-адресов "точка-сайт". Переход между подсетями часто требует публичного доступа.
  • Целевой узел не доступен.
  • Приложение не работает.
  • Указан неверный IP-адрес или неверное имя узла.
  • Ваше приложение прослушивает другой порт, нежели тот, который вы ожидали. Вы можете сопоставить идентификатор процесса с портом прослушивания, используя команду "netstat -aon" на конечной машине.
  • Группы безопасности сети настроены так, чтобы блокировать доступ к хосту и порту вашего приложения из диапазона IP-адресов типа "точка-точка".

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

Дополнительные действия по отладке:

  • Подключитесь к виртуальной машине в вашей виртуальной сети и попытайтесь из нее достичь ресурса узел:порт. Чтобы проверить доступ TCP, используйте команду PowerShell Test-NetConnection. Синтаксис:
Test-NetConnection hostname [optional: -Port]
  • Откройте приложение на виртуальной машине и проверьте из консоли приложения доступ к узлу и порту с помощью инструмента tcpping.

Локальные ресурсы

Если приложение не может перейти к ресурсу локально, проверьте, можно ли перейти к ресурсу через виртуальную сеть. Чтобы проверить доступ по протоколу TCP, используйте команду PowerShell Test-NetConnection. Если виртуальная машина не может подключиться к локальному ресурсу, возможно, неправильно настроено подключение VPN или ExpressRoute.

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

  • Ваши маршруты не настроены с подсетью или диапазонами адресов типа "точка-точка-сеть" в локальном шлюзе вашей сети.
  • Группы безопасности сети блокируют доступ к вашему диапазону IP-адресов точка-сайт.
  • Локальные брандмауэры блокируют трафик из диапазона IP-адресов подключений "точка — сеть".
  • Вы пытаетесь обратиться к адресу, не соответствующему требованиям RFC 1918, используя возможности интеграции с региональной виртуальной сетью.

Удаление плана службы приложений или веб-приложения перед отключением интеграции с виртуальной сетью

Если вы удалили веб-приложение или план службы приложений без предварительного отключения интеграции с виртуальной сетью, то не сможете выполнять операции обновления или удаления в виртуальной сети или подсети, которая использовалась для интеграции с удаленным ресурсом. Делегирование подсети 'Майкрософт.Web/serverFarms' останется назначенным в вашей подсети и предотвратит возможность выполнения операций обновлений и удалений.

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

  1. Повторно создайте план службы приложений и веб-приложение (обязательно используйте точно такое же имя веб-приложения, как и раньше).
  2. Перейдите в колонку "Сеть" в веб-приложении и настройте интеграцию с виртуальной сетью.
  3. После настройки интеграции с виртуальной сетью нажмите кнопку "Отключить".
  4. Удалите план службы приложений или веб-приложение.
  5. Обновите или удалите подсеть или виртуальную сеть.

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

Средство устранения неполадок сети

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

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

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

Проблемы с конфигурацией . Этот средство устранения неполадок проверяет допустимость подсети для интеграции виртуальной сети.

Снимок экрана, показывающий запуск средства устранения неполадок с конфигурацией.

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

Дополнительные сведения о сети и Функции Azure:

  • Last updated on