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

Сценарий: Маршрутизация трафика через NVA

When working with Virtual WAN virtual hub routing, there are quite a few available scenarios. В этом сценарии NVA цель состоит в том, чтобы маршрутизировать трафик через NVA (сетевое виртуальное устройство) для ветвления в виртуальную сеть и виртуальную сеть. For information about virtual hub routing, see About virtual hub routing.

Примечание

Если у вас уже есть настройка с маршрутами, предшествующими новым возможностям , как настроить маршрутизацию виртуального концентратора становится доступной, выполните действия, описанные в следующих версиях статей:

Дизайн

В этом сценарии мы будем использовать следующую схему именования:

  • "NVA VNets" для виртуальных сетей, где пользователи развернули NVA и подключили другие виртуальные сети в качестве радиальных спиц (VNet 2 и VNet 4 на Рисунке 2 далее в статье).
  • "NVA Spokes" for virtual networks connected to an NVA VNet (VNet 5, VNet 6, VNet 7, and VNet 8 in the Figure 2 further down in the article).
  • "Non-NVA VNets" для виртуальных сетей, подключенных к Virtual WAN, которые не имеют NVA или других виртуальных сетей, соединенных с ними (VNet 1 и VNet 3 на Рисунке 2 ниже в статье).
  • "Узлы" для управляемых Microsoft узлов виртуальной глобальной сети (Virtual WAN Hubs), к которым подключены сети NVA. VNets-узлы NVA не нужно подключать к узлам Virtual WAN, только к узлам NVA VNets.

The following connectivity matrix summarizes the flows supported in this scenario:

Connectivity matrix

От Кому: NVA Spokes NVA VNets Non-NVA VNets Отделения
NVA Spokes → Over NVA VNet Пиринговое соединение Over NVA VNet Через NVA VNet
NVA VNets → Пиринг Direct Direct Direct
Non-NVA VNets → Over NVA VNet Direct Direct Direct
Филиалы → Over NVA VNet Direct Direct Direct

Каждая ячейка в матрице связности описывает, как VNet или филиал (сторона "От" потока, заголовки строк в таблице) взаимодействует с целевым VNet или филиалом (сторона "К" потока, заголовки столбцов курсивом в таблице). «Прямое» означает, что подключение предоставляется нативно через Virtual WAN, «Пиринговое» означает, что подключение осуществляется с использованием пользовательского маршрута в VNet, а «Через NVA VNet» означает, что подключение проходит через NVA, развернутый в NVA VNet. Рассмотрите следующие пункты:

  • Спицы NVA не управляются виртуальной WAN. В результате механизмы, с помощью которых они будут общаться с другими VNet или филиалами, поддерживаются пользователем. Подключение к NVA VNet обеспечивается с помощью пиринга VNet, а маршрут по умолчанию к 0.0.0.0/0, указывающий на NVA в качестве следующего узла, должeн обеспечивать подключение к Интернету, другим спицам и филиалам.
  • Сети NVA знают о своих собственных разветвлениях NVA, но не о разветвлениях NVA, подключенных к другим сетям NVA. Например, на Рисунке 2 ниже в этой статье VNet 2 знает о VNet 5 и VNet 6, но не знает о других подключениях, таких как VNet 7 и VNet 8. A static route is required to inject other spokes' prefixes into NVA VNets
  • Аналогично, филиалы и VNets без NVA не будут знать о каких-либо узлах NVA, поскольку узлы NVA не подключены к концентраторам Virtual WAN. As a result, static routes are needed here as well.

Учитывая, что экземпляры NVA не управляются через виртуальную сеть WAN, все остальные строки демонстрируют ту же схему подключения. В результате используется единая таблица маршрутизации (по умолчанию).

  • Виртуальные сети (неузловые VNets и пользовательские узловые VNets):
    • Associated route table: Default
    • Распространение на таблицы маршрутизации: Default
  • Филиалы
    • Ассоциированная таблица маршрутов: Default
    • Распространение в таблицы маршрутов: Default

Однако в этой ситуации нам нужно подумать о том, какие статические маршруты настроить. Каждый статический маршрут состоит из двух компонентов: одна часть находится в концентраторе Virtual WAN и определяет, какое соединение следует использовать для каждого ответвления, а другая часть находится в этом конкретном соединении и указывает на конкретный IP-адрес, назначенный NVA (или балансировщик нагрузки перед несколькими NVAs), как показано на Рисунке 1.

