Развертывание экземпляра Azure Управление API в виртуальной сети — внешний режим

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: Разработчик | Премиум

Azure Управление API можно развернуть (внедрить) в виртуальную сеть Azure для доступа к внутренним службам в сети. Параметры подключения к виртуальной сети, требования и рекомендации см. в статье:

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

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

Конфигурации, относящиеся к внутреннему режиму, где конечные точки доступны только в виртуальной сети, см. в статье "Развертывание экземпляра Azure Управление API в виртуальной сети — внутренний режим".

Примечание.

Мы рекомендуем использовать модуль Azure Az PowerShell для взаимодействия с Azure. Чтобы начать работу, см. статью Установка Azure PowerShell. Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.

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

Перед началом работы просмотрите требования к сетевым ресурсам для внедрения Управление API в виртуальную сеть.

Некоторые предварительные отличаются в зависимости от версии (stv2 или stv1) вычислительной платформы, на которой размещен экземпляр Управления API.

Совет

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

  • Виртуальная сеть и подсеть в тех же регионе и подписке, что и экземпляр Управления API.

    • Подсеть, используемая для подключения к экземпляру службы Управление API, может содержать ресурсы Azure других типов.
    • Подсеть не должна включать делегирования. Подсеть делегата в параметр службы для подсети должна иметь значение None.

  • Группа безопасности сети, подключенная к подсети, которая указана выше. Чтобы явным образом разрешить входящее подключение, требуется группа безопасности сети (NSG), так как подсистема балансировки нагрузки, используемая внутри Управлением API, является безопасной по умолчанию и отклоняет весь входящий трафик. Сведения о конкретной конфигурации см. в разделе Настройка правил группы безопасности сети далее в этой статье.

  • Для определенных сценариев включите конечные точки службы в подсети зависимым службам, таким как служба хранилища Azure или SQL Azure. Дополнительные сведения см. в разделе "Принудительное подключение трафика к локальному брандмауэру" с помощью ExpressRoute или виртуальной сети (модуль) далее в этой статье.

  • Общедоступный адрес IPv4 ценовой категории "Стандартный". Ресурс общедоступного IP-адреса необходим при настройке виртуальной сети для внешнего или внутреннего доступа. При использовании внутренней виртуальной сети общедоступный IP-адрес используется только для операций управления. Дополнительные сведения об IP-адресах службы "Управление API".

    • IP-адрес должен находиться в том же регионе и подписке, что и экземпляр Управления API и виртуальная сеть.

    • При создании ресурса общедоступного IP-адреса обязательно назначьте ему метку DNS-имени. Как правило, следует использовать то же DNS-имя, что и экземпляр Управление API. При изменении экземпляра повторно разверните экземпляр, чтобы применить новую метку DNS.

    • Для оптимальной производительности сети рекомендуется использовать параметры маршрутизации по умолчанию: сеть Майкрософт.

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

    • Значение IP-адреса назначается в качестве виртуального общедоступного IPv4-адреса экземпляра Управления API в этом регионе.

    • При переходе с внешней на внутреннюю виртуальную сеть (и наоборот), изменении подсети в сети или обновлении зоны доступности для экземпляра Управления API необходимо настроить другой общедоступный IP-адрес.

Активация подключения к виртуальной сети

Активация возможности подключения к виртуальной сети с помощью портала Azure (вычислительная платформа stv2)

  1. Перейдите на портал Azure, чтобы найти экземпляр Управления API. Найдите и выберите Службы управления API.

  2. Выберите экземпляр Управления API.

  3. Выберите Сеть.

  4. Выберите тип доступа Внешний. Выберите виртуальную сеть на портале Azure.

  5. В списке расположений (регионов), где подготовлена служба "Управление API":

    1. Выберите расположение.
    2. Выберите виртуальную сеть, подсеть и IP-адрес.

    • Список виртуальных сетей заполнен виртуальными сетями Resource Manager, имеющимися в подписках Azure, которые заданы в настраиваемом регионе.

      Параметры виртуальной сети на портале.

  6. Выберите Применить. Страница Сеть экземпляра Управления API будет обновлена с учетом новых выбранных виртуальной сети и подсети.

  7. Продолжите настройку параметров виртуальной сети для остальных расположений экземпляра Управления API.

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

