Предотвращение исчерпания IPv4 в Azure

Корпоративные сети обычно используют адресные пространства из частных диапазонов адресов IPv4, определенных запросом комментариев (RFC) 1918, например 10.0.0.0/8, 172.16.0.0/12и 192.168.0.0/16. В локальных средах эти диапазоны предоставляют достаточно IP-адресов для удовлетворения требований даже крупнейших сетей. В результате многие организации разрабатывают методики управления адресами, которые определяют приоритеты простых конфигураций маршрутизации и гибких процессов для выделения IP-адресов. Они часто не определяют приоритеты эффективного использования адресного пространства IPv4.

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

Замечание

Рекомендуется использовать блоки адресов, определенные RFC 1918 в виртуальных сетях Azure. Дополнительные сведения см. в разделе "Диапазоны адресов" для виртуальных сетей.

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

• Метод 1. Используйте пиринг подсети IPv4 , чтобы исключить одну или несколько подсетей из пиринга между периферийной виртуальной сетью целевой зоны и виртуальной сетью концентратора. Вы можете назначить одинаковые не маршрутизируемые диапазоны IP-адресов подсетям, исключенным из отношений пиринга во всех посадочных зонах. Эти диапазоны IP-адресов не могут перекрываться с другими диапазонами маршрутизируемых IP-адресов.

• Метод 2. Развертывание приложений в изолированных виртуальных сетях, которые не подключены к виртуальным сетям целевых зон. Свяжите конечные точки с службами Приватного канала Azure. В спицевых виртуальных сетях целевых зон создайте частные конечные точки, связанные со службами Private Link. Изолированные виртуальные сети могут использовать любое адресное пространство IPv4, даже если оно перекрывается с маршрутизируемым адресным пространством корпоративной сети.

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

Выравнивание целевой зоны Azure

Рекомендации, приведенные в этой статье, относятся к топологиям сети, основанным на архитектуре целевой зоны Azure:

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

• Центральные и периферийные сети в разных регионах подключаются через пиринг глобальной виртуальной сети.

• Центральные и периферийные сети подключаются к локальным сайтам через каналы Azure ExpressRoute или виртуальные сети типа "сеть — сеть".

В архитектуре зоны приземления Azure каждое приложение выполняется в собственной спицевой виртуальной сети. Каждая периферийная виртуальная сеть использует уникальное адресное пространство IPv4 в корпоративной сети.

Все ресурсы в зоне приземления могут подключаться следующим образом:

• Использование IP-адреса для запуска подключений к любым другим ресурсам в корпоративной сети

• Получать прямые подключения из всей корпоративной сети через IP-адрес.

Однако ресурсы не всегда нуждаются в доступности из всей корпоративной сети. Например, в целевой зоне, содержащей веб-приложение с тремя уровнями, например интерфейс HTTP, бизнес-логику и уровень данных, доступ к интерфейсу HTTP должен быть доступен за пределами целевой зоны. Другие слои должны подключаться друг к другу и интерфейсной части, но им не нужно принимать подключения от клиентов. В этом примере можно свести к минимуму потребление адресов IPv4, назначив следующие компоненты каждой целевой зоне:

• Адресное пространство, уникальное для всей корпоративной сети. Только ресурсы, которые должны быть доступны из-за пределов целевой зоны, используют это адресное пространство. Эта статья называет это адресное пространство маршрутизируемым адресным пространством зоны посадки.

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

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

Метод 1. Нераутируемые подсети в спицевых виртуальных сетях

Пиринг подсети IPv4 можно использовать для ограничения пирингового взаимодействия между двумя виртуальными сетями к определённым подсетям. Только подсети, включенные в конфигурацию пиринга, могут направлять трафик друг другу. Подсети, исключенные из конфигурации пиринга, остаются невидимыми и недоступными из одноранговой виртуальной сети.

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

На следующей схеме представлены следующие компоненты:

• Диапазон 10.57.0.0/16 служит нераутируемым адресным пространством.

• Виртуальная сеть концентратора и каждая спицевая виртуальная сеть посадочной зоны используют уникальные диапазоны маршрутизируемых IP-адресов (10.0.0.0/24, 10.1.0.0/24, и 10.2.0.0/24).

• Каждая целевая зона периферийных виртуальных сетей также содержит одну или несколько нераутируемых подсетей в нераутируемом диапазоне 10.57.0.0/16. Адресное пространство виртуальной сети Azure может включать несколько диапазонов IP-адресов.

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

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

Скачайте файл PowerPoint этой архитектуры.

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

Развертывание приложений в зонах размещения

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

• Приложения, предоставляемые через контроллеры доставки приложений уровня 7: Эти контроллеры доставки приложений включают шлюз приложений Azure или виртуальные сетевые устройства, отличные от Майкрософт (NVA). Доступ к конечной точке контроллера доставки приложений должен быть доступен только от клиентов за пределами целевой зоны. Таким образом, контроллер доставки приложений является единственным интерфейсным компонентом, который должен находиться в маршрутизируемой подсети.

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

На следующей схеме показаны следующие шаблоны:

• Целевая зона А размещает трехуровневое веб-приложение, предоставляемое через контроллер доставки приложений, который является единственным компонентом в маршрутизируемой подсети.

• Целевая зона B размещает трехуровневое приложение, предоставляемое через внутреннюю подсистему балансировки нагрузки Azure.

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

Скачайте файл PowerPoint этой архитектуры.

Исходящие зависимости

Серверные компоненты приложения не нуждаются в получении входящих подключений из корпоративной сети. Но может потребоваться инициировать подключения к конечным точкам за пределами целевой зоны. Типичные примеры включают разрешение системы доменных имен (DNS), взаимодействие с контроллерами домена доменных служб Active Directory (AD DS) и доступ к приложениям в других целевых зонах или общих службах, таких как управление журналами или системы резервного копирования.

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

Эта схема содержит концентратор и два выделенных сегмента зон приземления в отдельных зонах приземления. Хаб содержит три маршрутизируемых подсети. Зона посадки A содержит контроллер доставки приложений и NAT в отдельных маршрутизируемых подсетях. Он также содержит HTTP-интерфейс, бизнес-логику и уровень данных в отдельных немаршрутизируемых подсетях. Контроллер доставки приложений указывает на три компонента в подсети внешнего интерфейса HTTP. Подключение от компонента проходит через брандмауэр в концентраторе через SNAT. Посадочная зона B содержит фронт-энд TCP/IP и NAT в отдельных маршрутизируемых подсетях. Он также включает бизнес-логику и уровень данных в отдельных нерутабельных подсетях. Подключение компонента в подсети бизнес-логики осуществляется через SNAT через брандмауэр в хабе. Концентратор подключен к каждой спице зоны приземления.

Скачайте файл PowerPoint этой архитектуры.

Немаршрутизируемые подсети должны использовать настраиваемую таблицу маршрутизации, которая перенаправит весь трафик, предназначенный за пределами зоны загрузки, на NVA с возможностью NAT. На предыдущей схеме диапазон 10.57.0.0/16 является не маршрутизируемым, а другие диапазоны в пределах 10.0.0.0/8 маршрутизируются. Настраиваемая таблица маршрутов для каждой нерутинговой подсети должна содержать следующий определяемый пользователем маршрут (UDR).

Место назначения	Тип следующего прыжка	IP-адрес следующего узла
10.0.0.0/8	VirtualNetworkAppliance	<IP-адрес NVA, поддерживающий NAT>

Таблица системных маршрутов виртуальной сети уже включает системный маршрут для назначений в нестатическом диапазоне 10.57.0.0/16. Вам не нужно определять маршруты, определяемые пользователем (UDR) для трафика в этом диапазоне.

Маршрутизируемые подсети, включая подсеть, в которую размещается NVA с поддержкой NAT, должны использовать настраиваемую таблицу маршрутов, которая перенаправит трафик за пределами целевой зоны, как правило, в виртуальные сети концентратора. Эти NVAs маршрутизовали трафик между периферийными узлами. Эти концентраторы NVAs не выполняют операции NAT. На предыдущей схеме таблица маршрутизации для каждой маршрутизируемой подсети должна содержать следующие пользовательские маршруты (UDR).

Место назначения	Тип следующего прыжка	IP-адрес следующего узла
10.0.0.0/8	VirtualNetworkAppliance	<IP-адрес маршрутизатора или брандмауэра концентратора>
10.0.0.0/24	VirtualNetworkAppliance	<IP-адрес маршрутизатора или брандмауэра концентратора>

Второй UDR с назначением 10.0.0.0/24 гарантирует, что подключения к ресурсам в виртуальной сети концентратора проходят через брандмауэр концентратора. Для некоторых приложений может потребоваться больше определяемых пользователем записей. Если виртуальные машины в целевой зоне нуждаются в доступе к Интернету через NVAs, которые обычно размещаются в концентраторе, необходимо также определить маршрут 0.0.0.0/0по умолчанию.

Замечание

Поддерживается связь клиентаto-AD с контроллером домена DS через NAT. Связь контроллера домена с контроллером домена через NAT не протестирована и не поддерживается. Дополнительные сведения см. в разделе "Границы поддержки" для Windows Server Active Directory по протоколу NAT. Рекомендуется развернуть контроллеры домена Windows Server Active Directory для маршрутизируемых подсетей.

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

Реализация SNAT с помощью Брандмауэр Azure

Если необходимо определить приоритеты низкой сложности и минимального управления, брандмауэр Azure предоставляет оптимальное решение для реализации SNAT для подключений, исходящих из подсетей, отличных отroutale. Брандмауэр Azure предоставляет следующие преимущества:

• Полностью управляемый жизненный цикл
• Встроенный высокий уровень доступности
• Автомасштабирование на основе объема трафика

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

• Разверните брандмауэр Azure в собственной зарезервированной подсети с именем AzureFirewallSubnet, которая должна использовать маршрутизируемое адресное пространство.

• Некоторые номера SKU или конфигурации брандмауэра Azure могут потребовать второй зарезервированной подсети для управления брандмауэром. Для подсети управления не требуется маршрутизируемое адресное пространство.

• Брандмауэр Azure имеет три разных номера SKU. SNAT не является ресурсоемким, поэтому начните с базового варианта SKU. Для целевых зон, которые создают большие объемы исходящего трафика из подсетей, отличных отroutale, рассмотрите номер SKU уровня "Стандартный".

• Настройте брандмауэр Azure с параметром «Выполнить SNAT» установленным на Всегда. Каждый экземпляр использует свои непривилегированные порты для SNAT. Чтобы настроить брандмауэр Azure для реализации SNAT во всех полученных подключениях, выполните действия по настройке SNAT.

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

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

Эта схема содержит концентратор и два выделенных сегмента зон приземления в отдельных зонах приземления. Хаб содержит три маршрутизируемых подсети. Зона размещения A содержит контроллер доставки приложений и брандмауэр в отдельных маршрутизируемых подсетях. Он также содержит HTTP-интерфейс, бизнес-логику и уровень данных в отдельных немаршрутизируемых подсетях. Контроллер доставки приложений указывает на три компонента в подсети внешнего интерфейса HTTP. Подключение от компонента проходит через брандмауэр в концентраторе через SNAT. Зона приземления B содержит фронтенд TCP/IP и брандмауэр в отдельных маршрутизируемых подсетях. Он также включает бизнес-логику и уровень данных в отдельных нерутабельных подсетях. Подключение компонента в подсети бизнес-логики осуществляется через SNAT через брандмауэр в хабе. Концентратор подключен к каждой спице зоны приземления.

Скачайте файл PowerPoint этой архитектуры.

Реализация SNAT с помощью NVAs, отличных от Майкрософт

Вы можете найти виртуальные сети, отличные от Майкрософт, имеющие возможности NAT в Azure Marketplace. Рассмотрите возможность использования NVA, отличного от Майкрософт, если требования превышают то, что может поддерживать брандмауэр Azure. Например, может потребоваться следующее:

• Детальный контроль над пулом NAT

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

• Детальный контроль над увеличением и уменьшением масштабирования

При использовании NVAs, отличных от Майкрософт, учитывайте следующие факторы:

• Разверните кластер, имеющий по крайней мере два NVA, чтобы обеспечить высокий уровень доступности.

