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

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

Подробности сценария

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

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

Диапазоны IP-адресов виртуальная сеть Azure

В виртуальных сетях Azure рекомендуется использовать блоки адресов, определенные RFC 1918. Эти блоки адресов предназначены для частных сетей общего назначения и являются неизменяемыми в общедоступном Интернете.

Вы можете использовать другие диапазоны, но прежде чем использовать эти диапазоны в виртуальной сети, ознакомьтесь с документацией центра назначения номеров Интернета (IANA), чтобы понять потенциальные последствия для вашей среды. Можно использовать следующие диапазоны:

• Общее адресное пространство, определенное RFC 6598 для преобразования сетевых адресов уровня оператора (NAT), которое рассматривается как частное адресное пространство в Azure виртуальная сеть. Блок адресов — 100.64.0.0/10.
• Общедоступные, интернет-маршрутизируемые IP-адреса, которыми не владеет ваша организация. Эта практика не рекомендуется, так как ресурсы в виртуальной сети не могут получить доступ к конечным точкам Интернета, предоставляемым через общедоступные IP-адреса.
• Блоки адресов специального назначения, определенные IANA, например 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24 и 233.252.0.0/24.

В виртуальных сетях Azure нельзя использовать следующие диапазоны IP-адресов:

• 224.0.0.0/4 (многоадресная рассылка)
• 255.255.255.255/32 (широковещательный адрес)
• 127.0.0.0/8 (петлевой адрес);
• 169.254.0.0/16 (локальный адрес канала);
• 168.63.129.16/32 (внутренний DNS)

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

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

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

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

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

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

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

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

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

RFC 1918 создает блоки IP-адресов из 32-разрядного адресного пространства IPv4 и делает их неизменяемыми в общедоступном Интернете, чтобы можно было повторно использовать их в нескольких частных сетях для внутренней связи. Этот метод основан на том же принципе, который применяется к частному адресному пространству. Один или несколько диапазонов адресов вырезаны из всего частного адресного пространства, используемого вашей организацией, и объявлены неизменяемыми в корпоративной сети вашей организации. Диапазоны адресов повторно используются в нескольких целевых зонах. В результате каждая целевая зона:

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

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

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

Каждая целевая зона приложения содержит две одноранговые виртуальные сети. Одна виртуальная сеть имеет маршрутизируемые IP-адреса и компоненты внешнего интерфейса. Другая виртуальная сеть имеет неизменяемые IP-адреса и узлы внутренних компонентов. Маршрутизируемая целевая зона говорила одноранговые узлы с региональным центром. Неизменяемые целевые зоны пиринговые узлы с routable целевой зоной. Пиринг между виртуальными сетями не является нетрансляционным, поэтому неизменяемые префиксы не видны региональному концентратору или остальной части корпоративной сети. Маршрутизируемые виртуальные сети не могут использовать неизменяемые диапазоны адресов. Некоторые организации фрагментировали адресное пространство, которое уже назначено маршрутизируемым сетям. Это может быть сложно определить неиспользуемые большие блоки адресов и объявить их неизменяемыми. В этом случае рассмотрите неиспользуемые адреса, которые не включены в адресное пространство RFC 1918. На предыдущей схеме представлен пример адресов NAT уровня оператора, таких как RFC 6598, в неизменяемых периферийных виртуальных сетях.

Миграция целевой зоны одной виртуальной сети

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

Следующие приложения предоставляются с помощью контроллеров доставки приложений уровня 7.

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

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

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

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

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

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

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

Когда службы инициируют подключения в неизменяемых периферийных виртуальных сетях, необходимо реализовать исходный NAT (SNAT) для подключений за routable IP-адрес. Чтобы реализовать SNAT, разверните устройство с поддержкой NAT в виртуальной сети с возможностью routable. Каждая целевая зона выполняет собственный выделенный NVA NAT. Существует два варианта реализации SNAT в целевой зоне: Брандмауэр Azure или сторонних NVAs. В обоих случаях все подсети в неизменяемой периферии должны быть связаны с пользовательской таблицей маршрутов. Как показано на следующей схеме, таблица маршрутов перенаправит трафик в места назначения за пределами целевой зоны на устройство SNAT. Шлюз NAT Azure не поддерживает SNAT для трафика, предназначенного для частного IP-адреса, например пространства RFC 1918.

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

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

Брандмауэр Azure.

• Обеспечивает высокий уровень доступности.
• Обеспечивает собственную масштабируемость и три разных номера SKU. SNAT не является ресурсоемкой задачей, поэтому сначала рассмотрим базовый номер SKU. Для целевых зон, требующих больших объемов исходящего трафика из неизменяемого адресного пространства, используйте стандартный номер SKU.
• Выполняет SNAT для трафика за частными IP-адресами любого из его экземпляров. Каждый экземпляр может использовать все непривилегированные порты.

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

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

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

На следующей схеме показан макет целевой зоны для реализации SNAT в Виртуальная глобальная сеть-центральной и периферийной сети с помощью Брандмауэр Azure.

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

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

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

Реализация SNAT через сторонние NVAs

Сторонние виртуальные сети с NAT доступны в Azure Marketplace. Они предоставляют:

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

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

• Для обеспечения высокого уровня доступности разверните кластеры по крайней мере с двумя сетевыми виртуальными машинами. Используйте подсистему балансировки нагрузки Azure для распространения входящих подключений из неизменяемой виртуальной сети между виртуальными сетями. Требуется правило балансировки нагрузки портов высокой доступности, так как кластер реализует SNAT во всех подключениях, которые покидают целевую зону. Azure Load Balancer (цен. категория поддерживает правила балансировки нагрузки портов высокой доступности.
• Стек AZURE SDN поддерживает единые и двойные виртуальные виртуальные машины. NVAs с одним рукой предпочтительнее, так как они сокращают потребление адресного пространства в routable виртуальных сетях.

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

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

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

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

Для обоих сторонних макетов NVA необходимо развернуть несколько экземпляров за подсистемой балансировки нагрузки Azure, чтобы обеспечить высокий уровень доступности. Требуется SKU Azure Load Balancer уровня "Стандартный".

Метод 2: службы Приватный канал Azure

Приватный канал предоставляет доступ к приложениям, развернутыми в виртуальной сети, которая не подключена к виртуальной сети. На стороне сервера или в виртуальной сети развернута служба Приватный канал и связана с конечной точкой приложения, которая предоставляется на интерфейсном IP-адресе внутренней подсистемы балансировки нагрузки SKU уровня "Стандартный Azure". В клиентской виртуальной сети развернут ресурс частной конечной точки и связан со службой Приватный канал. Частная конечная точка предоставляет конечную точку приложения в виртуальных сетях. Приватный канал предоставляет логику туннелирования и NAT для маршрутизации трафика между стороной клиента и стороной сервера. Дополнительные сведения см. в статье Что такое Приватный канал Azure.

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

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

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

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

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

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

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

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

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

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

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

Используйте одну частную конечную точку или службу Приватный канал для предоставления решения прокси-сервера или NAT, развернутого в маршрутизируемой сети. Правила перевода портов и адреса определяются на NVAs. Эти правила позволяют использовать одну частную конечную точку в изолированной виртуальной сети для доступа к нескольким зависимостям в маршрутизируемой сети.

Соавторы

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

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

• Федерико Геррини | Технический руководитель EMEA
• Хуш Кавирадж | Архитектор облачных решений
• Джек Tracey | Старший архитектор облачных решений

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

• Джоди Мартис | Технический писатель

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

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

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

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

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