Обновление экземпляра Управления API может занять от 15 до 45 минут. Экземпляры на уровне разработчика имеют простой во время процесса. Экземпляры на уровне "Премиум" не имеют простоя во время процесса.

Активация возможности подключения с помощью шаблона Resource Manager (вычислительная платформа stv2)

  • Шаблон Azure Resource Manager (API версии 2021-08-01)

    Кнопка для развертывания шаблона Resource Manager в Azure.

Активация возможности подключения с помощью командлетов Azure PowerShell (платформа stv1)

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

Настройка правил группы безопасности сети

Настройте пользовательские правила сети для подсети Управления API, чтобы фильтровать трафик для экземпляра Управления API. Рекомендуется использовать следующие минимальные правила NSG, чтобы обеспечить правильную работу и доступ к экземпляру. Внимательно просмотрите среду, чтобы определить больше правил, которые могут потребоваться.

Внимание

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

  • Для большинства сценариев используйте заданные теги службы вместо IP-адресов службы, чтобы указывать сетевые источники и назначения.
  • Задайте для этих правил приоритет выше, чем у правил по умолчанию.
Исходные и конечные порты Направление Транспортный протокол Теги служб
Ресурс и назначение		 Характер использования Тип виртуальной сети
* / [80], 443 Входящий трафик TCP Internet / VirtualNetwork Подключения клиентов к службе управления API Только внешний
* / 3443 Входящий трафик TCP ApiManagement/VirtualNetwork Конечная точка управления для портала Azure и PowerShell Внешний и внутренний
*/6390 Входящий трафик TCP AzureLoadBalancer/VirtualNetwork Подсистема балансировки нагрузки инфраструктуры Azure Внешний и внутренний
* / 443 Входящий трафик TCP AzureTrafficManager / VirtualNetwork маршрутизация Диспетчер трафика Azure для развертывания в нескольких регионах Только внешний
* / 443 Исходящие TCP VirtualNetwork/Storage Зависимость от служба хранилища Azure для основных функций службы Внешний и внутренний
* / 1433 Исходящие TCP VirtualNetwork/SQL Доступ к конечным точкам SQL Azure для основных функций службы Внешний и внутренний
* / 443 Исходящие TCP VirtualNetwork / AzureKeyVault Доступ к Azure Key Vault для основных функций службы Внешний и внутренний
* / 1886, 443 Исходящие TCP VirtualNetwork/AzureMonitor Публикация журналов диагностики и метрик, работоспособности ресурсов и Application Insights Внешний и внутренний

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

После подключения службы "Управление API" к виртуальной сети обращаться к размещенным в ней серверным службам можно будет точно так же, как к общедоступным службам. При создании или изменении API введите локальный IP-адрес или имя узла (если для виртуальной сети настроен DNS-сервер) веб-службы в поле URL-адрес веб-службы.

Добавление API из виртуальной сети

Настройка пользовательского DNS-сервера

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

Служба управления API зависит от нескольких служб Azure. Если служба "Управление API" размещается в виртуальной сети, в которой используется пользовательский DNS-сервер, она должна разрешить имена узлов этих служб Azure.

Внимание

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

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

  • Чтобы обеспечить доступ к конечным точкам и ресурсам Управления API вне виртуальной сети, резервируется общедоступный IP-адрес для подсистемы балансировки нагрузки.
    • Общедоступный виртуальный IP-адрес можно узнать в колонке Обзор и основные сведения на портале Azure.

Дополнительные сведения и рекомендации см. в статье IP-адрес Управления API Azure.

Виртуальные и динамические IP-адреса

