Поделиться через


Мультитенантность и Azure Private Link

Приватный канал Azure предоставляет частные IP-адреса для служб платформы Azure и для собственных приложений, размещенных на виртуальных машинах Azure. Вы можете использовать Private Link, чтобы включить частное подключение из Azure-сред арендаторов. Клиенты также могут использовать приватный канал для доступа к решению из локальных сред, когда они подключены через шлюзы виртуальной частной сети (VPN-шлюз) или ExpressRoute.

Приватный канал Azure используется многими крупными поставщиками SaaS, включая Snowflake, Confluent Cloudи MongoDB Atlas.

В этой статье мы рассмотрим, как настроить приватный канал для мультитенантного решения, размещенного в Azure.

Основные рекомендации

Перекрывающиеся пространства IP-адресов

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

Разные клиенты часто используют одинаковые или перекрывающиеся частные IP-адреса. Ваше мультитенантное решение, например, может использовать пространство IP-адресов 10.1.0.0/16. Предположим, арендатор A использует собственную локальную сеть с таким же пространством IP-адресов, и, что совпадение, арендатор B также использует то же пространство IP-адресов. Вы не можете напрямую подключать или объединять сети, так как диапазоны IP-адресов перекрываются.

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

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

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

Выбор службы

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

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

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

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

Ограничения

Тщательно рассмотрим количество частных конечных точек, которые можно создать на основе архитектуры решения. Если вы используете платформу приложений в качестве службы (PaaS), важно учитывать максимальное количество частных конечных точек, которые может поддерживать один ресурс. Если вы запускаете виртуальные машины, вы можете подключить экземпляр службы Private Link к стандартному балансировщику нагрузки (SLB). В этой конфигурации обычно можно подключить большее количество частных конечных точек, но ограничения по-прежнему применяются. Эти ограничения могут определить, сколько клиентов можно подключить к ресурсам с помощью приватного канала. Просмотрите ограничения подписки и службы Azure, квоты и ограничения, чтобы понять ограничения на количество конечных точек и подключений.

Кроме того, для некоторых служб требуется специальная конфигурация сети для использования приватного канала. Например, если вы используете Private Link (приватное соединение) с Azure Application Gateway (шлюзом приложений Azure), необходимо подготовить выделенную подсетьв дополнение к стандартной подсети для ресурса шлюза приложений.

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

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

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

Многие службы Azure PaaS поддерживают приватный канал для входящего подключения, даже в разных подписках Azure и клиентах Microsoft Entra. Вы можете использовать возможности Private Link этой службы для обеспечения доступа к вашей конечной точке.

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

Например, предположим, что вы создаете приложение с доступом к Интернету, которое выполняется в масштабируемом наборе виртуальных машин. Вы используете Azure Front Door, включая брандмауэр веб-приложения (WAF), для ускорения безопасности и трафика, и вы настроить Front Door для отправки трафика через частную конечную точку в серверную службу (источник). Клиент A подключается к решению с помощью общедоступной конечной точки, а клиент B подключается с помощью частной конечной точки. Поскольку Front Door не поддерживает Private Link для входящих подключений, трафик клиента B обходит ваш Front Door и его WAF.

на диаграмме показаны запросы, поступающие через Azure Front Door, а также через частную конечную точку, которая обходит Front Door.

Модели изоляции

Private Link предназначен для поддержки сценариев, когда один уровень приложений может использоваться несколькими отдельными клиентами, например, вашими арендаторами. При рассмотрении изоляции приватного канала основной проблемой является количество ресурсов, которые должны быть развернуты для поддержки ваших требований. Модели изоляции клиента, которые можно использовать для приватного канала, зависят от используемой службы.

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

Рассмотрение Общая служба приватного канала и общая подсистема балансировки нагрузки Выделенная служба приватного канала и выделенная подсистема балансировки нагрузки Выделенная служба приватного канала и общая подсистема балансировки нагрузки
сложности развертывания Низкий Средне-высокий, в зависимости от количества арендаторов Средне-высокий уровень в зависимости от количества арендаторов
Операционная сложность Низкий уровень Средний уровень в зависимости от количества ресурсов Средний уровень в зависимости от количества ресурсов
Ограничения, которые следует учитывать Количество частных конечных точек в той же службе Private Link Количество служб Private Link на подписки Количество служб Приватного канала для стандартной подсистемы балансировки нагрузки
пример сценария Крупное мультитенантное решение с общим уровнем приложений Отдельные метки развертывания для каждого клиента Общая платформа приложений в одном экземпляре с большим количеством арендаторов

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

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

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

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

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

