Используйте двухрегиональное Решение Azure VMware проектирование, которое не имеет глобального охвата
В этой статье описаны рекомендации по подключению, потокам трафика и высокой доступности при развертывании Решение Azure VMware в двух регионах и использовании безопасных Виртуальная глобальная сеть Azure с намерением маршрутизации. Он предоставляет рекомендации по использованию этой структуры без Global Reach. В этой статье описывается Виртуальная глобальная сеть топология намерений маршрутизации для Решение Azure VMware частных облаков, локальных сайтов и собственных ресурсов Azure. Реализация и настройка безопасных Виртуальная глобальная сеть с намерением маршрутизации выходит за рамки этой статьи.
Если вы используете регион, который не поддерживает Global Reach или у вас есть требование безопасности для проверки трафика между Решение Azure VMware и локальной средой в брандмауэре концентратора, необходимо открыть запрос в службу поддержки, чтобы включить транзитивность ExpressRoute -to-ExpressRoute. Виртуальная глобальная сеть по умолчанию не поддерживает транзитивность ExpressRoute в ExpressRoute. Дополнительные сведения см. в разделе "Транзитное подключение между каналами ExpressRoute" с намерением маршрутизации.
Использование безопасного Виртуальная глобальная сеть с двумя регионами без глобального охвата
Только номер SKU уровня "стандартный" Виртуальная глобальная сеть поддерживает безопасные Виртуальная глобальная сеть с намерением маршрутизации. Используйте безопасные Виртуальная глобальная сеть с намерением маршрутизации для отправки всего интернет-трафика и частного сетевого трафика (RFC 1918) в решение безопасности, например Брандмауэр Azure, виртуальное устройство, отличное от Майкрософт (NVA), или программное обеспечение как услуга (SaaS).
Центр этого сценария имеет следующую конфигурацию:
Сеть с двумя регионами имеет один экземпляр Виртуальная глобальная сеть и два концентратора. Каждый регион имеет один концентратор.
Каждый концентратор имеет собственный экземпляр Брандмауэр Azure, что делает их безопасными Виртуальная глобальная сеть концентраторов.
Безопасные Виртуальная глобальная сеть концентраторы имеют намерение маршрутизации.
Этот сценарий также содержит следующие компоненты:
Каждый регион имеет собственный Решение Azure VMware частное облако и виртуальную сеть Azure.
Локальный сайт подключается к обоим регионам.
Примечание.
Если вы используете префиксы, отличные от RFC 1918, в подключенных локальных ресурсах, виртуальных сетях или Решение Azure VMware, укажите эти префиксы в поле префиксов частного трафика функции намерения маршрутизации. Введите суммированные маршруты в поле префиксов частного трафика, чтобы покрыть диапазон. Не введите точный диапазон, объявляющий Виртуальная глобальная сеть, так как эта спецификация может привести к проблемам маршрутизации. Например, если канал Azure ExpressRoute объявляет 192.0.2.0/24 из локальной среды, введите диапазон маршрутизации между доменами /23 или больше, например 192.0.2.0/23. Дополнительные сведения см. в разделе "Настройка намерения маршрутизации и политик" на портале Виртуальная глобальная сеть.
Примечание.
При настройке Решение Azure VMware с безопасными центрами Виртуальная глобальная сеть задайте параметр предпочтения маршрутизации концентратора в качестве пути AS, чтобы обеспечить оптимальные результаты маршрутизации в концентраторе. Дополнительные сведения см. в разделе "Параметры маршрутизации виртуального концентратора".
На следующей схеме показан пример этого сценария.
В следующей таблице описывается подключение топологии на предыдущей схеме.
| Connection | Description |
|---|---|
| D | Решение Azure VMware подключение частного облака к локальному региональному концентратору |
| E | Локальное подключение через ExpressRoute к обоим региональным центрам |
| Interhub | Логическое подключение между двумя центрами, развернутыми в одном Виртуальная глобальная сеть |
Потоки трафика с двумя регионами, защищенными Виртуальная глобальная сеть
В следующих разделах описаны потоки трафика и подключение для Решение Azure VMware, локальных, виртуальных сетей Azure и Интернета.
Решение Azure VMware подключения к частному облаку и потокам трафика
На следующей схеме показаны потоки трафика для обоих Решение Azure VMware частных облаков.
В следующей таблице описывается подключение топологии на предыдущей схеме.
| Номер потока трафика | Источник | Назначение | Проверяет ли этот трафик защищенный брандмауэр Виртуальная глобальная сеть концентратора? |
|---|---|---|---|
| 1 | Решение Azure VMware облачном регионе 1 | Виртуальная сеть 1 | Да, через брандмауэр концентратора 1 |
| 2 | Решение Azure VMware облачном регионе 1 | Локально | Да, через брандмауэр концентратора 1 |
| 3 | Решение Azure VMware облачном регионе 1 | Виртуальная сеть 2 | Да, через брандмауэр концентратора 1, а затем через брандмауэр концентратора 2 |
| 4 | Решение Azure VMware облачном регионе 1 | Решение Azure VMware облачный регион 2 | Да, через брандмауэр концентратора 1, а затем через брандмауэр концентратора 2 |
| 5 | Решение Azure VMware облачный регион 2 | Виртуальная сеть 1 | Да, через брандмауэр концентратора 2, а затем через брандмауэр концентратора 1 |
| 6 | Решение Azure VMware облачный регион 2 | Виртуальная сеть 2 | Да, через брандмауэр концентратора 2 |
| 7 | Решение Azure VMware облачный регион 2 | Локально | Да, через брандмауэр концентратора 2 |
Каждое Решение Azure VMware частное облако подключается к концентратору через подключение ExpressRoute D.
Если включить транзитность ExpressRoute в ExpressRoute в безопасном концентраторе и включить намерение маршрутизации, безопасный концентратор отправляет адреса RFC 1918 по умолчанию (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) для Решение Azure VMware через D. Помимо адресов RFC 1918 по умолчанию, Решение Azure VMware узнайте больше о конкретных маршрутах из виртуальных сетей Azure и сетей филиалов, таких как VPN S2S, VPN P2S и SD-WAN, которые подключаются к обоим концентраторам. Оба Решение Azure VMware частных облаках не изучают определенные маршруты из локальных сетей.
Для маршрутизации трафика обратно в локальные сети Решение Azure VMware использует адреса RFC 1918 по умолчанию, которые он узнает через подключение D из локального регионального концентратора. Этот трафик передается через брандмауэр локального регионального концентратора. Брандмауэр концентратора использует определенные маршруты для локальных сетей для маршрутизации трафика к назначениям через подключение E. Трафик, передаваемый из любого Решение Azure VMware частного облака в виртуальные сети, передает брандмауэр концентратора.
Локальный поток подключения и трафика
На следующей схеме показаны потоки трафика для локального подключения.
В следующей таблице описывается подключение топологии на предыдущей схеме.
| Номер потока трафика | Источник | Назначение | Проверяет ли этот трафик защищенный брандмауэр Виртуальная глобальная сеть концентратора? |
|---|---|---|---|
| 2 | Локально | Решение Azure VMware облачном регионе 1 | Да, через брандмауэр концентратора 1 |
| 7 | Локально | Решение Azure VMware облачный регион 2 | Да, через брандмауэр концентратора 2 |
| 8 | Локально | Виртуальная сеть 1 | Да, через брандмауэр концентратора 1 |
| 9 | Локально | Виртуальная сеть 2 | Да, через брандмауэр концентратора 2 |
Локальный сайт подключается к обоим концентраторам через подключение ExpressRoute E.
При включении транзитности ExpressRoute в обоих безопасных центрах и включении намерения маршрутизации каждый безопасный концентратор отправляет адреса RFC 1918 по умолчанию (10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16) в локальную среду E. Помимо адресов RFC 1918 по умолчанию локальные маршруты из виртуальных сетей Azure и сетей филиалов Azure, таких как VPN S2S, VPN P2S и SD-WAN, которые подключаются к обоим концентраторам.
Локальные службы не изучают определенные маршруты для Решение Azure VMware частных облаков. В локальной среде вы узнаете адреса RFC 1918 по умолчанию из обоих центров через подключение E. Локальные маршруты в оба Решение Azure VMware частных облаках через адреса RFC 1918 по умолчанию, которые он узнает по подключению E.
Примечание.
Необходимо добавить определенные маршруты в обоих центрах. Если вы не добавляете определенные маршруты в концентраторы, можно ввести неоптимальную маршрутизацию, так как в локальной среде используется маршрутизация с равными затратами (ECMP) между подключениями E для трафика, который передается в частное облако Решение Azure VMware. В результате трафик между локальной средой и частным облаком Решение Azure VMware может столкнуться с задержкой, проблемами производительности или удалением пакетов.
Чтобы объявить более конкретный маршрут вниз в локальную среду, укажите эти префиксы в поле префиксов частного трафика функции намерения маршрутизации. Дополнительные сведения см. в разделе "Настройка намерения маршрутизации и политик" на портале Виртуальная глобальная сеть. Необходимо добавить сводные маршруты, охватывающие как блок /22 Решение Azure VMware, так и подсети Решение Azure VMware. Если добавить тот же точный префикс или более конкретный префикс вместо сводного маршрута, в среде Azure возникают проблемы с маршрутизацией. В поле префиксов частного трафика включены только суммированные маршруты.
Как показано на схеме, Решение Azure VMware частное облако 1 включает подсети рабочей нагрузки от 10.10.0.0/24 до 10.10.7.0/24. В концентраторе 1 сводный маршрут 10.10.0.0/21 добавляется в префиксы частного трафика, так как он охватывает все восемь подсетей. Кроме того, в концентраторе 1 сводный маршрут 10.150.0.0/22 добавляется в префиксы частного трафика для покрытия блока управления Решение Azure VMware. Сводные маршруты 10.10.0.0/21 и 10.150.0.0/22 объявляются в локальной среде через подключение E , чтобы локальная сеть имеет более конкретный маршрут, а не 10.0.0.0/8.
Решение Azure VMware частное облако 2 включает подсети рабочей нагрузки от 10.20.0.0/24 до 10.20.7.0/24. В концентраторе 2 сводный маршрут 10.20.0.0/21 добавляется в префиксы частного трафика, так как он охватывает все восемь подсетей. Кроме того, в концентраторе 2 сводный маршрут 10.250.0.0/22 добавляется в префиксы частного трафика, чтобы покрыть блок управления Решение Azure VMware. Сводные маршруты 10.20.0.0/21 и 10.250.0.0/22 объявляют локально через подключение E , чтобы локальная среда была более конкретной, а не 10.0.0.0/8.
Вы можете добавить весь блок управления Решение Azure VMware /22 в поле префиксов частного трафика, так как Решение Azure VMware не объявляет точный блок /22 обратно в Azure. Решение Azure VMware объявляет более конкретные маршруты.
При включении транзитивности ExpressRoute -to-ExpressRoute в концентраторе он отправляет адреса RFC 1918 по умолчанию в локальную сеть. Не объявляйте точные префиксы RFC 1918 обратно в Azure. Те же самые точные маршруты могут создавать проблемы маршрутизации в Azure. Вместо этого следует объявлять более конкретные маршруты обратно в Azure для локальных сетей.
Примечание.
Если вы объявляете адреса RFC 1918 по умолчанию из локальной среды в Azure и хотите продолжить эту практику, необходимо разделить каждый диапазон RFC 1918 на два равных подранга и объявить эти подранги обратно в Azure. Подранги — 10.0.0.0/9, 10.128.0.0/9, 172.16.0.0/13, 172.24.0.0/13, 192.168.0.0/17 и 192.168.128.0/17.
Подключение к виртуальной сети Azure и поток трафика
На следующей схеме показаны потоки трафика для виртуальных сетей Azure.
В следующей таблице описывается поток трафика на предыдущей схеме.
| Номер потока трафика | Источник | Назначение | Проверяет ли этот трафик защищенный брандмауэр Виртуальная глобальная сеть концентратора? |
|---|---|---|---|
| 1 | Виртуальная сеть 1 | Решение Azure VMware облачном регионе 1 | Да, через брандмауэр концентратора 1 |
| 3 | Виртуальная сеть 2 | Решение Azure VMware облачном регионе 1 | Да, через брандмауэр концентратора 2, а затем брандмауэр концентратора 1 |
| 5 | Виртуальная сеть 1 | Решение Azure VMware облачный регион 2 | Да, через брандмауэр концентратора 1 затем брандмауэр концентратора 2 |
| 6 | Виртуальная сеть 2 | Решение Azure VMware облачный регион 2 | Да, через брандмауэр концентратора 2 |
| 8 | Виртуальная сеть 1 | Локально | Да, через брандмауэр концентратора 1 |
| 9 | Виртуальная сеть 2 | Локально | Да, через брандмауэр концентратора 2 |
| 10 | Виртуальная сеть 1 | Виртуальная сеть 2 | Да, через брандмауэр концентратора 1, а затем брандмауэр концентратора 2 |
| 10 | Виртуальная сеть 2 | Виртуальная сеть 1 | Да, через брандмауэр концентратора 2, а затем брандмауэр концентратора 1 |
Каждая виртуальная сеть напрямую выполняет одноранговые подключения к своему региональному концентратору.
На схеме показано, как все собственные ресурсы Azure в обеих виртуальных сетях учатся их эффективным маршрутам. При включении намерения маршрутизации концентратор 1 и концентратор 2 отправляют адреса RFC 1918 по умолчанию в одноранговые виртуальные сети. Собственные ресурсы Azure в виртуальных сетях не учатся определенным маршрутам извне виртуальной сети.
При включении намерения маршрутизации все ресурсы в виртуальной сети изучают адрес RFC 1918 по умолчанию и используют его региональный брандмауэр концентратора в качестве следующего прыжка. Решение Azure VMware частные облака взаимодействуют друг с другом через подключение D над брандмауэром локального регионального концентратора. Оттуда они проходят через Виртуальная глобальная сеть межhub и проходят проверку на брандмауэре межрегионального концентратора. Решение Azure VMware частные облака также взаимодействуют с локальной средой через подключение D над брандмауэром локального регионального концентратора. Весь трафик, который входит и выходит из виртуальных сетей, передает их региональные брандмауэры концентратора.
Подключение к Интернету
В этом разделе описывается, как обеспечить подключение к Интернету для собственных ресурсов Azure в виртуальных сетях и Решение Azure VMware частных облаках в обоих регионах. Дополнительные сведения см . в рекомендациях по проектированию подключения к Интернету. Вы можете использовать следующие параметры для подключения к Интернету Решение Azure VMware.
- Вариант 1. Размещенная в Azure служба Интернета
- Вариант 2. Преобразование сетевых адресов с Решение Azure VMware управляемым Решение Azure VMware (SNAT)
- Вариант 3. Общедоступный IPv4-адрес Azure к пограничному центру обработки данных NSX-T
Двухрегиональное Виртуальная глобальная сеть проектирование, которое имеет намерение маршрутизации, поддерживает все варианты, но мы рекомендуем вариант 1. В следующем примере в этой статье используется вариант 1 для предоставления подключения к Интернету. Вариант 1 лучше всего работает с безопасными Виртуальная глобальная сеть, так как легко проверять, развертывать и управлять ими.
При включении намерения маршрутизации в обоих безопасных центрах она объявляет RFC 1918 непосредственно пиринговых виртуальных сетей. Но вы также можете объявить маршрут по умолчанию 0.0.0.0/0/0 для подключения к Интернету к подчиненным ресурсам. При включении намерения маршрутизации можно создать маршрут по умолчанию из обоих центральных брандмауэров. Этот маршрут по умолчанию объявляется непосредственно одноранговым виртуальным сетям и напрямую подключен к Решение Azure VMware.
Решение Azure VMware и подключение к Интернету виртуальной сети
На следующей схеме показаны потоки трафика для Решение Azure VMware частных облаков и виртуальных сетей.
В следующей таблице описывается поток трафика на предыдущей схеме.
| Номер потока трафика | Источник | Назначение | Проверяет ли этот трафик защищенный брандмауэр Виртуальная глобальная сеть концентратора? |
|---|---|---|---|
| 11 | Решение Azure VMware облачном регионе 1 | Интернету; | Да, через брандмауэр концентратора 1 |
| 12 | Виртуальная сеть 2 | Интернету; | Да, через брандмауэр концентратора 2 |
| 13 | Виртуальная сеть 1 | Интернету; | Да, через брандмауэр концентратора 1 |
| 14 | Решение Azure VMware облачный регион 2 | Интернету; | Да, через брандмауэр концентратора 2 |
При включении намерения маршрутизации для интернет-трафика по умолчанию безопасный Виртуальная глобальная сеть концентратор не объявляет маршрут по умолчанию через каналы ExpressRoute. Чтобы убедиться, что маршрут по умолчанию распространяется на его напрямую подключенные Решение Azure VMware из Виртуальная глобальная сеть, необходимо включить распространение маршрутов по умолчанию на каналах ExpressRoute Решение Azure VMware. Дополнительные сведения см. в разделе "Объявление маршрута по умолчанию 0.0.0.0/0" к конечным точкам.
После включения распространения маршрутов по умолчанию подключение D объявляет маршрут по умолчанию 0.0.0.0/0/0 из концентратора. Не включите этот параметр для локальных каналов ExpressRoute. Рекомендуется реализовать фильтр протокола BGP на локальном оборудовании, чтобы исключить обучение маршрута по умолчанию. Фильтр BGP добавляет дополнительный уровень защиты и помогает гарантировать, что конфигурация не влияет на локальное подключение к Интернету.
При включении намерения маршрутизации для доступа к Интернету оба региональных концентратора создают маршрут по умолчанию и объявляют его в одноранговых подключениях виртуальной сети с концентратором. Обратите внимание, что в сетевых картах виртуальных машин в виртуальной сети в следующем прыжке находится брандмауэр концентратора 0.0.0.0/0. Чтобы найти следующий прыжок, выберите "Действующие маршруты " в сетевом адаптере. Маршрут по умолчанию не объявляется через региональные центры по ссылке между узлами. Таким образом, виртуальные сети используют свой локальный региональный центр для доступа к Интернету, и у них нет резервного подключения к Интернету в межрегиональная сеть.
Устойчивость доступа к Интернету для Решение Azure VMware
Если вы не используете Global Reach в проектировании с двумя регионами, исходящее подключение к Интернету не имеет избыточности, так как каждое Решение Azure VMware частное облако узнает маршрут по умолчанию из локального регионального концентратора и не напрямую подключен к своему межрегиональное концентратору. Если региональный сбой влияет на локальный региональный концентратор, используйте одну из следующих конфигураций вручную для обеспечения избыточности Интернета.
Вариант 1
Используйте этот параметр только для исходящего доступа к Интернету. Во время локального регионального сбоя, если для рабочей нагрузки Решение Azure VMware требуется исходящий доступ к Интернету, используйте SNAT, управляемый Решение Azure VMware. Это решение обеспечивает простой и быстрый доступ. Дополнительные сведения см. в разделе "Включение управляемого SNAT" для рабочих нагрузок Решение Azure VMware.
Вариант 2
Используйте этот параметр для входящего и исходящего доступа к Интернету. Во время локального регионального сбоя, если вам нужен входящий и исходящий доступ к Интернету для вашего Решение Azure VMware облака, используйте следующий метод.
Удалите подключение, которое передается из Решение Azure VMware к локальному региональному концентратору (подключение D на схемах).
В портал Azure выберите Решение Azure VMware и удалите ключ авторизации, созданный для подключения D.
Создайте новое подключение к межрегионному концентратору.
Для обработки входящего трафика рекомендуется использовать Azure Front Door или Диспетчер трафика Azure для обеспечения высокой доступности региона.
Использование оптимизированной сети VMware HCX Mobility (MON) без глобального охвата
При использовании сетевого расширения HCX Mobility Optimized Network (MON) можно включить HCX Mobility Optimized Network (MON). MON обеспечивает оптимальную маршрутизацию трафика в определенных сценариях, чтобы предотвратить перекрытие сетей или циклирование между локальными и облачными ресурсами в расширенных сетях.
Исходящий трафик из Решение Azure VMware
При включении MON для определенной расширенной сети и виртуальной машины поток трафика изменяется. После реализации MON исходящий трафик из виртуальной машины не выполняет цикл обратно в локальную среду. Вместо этого он проходит туннель IPSec расширения сети. Трафик для виртуальной машины выходит из шлюза NSX-T уровня 1 Решение Azure VMware, переходит к шлюзу NSX-T уровня 0, а затем переходит к Виртуальная глобальная сеть.
Входящий трафик в Решение Azure VMware
При включении MON для определенной расширенной сети и виртуальной машины вы введете следующие изменения. Из Решение Azure VMware NSX-T MON внедряет маршрут узла /32 обратно в Виртуальная глобальная сеть. Виртуальная глобальная сеть объявляет этот маршрут /32 обратно в локальные, виртуальные сети и сети филиалов. Этот маршрут узла /32 гарантирует, что трафик из локальных, виртуальных сетей и сетей филиалов не использует туннель IPSec расширения сети при переходе трафика на виртуальную машину с поддержкой MON. Трафик из исходных сетей напрямую переходит к виртуальной машине с поддержкой MON, так как он узнает маршрут /32.
Ограничение HCX MON для безопасного Виртуальная глобальная сеть без глобального охвата
Если включить транзитность ExpressRoute -to-ExpressRoute в безопасном концентраторе и включить намерение маршрутизации, безопасный концентратор отправляет адреса RFC 1918 по умолчанию как в локальную среду, так и в Решение Azure VMware. Помимо адресов RFC 1918 по умолчанию, локальные и Решение Azure VMware узнайте больше о конкретных маршрутах из виртуальных сетей Azure и сетей филиалов, которые подключаются к концентратору.
Но локальные сети не изучают определенные маршруты из Решение Azure VMware, а Решение Azure VMware не изучают определенные маршруты из локальных сетей. Вместо этого обе среды полагаются на адреса RFC 1918 по умолчанию, чтобы упростить маршрутизацию обратно в другую через брандмауэр концентратора. Поэтому более конкретные маршруты, такие как маршруты узлов MON, не объявляются из Решение Azure VMware ExpressRoute в локальный канал ExpressRoute. То же самое будет наблюдаться и в обратной ситуации. Неспособность узнать конкретные маршруты вводит асимметричные потоки трафика. Исходящий трафик Решение Azure VMware через шлюз NSX-T Уровня 0, но возврат трафика из локальной среды возвращается через туннель IPSec расширения сети.
Исправление асимметрии трафика
Чтобы исправить асимметрию трафика, необходимо настроить маршруты политики MON. Маршруты политики MON определяют, какой трафик возвращается к локальному шлюзу через расширение L2. Они также решают, какой трафик проходит через шлюз NSX уровня 0 Решение Azure VMware.
Если целевой IP-адрес совпадает и вы задали его в конфигурации политики MON, происходит два действия. Во-первых, система идентифицирует пакет. Во-вторых, система отправляет пакет в локальный шлюз через устройство расширения сети.
Если целевой IP-адрес не соответствует или вы задали его запрету в политике MON, система отправляет пакет в шлюз Решение Azure VMware уровня 0 для маршрутизации.
В следующей таблице описаны маршруты политики HCX.
| Network | Перенаправление на одноранговый узел | Примечание. |
|---|---|---|
| Диапазон адресов виртуальной сети Azure | Запрет | Явно включите диапазоны адресов для всех виртуальных сетей. Трафик, предназначенный для исходящего трафика Azure через Решение Azure VMware и не возвращается в локальную сеть. |
| Адресные пространства RFC 1918 по умолчанию | Разрешить | Добавьте адреса RFC 1918 по умолчанию. Эта конфигурация гарантирует, что трафик, который не соответствует указанным выше критериям, перенаправляется обратно в локальную сеть. Если локальная настройка использует адреса, которые не являются частью RFC 1918, необходимо явно включить эти диапазоны. |
| Адресное пространство 0.0.0.0/0 | Запрет | Адреса, которые RFC 1918 не охватывают, например IP-адреса, доступные в Интернете, или трафик, который не соответствует указанным записям, выходит непосредственно через Решение Azure VMware и не перенаправляется обратно в локальную сеть. |
Следующие шаги
- Параметры виртуального концентратора
- Настройка брандмауэра Azure в концентраторе виртуальной глобальной сети
- Настройка брандмауэра нового поколения Palo Alto Networks Cloud Next Generation в Виртуальная глобальная сеть
- Настройка намерения и политик маршрутизации с помощью портала Виртуальная глобальная сеть