Динамические IP-адреса будут назначены каждой базовой виртуальной машине в службе и использованы для доступа к конечным точкам и ресурсам в виртуальной сети и одноранговых виртуальных сетях. Общедоступный виртуальный IP-адрес службы "Управление API" будет использоваться для доступа к общедоступным ресурсам.

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

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

Принудительное туннелирование трафика в локальный брандмауэр с помощью ExpressRoute или сетевого виртуального устройства

Принудительное туннелирование позволяет перенаправлять или принудительно направлять весь интернет-трафик из вашей подсети обратно в локальную среду для проверки и аудита. Обычно вы настраиваете и определяете собственный маршрут по умолчанию (0.0.0.0/0), вследствие чего весь трафик из подсети Управления API принудительно проходит через локальный брандмауэр или виртуальное сетевое устройство. Этот поток трафика прерывает подключение к службе "Управление API", так как исходящий трафик или блокируется локально, или преобразуется с помощью NAT в нераспознаваемый набор адресов, которые больше не относятся к различным конечным точкам Azure. Чтобы устранить эту проблему, используйте указанные ниже способы:

  • Включите конечные точки службы в подсети, в которой развернута служба "Управление API":

    • Azure SQL (обязательно только в основном регионе, если служба "Управление API" развернута в нескольких регионах)
    • Хранилище Azure
    • Центры событий Azure
    • Azure Key Vault (обязательно при развертывании службы "Управление API" на платформе stv2)

    Включение конечных точек для этих служб непосредственно из подсети службы "Управление API" позволяет использовать магистральную сеть Microsoft Azure с оптимальной маршрутизацией трафика службы. Если вы используете конечные точки службы с принудительным туннелированием Управления API, трафик указанных выше служб Azure не туннелируется принудительно. Однако другой трафик зависимостей службы "Управление API" продолжает туннелироваться принудительно. Убедитесь, что ваш брандмауэр или виртуальное устройство не блокирует этот трафик, иначе служба управления API может работать неправильно.

    Примечание.

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

  • Весь трафик плоскости управления из Интернета в конечную точку управления службы Управление API направляется через определенный набор входящих IP-адресов, размещенных Управление API, охватываемый тегом службы ApiManagement. При принудительном туннелировании трафика ответы не будут симметрично сопоставляться с этими входящими исходными IP-адресами, и подключение к конечной точке управления будет потеряно. Чтобы преодолеть это ограничение, настройте определяемый пользователем маршрут (UDR) для тега службы ApiManagement с типом следующего прыжка, установленным значением "Интернет", чтобы управлять трафиком обратно в Azure.

    Примечание.

    Разрешение трафику управления службы Управления API обходить локальный брандмауэр или сетевое виртуальное устройство не считается серьезной угрозой безопасности. Рекомендуемая конфигурация для подсети Управления API разрешает входящий трафик управления через порт 3443 только из набора IP-адресов Azure, охватываемых тегом службы ApiManagement. Рекомендуемая конфигурация UDR используется только для обратного пути этого трафика Azure.

  • (Режим внешней виртуальной сети) Трафик плоскости данных для клиентов, пытающихся подключиться к шлюзу Управления API и порталу разработчика из Интернета, также будет отброшен по умолчанию из-за асимметричной маршрутизации, введенной принудительным туннелированием. Для каждого клиента, которому требуется доступ, настройте явный определяемый пользователем маршрут с типом следующего прыжка "Интернет", чтобы обойти брандмауэр или виртуальное сетевое устройство.

  • Для других зависимостей службы "Управление API" с принудительным туннелированием необходимо разрешать имя узла и обеспечить доступ к конечной точке. Например:

    • Наблюдение за работоспособностью и метриками
    • Диагностика на портале Azure
    • Ретрансляция SMTP
    • CAPTCHA на портале разработчика
    • Сервер Azure KMS

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

Распространенные проблемы с конфигурацией сети

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

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

Неудачное первоначальное развертывание службы "Управление API" в подсети

  • Разверните виртуальную машину в той же подсети.
  • Подключение на виртуальную машину и проверьте подключение к одному из следующих ресурсов в подписке Azure:
    • Большой двоичный объект хранилища Azure
    • База данных SQL Azure
    • Таблица хранилища Azure
    • Azure Key Vault (для экземпляра Управления API, размещенного на платформе stv2)

