Планирование IP-адресации

Для вашей организации важно запланировать IP-адресацию в Azure. Планирование гарантирует отсутствие перекрытия диапазона IP-адресов в локальных расположениях и регионах Azure.

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

• Перекрывающиеся диапазоны IP-адресов в локальной среде и регионах Azure создают серьезные проблемы с состязанием.

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

  

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

• Azure резервирует пять IP-адресов в каждой подсети. Учитывайте эти адреса при определении размера виртуальных сетей и охваченных подсетей.

• Некоторым службам Azure требуются выделенные подсети. К таким службам относятся Брандмауэр Azure и VPN-шлюз Azure.

• Для создания экземпляров службы в подсети можно делегировать подсети определенным службам.

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

• Заранее спланируйте неперекрывающиеся диапазоны IP-адресов в регионах Azure и локальных расположениях.

• Используйте IP-адреса из выделения адресов для частного Интернета, известные как адреса RFC 1918.

• Не используйте следующие диапазоны адресов:

  • 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)

• Для сред с ограниченной доступностью частных IP-адресов рекомендуется использовать IPv6. Виртуальные сети могут быть только на IPv4 или устроены двойным стеком (на IPv4 + IPv6).

  

• Не создавайте большие виртуальные сети, такие как /16. Это позволяет избежать пустой траты диапазона IP-адресов. Минимальный размер подсети для протокола IPv4 равен /29, максимальный — /2 (согласно определениям подсети бесклассовой междоменной маршрутизации (CIDR)). Размер подсетей для протокола IPv6 должен составлять в точности /64.

• Создавать виртуальные сети следует только после планирования требуемого диапазона адресов.

• Не используйте общедоступные IP-адреса для виртуальных сетей, особенно если общедоступные IP-адреса не принадлежат вашей организации.

• Примите во внимание службы, которые вы собираетесь использовать, есть некоторые службы с зарезервированными IP-адресами (IP-адресами), такими как AKS с сетями CNI

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

Рекомендации по IPv6

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

Microsoft Cloud Adoption Framework для Azure помогает понять рекомендации, которые следует учитывать при создании систем в облаке. Дополнительные сведения об архитектурных рекомендациях по проектированию устойчивых систем см . в принципах проектирования целевой зоны Azure. Подробные рекомендации и рекомендации по облачной архитектуре, включая развертывания эталонной архитектуры, схемы и руководства, см. в руководстве по Центру архитектуры для IPv6.

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

• Этап внедрения IPv6. На основе бизнес-потребностей реализуйте IPv6 по необходимости. Помните, что IPv4 и IPv6 могут сосуществовать до тех пор, пока это необходимо.

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

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

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

• Некоторые сложные развертывания и приложения, использующие сочетание сторонних служб, служб платформы как службы (PaaS) и внутренних решений, могут не поддерживать собственный IPv6. В этих случаях необходимо использовать решение NAT/NAT64 или прокси-сервера IPv6, чтобы обеспечить связь между IPv6 и IPv4.

• Если сложность архитектуры приложения или других факторов, таких как затраты на обучение, считаются значительными, может потребоваться использовать инфраструктуру только IPv4 на серверной части и развернуть виртуальный виртуальный (модуль) сети сторонних производителей (NVA) для доставки служб с двойным стеком IPv4/IPv6.

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

  

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

Вот более подробный обзор того, как выглядит типичная архитектура:

• Разверните NVA в Масштабируемые наборы виртуальных машин с помощью гибкой оркестрации (VMSS Flex) для обеспечения устойчивости и предоставления доступа к Интернету через Azure Load-Balancer, который имеет внешний интерфейс общедоступного IP-адреса.

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

• Разверните Azure Front Door , чтобы обеспечить глобальную маршрутизацию для веб-трафика.

  Возможности Azure Front Door включают прокси-запросы клиентов IPv6 и трафик к серверной части, доступной только для IPv4, как показано ниже.

  

Это основные различия между подходом NVA и подходом Azure Front Door:

• Виртуальные сети являются управляемыми клиентом, работают на уровне 4 модели OSI и могут быть развернуты в той же виртуальной сети Azure, что и приложение, с частным и общедоступным интерфейсом.
• Azure Front Door — это глобальная служба Azure PaaS и работает на уровне 7 (HTTP/HTTPS). Серверная часть приложения — это служба, доступная к Интернету, которая может быть заблокирована, чтобы принимать только трафик из Azure Front Door.

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

Блоки CIDR виртуальной сети IPv6:

• При создании новой виртуальной сети в существующем развертывании Azure в подписке можно связать один блок маршрутизации без классов IPv6( CIDR). Размер подсети для IPv6 должен иметь значение /64. Этот размер обеспечивает будущую совместимость, если вы решите включить маршрутизацию подсети в локальную сеть. Некоторые маршрутизаторы могут принимать только маршруты IPv6 /64.
• Если у вас есть существующая виртуальная сеть, поддерживающая только IPv4 и ресурсы в подсети, настроенные для использования только IPv4, можно включить поддержку IPv6 для виртуальной сети и ресурсов. Виртуальная сеть может работать в режиме двойного стека, что позволяет ресурсам взаимодействовать по протоколу IPv4, IPv6 или обоим. Связь IPv4 и IPv6 не зависят друг от друга.
• Вы не можете отключить поддержку IPv4 для виртуальной сети и подсетей. IPv4 — это система IP-адресов по умолчанию для виртуальных сетей Azure.
• Свяжите блок CIDR IPv6 с виртуальной сетью и подсетью или IPv6 BYOIP. Нотация CIDR — это метод представления IP-адреса и его сетевой маски. Форматы этих адресов приведены следующим образом:
  • Отдельный IPv4-адрес составляет 32 бита, с четырьмя группами из трех десятичных цифр. Например, 10.0.1.0.
  • Блок CIDR IPv4 содержит четыре группы из трех десятичных цифр от 0 до 255, разделенных периодами, а затем косой чертой и числом от 0 до 32. Например, 10.0.0.0/16.
  • Отдельный IPv6-адрес составляет 128 бит. Он имеет восемь групп из четырех шестнадцатеричных цифр. Например, 2001:0db8:85a3:0000:0000:8a2e:0370:7334.
  • Блок CIDR IPv6 содержит четыре группы из четырех шестнадцатеричных цифр, разделенных двоеточиями, за которыми следует двойная двоеточие, а затем косая черта и число от 1 до 128. Например, 2001:db8:1234:1a00::/64.
• Обновите таблицы маршрутов для маршрутизации трафика IPv6. Для общедоступного трафика создайте маршрут, который направляет весь трафик IPv6 из подсети в VPN-шлюз или шлюз Azure ExpressRoute.
• Обновите правила группы безопасности, чтобы включить правила для IPv6-адресов. Это позволяет трафику IPv6 передаваться в экземпляры и из нее. Если у вас есть правила группы безопасности сети для управления потоком трафика в подсеть и из нее, необходимо включить правила для трафика IPv6.
• Если тип экземпляра не поддерживает IPv6, используйте двойной стек или разверните NVA, как описано ранее, которое преобразуется из IPv4 в IPv6.

средства управление IP-адресами (IPAM)

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

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

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

• При оценке реализации средства IPAM следует учитывать следующие факторы:

  • Минимальные возможности, необходимые вашей организации
  • Общая стоимость владения (TCO), включая лицензирование и текущее обслуживание
  • Аудит следов, ведения журнала и управления доступом на основе ролей
  • Проверка подлинности и авторизация с помощью идентификатора Microsoft Entra
  • Доступ через API
  • Интеграция с другими средствами и системами управления сетями
  • Поддержка активного сообщества или уровень поддержки от поставщика программного обеспечения

• Рассмотрите возможность оценки средства IPAM с открытым исходным кодом, например Azure IPAM. Azure IPAM — это упрощенное решение, созданное на платформе Azure. Он автоматически обнаруживает использование IP-адресов в клиенте Azure и позволяет управлять им с помощью централизованного пользовательского интерфейса или с помощью API RESTful.

• Рассмотрим операционную модель организации и владение инструментом IPAM. Целью реализации средства IPAM является упрощение процесса запроса новых пространств IP-адресов для команд приложений без зависимостей и узких мест.

• Важной частью функциональных возможностей средства IPAM является инвентаризация использования пространства IP-адресов и логически упорядочение его.

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

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

  • Например, вы можете применить размер футболки, чтобы упростить для команд приложений описание своих потребностей:
    • Небольшой — /24 256 IP-адресов
    • Средний — /22 1 024 IP-адреса
    • Большой — /20 4096 IP-адресов

• Средство IPAM должно иметь API для резервирования не перекрывающихся пространств IP-адресов для поддержки подхода "Инфраструктура как код" (IaC). Эта функция также имеет решающее значение для эффективной интеграции IPAM в процесс вендинг по подписке, тем самым уменьшая риск ошибок и необходимость ручного вмешательства.

  • Пример подхода IaC — Bicep с его функциональностью скрипта развертывания или источниками данных Terraform для динамического получения данных из API IPAM.

• Создайте систематическую структуру для пространств IP-адресов, структурируя их в соответствии с регионами Azure и архетипами рабочей нагрузки, обеспечивая чистую и отслеживаемую инвентаризацию сети.

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