Схема проектирования межоблачной сети

В этом руководстве предлагается последовательный порядок чтения руководства по проектированию сетевых решений Azure для клиентов, подключающих Azure к Amazon Web Services (AWS), Google Cloud или переносящих рабочие нагрузки из другого облачного провайдера. Выполните нумерованные действия по проектированию безопасного, отслеживаемого подключения между Azure и существующей облачной инфраструктурой.

Почему обнаружение приходит в первую очередь

Межоблачная сеть соединяет Azure с одной или несколькими внешними облачными средами. Вы можете запускать рабочие нагрузки в AWS или Google Cloud, которым требуется частное подключение к службам Azure, или перенести приложения из другого облака в Azure при сохранении подключения к приложениям, которые остаются позади. В любом случае Azure сеть должна интегрироваться с инфраструктурой, которую вы не полностью контролируете с другой стороны.

Этот путь чтения начинается с обнаружения вместо проектирования инфраструктуры Azure. Сначала вы анализируете существующую мультиоблачную топологию, чтобы понять, что и где работает, как всё соединено и какие потоки трафика идут между облаками, и только потом проектируете инфраструктуру на стороне Azure. Такой подход, начинающийся с анализа, позволяет избежать переделок: если вы проектируете сетевую инфраструктуру в Azure, не понимая топологию вашей среды в AWS или Google Cloud, вы рискуете столкнуться с конфликтами IP-адресов, проблемами со связностью и слепыми зонами в системе безопасности.

Целевая архитектура использует Azure Virtual Wide Area Network (WAN) в качестве транзитного концентратора (эквивалента AWS Transit Gateway в Azure) с VPN-туннелями IPSec к AWS Virtual Private Gateway и Google Cloud VPN. Брандмауэр Azure в защищенном виртуальном концентраторе проверяет весь трафик между облаком и филиалами. DNS требует тщательного планирования переключения, чтобы разрешение имён продолжало работать между облачными средами во время миграции.

Prerequisites

  • Ознакомьтесь с планом сети Azure и обзором проектирования для ориентации на доступные Azure сетевые службы.
  • Полное обнаружение топологии в средах AWS и Google Cloud:
    • AWS: запустите AWS Migration Hub или Workload Discovery on AWS, чтобы выполнить инвентаризацию виртуальных частных облаков (VPC), транзитных шлюзов и связности между VPC.
    • Google Cloud: используйте Центр аналитики сети для сопоставления сетей VPC, вложений Cloud Interconnect и правил брандмауэра.
  • Документируйте потоки трафика между облаками: какие приложения взаимодействуют между облаками, необходимую пропускную способность, чувствительность к задержке и требования к шифрованию.
  • Создайте инвентаризацию диапазонов IP-адресов во всех трех облаках, чтобы определить перекрытие.

Путь чтения

Следующие этапы помогут вам выполнить проектирование сети в нескольких облаках в последовательности.

Этап 1. Обнаружение

Начните с обнаружения. Ознакомьтесь с ландшафтом с несколькими облаками перед проектированием инфраструктуры Azure.

1. Подключение между регионами и несколькими облаками

Эта статья является главной точкой принятия решений по проектированию. Сопоставьте топологию мультиоблачной среды: какие сети VPC в AWS и Google Cloud требуют подключения к Azure, какие потоки трафика проходят между облаками и какой архитектурный шаблон подходит для вашего масштаба. Используйте сопоставление служб между облачными провайдерами (Transit Gateway → Виртуальная глобальная сеть, Security Groups → Network Security Groups, VPC Peering → VNet peering), чтобы перевести существующую архитектуру в термины Azure.

2. Виртуальная глобальная сеть Azure

Виртуальная глобальная сеть — это рекомендуемая транзитная модель, если у вас есть несколько VPC, филиалов, регионов или пограничных облачных узлов. Виртуальная глобальная сеть является эквивалентом AWS Transit Gateway в Azure и обеспечивает автоматическую маршрутизацию, централизованную безопасность и масштаб для разветвлённых и мультирегиональных сетей. Оцените, оправдывает ли ваша межоблачная инфраструктура использование Виртуальная глобальная сеть или достаточно более простой архитектуры hub-and-spoke с VPN-шлюз.

Этап 2. Основы

3. Виртуальные сети и подсети

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

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

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

5. Группы безопасности сети и группы безопасности приложений

Преобразуйте группы безопасности AWS и правила брандмауэра Google Cloud в группы безопасности сети Azure (NSG). Преобразуйте существующие правила разрешения и запрета в формат NSG. Используйте группы безопасности приложений (ASG), чтобы реплицировать группирование на основе тегов, которые предоставляют ссылки на группы безопасности AWS.

Этап 3. Подключение

6. Гибридное подключение

Настройте VPN-туннели IPSec между Azure и AWS или Google Cloud для зашифрованного транзита между облаком. Подключите Azure VPN Gateway (или Виртуальная глобальная сеть VPN-подключения) к виртуальному частному шлюзу AWS и VPN Google Cloud. Выберите пропускную способность туннеля в зависимости от потребностей межоблачного трафика. Запланируйте избыточные туннели, чтобы избежать отдельных точек сбоя.

Этап 4. Безопасность

7. Безопасность DNS и разрешение частных имен

Спланируйте стратегию переключения DNS перед переносом рабочих нагрузок. Приложения в AWS или Google Cloud выполняют разрешение имён хостов, которые после миграции могут указывать на Azure. Настройте Azure DNS Private Resolver с исходящими конечными точками для межоблачного разрешения имен. См. контрольный список для переключения DNS далее в этой статье с пошаговыми инструкциями по миграции.

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

Разверните Брандмауэр Azure в безопасном виртуальном концентраторе для проверки всего трафика между облаком и филиалами. Каждый пакет, проходящий между Azure и AWS или Google Cloud, проходит через брандмауэр для ведения журнала и применения политик. Используйте сетевые правила для схем межоблачного трафика и фильтрацию на основе данных аналитики угроз, чтобы блокировать известные вредоносные адреса назначения.

Этап 5. Операции

9. Мониторинг сети и наблюдаемость

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

Условные статьи

Включите следующие статьи на основе конкретных требований:

Condition Статья Когда следует включить
Общедоступное приложение Интернет-входящий трафик Перенесенное приложение подключено к Интернету (требуется прямой общедоступный доступ)
Приложение HTTP/HTTPS Брандмауэр веб-приложений WaF уровня 7 необходим для общедоступных веб-приложений
Требуется распределение трафика на уровне 7 Доставка приложений и производительность После миграции требуется глобальное или региональное распределение трафика
Общедоступные конечные точки Защита от атак DDoS У вас есть требования к бесперебойной работе общедоступных сервисов
Предпочтительный центр и периферийный Топология концентратора и периферийной топологии Ваша кросс-облачная инфраструктура настолько мала, что использование Виртуальная глобальная сеть не оправдано
Мультирегиональный Azure Сеть с несколькими регионами Целевой объект Azure охватывает несколько регионов за пределами межоблачного подключения
Доступ администратора виртуальной машины Доступ разработчика и администратора Вам нужен безопасный доступ RDP/SSH к Azure размещенным виртуальным машинам
Централизованный исходящий трафик Исходящий доступ к Интернету Централизованная политика исходящего трафика в Интернете является частью целевой разработки
Крупная инфраструктура VNet Централизованное управление сетями Среда Azure разрастается в управляемую среду с несколькими подписками
Частные конечные точки PaaS Частный доступ PaaS Целевая архитектура включает службы Azure PaaS с частными конечными точками

Контрольный список межоблачного обнаружения

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

Сопоставление служб AWS для Azure

Служба AWS Эквивалент Azure Notes
Транзитный шлюз Виртуальная глобальная сеть Azure Централизованный узел маршрутизации для нескольких VPC, нескольких регионов и нескольких облаков
VPC Виртуальная сеть Azure Изолированная граница сети с подсетями и таблицами маршрутов
Пиринг VPC Пиринг виртуальных сетей Прямое подключение между двумя виртуальными сетями
Группы безопасности Группы безопасности сети (NSG) Фильтрация трафика с отслеживанием состояния на уровне подсети или сетевого интерфейса
Сетевые списки управления доступом NSG (на уровне подсети) В Azure группы безопасности сети (NSG) сочетают в себе функции группы безопасности и NACL
Виртуальный частный шлюз VPN-шлюз Точка завершения VPN IPSec
Прямое подключение Azure ExpressRoute Выделенное частное подключение (не через общедоступный Интернет)
Частные размещенные зоны маршрута 53 Частные зоны DNS Azure. Разрешение DNS-имен в закрытой DNS в виртуальных сетях
таблицы маршрутов; Маршруты, определяемые пользователем (UDR) Пользовательская маршрутизация для переопределения системных маршрутов Azure или подразумеваемых маршрутов AWS
Эластичный балансировщик нагрузки (ALB/NLB) Azure Load Balancer / Шлюз приложений Балансировка нагрузки L4 и L7; Шлюз приложений предоставляет функции WAF, аналогичные AWS ALB с AWS WAF
AWS WAF Брандмауэр веб-приложений Azure Защита HTTP/HTTPS уровня 7
Сетевой брандмауэр Брандмауэр Azure Сетевой брандмауэр с контролем состояния и аналитикой угроз

Сопоставление служб Google Cloud с Azure

Облачная служба Google Эквивалент Azure Notes
Сеть VPC Виртуальная сеть Azure Глобальный ресурс в Google Cloud; региональный в Azure (используйте пиринг VNet для связи между регионами)
Подключение к облаку Azure ExpressRoute Выделенное частное подключение
Облачная VPN VPN-шлюз VPN-туннели IPSec
Облачный NAT Azure NAT Шлюз Исходящий доступ к Интернету для частных ресурсов
Облачный маршрутизатор Сервер маршрутизации Azure Динамический обмен маршрутами BGP с сетевыми виртуальными устройствами
Cloud Armor Брандмауэр веб-приложений Azure Защита от атак DDoS уровня 7 и приложений
Правила межсетевого экрана Группы сетевой безопасности Фильтрация трафика (правила Google Cloud действуют глобально; группы безопасности сети Azure применяются к каждой подсети или каждому сетевому интерфейсу)
Облачные частные зоны DNS Частные зоны DNS Azure. Разрешение закрытых имен внутри сети
Центр аналитики сети Наблюдатель за сетями Azure Визуализация сетевого мониторинга, диагностики и топологии

Контрольный список переключения DNS

Переключение DNS — это самый высокий риск при миграции между облаками. Следуйте этому контрольному списку, чтобы свести к минимуму сбои при устранении проблем в процессе перехода.

Перед миграцией

  1. Уменьшите значения времени жизни (TTL) для всех изменяемых записей DNS. Установите TTL на 60–300 секунд как минимум за 48 часов до переключения. Этот шаг гарантирует, что срок действия кэша истекает быстро при обновлении записей.
  2. Задокументируйте каждую запись DNS , которая указывает на инфраструктуру, которую вы переносите: записи CNAME для служб, записи MX для почты и записи SRV для обнаружения служб.
  3. Настройте частный распознаватель DNS Azure с исходящими конечными точками в вашей виртуальной сети Azure. Этот резолвер перенаправляет запросы для зон, размещённых в AWS/Google Cloud, на соответствующие вышестоящие DNS-серверы в течение периода сосуществования.
  4. Проверьте прямое и обратное разрешение имен из виртуальных сетей Azure для имен, размещенных в AWS или Google Cloud, перед переносом каких-либо рабочих нагрузок.

Во время миграции

  1. Обновите записи CNAME для служб, которые перемещаются на Azure. Направляйте записи CNAME на конечные точки Azure Front Door, Диспетчер трафика Azure или Шлюз приложений Azure по мере переноса каждой службы.
  2. Обновите записи узла A для отдельных серверов, которые переносятся. Замените IP-адреса AWS или Google Cloud на частные IP-адреса Azure в ваших зонах DNS.
  3. Оставьте условную переадресацию включённой, чтобы имена в зонах, которые вы ещё не перенесли, продолжали разрешаться через DNS-серверы исходного облака.

После миграции

  1. Проверьте разрешение имён из всех расположений: локальные клиенты, виртуальные сети Azure и все остальные рабочие нагрузки в AWS или Google Cloud должны правильно разрешать перенесённые имена.
  2. Возвращайте значения TTL к рабочим уровням (3600 секунд или выше) после подтверждения стабильного разрешения.
  3. Удалите условные перенаправители для зон, которые полностью перенесены в Azure DNS. Сохраняйте серверы пересылки только для зон, которые остаются в AWS или Google Cloud.

То, что вы создали

Следуя этому пути чтения, вы подключили Azure к существующей среде AWS или Google Cloud с зашифрованным транзитом, централизованной проверкой брандмауэра и отслеживаемым подключением. Ваш дизайн включает в себя:

  • Обнаружение и сопоставление служб многооблачной топологии
  • архитектура транзита Виртуальная глобальная сеть или концентратора и периферийной передачи
  • VPN-туннели IPSec в AWS и Google Cloud
  • Брандмауэр Azure для межоблачной проверки трафика
  • Переключение DNS с помощью частного резолвера для разрешения имен между облаками
  • Мониторинг работоспособности и производительности туннеля в Наблюдатель за сетями

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

  • Last updated on