Внимание

После проверки возможности подключения удалите все ресурсы в подсети перед развертыванием в ней Управления API (требуется, если Управление API размещается на платформе stv1).

Проверка состояния сети

  • После развертывания службы "Управление API" в подсети используйте портал, чтобы проверить подключение экземпляра к зависимостям, таким как служба хранилища Azure.

  • На портале в меню слева в разделе Развертывание и инфраструктура выберите Сеть>Состояние сети.

    Снимок экрана: проверка состояния сетевого подключения на портале.

Фильтр Description
Обязательный Выберите проверку подключения к необходимым службам Azure для службы "Управление API". Сбой указывает на то, что экземпляру не удается выполнить основные операции для управления API.
Необязательно Выберите проверку подключения к дополнительным службам. Сбой указывает только на то, что определенные функциональные возможности не будут работать (например, SMTP). Сбой может привести к снижению производительности при использовании и отслеживании экземпляра Управления API, а также обеспечении требований SLA.

Чтобы устранить неполадки с подключением, выберите:

  • Метрики — проверка метрик состояния сетевого подключения

  • Диагностика — запуск средства проверки виртуальной сети за указанный период времени

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

Добавочные операции обновления

При внесении изменений в сеть обратитесь к API NetworkStatus, чтобы убедиться, что служба Управление API не потеряла доступ к критически важным ресурсам. Состояние подключения должно обновляться каждые 15 минут.

Чтобы применить изменение конфигурации сети к экземпляру Управления API с помощью портала:

  1. В меню слева для экземпляра в разделе "Развертывание и инфраструктура" выберите ">Виртуальная сеть".
  2. Выберите Применить конфигурацию сети.

Экземпляр Управление API, размещенный на stv1 вычислительной платформе, при развертывании в подсети виртуальной сети Resource Manager резервирует подсеть, создав ссылку навигации по ресурсам. Если эта подсеть уже содержит ресурс другого поставщика, развертывание завершится ошибкой. Аналогично, если вы удаляете службу "Управление API" или перемещаете ее в другую подсеть, ссылка для перехода на ресурс удаляется.

Проблемы, возникающие при переназначии экземпляра Управление API в предыдущую подсеть

  • Блокировка виртуальной сети. При перемещении экземпляра Управление API обратно в исходную подсеть немедленное переназначение может быть невозможно из-за блокировки виртуальной сети, которая занимает до шести часов. Если исходная подсеть имеет другие stv1 платформенные службы Управление API (на основе облачной службы), удаление и ожидание 6 часов необходимо для развертывания stv2 службы на основе платформы в той же подсети.
  • Блокировка группы ресурсов — другой сценарий, который следует рассмотреть, заключается в наличии блокировки область на уровне группы ресурсов или выше, что препятствует процессу удаления канала навигации по ресурсам. Чтобы устранить эту проблему, удалите блокировку область и разрешите задержку около 4–6 часов для службы Управление API отсоединить исходную подсеть до удаления блокировки, что позволяет развернуть нужную подсеть.

Устранение неполадок подключения к Microsoft Graph из виртуальной сети

Сетевое подключение к Microsoft Graph необходимо для функций, включая вход пользователей на портал разработчика с помощью поставщика удостоверений Microsoft Entra.

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

  • Убедитесь, что NSG и другие сетевые правила настроены для исходящего подключения из экземпляра Управление API к Microsoft Graph (с помощью тега службы AzureActiveDirectory).

  • Убедитесь, что разрешение DNS и сетевой доступ из graph.microsoft.com виртуальной сети. Например, подготовьте новую виртуальную машину в виртуальной сети, подключитесь к ней и попробуйте выполнить GET https://graph.microsoft.com/v1.0/$metadata попытку из браузера или с помощью cURL, PowerShell или других средств.

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

См. также: