Планирование IP-адресов для виртуальных сетей Azure

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

Описание этой статьи

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

Кто нуждается в этой статье

Ознакомьтесь с этой статьей, если вы:

• Развертывает виртуальную сеть в Azure и необходимо решить, какие диапазоны IP-адресов следует использовать.
• Подключаете сети Azure к локальным средам и хотите предотвратить конфликты адресов.
• Необходимо выбрать между общедоступными IP-адресами уровня "Стандартный", префиксами общедоступных IP-адресов или собственными диапазонами IP-адресов (BYOIP).
• Хотите понять, когда для рабочих нагрузок подходит двойной стек IPv6.
• Вы управляете крупной или растущей ИТ-средой и нуждаетесь в стратегии отслеживания распределения IP-адресов в масштабах всей инфраструктуры.

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

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

Фокус на нескольких облаках: Создайте глобальный план адресов, который не сталкивается с существующими диапазонами AWS VPC или Google Cloud CIDR, который является обязательным перед подключением к облакам через VPN или межсоединение.

Azure службы и функции

Следующие службы и функции поддерживают планирование IP-адресов в Azure:

Служба или компонент	Что он предоставляет	Когда его использовать
Частные адресные пространства RFC 1918	Три зарезервированных диапазона для частного использования: 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16. Azure виртуальные сети используют эти диапазоны для внутреннего взаимодействия.	Всегда: для каждой виртуальной сети требуется как минимум один частный диапазон адресов из этих пространств.
Общее адресное пространство RFC 6598	100.64.0.0/10: рассматривается как частное адресное пространство в Azure. Первоначально разработано для сред NAT (CGNAT) уровня оператора.	Если ваша организация уже использует диапазоны RFC 6598 в локальной среде или когда пространство RFC 1918 исчерпано.
Стандартный общедоступный IP-адрес	Статический общедоступный IP-адрес с резервированием по зонам, назначенный одному ресурсу. Безопасность по умолчанию с закрытым входящим трафиком.	Если ресурсу требуется уникальная общедоступная конечная точка, например подсистема балансировки нагрузки, VPN-шлюз или общедоступная виртуальная машина.
Префикс общедоступного IP-адреса	Зарезервированный смежный блок общедоступных IP-адресов из определенного Azure региона.	Если вам нужны предсказуемые диапазоны IP-адресов для шлюза NAT, Масштабируемые наборы виртуальных машин или для внесения внешних адресов в список разрешённых.
BYOIP / Настраиваемый префикс IP	Подключение собственных диапазонов общедоступных IP-адресов к Azure. Использует трехэтапный процесс: подтверждение права собственности, выделение префикса, а затем ввод его в эксплуатацию.	Если необходимо сохранить существующую репутацию IP-адресов, сохранить внешние утвержденные записи списка или перенести рабочие нагрузки без изменения общедоступных IP-адресов.
AZURE VIRTUAL NETWORK MANAGER IPAM	Встроенная функция управления IP-адресами в Диспетчер виртуальных сетей Azure. Общедоступная версия в большинстве регионов. Обеспечивает централизованный обзор и отслеживание распределения по всем подпискам.	При управлении множеством виртуальных сетей в нескольких подписках, если вам требуется автоматическое отслеживание использования адресов. См. централизованное управление сетями.

Как выбрать

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

Лучшие практики планирования IP-адресов

Практика	Почему	Example
Выделите крупный родительский блок CIDR (/16) и разбейте его на подсети	Предотвращает исчерпание адресов по мере роста рабочих нагрузок. Проще суммировать маршруты.	Назначьте производственной среде сеть 10.1.0.0/16, затем выделите /24-подсети для каждого уровня нагрузки.
Оставьте не менее 30% запаса в каждой подсети	Службы масштабирования, такие как Масштабируемые наборы виртуальных машин, AKS и App Service Environments, быстро расходуют IP-адреса при горизонтальном масштабировании.	Подсеть /24 предоставляет 251 доступных IP-адресов. Если в базовом развертывании используется 100, у вас есть запас для трехкратного увеличения.
Использование смежных блоков CIDR для каждой среды	Упрощает сводку маршрутов и правила брандмауэра. Единый сводный маршрут представляет всю среду.	Продукционная среда: 10.1.0.0/16. Промежуточное выполнение: 10.2.0.0/16. Разработка: 10.3.0.0/16.
Избегайте диапазонов, зарезервированных платформой Azure, и запрещённых диапазонов	Использование зарезервированных диапазонов приводит к сбоям маршрутизации и ошибкам развертывания.	Не назначайте 169.254.0.0/16, 168.63.129.16/32, 224.0.0.0/4, 127.0.0.0/8 или 255.255.255.255.255.255/32.
Документируйте распределения в Azure IPAM или в электронной таблице	Предотвращает перекрытие при расширении среды. Централизованная видимость для сетевых команд.	Используйте Диспетчер виртуальных сетей Azure IPAM для автоматического отслеживания или обслуживания общей электронной таблицы для небольших сред.

Типы общедоступных IP-адресов

Type	Что это такое	Когда его использовать
Стандартный общедоступный IP-адрес	Отдельный статический общедоступный IP-адрес. По умолчанию используется избыточность между зонами в регионах, поддерживающих зоны доступности. По умолчанию используется безопасная конфигурация: весь входящий трафик блокируется, пока правило NSG или балансировщика нагрузки не разрешит его.	Общедоступные подсистемы балансировки нагрузки, VPN-шлюзы, Бастион Azure, шлюзы приложений или любой ресурс, которому требуется уникальная общедоступная конечная точка.
Префикс общедоступного IP-адреса	Зарезервированный смежный блок общедоступных IP-адресов из определенного региона. Гарантирует последовательные адреса.	Шлюз NAT (требует префикса для нескольких исходящих IP-адресов), масштабируемые наборы виртуальных машин или, когда внешним системам необходимо добавить предсказуемый диапазон IP-адресов в утверждённый список.
BYOIP / Настраиваемый префикс IP-адреса	Диапазоны общедоступных IP-адресов, принадлежащие клиенту, подключены к Azure через трехэтапный процесс: проверка, подготовка и ввод в эксплуатацию. Региональные префиксы вводятся в эксплуатацию примерно за 30 минут; глобальные префиксы — за 3–4 часа.	Сохранение репутации IP-адресов во время миграции в облако, сохранение записей во внешних списках разрешений или соблюдение нормативных требований к владению IP-адресами. IP-адреса, полученные из настраиваемого префикса IP-адресов, также могут использовать службу Azure DDoS Protection.

Note

Общедоступные IP-адреса SKU уровня "Базовый" были прекращены 30 сентября 2025 года. Существующие базовые IP-адреса продолжают функционировать, но не поддерживаются и не имеют соглашение об уровне обслуживания. Перейдите на SKU уровня Standard для всех новых развертываний.

Решение IPv6

Сценарий	Recommendation	Логическое обоснование
Рабочая нагрузка обслуживает только клиенты IPv4, не требуется нормативных требований IPv6.	Только IPv4	Простейшая конфигурация. Избегает затрат на управление двумя стеками. Большинство служб Azure поддерживают IPv4 в собственном коде.
Рабочая нагрузка должна служить клиентам IPv6 или нормативным требованиям, требующим поддержки IPv6	Двойной стек (IPv4 + IPv6)	Виртуальные сети Azure поддерживают подсети с двойным стеком. Разверните IPv6 вместе с IPv4 на одних и том же ресурсах.
Рабочая нагрузка нуждается в IPv6, но зависит от Брандмауэр Azure, Виртуальная глобальная сеть или сервера маршрутизации	Только IPv4 (с внешней терминацией IPv6)	Брандмауэр Azure, Виртуальная глобальная сеть и сервер маршрутизации в настоящее время не поддерживают IPv6. Завершайте IPv6 на внешнем балансировщике нагрузки или пограничном устройстве, прежде чем трафик поступит в эти службы. VPN-шлюз IPv6 доступен в предварительной версии.

Двойной стек IPv6 в Azure

Azure поддерживает развертывания с двойным стеком IPv6 в виртуальных сетях. При включении двойного стека каждая подсеть получает диапазон IPv4 и диапазон IPv6 /64. Ресурсы получают адреса от обоих семей и могут обмениваться данными по обоим протоколам одновременно.

IPv6 в Azure имеет определенные требования к размеру. Подсети IPv6 должны быть точно /64. Другая длина префикса не поддерживается. Адресное пространство IPv6, назначаемое виртуальной сети, должно быть достаточно большим для размещения подсетей /64 для каждой подсети, требующей подключения IPv6. Запланируйте выделение адресов IPv6 вместе с диапазонами IPv4 во время начальной разработки сети.

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

Service	Поддержка IPv6
Виртуальная сеть Azure	Двухстековые подсети с диапазонами IPv6 /64
Стандартный балансировщик нагрузки	Общедоступные и внутренние интерфейсы IPv6
VPN-шлюз	Конечные точки туннеля IPv6 (предварительная версия; требуется согласие)
Шлюз NAT	Исходящая трансляция IPv6 (только для SKU StandardV2; SKU Standard поддерживает только IPv4)
Общедоступный IP-адрес (номер SKU категории "Стандартный")	Общедоступные адреса IPv6
Масштабируемые группы виртуальных машин (Масштабируемые наборы виртуальных машин)	Сетевые интерфейсы IPv6
Пиринг виртуальных сетей	IPv6-трафик между пиринговыми виртуальными сетями
Группы сетевой безопасности	Правила IPv6 для фильтрации
DNS (Azure DNS)	Поддержка записей AAAA

Ключевые службы, не поддерживающие IPv6: Брандмауэр Azure (требуется подсеть только для IPv4), Виртуальная глобальная сеть (только IPv4) и сервер маршрутизации (только IPv4). VPN-шлюз поддерживает IPv6 в режиме двойного стека, но только в качестве предварительной версии (требуется согласие). Если архитектура зависит от Брандмауэр Azure, Виртуальная глобальная сеть или сервера маршрутов для проверки трафика или маршрутизации, создайте сеть таким образом, чтобы трафик IPv6 обрабатывался до достижения этих компонентов.

Подробные возможности IPv6, ограничения и действия по настройке см. в разделе IPv6 для Azure Virtual Network.

Зарезервированные адреса Azure

Azure резервирует пять IP-адресов в каждой подсети:

Зарезервированный адрес	Purpose
Первый адрес (.0)	Сетевой идентификатор
Второй адрес (.1)	Шлюз по умолчанию
Третий адрес (.2)	сопоставление Azure DNS
Четвертый адрес (.3)	сопоставление Azure DNS
Последний адрес (трансляция)	Адрес широковещательной трансляции

Учитывайте эти пять зарезервированных адресов во всех вычислениях размера подсети. Подсеть /24 предоставляет 256 общих адресов минус 5 зарезервированных, оставляя 251 доступных IP-адресов узлов. Наименьшая поддерживаемая подсеть IPv4 — /29 (8 адресов минус 5 зарезервировано = 3 доступных для использования). Самая большая поддерживаемая подсеть IPv4 — /2.

Tip

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

Рекомендации по проектированию

Фокус на проектировании планирования IP-адресов в режиме лифта и смены

• Зарезервируйте один большой блок CIDR (обычно /16) для лендинг-зоны и разбейте его на подсети для каждого перенесённого приложения, оставив около 20 % адресного пространства в резерве для роста.
• Выберите диапазоны, которые не перекрываются с локальными сетями, к которым вы подключаетесь через VPN-шлюз или ExpressRoute, чтобы маршрутизация работала без трансляции адресов.
• Учитывайте пять зарезервированных адресов Azure для каждой подсети и выделенных подсетей, необходимых службам платформы, например GatewaySubnet (/27) и AzureFirewallSubnet (/26).
• Там, где сети не образуют пиринговых соединений, можно целенаправленно повторно использовать частные диапазоны IPv4, чтобы экономить адресное пространство.

Модернизация фокуса на проектировании IP-планирования

• Выделите не перекрывающиеся диапазоны в основных регионах и регионах резервного копирования, чтобы активные и активные рабочие нагрузки могли использовать глобальный пиринг позже без повторной адресации.
• Зарезервируйте выделенную подсеть для Среда службы приложений размером /24 или /23 при масштабе, близком к максимальному. Для AKS с CNI Overlay размер подсети следует рассчитывать только для узлов, поскольку поды используют адреса из отдельного диапазона CIDR в overlay-сети, поэтому подсеть для узлов может быть значительно меньше, чем требуется при плоской схеме CNI.
• Зарезервируйте выделенную подсеть для частных конечных точек, чтобы внедрение PaaS не фрагментирует план адресов.
• Используйте функцию управления IP-адресами в Диспетчер виртуальных сетей Azure для отслеживания и автоматизации назначения адресов по мере масштабирования вашей среды.

Акцент на проектировании межоблачного планирования IP-адресов

• Сначала создайте глобальный план адресного пространства: зарезервируйте блоки CIDR в Azure, которые не пересекаются с существующими сетями VPC в AWS или сетями VPC в Google Cloud, что необходимо для маршрутизируемого VPN-подключения или interconnect-подключения.
• Задокументируйте диапазоны адресов каждого подключенного облака и ветви, чтобы можно было спланировать суммированные маршруты через Виртуальная глобальная сеть Azure.
• Резервируйте адресное пространство для транзитных компонентов, таких как подсети, используемые концентратором Виртуальная глобальная сеть и VPN-шлюзом, предусмотрев запас для масштабирования по мере добавления пограничных облачных узлов и филиалов.
• Если пересечения адресных пространств неизбежны, запланируйте трансляцию сетевых адресов (NAT) для затронутых VPN-подключений или изменение адресации рабочих нагрузок в ходе миграции, а не после неё.

Prerequisites

Перед планированием выделения IP-адресов:

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

Вопросы безопасности

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

• Запретить перекрытие адресов: Перекрывающиеся диапазоны IP-адресов между локальными сетями, Azure виртуальными сетями и одноранговыми виртуальными сетями вызывают сбои маршрутизации. Трафик может попасть не по назначению или быть отброшен без уведомления. Убедитесь, что каждый диапазон адресов уникален во всей сети.
• Избегайте запрещенных диапазонов: Azure резервирует следующие диапазоны для операций платформы. Никогда не используйте их в качестве адресного пространства виртуальной сети:
  • 169.254.0.0/16 (link-local)
  • 168.63.129.16/32 (внутренний DNS Azure)
  • 224.0.0.0/4 (многоадресная рассылка)
  • 127.0.0.0/8 (обратная петля)
  • 255.255.255.255/32 (трансляция)
• Документ и аудит: Сохраняйте текущую запись всех выделений IP-адресов. Незадокументированные диапазоны приводят к случайному пересечению при развертывании новых рабочих нагрузок. Используйте Диспетчер виртуальных сетей Azure IPAM для автоматического отслеживания соответствия требованиям или сохраняйте общую электронную таблицу, которая проверяется во время каждого развертывания.
• Защита общедоступных IP-адресов: Связывание Azure защиты от атак DDoS с ресурсами общедоступного IP-адреса в рабочих средах. Диапазоны BYOIP также можно защитить с помощью защиты от атак DDoS.

Связанные статьи

В этих статьях рассматриваются темы, которые взаимодействуют с планированием IP-адресов:

• Виртуальные сети Azure и подсети: структура VNet и подсетей, в которой назначаются IP-адреса.
• Группы безопасности сети и группы безопасности приложений: правила безопасности, ссылающиеся на диапазоны IP-адресов.
• Топология концентраторов и периферийных узлов: планирование IP-адресов между общими и рабочими сетями в структуре концентратора и периферийной сети.
• Топология Виртуальная глобальная сеть: планирование адресного пространства для концентраторов Виртуальная глобальная сеть и подключенных сетей VNet.
• Многорегиональная сеть: планирование IP-адресации в разных регионах, включая непересекающиеся диапазоны для межрегионального пиринга.
• Централизованное управление сетями: Диспетчер виртуальных сетей Azure IPAM для крупномасштабного отслеживания и выделения IP-адресов.

Узнать больше

• IP-адресация для виртуальных сетей Azure
• Общедоступные IP-адреса в Azure
• Префикс пользовательского IP-адреса (BYOIP)
• Что такое IPAM Диспетчер виртуальных сетей Azure?
• IPv6 для Azure Virtual Network
• Виртуальная сеть Azure. Вопросы и ответы

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

Tip

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

Далее в пути лифта и смены:

Защита подсетей с помощью групп безопасности сети: зеркальное отображение существующих правил брандмауэра в виде правил NSG для поддержания состояния безопасности в Azure.

Далее в пути модернизации:

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

Следующий этап вашего мультиоблачного пути:

Защитите свои подсети с помощью групп безопасности сети: отразите свои группы безопасности AWS и правила брандмауэра Google Cloud в виде групп безопасности сети Azure.