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

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

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

• Использование виртуальной сети с Управлением API Azure
• Требования к сетевым ресурсам для внедрения управления API в виртуальную сеть

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

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

Предварительные условия

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

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

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

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

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

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

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

4. Выберите тип доступа Внешний.

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

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

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

     

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

7. Продолжайте настройку параметров VNet для других местоположений вашего экземпляра API Management.

8. В верхней панели навигации нажмите кнопку "Сохранить".

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

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

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

  

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

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

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

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

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

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

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

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

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

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

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

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

• Чтобы обеспечить доступ к конечным точкам и ресурсам Управления API вне виртуальной сети, резервируется общедоступный IP-адрес для подсистемы балансировки нагрузки.
  • Общедоступный VIP можно найти на вкладке Обзор/Основные сведения на портале 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 Management и порталу разработчика из Интернета, также будет отклонен по умолчанию из-за асимметричной маршрутизации, вызванной принудительным туннелированием. Для каждого клиента, которому требуется доступ, настройте явный определяемый пользователем маршрут (UDR) с типом следующего узла "Интернет", чтобы обойти брандмауэр или виртуальное сетевое устройство.

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

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

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

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

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

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

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

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

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

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

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

  

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

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

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

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

Инкрементальные обновления

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

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

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

Ссылки для перехода на ресурсы

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

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

• VNet lock - При перемещении экземпляра API Management обратно в исходную подсеть немедленное переназначение может быть невозможно из-за VNet lock, который может быть снят в течение одного часа. Если в исходной подсети есть другие stv1 службы управления API (на основе облачной платформы), необходимо их удалить и подождать, прежде чем развернуть 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 или других средств.

Связанный контент

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

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