Figure 1

Figure 1

С учетом этого статические маршруты, которые нам нужны в таблице по умолчанию для отправки трафика на стороны NVA за NVA VNet, следующие:

Описание Таблица маршрутизации Статический маршрут
VNet 2 По умолчанию 10.2.0.0/16 -> eastusconn
VNet 4 По умолчанию 10.4.0.0/16 -> weconn

Now, these static routes will be advertised to your on-premises branches, and the Virtual WAN hub will know which VNet connection to forward traffic to. However, the VNet connection needs to know what to do when receiving this traffic: This is where the connection route tables are used. Здесь мы будем использовать более короткие префиксы (/24 вместо более длинных /16), чтобы убедиться, что эти маршруты имеют приоритет над маршрутами, импортированными из сетей NVA VNet (VNet 2 и VNet 4).

Описание Соединение Static route
VNet 5 eastusconn 10.2.1.0/24 -> 10.2.0.5
VNet 6 eastusconn 10.2.2.0/24 -> 10.2.0.5
VNet 7 weconn 10.4.1.0/24 -> 10.4.0.5
VNet 8 weconn 10.4.2.0/24 -> 10.4.0.5

Теперь сетевые виртуальные сети NVA, не-NVA и филиалы знают, как добраться до всех спиц NVA. Для получения дополнительной информации о маршрутизации виртуального узла см. О маршрутизации виртуального узла.

Архитектура

На Рисунке 2 показаны два узла: Hub1 и Hub2.

  • Hub1 и Hub2 непосредственно подключены к сетям NVA VNet 2 и VNet 4.

  • VNet 5 и VNet 6 объединены с VNet 2.

  • VNet 7 и VNet 8 подключены к VNet 4.

  • VNets 5,6,7,8 являются косвенными spokes, не подключенными напрямую к виртуальному хабу.

Figure 2

Figure 2

Соображения

  • В этом сценарии можно использовать стороннюю NVA или брандмауэр Azure в виртуальной сети 2 и виртуальной сети 4.

  • Этот сценарий не поддерживает безопасные центры с намерением маршрутизации из-за ограничений политик маршрутизации в отношении статических маршрутов. Однако вы можете использовать функцию пиринга BGP для использования непрямых перов вместе с Secure Hubs с намерением маршрутизации.

Рабочий процесс сценария

Чтобы настроить маршрутизацию через NVA, вот шаги, которые следует учитывать:

  1. Identify the NVA spoke VNet connection. In Figure 2, they're VNet 2 Connection (eastusconn) and VNet 4 Connection (weconn).

    Ensure there are UDRs set up:

    • From VNet 5 and VNet 6 to VNet 2 NVA IP
    • From VNet 7 and VNet 8 to VNet 4 NVA IP

    Вам не нужно напрямую подключать VNets 5, 6, 7, 8 к виртуальным концентраторам. Убедитесь, что NSG в VNets 5, 6, 7, 8 допускают трафик для филиалов (VPN/ER/P2S) или VNets, подключенных к удаленным VNets. For example, VNets 5,6 must ensure NSGs allow traffic for on-premises address prefixes and VNets 7,8 that are connected to the remote Hub 2.

Виртуальная WAN не поддерживает сценарий, в котором виртуальные сети 5 и 6 подключаются к виртуальному концентратору и обмениваются данными через IP-адрес NVA виртуальной сети 2. Поэтому необходимо подключить виртуальные сети 5 и 6 к виртуальной сети 2, а также аналогично виртуальные сети 7 и 8 к виртуальной сети 4.

  1. Add an aggregated static route entry for VNets 2,5,6 to Hub 1’s Default route table.

    Example

    Note

    To simplify the routing and to reduce the changes in the Virtual WAN hub route tables, we recommend the new BGP peering with Virtual WAN hub. For more information, see the following articles:

  2. Configure a static route for VNets 5,6 in VNet 2’s virtual network connection. Чтобы настроить конфигурацию маршрутизации для соединения виртуальной сети, см. маршрутизацию виртуального узла.

  3. Добавьте агрегированную запись статического маршрута для виртуальных сетей 4, 7, 8 в таблицу маршрутов по умолчанию концентратора 1.

  4. Повторите шаги 2, 3 и 4 для таблицы маршрутов по умолчанию концентратора 2.

This results in the routing configuration changes, as shown in Figure 3.

Figure 3

Figure 3

Следующие шаги