Внедрение маршрутов по умолчанию в периферийных виртуальных сетях

Одной из наиболее распространенных архитектур в Azure является центральный и периферийный дизайн, где рабочие нагрузки, развернутые в периферийной виртуальной сети ( виртуальной сети), отправляют трафик через общие сетевые устройства, существующие в виртуальной сети концентратора. Определяемые пользователем маршруты (UDR) обычно необходимо настроить в периферийных виртуальных сетями для управления трафиком к устройствам безопасности в концентраторе. Однако эта конструкция требует от администраторов управлять этими маршрутами во многих периферийных устройствах.

Сервер маршрутов Azure предлагает централизованную точку, в которой виртуальные сетевые (модуль) (NVAs) могут объявлять маршруты, которые он внедряет в периферийные виртуальные сети. Таким образом, администраторам не нужно создавать и обновлять таблицы маршрутов в периферийных виртуальных сетям.

Топология

На следующей схеме показан простой макет концентратора и периферийных виртуальных сетей с виртуальной сетью концентратора и двумя периферийными виртуальными сетями. В концентраторе развернуты виртуальные сетевые (модуль) и сервер маршрутизации. Без сервера маршрутизации определяемые пользователем маршруты должны быть настроены на каждом периферийном сервере. Эти UDR обычно содержат маршрут по умолчанию для 0.0.0.0/0/0, который отправляет весь трафик из периферийных виртуальных сетей через NVA. Этот сценарий можно использовать, например, для проверки трафика в целях безопасности.

При использовании сервера маршрутизации в виртуальной сети концентратора нет необходимости использовать определяемые пользователем маршруты. NVA объявляет префиксы сети на сервер маршрутизации, который внедряет их, чтобы они отображались в эффективных маршрутах любой виртуальной машины, развернутой в центральной виртуальной сети или периферийных виртуальных сетях, пиринговых с виртуальной сетью концентратора с параметром "Использовать шлюз удаленной виртуальной сети" или "Сервер маршрутизации".

Подключение к локальной среде через NVA

Если NVA используется для обеспечения подключения к локальной сети по протоколам VPN IPsec или технологиям SD-WAN, тот же механизм можно использовать для привлечения трафика с периферийных серверов к NVA. Кроме того, NVA может динамически получать префиксы Azure от Azure Route Server и объявлять их с помощью протокола динамической маршрутизации в локальной среде. Эта конфигурация показана на схеме ниже:

Проверка частного трафика через NVA

В предыдущих разделах показан трафик, проверяемый виртуальным сетевым (модуль) (NVA), путем внедрения 0.0.0.0/0 маршрута по умолчанию из NVA на сервер маршрутизации. Однако если вы хотите проверить только периферийный и периферийный трафик через NVA, следует учитывать, что сервер маршрутизации Azure не объявляет маршрут, который является одинаковым или более длинным префиксом, чем адресное пространство виртуальной сети, полученное из NVA. Другими словами, Сервер маршрутизации Azure не внедряет эти префиксы в виртуальную сеть, и они не будут программироваться на сетевых адаптерах виртуальных машин в концентраторе или периферийных виртуальных сетях.

Однако сервер маршрутизации Azure будет объявлять большую подсеть, чем адресное пространство виртуальной сети, полученное из NVA. Можно объявить из NVA суперсеть о том, что у вас есть в виртуальной сети. Например, если виртуальная сеть использует адресное пространство 10.0.0.0/16RFC 1918, NVA может объявлять 10.0.0.0/8 серверу маршрутов Azure, а эти префиксы будут введены в концентратор и периферийные виртуальные сети. Это поведение виртуальной сети ссылается на сведения о BGP с VPN-шлюз.

Внимание

Если у вас есть сценарий, в котором префиксы с той же длиной объявляются из ExpressRoute и NVA, Azure предпочитает и программирует маршруты, полученные из ExpressRoute. Для получения дополнительных сведений см. следующий раздел.

Подключение чувствительность к локальной среде через шлюзы виртуальной сети

Если VPN или шлюз ExpressRoute существует в той же виртуальной сети, что и сервер маршрутизации и NVA для обеспечения подключения к локальным сетям, маршруты, полученные этими шлюзами, будут программироваться, а также в периферийных виртуальных сетях. Эти маршруты переопределяют маршрут по умолчанию (0.0.0.0/0), внедренный сервером маршрутов, так как они будут более конкретными (более длинными сетевыми масками). На следующем изображении представлена предыдущая схема, в которой был добавлен шлюз ExpressRoute.

Вы не можете настроить подсети в периферийных виртуальных сетям, чтобы узнать только маршруты с сервера маршрутизации Azure. Отключение "Распространение маршрутов шлюза" в таблице маршрутов, связанной с подсетью, запрещает внедрение обоих типов маршрутов (маршрутов из шлюза виртуальной сети и маршрутов из сервера маршрутизации Azure) в сетевые карты в этой подсети.

По умолчанию сервер маршрутизации объявляет все префиксы, извлеченные из NVA в ExpressRoute. Это может быть нежелательно, например из-за ограничений маршрутов ExpressRoute или самого Route Server. В этом случае NVA может объявить свои маршруты к серверу маршрутизации, включая сообщество no-advertise BGP (со значением 65535:65282). Когда сервер маршрутизации получает маршруты с этим сообществом BGP, он внедряет их в подсети, но он не будет объявлять их другим одноранговым узлам BGP (например, ExpressRoute или VPN-шлюзам или другим NVAs).

Сосуществование SDWAN с ExpressRoute и Брандмауэром Azure

Конкретный случай предыдущей схемы — когда клиенты вставляют Брандмауэр Azure в поток трафика, чтобы проверять весь трафик, поступающий в локальные сети, через ExpressRoute или через устройства SD-WAN/VPN. В этой ситуации у всех периферийных подсетей есть таблицы маршрутизации, которые не позволяют периферийным сетям получать маршруты от ExpressRoute или Route Server, а также есть маршруты по умолчанию (0.0.0.0/0) с Брандмауэром Azure в качестве следующего прыжка, как показано на следующей схеме:

Подсеть Брандмауэр Azure узнает маршруты, поступающие из ExpressRoute и VPN/SDWAN NVA, и решает, отправляет ли трафик один или другой. Как описано в предыдущем разделе, если NVA (модуль) объявляет более 200 маршрутов на сервер маршрутизации, он должен отправить свои маршруты BGP, помеченные сообществом BGPno-advertise. Таким образом префиксы SDWAN не будут внедряться в локальную среду через Express-Route.

Симметрия трафика

Если несколько экземпляров NVA используются в активном или активном сценарии для повышения устойчивости или масштабируемости, симметрия трафика является требованием, если NVAs должны сохранить состояние подключений. Например, это относится к брандмауэрам следующего поколения.

• Для подключения с виртуальных машин Azure к общедоступному Интернету NVA использует преобразование исходных сетевых адресов (SNAT), чтобы исходящий трафик был получен из общедоступного IP-адреса NVA, поэтому достигается симметрия трафика.
• Для входящего трафика из Интернета в рабочие нагрузки, выполняемые на виртуальных машинах, дополнительные для преобразования сетевых адресов назначения (DNAT), NVAs потребуется выполнить преобразование сетевых адресов источника (SNAT), чтобы убедиться, что возвращаемый трафик из виртуальных машин приземляется в том же экземпляре NVA, который обработал первый пакет.
• Для подключения Azure в Azure, поскольку исходная виртуальная машина будет принимать решение о маршрутизации независимо от места назначения, для достижения симметрии трафика теперь требуется SNAT.

Несколько экземпляров NVA также можно развернуть в конфигурации "активный / пассивный", например, если один из них объявляет худшие маршруты (с более длинным путем AS), чем другой. В этом случае Azure Route Server внедряет только предпочтительный маршрут на виртуальные машины виртуальной сети, и менее предпочтительный маршрут будет использоваться только в том случае, если основной экземпляр NVA прекращает объявление по протоколу BGP.

Различные серверы маршрутизации для объявления маршрутов к шлюзам виртуальных сетей и виртуальным сетям

Как показано в предыдущих разделах, Azure Route Server имеет двойную роль:

• Он изучает и объявляет маршруты из шлюзов виртуальной сети (VPN и ExpressRoute)
• Он настраивает обучаемые маршруты в своей виртуальной сети и напрямую пиринговые виртуальные сети.

Эта двойная функциональность часто вызывает интерес, но иногда может идти вразрез с определенными требованиями. Например, если сервер маршрутизации развернут в виртуальной сети с виртуальным сетевым модулем, который объявляет маршрут 0.0.0.0/0 и шлюзом ExpressRoute, который объявляет префиксы из локальной среды, он настроит все маршруты (как 0.0.0.0/0 из виртуального сетевого модуля, так и локальные префиксы) на виртуальных машинах в своей виртуальной сети и виртуальных сетях с прямым пирингом. Как следствие, поскольку локальные префиксы будут более конкретными, чем 0.0.0.0/0/0, трафик между локальной средой и Azure будет обходить виртуальный сетевой модуль. Если это не нужно, в предыдущих разделах этой статьи показано, как отключить распространение BGP в подсетях виртуальных машин и настроить определяемые пользователем запросы.

Однако есть альтернативный, более динамический подход. Вы можете использовать разные серверы маршрутизации Azure для разных функциональных возможностей: один из них будет отвечать за взаимодействие с шлюзами виртуальной сети, а другой — за взаимодействие с маршрутизацией виртуальной сети. На следующей схеме показана возможная конструкция для этих целей:

Сервер маршрутизации 1 в концентраторе используется для внедрения префиксов из SDWAN в ExpressRoute. Так как периферийные виртуальные сети пиринговые с концентратором виртуальной сети без шлюза удаленной виртуальной сети или сервера маршрутизации (в пиринге периферийной виртуальной сети) и используют шлюз этой виртуальной сети или сервер маршрутизации (транзит шлюза в пиринге центральной виртуальной сети), периферийные виртуальные сети не изучают эти маршруты (ни префиксы SDWAN, ни префиксы ExpressRoute).

Чтобы распространить маршруты на периферийные виртуальные сети, NVA использует Route Server 2, развернутый в новой вспомогательной виртуальной сети. NVA будет распространять только один 0.0.0.0/0 маршрут на Route Server 2. Так как периферийные виртуальные сети пиринговые с этой вспомогательной виртуальной сетью используют шлюз удаленной виртуальной сети или сервер маршрутизации (в пиринге периферийной виртуальной сети) и используют шлюз этой виртуальной сети или сервер маршрутизации (транзит шлюза в пиринге виртуальной сети концентратора), 0.0.0.0/0 маршрут будет обучен всеми виртуальными машинами в периферийных серверах.

Следующий прыжок маршрута 0.0.0.0/0 — это NVA, поэтому периферийные виртуальные сети по-прежнему должны быть одноранговыми в виртуальной сети концентратора. Еще одним важным аспектом является то, что виртуальная сеть концентратора должна быть пиринговой в виртуальной сети, в которой развертывается сервер маршрутизации 2, в противном случае она не сможет создать привязку BGP.

Если трафик из ExpressRoute в периферийные виртуальные сети отправляется в брандмауэр NVA для проверки, требуется таблица маршрутов в ШлюзеSubnet, в противном случае шлюз виртуальной сети ExpressRoute будет отправлять пакеты на виртуальные машины с помощью маршрутов, полученных от пиринга виртуальной сети. Маршруты в этой таблице маршрутов должны соответствовать периферийным префиксам, а следующий прыжок должен быть IP-адресом NVA брандмауэра (или подсистемой балансировки нагрузки перед NVA брандмауэра для избыточности). NVA брандмауэра может совпадать с NVA SDWAN на схеме выше или может быть другим устройством, например Брандмауэр Azure, так как SDWAN NVA может объявлять маршруты с помощью следующего прыжка на другие IP-адреса. На следующей схеме показана эта схема с добавлением Брандмауэр Azure:

Примечание.

Для любого трафика из локальной среды, предназначенной для частных конечных точек, этот трафик будет обходить NVA брандмауэра или Брандмауэр Azure в концентраторе. Однако это приводит к асимметричной маршрутизации (что может привести к потере подключения между локальными и частными конечными точками), так как частные конечные точки пересылают локальный трафик в брандмауэр. Чтобы обеспечить симметрию маршрутизации, включите политики сети таблицы маршрутов для частных конечных точек в подсетях, где развертываются частные конечные точки.

Эта конструкция позволяет автоматически добавлять маршруты в периферийные виртуальные сети без вмешательства других маршрутов, извлеченных из ExpressRoute, VPN или среды SDWAN, а также добавления NVA брандмауэра для проверки трафика.

Связанный контент

• Дополнительные сведения о поддержке Сервера маршрутов Azure для ExpressRoute и VPN Azure.
• Узнайте, как настроить пиринг между сервером маршрутизации Azure и виртуальным сетевым устройством.