• Используйте стандартный SKU балансировщик нагрузки Azure для распределения подключений из нероутируемой виртуальной сети к виртуальным сетевым устройствам. Все подключения должны использовать SNAT независимо от порта назначения, поэтому следует использовать правила балансировки нагрузки высокой доступности, также известные как правила балансировки нагрузки любого порта.

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

На следующей схеме показано, как реализовать SNAT в топологии сети концентратора и периферийной сети с помощью NVAs, отличных от Майкрософт.

Эта схема содержит концентратор и два выделенных сегмента зон приземления в отдельных зонах приземления. Хаб содержит три маршрутизируемых подсети. Целевая зона A содержит контроллер доставки приложений в маршрутизируемой подсети и два экземпляра NAT в маршрутизируемой подсети. Он также содержит HTTP-интерфейс, бизнес-логику и уровень данных в отдельных немаршрутизируемых подсетях. Контроллер доставки приложений указывает на три компонента в подсети внешнего интерфейса HTTP. Подключение от компонента проходит через экземпляр NAT, а затем брандмауэр в концентраторе через SNAT. Посадочная зона B содержит фронтенд TCP/IP в маршрутизируемой подсети и два экземпляра NAT в той же подсети. Он также включает бизнес-логику и уровень данных в отдельных нерутабельных подсетях. Подключение от компонента в подсети бизнес-логики проходит через экземпляр NAT, а затем через SNAT в брандмауэре центрального узла. Концентратор подключен к каждой спице зоны приземления.

Скачайте файл PowerPoint этой архитектуры.

Использование метода 1 с виртуальной глобальной сетью Azure

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

• Назначьте маршрутизируемое адресное пространство первой виртуальной сети и подключите его к концентратору виртуальной глобальной сети.

• Назначьте немаршрутизируемое адресное пространство второй виртуальной сети и подключите её к маршрутизируемой виртуальной сети.

На следующей схеме показана итоговая топология.

Эта схема содержит концентратор виртуальной глобальной сети и две целевые зоны. Целевая зона A содержит маршрутизируемую и немаршрутизируемую целевые зоны, которые подключены через пиринг виртуальной сети. Маршрутизируемый spoke содержит контроллер доставки приложений в маршрутизируемой подсети. Спицевое соединение, не поддерживающее маршрутизацию, содержит интерфейс HTTP, бизнес-логику и уровень данных в отдельных немаршрутизируемых подсетях. Контроллер доставки приложений подключается к трем компонентам в подсети внешнего интерфейса HTTP. Посадочная зона B содержит маршрутизируемый споук зоны посадки и немаршрутизируемый споук зоны посадки, которые подключены через пиринг виртуальной сети. Маршрутизируемая спица содержит фронтенд TCP/IP в маршрутизируемой подсети. Немаршрутизируемая спица содержит бизнес-логику и слой данных в отдельных немаршрутизируемых подсетях. Концентратор виртуальной глобальной сети подключен к каждой маршрутизируемой целевой зоне.

Скачайте файл PowerPoint этой архитектуры.

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

С точки зрения маршрутизации нет разницы между следующими конфигурациями:

• Маршрутизируемые и немаршрутизируемые подсети в одной виртуальной сети (описаны в предыдущем разделе для традиционных сетей типа звезда и периферия)

• Прямые пиринговые виртуальные сети (описанные в этом разделе для центральной и периферийной сети на основе виртуальной глобальной сети)

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

• Компоненты приложения можно распределять между маршрутизируемыми и неруталными подсетями, используя те же рекомендации, которые описаны в предыдущих разделах.

• Вы можете управлять зависимостями при исходящих соединениях с помощью NVAs с поддержкой NAT в маршрутизируемых подсетях.

Метод 2: Службы Private Link

Приватный канал позволяет клиентам в виртуальной сети использовать приложения в другой виртуальной сети без настройки подключения уровня 3, например пиринг между виртуальными сетями или VPN виртуальной сети. Две виртуальные сети могут использовать перекрывающиеся диапазоны IP-адресов. Azure прозрачно обрабатывает необходимую логику NAT. Этот метод применяется как к традиционным концентраторам и периферийным сетям, так и к сетям на основе виртуальной глобальной сети.

Чтобы опубликовать приложение через Private Link, сделайте следующее:

1. Добавьте конечные точки приложения в внутренний пул внутренней подсистемы балансировки нагрузки Azure с номером SKU уровня "Стандартный".

2. Свяжите внешний IP-адрес подсистемы балансировки нагрузки с ресурсом службы приватного канала.

3. На стороне клиента создайте ресурс частной конечной точки и свяжите его со службой приватного канала на стороне сервера.

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

Для устранения нехватки IPv4 можно использовать приватный канал, назначив две виртуальные сети каждой целевой зоне:

• Виртуальная сеть с маршрутизируемым адресным пространством, подключенная к корпоративной сети

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

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

На следующей схеме показаны две зоны посадки, использующие большое адресное пространство 10.0.0.0/16, которое перекрывается с адресным пространством корпоративной сети. Каждая целевая зона назначает это пространство изолированной виртуальной сети. Приложения развертываются в изолированных периферийных виртуальных сетях и связаны со службами Private Link.

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

Скачайте файл PowerPoint этой архитектуры.

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

Эта диаграмма содержит концентратор и две зоны посадки. Хаб содержит три маршрутизируемых подсети. Каждая зона посадки содержит шлейф маршрутизируемой зоны и шлейф изолированной зоны. Маршрутизируемый узел содержит подсеть частной конечной точки и маршрутизируемую подсеть. Изолированная спица содержит подсеть приложения и подсеть службы Private Link, которая подключается к частной конечной точке в маршрутизируемой спице. Подсеть приложения подключается к подсети службы частного соединения. Концентратор подключается к каждой зоне приземления доступного сегмента через пиринг виртуальных сетей. Существует два потока. Один поток переходит из маршрутизируемой подсети в целевой зоне A, в брандмауэр в маршрутизируемой подсети в концентраторе, к подсети частной конечной точки в целевой зоне B, к подсети службы приватного канала в целевой зоне B и, наконец, к подсети приложения в целевой зоне B. Второй поток переходит из маршрутизируемой подсети H3 в концентратор, в подсеть частной конечной точки в целевой зоне А, в подсеть службы приватного канала в целевой зоне A и, наконец, к подсети приложения в целевой зоне A.

Скачайте файл PowerPoint этой архитектуры.

Использование службы Приватный канал для исходящих зависимостей

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

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

Эта диаграмма содержит концентратор и две зоны посадки. Концентратор содержит две маршрутизируемые подсети, подсеть общих служб и подсеть службы Private Link. Подсеть общей службы подключается к подсети службы Private Link. Каждая зона посадки содержит шлейф маршрутизируемой зоны и шлейф изолированной зоны. Маршрутизируемый узел содержит подсеть частной конечной точки и маршрутизируемую подсеть. Изолированная спица в посадочной зоне A содержит подсеть приложения, подсеть службы Private Link, которая подключается к частной конечной точке в маршрутизируемой спице, и другую подсеть частной конечной точки. Подсеть приложения подключается к каждой частной конечной точке в подсети частной конечной точки. Одна частная конечная точка (помеченная 1) подключается к подсети службы приватного канала в концентраторе. Другая частная конечная точка (помеченная 2) подключается к подсети службы Private Link в целевой зоне высадки B. Изолированный сегмент в целевой зоне высадки B содержит подсеть службы Private Link и подсеть приложения. Каждая подсеть приложения подключается к подсети службы Private Link в той же целевой зоне. Концентратор подключается к каждому маршрутизируемому спицевому подключению в посадочной зоне.

Скачайте файл PowerPoint этой архитектуры.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

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

• Федерико Геррини | Старший архитектор облачных решений, EMEA Technical Lead Azure Networking
• Хуш Кавирадж | Архитектор облачных решений
• Джек Tracey | Старший архитектор облачных решений

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

Дальнейшие шаги

• Настройка пиринга подсети
• Развертывание Брандмауэр Azure в виртуальной сети
• Настройка SNAT в Брандмауэр Azure
• Поддерживаемые IP-адреса в Azure виртуальная сеть
• Приватный канал
• Azure Load Balancer
• Пиринг виртуальной сети
• Топология сети концентратора и периферийной сети

Связанные ресурсы

• Проектирование архитектуры сети
• Архитектурные подходы к организации сети в мультитенантных решениях