Подробный обзор маршрутизации Виртуальной глобальной сети
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, так как тип следующего прыжка "HubBgpConnection" подразумевает (см . пиринг 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:
Следующие шаги
Дополнительные сведения о Виртуальной глобальной сети см. в следующей статье: