Руководство по использованию Azure Private Link в мультитенантном решении

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

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

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

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

Выбор службы

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

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

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

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

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

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

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

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

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

Когда трафик поступает в мультитенантное решение, он уже преобразован. Это означает, что трафик, кажется, исходит из диапазона IP-адресов виртуальной сети самой мультитенантной службы. Некоторые службы Private Link предоставляют метаданные для каждого сокета через компонент TCP Proxy Protocol версии 2. Эта функция позволяет компоненту рабочей нагрузки узнать, через какое подключение к частной конечной точке выполнен запрос, и, следовательно, определить клиент, отправляющий запрос. Он также предоставляет исходный IP-адрес из исходной сети. Однако доступность этих метаданных зависит от службы Azure, к которой вы подключаетесь.

Процесс подготовки

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

  • Создайте частную конечную точку в конечной виртуальной сети. Это действие должно выполняться пользователем или субъектом с необходимыми разрешениями.
  • Установите подключение к частной конечной точке. Для этого действия также требуются разрешения.
  • Утвердить подключение. Дополнительные сведения об утверждениях подключений в мультитенантном решении см. в разделе "Утверждения подключений".

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

Ограничения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Участники

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

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

  • John Downs | Ведущий инженер-программист, Azure шаблоны и практики
  • Arsen Владимирский | Главный инженер клиентов, FastTrack для Azure

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

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

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

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

  • Последнее обновление: