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

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

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

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

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

• Шлюз API
• Портал разработчика
• Прямое управление
• Git

Используйте Управление API во внутреннем режиме, чтобы:

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

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

Предпосылки

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

• Инстанция управления API. Дополнительные сведения см. в разделе Создание экземпляра Azure API Management.

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

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

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

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

• (Необязательно) Общедоступный IPv4-адрес уровня SKU "Стандартный" .

  Это важно

  • Начиная с мая 2024 г. ресурс общедоступного IP-адреса больше не требуется при развертывании (внедрении) экземпляра Управление API в виртуальной сети в внутреннем режиме или переносе конфигурации внутренней виртуальной сети в новую подсеть. В режиме внешней виртуальной сети указание общедоступного IP-адреса — optional; Если он не указан, то общедоступный IP-адрес, управляемый Azure, автоматически настраивается и используется для трафика API среды выполнения. Укажите только общедоступный IP-адрес, если вы хотите владеть общедоступным IP-адресом, используемым для входящего или исходящего подключения к Интернету.

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

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

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

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

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

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

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

Включение подключения к виртуальной сети с помощью портала Azure

1. Перейдите на портал Azure, чтобы найти экземпляр управления API. Найдите и выберите Службы управления API.
2. Выберите экземпляр Управления API.
3. > Выберитевиртуальную сеть.
4. Выберите тип внутреннего доступа.
5. В списке расположений (регионов), где развернута ваша служба управления API:
   1. Выберите расположение.
   2. Выберите виртуальную сеть и подсеть.
      • Список виртуальных сетей заполняется виртуальными сетями Azure Resource Manager, доступными в подписках Azure, настроенных в регионе, который вы настраиваете.
6. Нажмите кнопку "Применить". Страница виртуальной сети вашего экземпляра средства управления API обновляется в соответствии с вашими новыми параметрами виртуальной сети и подсети.
7. Продолжайте настройку параметров VNet для других местоположений вашего экземпляра API Management.
8. В верхней панели навигации нажмите кнопку "Сохранить".

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

Включение подключения с помощью шаблона Resource Manager

• Azure Resource Manager template (API версии 2021-08-01)

  

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

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

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

DNS configuration (Настройка DNS)

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

Мы рекомендуем:

1. Настройте частную зону Azure DNS.
2. Свяжите Azure DNS частную зону с виртуальной сетью, в которую вы развернули службу управления API.

Узнайте, как настроить частную зону в Azure DNS.

Доступ к именам узлов по умолчанию

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

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

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

Настройка записей DNS

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

В целях тестирования можно обновить файл узлов на виртуальной машине в подсети, подключенной к виртуальной сети, в которой развертывается управление API. Если для вашей службы используется частный виртуальный IP-адрес 10.1.0.5, можно изменить файл hosts следующим образом. Файл сопоставления узлов находится в %SystemDrive%\drivers\etc\hosts (Windows) или /etc/hosts (Linux, macOS).

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

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

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

Общедоступные и частные IP-адреса с балансировкой нагрузки можно найти в колонке Overview на портале Azure.

Дополнительные сведения и аспекты, которые следует учесть, см. в разделе IP-адреса Azure API Management.

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

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

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

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

Пример

При развертывании 1 единицы мощности API на уровне "Премиум" во внутренней виртуальной сети будут использоваться 3 IP-адреса: 1 для частного виртуального IP-адреса и по одному для DIP для двух виртуальных машин. Если расширить масштабы до 4 единиц, будет использоваться больше IP-адресов для дополнительных DIP-ов из подсети.

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

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

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

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

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

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

  Замечание

  Настоятельно рекомендуется включить конечные точки сервиса непосредственно с подсети API Management для зависимых служб, таких как 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 на портале разработчика
  • сервер KMS Azure

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

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

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

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

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

• Разверните виртуальную машину в той же подсети.
• Подключитесь к виртуальной машине и проверьте подключение к одному из следующих ресурсов в подписке Azure:
  • Объект Blob в служба хранилища Azure
  • База данных SQL Azure
  • Таблица служба хранилища Azure
  • Azure Key Vault

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

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

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

  

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

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

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

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

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

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

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

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

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

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

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

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

• Справочник по конфигурации виртуальной сети
• Часто задаваемые вопросы о виртуальной сети
• Создание записи в DNS