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

  • Статья

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

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

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

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

Примечание.

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

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

  • предоставлять третьим лицам защищенный доступ к API, размещенным в частном центре обработки данных, с помощью VPN-подключений Azure или Azure ExpressRoute;
  • создать гибридное облачное развертывание, предоставляя единый шлюз для облачных и локально размещенных 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. Выберите тип доступа Внутренний.

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

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

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

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

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

    Обновление экземпляра Управления API может занять от 15 до 45 минут. Во время обработки для категории "Разработчик" возникает простой. Для ценовой категории "Базовый" и более высоких простой не возникает.

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

Общедоступные и частные IP-адреса на портале Azure

Примечание.

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

Активация возможности подключения с помощью шаблона 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 Внешний и внутренний

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

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

Примите во внимание следующие рекомендации.

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

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

Примечание.

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

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

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

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

Конечная точка Конфигурация конечной точки
API Gateway contosointernalvnet.azure-api.net
Портал разработчика contosointernalvnet.portal.azure-api.net
Новый портал разработчика contosointernalvnet.developer.azure-api.net
Конечная точка прямого управления contosointernalvnet.management.azure-api.net
Git contosointernalvnet.scm.azure-api.net

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

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

Настройка имени личного домена

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

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

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

Внутренний виртуальный IP-адрес Конфигурация конечной точки
10.1.0.5 contosointernalvnet.azure-api.net
10.1.0.5 contosointernalvnet.portal.azure-api.net
10.1.0.5 contosointernalvnet.developer.azure-api.net
10.1.0.5 contosointernalvnet.management.azure-api.net
10.1.0.5 contosointernalvnet.scm.azure-api.net

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

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

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

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

Зарегистрируйте этот адрес на DNS-серверах, используемых виртуальной сетью.
Общедоступный виртуальный IP-адрес Используется только для трафика уровня управления, направляемого в конечную точку управления через порт 3443. Может быть заблокирован для тега службы ApiManagement.

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

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

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

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

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

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

Пример

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

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

Принудительное туннелирование трафика в локальный брандмауэр с помощью 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 или других средств.

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

См. также: