Поделиться через

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

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

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

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

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

    {Схема, показывающая, как NAT работает с VPN-шлюзом.}

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

  • 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 (link-local)
    • 168.63.129.16/32 (внутренний DNS)

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

    Схема с двумя стеками IPv4 и IPv6.

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

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

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

  • Учитывайте службы, которые вы собираетесь использовать, так как есть некоторые службы с зарезервированными IP-адресами, такие как AKS с CNI-сетями.

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

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

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

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

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

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

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

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

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

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

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

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

    На схеме показан шлюз IPv4/IPv6 с двойным стеком, предоставляющий доступ к серверной части, поддерживающей только IPv4.

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

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

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

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

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

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

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

    Схема, показывающая Azure Front Door, предоставляющая доступ к серверной части, доступной только для 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 Inter-Domain маршрутизации (CIDR). Размер подсети для IPv6 должен иметь значение /64. Этот размер обеспечивает будущую совместимость, если вы решите включить маршрутизацию подсети в локальную сеть. Некоторые маршрутизаторы могут принимать только маршруты IPv6 /64.
  • Если у вас есть существующая виртуальная сеть, поддерживающая только IPv4 и ресурсы в подсети, настроенные для использования только IPv4, можно включить поддержку IPv6 для виртуальной сети и ресурсов. Виртуальная сеть может работать в режиме двойного стека, что позволяет ресурсам взаимодействовать по протоколу IPv4, IPv6 или обоим. Связь IPv4 и IPv6 не зависят друг от друга.
  • Вы не можете отключить поддержку IPv4 для виртуальной сети и подсетей. IPv4 — это система IP-адресов по умолчанию для виртуальных сетей Azure.
  • Свяжите блок IPv6 CIDR с вашей виртуальной сетью и подсетью или с 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-адресов, которые больше не используются, которые впоследствии можно перепрофилировать для предстоящих новых рабочих нагрузок, повышая эффективное использование ресурсов.