Более распространено развертывание нескольких общих служб Private Link. Этот подход позволяет расширить количество частных конечных точек, которые ваше решение может поддерживать в одной общей подсистеме балансировки нагрузки.

Модели изоляции для служб PaaS Azure с частными конечными точками

При развертывании служб платформы Azure в качестве службы (PaaS) и если требуется разрешить арендаторам доступ к этим службам с частными конечными точками, тогда учтите возможности и ограничения конкретной службы. Кроме того, рассмотрите, выделены ли ресурсы уровня приложений определенному клиенту или если они совместно используются между клиентами.

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

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

Private Link имеет несколько функций, которые полезны в мультитенантной среде. Однако определенные функции, доступные для вас, зависят от используемой службы. Базовая служба Приватного канала Azure для виртуальных машин и подсистем балансировки нагрузки поддерживает все функции, описанные ниже. Другие службы с поддержкой приватного канала могут предоставлять только подмножество этих функций.

Псевдонимы служб

Когда клиент настраивает доступ к службе с помощью приватного канала, они должны иметь возможность идентифицировать службу, чтобы Azure могла установить подключение.

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

Видимость службы

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

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

Утверждения подключения

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

Сервис Private Link поддерживает несколько типов потоков утверждения, в том числе:

  • утверждение вручную, где ваша команда явно утверждает каждое подключение. Этот подход является жизнеспособным, если у вас есть только несколько арендаторов, использующих службу через Private Link.
  • утверждение на основе API, где служба приватного канала обрабатывает подключение как требование ручного утверждения, а приложение использует обновление API подключения частной конечной точки, Azure CLI или Azure PowerShell для утверждения подключения. Этот подход может оказаться полезным, если у вас есть список клиентов, которым разрешено использовать частные конечные точки.
  • автоматическое утверждение, где сама служба Private Link ведет список идентификаторов подписок, которые должны иметь автоматически утвержденные подключения.

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

Протокол прокси версии 2

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

Приватный канал позволяет получить доступ к исходному IP-адресу клиента в виртуальной сети клиента. Эта функция использует протокол TCP-прокси версии 2.

Например, предположим, что администраторы клиентов должны добавлять ограничения доступа на основе IP-адресов, например узел 10.0.0.10 может получить доступ к службе, но узел 10.0.0.20 не может. При использовании прокси-протокола версии 2 клиенты могут настроить эти типы ограничений доступа в приложении. Однако код приложения должен проверить исходный IP-адрес клиента и применить ограничения.

  • объяснение и демонстрация службы Private Link Azure с точки зрения поставщика (SaaS ISV) и потребителя: видео, в котором рассматривается функция службы Private Link Azure, которая дает возможность мультитенантным поставщикам услуг, таким как независимые разработчики программного обеспечения, создавать продукты SaaS. Это решение позволяет потребителям получать доступ к службе поставщика с помощью частных IP-адресов из собственных виртуальных сетей Azure потребителя.
  • протокол TCP-прокси версии 2 со службой приватного канала Azure— глубокое погружение: видео, представляющее собой подробный обзор протокола TCP-прокси версии 2, который является расширенной функцией службы приватного канала Azure. Это полезно в мультитенантных и сценариях SaaS. В видео показано, как включить протокол прокси версии 2 в службе Приватного канала Azure. В нем также показано, как настроить службу NGINX для чтения исходного частного IP-адреса исходного клиента, а не IP-адреса NAT для доступа к службе через частную конечную точку.
  • Использование NGINX Plus для декодирования TLV протокола прокси-сервера linkIdentifier из службы Azure Private Link: видео, которое показывает, как использовать NGINX Plus для получения TLV из протокола TCP-прокси версии 2 из службы Azure Private Link. В видео показано, как извлечь и декодировать числовое значение linkIdentifier, также называемое LINKID, подключения к частной конечной точке. Это решение полезно для мультитенантных поставщиков, которым необходимо определить конкретного арендатора потребителя, с которого было установлено соединение.
  • шаблон частного подключения SaaS. Пример решения, демонстрирующего один подход к автоматизации утверждения подключений к частной конечной точке с помощью управляемых приложений Azure.

Участники

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

Основные авторы:

Другой участник:

  • Sumeet Mittal | Главный менеджер по продукту, Azure Private Link

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Дальнейшие действия

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