Подробный обзор маршрутизации Виртуальной глобальной сети
Azure Виртуальная глобальная сеть — это сетевое решение, которое позволяет легко создавать сложные топологии сети: она включает маршрутизацию между виртуальными сетями Azure и локальными расположениями через VPN типа "точка — сеть", VPN типа "сеть — сеть", ExpressRoute и интегрированные (модуль) SDWAN, включая возможность защиты трафика. В большинстве сценариев вам не требуется глубокое знание того, как работает внутренняя маршрутизация Виртуальная глобальная сеть, но в определенных ситуациях это может быть полезно для понимания концепций маршрутизации Виртуальная глобальная сеть.
В этом документе рассматриваются примеры сценариев Виртуальная глобальная сеть, которые объясняют некоторые из поведения, с которыми могут столкнуться организации при подключении виртуальных сетей и ветвей в сложных сетях. Сценарии, показанные в этой статье, не являются рекомендациями по проектированию, они просто примеры топологий, предназначенных для демонстрации определенных функций Виртуальная глобальная сеть.
Сценарий 1. Топология с предпочтительной маршрутизацией по умолчанию
Первый сценарий в этой статье анализирует топологию с двумя центрами Виртуальная глобальная сеть, подключением ExpressRoute, VPN и SDWAN. В каждом концентраторе есть виртуальные сети, подключенные напрямую (виртуальные сети 11 и 21) и косвенно через NVA (виртуальные сети 121, 122, 221 и 222). Виртуальная сеть 12 обменивается данными маршрутизации с концентратором 1 через BGP (см . пиринг BGP с виртуальным концентратором), а виртуальная сеть 22 имеет статические маршруты, чтобы можно было отображать различия между обоими параметрами.
В каждом концентраторе VPN и SDWAN (модуль) служат двойной задачей: на одной стороне они объявляют свои собственные отдельные префиксы (через VPN в концентраторе 1 и по SDWAN в концентраторе 2), а в других они объявляют те же префиксы, что и каналы ExpressRoute в том же регионе (10.4.1.0/2410.4.2.0/24в концентраторе 1 и 10.5.3.0/24 10.5.2.0/24 в концентраторе 2). Это различие будет использоваться для демонстрации того, как работает предпочтения маршрутизации Виртуальная глобальная сеть концентратора.
Все подключения виртуальных сетей и ветвей связаны и фиксируются в заданной по умолчанию таблице маршрутизации. Хотя центры защищены (в каждом концентраторе развернуты Брандмауэр Azure), они не настроены для защиты частного или интернет-трафика. Это приведет ко всем подключениям, распространяющимся на None таблицу маршрутов, что приведет к удалению всех нестатических маршрутов из Default таблицы маршрутов и поражению цели этой статьи, так как эффективная колонка маршрутов на портале будет почти пуста (за исключением статических маршрутов для отправки трафика в Брандмауэр Azure).
Внимание
На предыдущей схеме показаны два защищенных виртуальных концентратора, эта топология поддерживается с намерением маршрутизации. Дополнительные сведения см. в статье о настройке намерений маршрутизации и политик маршрутизации центра Виртуальная глобальная сеть.
Вне поля Виртуальная глобальная сеть концентраторы обмениваются информацией друг с другом, чтобы связь между регионами была включена. Действующие маршруты можно проверить в таблицах маршрутизации Виртуальной глобальной сеть: например, на следующем рисунке показаны действующие маршруты концентратора 1.
Затем эти действующие маршруты будут объявлены Виртуальная глобальная сеть в ветви и будут внедрять их в виртуальные сети, подключенные к виртуальным концентраторам, что делает использование определяемых пользователем маршрутов ненужным. При проверке действующих маршрутов в виртуальном концентраторе поля "Тип следующего прыжка" и "Источник" указывают, откуда идут маршруты. Например, тип следующего прыжка "Подключение к виртуальной сети" указывает, что префикс определен в виртуальной сети, напрямую подключенной к Виртуальной глобальной сети (виртуальные сети 11 и 12 на предыдущем снимке экрана).
NVA в виртуальной сети 12 внедряет маршрут 10.1.1.20.0/22 по BGP, так как тип следующего прыжка "HubBgp Подключение ion" подразумевает (см. пиринг BGP с виртуальным концентратором). Этот сводный маршрут охватывает как косвенные периферийные периферийные сети 121 (10.1.21.0/24), так и виртуальную сеть 122 (10.1.22.0/24). Виртуальные сети и ветви в удаленном концентраторе отображаются с помощью следующего прыжка hub2. Как можно заметить в пути AS, номер 65520 автономной системы был дважды добавлен к этим маршрутам между концентраторами.
В концентраторе 2 есть интегрированный виртуальный сетевой модуль SDWAN. Дополнительные сведения о поддерживаемых NVAs для этой интеграции см. в разделе "Сведения о NVAs" в центре Виртуальная глобальная сеть. Обратите внимание, что следующий прыжок для маршрута 10.5.3.0/24 к ветви SDWAN — VPN_S2S_Gateway. В настоящее время этот тип следующего прыжка может указывать на маршруты от шлюза виртуальной сети Azure или от NVA, интегрированных с концентратором.
В концентраторе 2 маршрут для 10.2.20.0/22 непрямой периферии виртуальной сети 221 (10.2.21.0/24) и виртуальной сети 222 (10.22.0/24) устанавливается как статический маршрут, как указано в источнике defaultRouteTable. Если вы проверка в эффективных маршрутах для концентратора 1, этот маршрут не существует. Причина заключается в том, что статические маршруты не распространяются через BGP, но необходимо настроить в каждом концентраторе. Таким образом, концентратору 1 необходим статический маршрут, чтобы обеспечить подключение своих виртуальных сетей и ветвей к опосредованно подключенным периферийным виртуальным сетям концентратора 2 (виртуальные сети 221 и 222):
После добавления статического маршрута концентратор 1 также будет содержать 10.2.20.0/22 маршрут:
Сценарий 2. Global Reach и предпочтительная маршрутизация концентратора
Даже если концентратор 1 знает префикс ExpressRoute из канала 2 (10.5.2.0/24) и концентратора 2 знает префикс ExpressRoute из канала 1 (10.4.2.0/24), маршруты ExpressRoute из удаленных регионов не объявляются обратно в локальные ссылки ExpressRoute. Следовательно, для обмена данными между расположениями ExpressRoute требуется глобальная сеть ExpressRoute:
Внимание
На предыдущей схеме показаны два защищенных виртуальных концентратора, эта топология поддерживается с намерением маршрутизации. Дополнительные сведения см. в статье о настройке намерений маршрутизации и политик маршрутизации центра Виртуальная глобальная сеть.
Как описано в предпочтениях маршрутизации виртуального концентратора, Виртуальная глобальная сеть предпочитает маршруты, поступающие из ExpressRoute по умолчанию. Так как маршруты объявляются из концентратора 1 в канал ExpressRoute 1, из канала ExpressRoute 1 в канал 2, а также от канала ExpressRoute 2 к концентратору 2 (и наоборот), виртуальные концентраторы предпочитают этот путь по более прямой связи между концентраторами. Действующие маршруты в концентраторе 1 показывают следующее:
Как вы видите на маршрутах, ExpressRoute Global Reach предварительно добавляет номер автономной системы ExpressRoute (12076) несколько раз, прежде чем отправлять маршруты обратно в Azure, чтобы сделать эти маршруты менее предпочтительнее. Однако заданная по умолчанию в концентраторе Виртуальной глобальной сети предпочтительная маршрутизация с использованием ExpressRoute игнорирует длину пути AS при принятии решения о маршрутизации.
Действующие маршруты в концентраторе 2 будут аналогичными.
Параметры маршрутизации можно изменить на VPN или AS-Path, как описано в параметрах маршрутизации виртуального концентратора. Например, можно отдать предпочтение VPN, как показано на этом рисунке.
При предпочтении маршрутизации концентратора VPN действующие маршруты в концентраторе 1 выглядят следующим образом:
На изображении выше показано, как что теперь следующим прыжком маршрута к 10.4.2.0/24 является VPN_S2S_Gateway, тогда как при использовании предпочтительной маршрутизации по умолчанию через ExpressRoute это был ExpressRouteGateway. Однако в концентраторе 2 следующим прыжком для маршрута к 10.5.2.0/24 по-прежнему является ExpressRoute, так как в этом случае альтернативный маршрут выстроен не от VPN-шлюза, а от NVA, интегрированного с концентратором:
Однако трафик между концентраторами по-прежнему предпочитает маршруты через ExpressRoute. Чтобы использовать более эффективное прямое подключение между виртуальными центрами, для параметра маршрута можно задать значение AS Path в обоих центрах:
Теперь следующим прыжком маршрутов для удаленных периферийных виртуальный сетей и ветвей в концентраторе 1 будет Remote Hub, что и требовалось.
Вы можете увидеть, что префикс IP-адреса для концентратора 2 (192.168.2.0/23) по-прежнему доступен по ссылке Global Reach, но это не должно влиять на трафик, так как не должно быть никакого трафика, адресованного устройствам в концентраторе 2. Этот маршрут может быть проблемой, хотя, если в обоих центрах были NVA, устанавливающие туннели SDWAN между собой.
Однако обратите внимание, что для 10.4.2.0/24 теперь предпочтительным является VPN-шлюз. Это может произойти, если у маршрутов, объявленных через VPN, путь AS короче, чем у маршрутов, объявленных через ExpressRoute. После настройки локального VPN-устройства, которое будет добавлять свой номер автономной системы (65501) к маршрутам VPN, чтобы сделать их менее предпочтительными, концентратор 1 теперь выбирает ExpressRoute в качестве следующего прыжка для 10.4.2.0/24.
Таблица действующих маршрутов у концентратора 2 будет аналогичной: следующим прыжком для виртуальных сетей и ветвей в другом концентраторе будет Remote Hub.
Сценарий 3. Перекрестное подключение каналов ExpressRoute к обоим концентраторам
Чтобы добавить прямые связи между регионами Azure и локальными расположениями, подключенными через ExpressRoute, часто желательно подключить один канал ExpressRoute к нескольким Виртуальная глобальная сеть концентраторам в топологии несколько раз, описанных как "галстук боучок", как показано в следующей топологии:
Внимание
На предыдущей схеме показаны два защищенных виртуальных концентратора, эта топология поддерживается с намерением маршрутизации. Дополнительные сведения см. в разделе "Настройка намерений маршрутизации и политик маршрутизации центра Виртуальная глобальная сеть".
Виртуальная глобальная сеть показывает, что оба канала подключены к обоим концентраторам:
При возвращении к заданной по умолчанию предпочтительной маршрутизации концентратора через ExpressRoute маршруты к удаленным ветвям и виртуальным сетям в концентраторе 1 снова будут отображать ExpressRoute в качестве следующего прыжка. Хотя на этот раз причина не Global Reach, но тот факт, что каналы ExpressRoute отскочили от рекламы маршрута они получают от одного концентратора к другому. Например, действующие маршруты концентратора 1 с предпочтениями маршрутизации концентратора ExpressRoute приведены следующим образом:
Повторное изменение предпочтения маршрутизации концентратора на AS Path возвращает маршруты между концентраторами в оптимальный путь с помощью прямого подключения между концентраторами 1 и 2:
Следующие шаги
Дополнительные сведения о Виртуальной глобальной сети см. в следующей статье: