Используйте брандмауэр Azure для маршрутизации топологии типа «многие концентраторы и периферия»

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

Вы можете реализовать архитектуры концентраторов и периферийных серверов двумя способами:

• Самоуправляемая топология «концентратор-луч» (традиционная): вы сохраняете полный контроль над виртуальными сетями концентратора и конфигурацией маршрутизации.
• Виртуальная глобальная сеть. Корпорация Майкрософт управляет виртуальными сетями концентратора и упрощает администрирование с помощью таких функций, как намерение маршрутизации и политики маршрутизации.

В этой статье рассматриваются самоуправляемые топологии концентратора и периферийных узлов, где вы имеете полную видимость и контроль над виртуальной сетью концентратора и развертыванием брандмауэра Azure.

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

Альтернатива таблицам маршрутов Azure в периферийных виртуальных сетях внедряет маршруты в подсети с помощью Сервера маршрутов Azure, как описано в инструкции по внедрению маршрутов по умолчанию в периферийных виртуальных сетях. Однако этот шаблон часто не используется из-за сложности, которая может возникать из-за взаимодействия между сервером маршрутизации Azure и VPN или шлюзами виртуальной сети ExpressRoute.

В самостоятельной настройке концентратора и периферийных узлов:

• Концентратор: виртуальная сеть, служащая центральной точкой подключения к вашей локальной сети через VPN, ExpressRoute или управляемую программно широкую сеть (SD-WAN). Устройства безопасности сети, такие как брандмауэры, развертываются в виртуальной сети концентратора.
• Периферийные устройства: виртуальные сети, одноранговые с концентратором и размещающие рабочие нагрузки.

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

Архитектура концентратора с одним регионом и периферийной архитектурой

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

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

• Трафик между узлами: Периферийные узлы не соединены пиринговой связью друг с другом, а пиринг виртуальных сетей не является транзитивным. Каждое подключение (спица) по умолчанию знает, как маршрутизировать в концентратор виртуальной сети, но не к другим подключением (спицам). Маршрут для 0.0.0.0/0, применяемый ко всем периферийным подсетям, охватывает трафик между периферийными подсетями.
• Трафик spoke-к-интернету: 0.0.0.0/0 маршрут в таблице маршрутов spoke также охватывает трафик, отправленный в общедоступный интернет. Этот маршрут перезаписывает системный маршрут, включенный в общедоступные подсети по умолчанию. Дополнительные сведения см. в статье Исходящий доступ по умолчанию в Azure.
• Трафик от Интернета к концентратору: трафик из Интернета в концентратор обычно сначала проходит через брандмауэр Azure. Брандмауэр Azure имеет настроенные правила преобразования сетевых адресов (DNAT), которые также переводят исходный IP-адрес (перевод исходного сетевого адреса или SNAT). Рабочие нагрузки периферийных узлов видят трафик как поступающий из подсети брандмауэра Azure. Пиринг между виртуальными сетями создает системные маршруты к концентратору (10.1.0.0/24), поэтому периферийные узлы знают, как маршрутизировать возвращаемый трафик.
• Трафик от локального узла к спицевому узлу и от спицевого узла к локальному узлу: рассмотрим каждое направление отдельно:
  • Локальный и периферийный трафик: трафик поступает из локальной сети к VPN или шлюзам ExpressRoute. При маршрутизации по умолчанию в Azure системный маршрут создается в подсети шлюза (и других подсетях в виртуальной сети концентратора) для каждой конечной сети. Необходимо переопределить эти системные маршруты и задать следующий шаг к приватному IP-адресу брандмауэра Azure. В этом примере требуется два маршрута в таблице маршрутов, связанной с подсетью шлюза, по одному для каждой спицы (10.1.1.0/24 и 10.1.2.0/24). Использование сводки, такой как 10.1.0.0/16, охватывающей все спицевые виртуальные сети, не работает, поскольку системные маршруты, введенные пирингами виртуальной сети в подсети шлюза, являются более конкретными (/24 по сравнению с /16 сводкой). В этой таблице маршрутов должен быть включен переключатель распространение маршрутов шлюза (задано значение "Да"), в противном случае маршрутизация шлюза может стать непредсказуемой.
  • Трафик от периферии к локальной сети: пиринги виртуальной сети между концентратором и периферийными узлами должны иметь включенную разрешить транзит через шлюз на стороне концентратора и включенное использование удаленных шлюзов на стороне периферии. Эти параметры необходимы, чтобы VPN-шлюзы и шлюзы ExpressRoute объявляли периферийные префиксы через протокол BGP для локальных сетей. Эти настройки также приводят к тому, что спицы по умолчанию изучают префиксы, объявленные из локальной среды в Azure. Так как префиксы локальной среды являются более конкретными, чем маршрут, заданный пользователем 0.0.0.0/0 в таблице маршрутов узла, трафик из узлов в локальную сеть будет обходить брандмауэр по умолчанию. Чтобы предотвратить эту ситуацию, установите переключатель "Распространение маршрутов шлюза" на "Нет" в спицевой таблице маршрутов, чтобы локальные префиксы не изучались и маршрут 0.0.0.0/0 использовался для трафика в локальную сеть.

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

Рабочие нагрузки виртуальной сети концентратора

При развертывании рабочих нагрузок в центральной виртуальной сети (таких как контроллеры домена Active Directory, DNS-серверы или другая общая инфраструктура), это повышает сложность проектирования концентратора и периферийных серверов. Рекомендуется избегать размещения рабочих нагрузок в центре и вместо этого развертывать их в выделенном периферийном интерфейсе для общих служб.

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

На следующей схеме показана схема с одним регионом с подсетью рабочей нагрузки в виртуальной сети концентратора:

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

• Конфигурация подсети шлюза. Настройка маршрута в подсети шлюза для всей виртуальной сети концентратора (10.1.0.0/24 в этом примере) переопределяет системный маршрут для виртуальной сети концентратора. Это приводит к тому, что трафик внутри подсети между VPN-шлюзами или шлюзами ExpressRoute отправляется в брандмауэр, что может привести к нарушению работы шлюза.
• Конфигурация периферийной подсети: настройка маршрута в периферийных подсетях для всей виртуальной сети концентратора (10.1.0.0/24 в этом примере) переопределяет системный маршрут, созданный пирингом с виртуальной сетью концентратора. Весь трафик, отправляемый в концентратор, будет перенаправлен в брандмауэр Azure, включая трафик от самого брандмауэра Azure, например, трафик от интернета к сегменту сети, который проходит через трансляцию сетевых адресов источника (SNAT). Эта конфигурация вводит асимметричный трафик и приводит к потере пакетов.

Проверка трафика между подсетью

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

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

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

Для подсети A21 вам потребуется два дополнительных маршрута:

• Маршрут к 10.1.2.0/24: переопределяющий системный маршрут для трафика внутри виртуальной сети. Без других маршрутов весь трафик внутри виртуальной сети отправляется в брандмауэр Azure, даже трафик между виртуальными машинами в одной подсети.
• Маршрут к 10.1.2.0/26, следующая точка — виртуальная сеть: исключение из предыдущего маршрута, поэтому трафик в этой конкретной подсети не отправляется к брандмауэру, а маршрутизируется локально внутри виртуальной сети. Этот маршрут предназначен для каждой подсети, поэтому для каждой подсети требуется отдельная таблица маршрутов.

виртуальные сетевые устройства SD-WAN

Если вы используете SD-WAN сетевые виртуальные устройства (NVA) вместо VPN-шлюзов или шлюзов ExpressRoute, дизайн аналогичен, как показано на следующей схеме:

Существуют различные способы интеграции SD-WAN NVAs в Azure. Для получения дополнительной информации см. интеграция SD-WAN с топологиями сети хаб и спица в Azure. В этой статье показано, как интегрироваться с azure Route Server, одним из наиболее распространенных методов маршрутизации трафика в SD-WAN сети. SD-WAN NVAs объявляют локальные префиксы на сервер маршрутизации Azure через BGP. Azure Route Server внедряет эти префиксы в подсеть брандмауэра Azure, чтобы брандмауэр Azure получил сведения о маршрутизации для локальных сетей. Спицы не изучают внутренние префиксы, поскольку параметр "Распространение маршрутов шлюза" отключен в таблице маршрутов спиц.

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

Архитектура типа "звезда" с несколькими регионами

После того, как вы поймете, как работает трафик в одном централизованном регионе, расширить проект до много региональной архитектуры просто. На следующей схеме показан обновленный дизайн сети с концентраторами в двух регионах (A и B):

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

В этом примере каждый регион можно легко суммировать:

• Регион А содержит префиксы в 10.1.0.0/16
• Регион B содержит префиксы в 10.2.0.0/16

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

Включите распространение маршрутов шлюза в таблице маршрутов подсети Azure Firewall, чтобы брандмауэр мог получать локальные маршруты из VPN и шлюзов ExpressRoute.

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

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

• См. дополнительные сведения о развертывании и настройке Брандмауэра Azure.