Как настроить намерение маршрутизации и политики маршрутизации для виртуального концентратора WAN

Маршрутизационное намерение в концентраторе виртуальной глобальной сети позволяет настраивать простые и декларативные политики маршрутизации для отправки трафика во встроенные в сеть решения безопасности, такие как Azure Firewall, сетевые виртуальные устройства или решения SaaS, развернутые в концентраторе виртуальной глобальной сети.

Общие сведения

Намерения маршрутизации и политики маршрутизации позволяют настроить узел Виртуальная глобальная сеть для пересылки интернет-ориентированного и частного трафика (VPN точка-сайт, VPN сайт-сайт, ExpressRoute, виртуальная сеть и сетевое виртуальное устройство) в брандмауэр Azure, брандмауэр следующего поколения (NGFW), сетевое виртуальное устройство (NVA) или решение безопасности как услуга (SaaS), развернутое в виртуальном узле.

Существует два типа политик маршрутизации: политики для интернет-трафика и для частного трафика. Каждый Virtual WAN Hub может иметь не более одной политики маршрутизации интернет-трафика и одной политики маршрутизации частного трафика, каждая из которых использует один ресурс Next Hop. Хотя частный трафик включает в себя префиксы адресов ветвей и виртуальной сети, политики маршрутизации рассматривают их как единую сущность в рамках концепций намерений маршрутизации.

• Маршрутизация интернет-трафика: Если политика маршрутизации интернет-трафика настроена в хабе Виртуальной глобальной сети, все подключения ветвей (VPN удаленного пользователя (VPN типа "точка-сеть", VPN типа "сеть-сеть") и ExpressRoute) и виртуальные сетевые подключения к этому хабу Виртуальной глобальной сети передают интернет-трафик в Брандмауэр Azure, стороннего поставщика безопасности, сетевое виртуальное устройство или решение SaaS, указанные в рамках политики маршрутизации.

  Другими словами, когда Политика маршрутизации интернет-трафика настроена в центре Виртуальная WAN, Виртуальная WAN объявляет маршрут по умолчанию (0.0.0.0/0) ко всем спицам, шлюзам и сетевым виртуальным устройствам (развернутым в концентраторе или спице).

• Политика маршрутизации частного трафика: Когда политика маршрутизации частного трафика настроена на концентраторе Виртуальная WAN, весь входящий и исходящий трафик для всех отделений и виртуальных сетей в и из концентратора Виртуальная WAN, включая трафик между концентраторами, пересылается на следующий узел Брандмауэр Azure, сетевое виртуальное устройство или ресурс решения SaaS.

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

Случаи использования

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

Все узлы виртуальной WAN-сети защищены (развернуты с Брандмауэром Azure, NVA или решением SaaS)

В этом сценарии все концентраторы Виртуальной глобальной сети (Virtual WAN) развертываются с помощью решения Azure Firewall, NVA или SaaS. В этом сценарии можно настроить политику маршрутизации трафика в Интернете, политику маршрутизации частного трафика или оба в каждом виртуальном концентраторе глобальной сети.

Рассмотрим приведенную ниже конфигурацию, где в концентраторах 1 и 2 настроены политики маршрутизации для частного трафика и трафика Интернета.

Конфигурация концентратора 1:

• Политика частного трафика с решением Next Hop Hub 1, таким как брандмауэр Azure, NVA или SaaS.
• Политика интернет-трафика с использованием Azure Firewall, NVA или SaaS решения для Next Hop Hub 1.

Конфигурация концентратора 2:

• Политика частного трафика с использованием Next Hop Hub 2 для Брандмауэра Azure, NVA или решения SaaS
• Политика интернет-трафика с использованием Next Hop Hub 2, межсетевого экрана Azure, NVA или SaaS.

Ниже приведены потоки трафика в такой конфигурации.

Развертывание как защищенных, так и обычных узлов виртуальной сети WAN

В этом сценарии не все узлы в глобальной сети являются защищенными виртуальными узлами WAN (узлами, в которых развернуто решение безопасности).

Рассмотрим приведенную ниже конфигурацию, где концентратор 1 (обычный) и концентратор 2 (защищенный) развернуты в виртуальной глобальной сети. В концентраторе 2 настроены политики маршрутизации частного и интернет-трафика.

Конфигурация концентратора 1:

• N/A (не удается настроить политики маршрутизации, если концентратор не развернут с помощью решения Брандмауэр Azure, NVA или SaaS)

Конфигурация концентратора 2:

• Политика частного трафика с решением Next Hop Hub 2: Azure Firewall, NVA или SaaS.
• Политика интернет-трафика с использованием решения "Next Hop Hub 2" с брандмауэром Azure, NVA или SaaS.

Ниже приведены потоки трафика в такой конфигурации. Ветви и виртуальная сеть, подключенные к Концентратору 1, не могут получить доступ к Интернету через решение безопасности, развернутое в Центре, так как маршрут по умолчанию (0.0.0.0/0) не распространяется между центрами.

Известные ограничения

• В следующей таблице описывается доступность намерения маршрутизации в разных средах Azure.
  • Намерение маршрутизации недоступно в Microsoft Azure, управляемом 21 Vianet.
  • Palo Alto Cloud NGFW доступен только в Общедоступной среде Azure. Обратитесь в Palo Alto Networks по вопросу доступности Cloud NGFW в Azure Government и Microsoft Azure под управлением Viacom.
  • Виртуальные сетевые устройства недоступны во всех регионах Azure для государственных организаций. Обратитесь к партнеру NVA относительно доступности в Azure для государственных организаций.

• Инструмент "Routing Intent" упрощает процесс маршрутизации, управляя сопоставлением таблиц маршрутов и распространением маршрутов для всех подключений: виртуальные сети, VPN "сеть-сеть", VPN "точка-сеть" и ExpressRoute. Виртуальные WAN с настраиваемыми таблицами маршрутов и политиками нельзя использовать с конструкциями намерений маршрутизации.
• Зашифрованные туннели ExpressRoute (туннели VPN типа "сеть-сеть", работающие через каналы ExpressRoute) поддерживаются на узлах, где настроено назначение маршрутизации, если Azure Firewall настроен на разрешение трафика между конечными точками VPN-туннеля (частный IP-адрес VPN-шлюза типа "сеть-сеть" и частный IP-адрес локального VPN-устройства). Дополнительные сведения о необходимых конфигурациях см. в разделе Encrypted ExpressRoute с целью маршрутизации.
• Следующие варианты использования подключения не поддерживаются при использовании намерения маршрутизации.
  • Статические маршруты в defaultRouteTable, указывающие на подключение виртуальной сети, нельзя использовать в сочетании с целью маршрутизации. Однако можно использовать функцию пиринга BGP.
  • Статические маршруты в соединении виртуальной сети с включённым распространением статических маршрутов не применяются к ресурсу следующего шага, указанному в политиках частной маршрутизации. Поддержка применения статических маршрутов в подключениях виртуальных сетей к следующему узлу политики частной маршрутизации включена в дорожную карту.
  • Возможность развертывания как подключения SD-WAN NVA, так и отдельного решения брандмауэра NVA или SaaS в одном и том же центре Виртуальной глобальной сети в настоящее время находится в дорожной карте. После настройки намерения маршрутизации с решением SaaS для следующего прыжка или с брандмауэром NVA, подключение между NVA SD-WAN и Azure может быть нарушено. Вместо этого разверните решение SD-WAN NVA и брандмауэра NVA или SaaS в разных виртуальных центрах. Кроме того, вы можете развернуть NVA SD-WAN в периферийной виртуальной сети, подключённой к концентратору, и использовать возможность пиринга BGP виртуального концентратора.
  • Виртуальные сетевые устройства (NVAs) можно указать только в качестве следующего узла для маршрутного намерения, если они являются брандмауером следующего поколения или выполняют двойную роль брандмауера следующего поколения и SD-WAN. В настоящее время checkpoint, fortinet-ngfw, fortinet-ngfw-and-sdwan и cisco-tdv-vwan-nva являются единственными NVA, которые могут быть настроены в качестве следующего шага для намерения маршрутизации. Если вы попытаетесь указать другой NVA, это приведет к сбою в создании намерения маршрутизации. Вы можете проверить тип NVA, перейдя к виртуальному концентратору —> сетевые виртуальные устройства, а затем просмотрите поле "Поставщик ". Palo Alto Networks Cloud NGFW также поддерживается в качестве следующего шага при маршрутизации, но рассматривается как следующий шаг типа SaaS-решения.
  • Пользователи с намерением маршрутизации, которые хотят подключить к Виртуальной глобальной сети несколько каналов ExpressRoute и отправлять трафик между ними через решение безопасности, развернутое в концентраторе, могут открыть запрос в службу поддержки, чтобы включить этот вариант использования. Для ознакомления с дополнительными сведениями см. Включение соединения между каналами ExpressRoute.

Ограничения адресного пространства виртуальной сети

При использовании клиентами намерения маршрутизации максимальное количество диапазонов адресов во всех виртуальных сетях, напрямую подключенных к одному концентратору Виртуальной глобальной сети, равно 400. Это ограничение применяется отдельно к каждому концентратору в развертывании Виртуальной глобальной сети. Адресные пространства виртуальных сетей, подключённые к удалённым узлам (другим концентраторам в той же Виртуальной глобальной сети), не учитываются в этом пределе.

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

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

В следующей таблице приведены примеры вычислений адресного пространства виртуальной сети.

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

Обязательно измените идентификатор ресурса центра Виртуальная глобальная сеть в скрипте, чтобы он соответствовал вашей среде. Если у вас есть подключения виртуальных сетей между арендаторами, убедитесь, что у вас есть достаточно разрешений для чтения объекта подключения виртуальной сети глобальной сети (Virtual WAN) и подключенного ресурса виртуальной сети.

$hubVNETconnections = Get-AzVirtualHubVnetConnection -ParentResourceId "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualHubs/<virtual hub name>"
$addressSpaceCount = 0
  
foreach($connection in $hubVNETconnections) {
  try{
    $resourceURI = $connection.RemoteVirtualNetwork.Id
    $RG = ($resourceURI -split "/")[4]
    $name = ($resourceURI -split "/")[8]
    $VNET = Get-AzVirtualNetwork -Name $name -ResourceGroupName $RG -ErrorAction "Stop"
    $addressSpaceCount += $VNET.AddressSpace.AddressPrefixes.Count
  }
  catch{
    Write-Host "An error occurred while processing VNET connected to Virtual WAN hub with resource URI:  " -NoNewline
    Write-Host $resourceURI 
    Write-Host "Error Message: " -ForegroundColor Red
    Write-Host $_.Exception.Message -ForegroundColor Red 
  }
  finally{
  }
}
Write-Host "Total Address Spaces in VNETs connected to this Virtual WAN Hub: " -ForegroundColor Green -NoNewline
Write-Host $addressSpaceCount -ForegroundColor Green

Рекомендации

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

Прежде чем включить намерение маршрутизации, рассмотрите следующее:

• Намерение маршрутизации можно настроить только на узлах, где нет пользовательских таблиц маршрутов и статических маршрутов в таблице маршрутов по умолчанию (DefaultRouteTable) с следующей точкой перехода в сетевом соединении. Дополнительные сведения см. в разделе Предварительные требования.
• Сохраните копию шлюзов, подключений и таблиц маршрутов перед включением параметров маршрутизации. Система не будет автоматически сохранять и применять предыдущие конфигурации. Дополнительные сведения см. в статье стратегия отката.
• Намерение маршрутизации изменяет статические маршруты в defaultRouteTable. Из-за оптимизации портала Azure состояние defaultRouteTable после настройки намерения маршрутизации может отличаться, если вы настраиваете намерение маршрутизации с помощью REST, CLI или PowerShell. Дополнительные сведения см. в статических маршрутах.
• Включение целевой маршрутизации влияет на объявление префиксов во внутреннюю сеть. Дополнительные сведения см. в разделе рекламные объявления префиксов.
• Вы можете открыть запрос в службу поддержки, чтобы включить подключение через сеть ExpressRoute с помощью устройства брандмауэра в концентраторе. Включение этого паттерна подключения изменяет рекламируемые префиксы в контурах ExpressRoute. Дополнительные сведения см. в разделе "О ExpressRoute ".
• Намерение маршрутизации — это единственный механизм в Виртуальной WAN для обеспечения проверки межузлового трафика с помощью средств безопасности, развернутых в узле. Для проверки трафика между концентраторами также требуется включить намерение маршрутизации на всех концентраторах, чтобы обеспечить симметричную маршрутизацию трафика между устройствами безопасности, развернутыми в концентраторах Виртуальной глобальной сети.
• Направление маршрутизации отправляет трафик из виртуальной сети и локальной сети в ресурс следующего узла, указанный в политике маршрутизации. Виртуальная WAN программирует базовую платформу Azure для маршрутизации трафика вашей локальной сети и трафика виртуальной сети в соответствии с настроенной политикой маршрутизации, не обрабатывая трафик через маршрутизатор Виртуального концентратора. Так как пакеты, перенаправленные с помощью намерения маршрутизации, не обрабатываются маршрутизатором, вам не нужно выделять дополнительные единицы маршрутизационной инфраструктуры для пересылки пакетов в плоскости данных на концентраторах, настроенных с использованием намерения маршрутизации. Однако может потребоваться выделить дополнительные единицы инфраструктуры маршрутизации на основе количества виртуальных машин в виртуальных сетях, подключенных к Концентратору виртуальной глобальной сети.
• Основные параметры маршрутизации позволяют настроить различные ресурсы следующего узла для частных и интернет-политик маршрутизации. Например, можно задать следующий узел для политик частной маршрутизации на Azure Firewall в узле и следующий узел для политики маршрутизации интернета на решение NVA или SaaS в узле. Так как решения SaaS и NVA брандмауэра развертываются в той же подсети в узле виртуальной глобальной сети, развертывание решений SaaS с NVA брандмауэра в том же узле может повлиять на горизонтальное масштабирование решений SaaS, так как для горизонтального масштабирования доступно меньше IP-адресов. Кроме того, в каждом узле виртуальной глобальной сети может быть развернуто не более одного решения SaaS.

Предварительные условия

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

• В виртуальном концентраторе нет настраиваемых таблиц маршрутов. Единственными таблицами маршрутов, которые существуют, являются noneRouteTable и defaultRouteTable.
• Вы не можете иметь статические маршруты с последующим узлом виртуального сетевого подключения. У вас в таблице маршрутизации defaultRouteTable могут быть статические маршруты, следующим узлом которых является Брандмауэр Azure.

Параметр настройки намерения маршрутизации неактивен для концентраторов, которые не соответствуют указанным выше требованиям.

Использование намерения маршрутизации (включение опции между концентраторами) в диспетчере Брандмауэра Azure имеет дополнительное требование:

• Маршруты, созданные диспетчером Брандмауэр Azure, соответствуют соглашению об именовании private_traffic, internet_traffic или all_traffic. Поэтому все маршруты в defaultRouteTable должны соответствовать этому соглашению.

Стратегия отката

Намерение маршрутизации упрощает маршрутизацию и настройку путем управления сопоставлениями маршрутов и распространением всех подключений в концентраторе.

В следующей таблице описана связанная таблица маршрутов и распространяемые таблицы маршрутов всех подключений после настройки намерения маршрутизации.

Статические маршруты в defaultRouteTable

В следующем разделе описывается, как функционал маршрутизации управляет статическими маршрутами в таблице маршрутов по умолчанию при активации маршрутизации в узле концентрации. Изменения, внесенные намерением маршрутизации в значение defaultRouteTable, необратимы.

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

Диспетчер брандмауэра Azure и портал узла виртуальной глобальной сети.

Если намерение маршрутизации включено в концентраторе, статические маршруты, соответствующие настроенным политикам маршрутизации, создаются автоматически в defaultRouteTable. Эти маршруты:

Например, рассмотрим сценарий, в котором defaultRouteTable имеет следующие маршруты перед настройкой намерения маршрутизации:

Включение маршрутизации в этом концентраторе приведет к следующему конечному состоянию таблицы маршрутизации по умолчанию. Все префиксы, не RFC1918 или 0.0.0.0/0/0, объединяются в один маршрут с именем private_traffic.

Другие методы (PowerShell, REST, CLI)

Создание маршрутизационной политики с использованием методов, не связанных с порталом, автоматически создает соответствующие маршруты политики в defaultRouteTable, а также удаляет любые префиксы в статических маршрутах, которые точно совпадают с 0.0.0.0/0 или суперсетями RFC1918 (10.0.0.0/8, 192.168.0.0/16 или 172.16.0.0/12). Однако другие статические маршруты не объединяются автоматически.

Например, рассмотрим сценарий, в котором defaultRouteTable имеет следующие маршруты перед настройкой намерения маршрутизации:

Следующая таблица представляет окончательное состояние defaultRouteTable после успешного создания намерения маршрутизации. Обратите внимание, что firewall_route_1 и to_internet автоматически удалены в качестве единственного префикса в этих маршрутах: 10.0.0.0/8 и 0.0.0.0/0/0. firewall_route_2 было изменено, чтобы удалить 192.168.0.0/16, так как этот префикс является RFC1918 агрегатным префиксом.

Объявление префикса для локальной инфраструктуры

В следующем разделе описывается, как Виртуальная глобальная сеть объявляет маршруты в локальную среду после настройки намерения маршрутизации в виртуальном концентраторе.

Политика маршрутизации через Интернет

Если вы включите политики маршрутизации Интернета в Виртуальном концентраторе, маршрут по умолчанию 0.0.0.0/0 будет объявлен для всех подключений к концентратору (виртуальная сеть ExpressRoute, VPN типа "сеть-сеть", VPN типа "точка-сеть", NVA в концентраторе и подключениях BGP), где установлен флаг распространения маршрута по умолчанию или включена интернет-безопасность и установлено значение true. Можно установить этот флаг в значение false для всех подключений, которые не должны учить маршрут по умолчанию.

Политика частной маршрутизации

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

• Маршруты, соответствующие префиксам, полученным из виртуальных сетей локального концентратора, ExpressRoute, VPN типа "сеть — сеть", VPN типа "точка — сеть", "NVA в концентраторе" или подключений BGP, соединенных с текущим концентратором.
• Маршруты, соответствующие префиксам, извлеченным из удаленных концентраторов виртуальных сетей, ExpressRoute, VPN типа «сеть-сеть», VPN типа «точка-сеть», NVA в узле или подключений BGP, где настроены политики частной маршрутизации.
• Маршруты, соответствующие префиксам, извлеченным из удаленных концентраторов виртуальных сетей, ExpressRoute, VPN типа 'сеть-сеть', VPN типа 'точка-сеть', NVA-in-the-hub и подключениям BGP, где намерение маршрутизации не настроено, а удаленные подключения распространяются в таблицу маршрутов по умолчанию локального концентратора.
• Префиксы, полученные из одного канала ExpressRoute, не объявляются другим каналам ExpressRoute, пока не включена функция Global Reach. Если вы хотите включить транзит через ExpressRoute в ExpressRoute через решение безопасности, развернутое в центре, откройте заявку в поддержку. Дополнительные сведения см. в разделе "Включение подключения через схемы ExpressRoute".

Сценарии ключевой маршрутизации

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

Транзитное подключение между каналами ExpressRoute с намерением маршрутизации

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

• ExpressRoute Global Reach: ExpressRoute Global Reach позволяет двум каналам с поддержкой Global Reach обмениваться трафиком напрямую без прохождения через виртуальный концентратор.
• Политика частной маршрутизации Routing Intent: Настройка политик частной маршрутизации позволяет двум каналам ExpressRoute отправлять трафик друг другу через средство безопасности, развернутое в хабе.

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

• Оба канала ExpressRoute подключены к одному концентратору, а политика частной маршрутизации настроена в этом концентраторе.
• Каналы ExpressRoute подключены к разным концентраторам, а политика частной маршрутизации настроена в обоих центрах. Таким образом, оба центра должны развертывать решение для обеспечения безопасности.

Рекомендации по маршрутизации с помощью ExpressRoute

После включения транзитного подключения между каналами ExpressRoute с помощью устройства брандмауэра, развернутого в виртуальном концентраторе, можно ожидать следующие изменения в поведении в том, как маршруты объявляются в локальной среде ExpressRoute:

• Виртуальная глобальная сеть автоматически рекламирует агрегированные префиксы RFC1918 (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) в корпоративную сеть, подключенную к ExpressRoute. Эти агрегатные маршруты объявляются в дополнение к маршрутам, описанным в предыдущем разделе.
• Виртуальная сеть WAN автоматически объявляет все статические маршруты в таблице маршрутов по умолчанию для локальных сетей, подключённых через канал ExpressRoute. Это означает, что Виртуальная глобальная сеть объявляет маршруты, указанные в текстовом поле префикса частного трафика, в локальную среду.

В результате этих изменений объявления маршрутов, локальные подключения ExpressRoute не могут указывать точные диапазоны адресов для агрегированных диапазонов адресов RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Убедитесь, что вы рекламируете более конкретные подсети (в пределах RFC1918 диапазонов) в отличие от агрегатных суперсетей и любых префиксов в текстовом поле "Частный трафик".

Кроме того, если линия ExpressRoute рекламирует префикс, не соответствующий RFC1918 в Azure, убедитесь, что адресные диапазоны, которые вы вводите в текстовое поле префиксов частного трафика, менее конкретные, чем объявленные маршруты ExpressRoute. Например, если канал ExpressRoute анонсирует 40.0.0.0/24 из локальной среды, поместите диапазон CIDR /23 или больше в текстовое поле префикса частного трафика (например, 40.0.0.0/23).

Маршрутизация объявлений в другие локальные сети (VPN типа "сеть — сеть", VPN типа "точка — сеть", NVA) не оказывает влияния на соединение ExpressRoute к транзитной сети ExpressRoute через устройство безопасности, развернутое в концентраторе.

Защищенное соединение ExpressRoute

Чтобы использовать зашифрованный ExpressRoute (VPN-туннель типа "сеть-сеть" через канал ExpressRoute) с политиками частной маршрутизации, настройте правило брандмауэра, чтобы разрешить трафик между частными IP-адресами туннеля Виртуального WAN шлюза "сеть-сеть" (источник) и локальным VPN-устройством (назначение). Для клиентов, использующих глубокую проверку пакетов на устройстве брандмауэра, рекомендуется не подвергать глубокой проверке пакетов трафик между этими частными IP-адресами.

Вы можете получить частные IP-адреса туннеля шлюза VPN "Точка-точка" виртуальной глобальной сети, загрузив конфигурацию VPN и проверив vpnSiteConnections: gatewayConfiguration: IPAddresses. IP-адреса, перечисленные в поле IPAddresses, являются частными IP-адресами, назначенными каждому экземпляру VPN-шлюза типa "сеть-сеть", который используется для завершения VPN-туннелей по сети ExpressRoute. В приведенном ниже примере IP-адреса туннеля на шлюзе — 192.168.1.4 и 192.168.1.5.

 "vpnSiteConnections": [
      {
        "hubConfiguration": {
          "AddressSpace": "192.168.1.0/24",
          "Region": "South Central US",
          "ConnectedSubnets": [
            "172.16.1.0/24",
            "172.16.2.0/24",
            "172.16.3.0/24",
            "192.168.50.0/24",
            "192.168.0.0/24"
          ]
        },
        "gatewayConfiguration": {
          "IpAddresses": {
            "Instance0": "192.168.1.4",
            "Instance1": "192.168.1.5"
          },
          "BgpSetting": {
            "Asn": 65515,
            "BgpPeeringAddresses": {
              "Instance0": "192.168.1.15",
              "Instance1": "192.168.1.12"
            },
            "CustomBgpPeeringAddresses": {
              "Instance0": [
                "169.254.21.1"
              ],
              "Instance1": [
                "169.254.21.2"
              ]
            },
            "PeerWeight": 0
          }
        }

Частные IP-адреса локальных устройств, используемые для завершения VPN, — это IP-адреса, указанные в рамках подключения сайта VPN.

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

Производительность зашифрованного ExpressRoute

Настройка политик частной маршрутизации для Encrypted ExpressRoute направляет пакеты VPN ESP через устройство безопасности следующего узла, развернутое в концентраторе. В результате можно ожидать, что максимальная пропускная способность VPN-туннеля ExpressRoute в зашифрованном режиме составляет 1 Гбит/с в обоих направлениях (входящий трафик из локальной среды и исходящего трафика из Azure). Чтобы достичь максимальной пропускной способности VPN-туннеля, рассмотрите следующие оптимизации развертывания:

• Разверните Брандмауэр Azure Premium вместо Брандмауэр Azure уровня "Стандартный" или Брандмауэр Azure "Базовый".
• Убедитесь, что Брандмауэр Azure обрабатывает правило, разрешающее трафик между конечными точками VPN-туннеля (192.168.1.1.4 и 192.168.1.5 в приведенном выше примере), сначала сделав правило самым высоким приоритетом в политике Брандмауэр Azure. Дополнительные сведения о логике обработки правил Брандмауэра Azure см. в соответствующем разделе.
• Отключите глубокий пакет для трафика между конечными точками VPN-туннеля. Чтобы получить информацию о том, как настроить брандмауэр Azure для исключения трафика из глубокой проверки пакетов, обратитесь к документации по списку обхода IDPS.
• Настройте VPN-устройства для использования GCMAES256 для шифрования и целостности IPSEC для повышения производительности.

Прямая маршрутизация к экземплярам NVA для двойной роли подключения и брандмауэрных NVA.

Некоторые сетевые виртуальные устройства могут иметь возможности подключения (SD-WAN) и безопасности (NGFW) на одном устройстве. Эти NVAs считаются устройствами с двойной ролью. Проверьте, является ли ваш NVA двойной функцией NVA среди партнёров NVA.

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

Для активно-пассивных конфигураций NVA, где только один экземпляр NVA рекламирует маршрут для определенного префикса в Виртуальной глобальной сети (или длина маршрутов AS-PATH, полученных из одного из экземпляров, всегда самая короткая), Виртуальная глобальная сеть гарантирует, что исходящий трафик из виртуальной сети Azure всегда направляется в активный (или предпочтительный) экземпляр NVA.

Для конфигураций NVA "active-active" (несколько экземпляров NVA объявляют один и тот же префикс с той же длиной AS-PATH) Azure автоматически использует ECMP для маршрутизации трафика из Azure в локальную инфраструктуру. Программно-определяемая сетевая платформа Azure не гарантирует симметрию уровня потока, то есть входящий поток в Azure и исходящий поток из Azure может приземлиться на разных экземплярах NVA. Это приводит к асимметричной маршрутизации, которая блокируется проверкой брандмауэра с учетом состояния. Поэтому не рекомендуется использовать шаблоны подключения active-active, при которых NVA выполняет двойную роль, если NVA не может поддерживать асимметричное перенаправление или совместное использование и синхронизацию сеансов. Дополнительные сведения о том, поддерживает ли NVA асимметричное перенаправление или синхронизацию состояния сеанса, можно получить, обратившись к поставщику NVA.

Настройка намерения маршрутизации на портале Azure

Назначение маршрутизации и политики маршрутизации можно настроить через портал Azure с помощью диспетчера Azure Firewall или портала Virtual WAN. Портал диспетчера брандмауэра Azure позволяет настроить политики маршрутизации с использованием Azure Firewall в качестве ресурса для следующего перехода. Портал Azure Virtual WAN позволяет настраивать политики маршрутизации с использованием ресурса следующего перехода Azure Firewall, сетевых виртуальных устройств, развернутых в виртуальном узле, или решений SaaS.

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

Настройка намерения маршрутизации и политик с помощью диспетчера Брандмауэр Azure

Ниже описано, как настроить намерения маршрутизации и политики маршрутизации в виртуальном концентраторе с помощью диспетчера Брандмауэр Azure. Менеджер брандмауэров Azure поддерживает только ресурсы следующего узла типа Брандмауэр Azure.

1. Перейдите к концентратору виртуальной глобальной сети, на котором вы хотите настроить политики маршрутизации.

2. В разделе "Безопасность" выберите параметры защищенного виртуального концентратора, а затем выберите "Управление поставщиком безопасности" и параметрами маршрута для этого защищенного виртуального концентратора в диспетчере Брандмауэр Azure.

3. Выберите в меню концентратор, в котором нужно настроить политики маршрутизации.

4. Выберите пункт Конфигурация безопасности в разделе Параметры.

5. Если вам нужно настроить политику маршрутизации интернет-трафика, выберите Брандмауэр Azure или соответствующего поставщика безопасности в раскрывающемся списке Интернет-трафик. В противном случае выберите Нет.

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

   

7. Если вам нужно настроить политику маршрутизации частного трафика и у вас есть ветви или частные сети с несовместимыми с IANA RFC1918 префиксами, выберите Префиксы частного трафика и укажите диапазоны несовместимых с IANA RFC1918 префиксов в появившемся текстовом поле. Нажмите кнопку Готово.

   

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

9. Выберите Сохранить.

10. Повторите действия 2–8 для других защищенных концентраторов виртуальных глобальных сетей, для которых требуется настроить политики маршрутизации.

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

Настройка намерений и политик маршрутизации с помощью портала Виртуальная глобальная сеть

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

1. Перейдите по специальной ссылке на портал из сообщения с подтверждением, полученного на 3-м шаге раздела Предварительные требования, перейдите к концентратору Виртуальной глобальной сети, в котором нужно настроить политики маршрутизации.

2. В разделе "Маршрутизация" выберите Политики маршрутизации.

   

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

   

4. Если вам нужно настроить политику маршрутизации частного трафика и у вас есть ветви или частные сети с несовместимыми с IANA RFC1918 префиксами, выберите Дополнительные префиксы и укажите диапазоны несовместимых с IANA RFC1918 префиксов в появившемся текстовом поле. Нажмите кнопку Готово. Убедитесь, что вы добавили один и тот же префикс в текстовое поле префикса частного трафика во всех виртуальных концентраторах, настроенных с помощью политик частной маршрутизации, чтобы убедиться, что правильные маршруты объявляются всем концентраторам.

   

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

   

6. Чтобы применить конфигурацию намерений маршрутизации и политик маршрутизации, щелкните Сохранить.

   

7. Повторите для всех концентраторов, для которых вы хотите настроить политики маршрутизации.

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

Настройка намерения маршрутизации с помощью файла Bicep

Сведения о шаблоне и шагах см. в файле Bicep .

Устранение неполадок

В следующем разделе описаны распространенные способы устранения неполадок при настройке намерения маршрутизации и политик в центре Виртуальная глобальная сеть.

Фактические маршруты

При настройке политик частной маршрутизации в Виртуальном концентраторе весь трафик между локальными и виртуальными сетями проверяется файрволом Azure, сетевым виртуальным устройством или решением SaaS в Виртуальном концентраторе.

Таким образом, маршруты по умолчанию в RouteTable показывают агрегированные префиксы RFC1918 (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) со следующим переходом через брандмауэр Azure или сетевую виртуальную аппаратуру. Это отражает, что весь трафик между виртуальными сетями и филиалами направляется на Брандмауэр Azure, NVA или SaaS-решение в центре для проверки.

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

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

Устранение проблем с конфигурацией

Если вы устраняете неполадки конфигурации, рассмотрите следующие моменты:

• Убедитесь, что у вас нет пользовательских таблиц маршрутов или статических маршрутов в "defaultRouteTable" со следующим переходом через подключение к виртуальной сети.
  • Параметр настройки намерения маршрутизации неактивен в портале Azure, если развертывание не соответствует приведенным выше требованиям.
  • Если вы используете CLI, PowerShell или REST, операция создания намерения маршрутизации завершается сбоем. Удалите неудачное намерение маршрутизации, удалите пользовательские таблицы маршрутов и статические маршруты, а затем попробуйте создать их заново.
  • Если вы используете диспетчер Брандмауэр Azure, убедитесь, что существующие маршруты в defaultRouteTable называются private_traffic, internet_traffic или all_traffic. Опция настройки маршрутизации (включение взаимодействия между узлами) неактивна, если маршруты названы по-разному.
• После настройки намерения маршрутизации в концентраторе убедитесь, что все обновления существующих подключений или новые подключения к концентратору создаются с пустыми необязательными полями ассоциированной и распространяемой таблицы маршрутов. Задание необязательных связей и распространений как пустых осуществляется автоматически для всех операций, проводящихся через портал Azure.

Устранение неполадок в передаче данных

Если вы уже ознакомились с разделом "Известные ограничения", ниже приведены некоторые способы устранения неполадок с подключениями и передачей данных.

• Устранение неполадок с действующими маршрутами:
  • Если политики частной маршрутизации настроены, вы должны увидеть маршруты с брандмауэром следующего прыжка в эффективных маршрутах defaultRouteTable для агрегатов RFC1918 (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12), а также любые префиксы, указанные в текстовом поле частного трафика. Убедитесь, что все префиксы виртуальных сетей и локальных сетей являются подсетями в статических маршрутах в defaultRouteTable. Если локальная или виртуальная сеть использует адресное пространство, которое не является подсетью в эффективных маршрутах в defaultRouteTable, добавьте префикс в текстовое поле частного трафика.
  • Если политики маршрутизации интернет-трафика настроены, в эффективных маршрутах таблицы маршрутов по умолчанию должен отображаться маршрут (0.0.0.0/0).
  • Убедившись, что действующие маршруты defaultRouteTable имеют правильные префиксы, просмотрите действующие маршруты сетевого виртуального устройства или Брандмауэр Azure. Эффективные маршруты на брандмауэре показывают, какие маршруты выбраны Виртуальной глобальной сетью и определяют, в какие узлы брандмауэр может пересылать пакеты. Определение отсутствующих или находящихся в неправильном состоянии префиксов помогает сузить проблемы с путем к данным и указать на правильное подключение VPN, ExpressRoute, NVA или BGP для устранения неполадок.
• Устранение неполадок, связанных с сценарием:
  • Если у вас есть незащищенный концентратор (концентратор без Azure Firewall или NVA) в Виртуальная WAN, убедитесь, что подключения к незащищенным концентраторам распространяются в таблицу маршрутов по умолчанию концентраторов с настроенным намерением маршрутизации. Если для распространения не задано значение defaultRouteTable, подключения к защищенному концентратору не смогут отправлять пакеты в незащищенный концентратор.
  • Если у вас настроены политики маршрутизации Интернета, убедитесь, что параметр "Распространение маршрута по умолчанию" или параметр "Включить интернет-безопасность" имеет значение true для всех подключений, которые должны узнать маршрут по умолчанию 0.0.0.0/0. Подключения, в которых этот параметр имеет значение false, не изучат маршрут 0.0.0.0/0, даже если настроены политики маршрутизации Интернета.
  • Если вы используете частные конечные точки, развернутые в виртуальных сетях, подключенных к виртуальному концентратору, трафик из локальной среды, предназначенный для частных конечных точек, развернутых в виртуальных сетях, подключенных к концентратору Виртуальной глобальной сети, по умолчанию обходит следующую точку маршрутизации, предназначенную для Azure Firewall, NVA или SaaS. Однако это приводит к асимметричной маршрутизации (из-за которой возможен разрыв связи между локальными и частными конечными точками), поскольку частные конечные точки в периферийных виртуальных сетях направляют локальный трафик к брандмауэру. Чтобы обеспечить симметричную маршрутизацию, включите политики сети таблицы маршрутизации для частных конечных точек в подсетях, где развертываются частные конечные точки. Настройка маршрутов /32, соответствующих частным IP-адресам частной конечной точки в текстовом поле "Частный трафик", не гарантирует симметрию трафика при настройке политик частной маршрутизации в концентраторе.
  • Если вы используете Encrypted ExpressRoute с политиками частной маршрутизации, убедитесь, что на вашем устройстве брандмауэра настроено правило, разрешающее трафик между частной IP-туннельной конечной точкой VPN-шлюза связи "сайт-с-сайтом" Виртуальной глобальной сети и локальным VPN-устройством. Пакеты ESP (зашифрованные внешние) должны записываться в журналы Azure Firewall. Дополнительные сведения о Encrypted ExpressRoute с маршрутизацией по назначению см. в документации по Encrypted ExpressRoute.
  • Если вы используете пользовательские таблицы маршрутов в периферийных виртуальных сетях, убедитесь, что параметр "Распространение маршрутов шлюза" имеет значение "Да" в таблице маршрутов. Для распространения маршрутов на рабочие нагрузки, развернутые в периферийных виртуальных сетях, подключенных к Виртуальной глобальной сети, необходимо включить параметр "Распространение маршрутов шлюза" в Виртуальной глобальной сети. Дополнительные сведения о параметрах таблицы маршрутов, определяемых пользователем, см. в документации по маршрутизации виртуальной сети, определяемой пользователем.

Устранение неполадок с маршрутизацией Брандмауэр Azure

• Убедитесь, что состояние развертывания брандмауэра Azure успешное прежде чем пытаться настроить намерение маршрутизации.
• Если вы используете отличные от IANA RFC1918 префиксы в ветвях или виртуальных сетях, убедитесь, что вы указали эти префиксы в текстовом поле «Частные префиксы». Настроенные "Частные префиксы" не распространяются автоматически на другие центры в Виртуальную глобальную сеть, которая была настроена с намерением маршрутизации. Чтобы обеспечить подключение, добавьте эти префиксы в текстовое поле "Частные префиксы" в каждом отдельном концентраторе с намерением маршрутизации.
• Если в текстовом поле Префиксы частного трафика в Диспетчере брандмауэра указаны адреса, отличные от RFC1918, может потребоваться настроить в брандмауэре политики SNAT, которые отключают SNAT для частного трафика с адресами, несовместимыми с RFC1918. Дополнительные сведения см. в диапазонах SNAT брандмауэра Azure.
• Для устранения неполадок и анализа сетевого трафика рекомендуем настроить и просмотреть журналы Брандмауэра Azure. Дополнительные сведения о настройке мониторинга для Брандмауэра Azure см. в разделе Диагностика Брандмауэра Azure. Для получения общей информации о различных типах журналов брандмауэра см. журналы и метрики Azure Firewall.
• Дополнительные сведения о Брандмауэре Azure см. в документации по Брандмауэру Azure.

Устранение неполадок с виртуальными сетевыми модулями

• Убедитесь, что состояние развертывания сетевого виртуального устройства успешно завершено прежде чем пытаться настроить направленность маршрутизации.
• Если вы используете префиксы, отличные от префиксов IANA RFC1918 в подключенных локальных или виртуальных сетях, убедитесь, что эти префиксы указаны в поле "Частные префиксы". Настроенные "Частные префиксы" не распространяются автоматически на другие центры в Виртуальную глобальную сеть, которая была настроена с намерением маршрутизации. Чтобы обеспечить подключение, добавьте эти префиксы в текстовое поле "Частные префиксы" в каждом отдельном концентраторе с намерением маршрутизации.
• Если вы указали адреса, не являющиеся RFC1918, в текстовом поле префиксов частного трафика, может потребоваться настроить политики SNAT в NVA, чтобы отключить SNAT для определенного частного трафика, не являющегося RFC1918.
• Проверьте журналы брандмауэра NVA, чтобы узнать, блокируется или отклоняется ли трафик вашими правилами брандмауэра.
• Обратитесь к поставщику NVA для получения дополнительной поддержки и рекомендаций по устранению неполадок.

Устранение неполадок программного обеспечения как службы

• Убедитесь, что состояние подготовки решения SaaS выполнено успешно, прежде чем пытаться настроить параметры маршрутизации.
• Дополнительные советы по устранению неполадок см. в разделе "Устранение неполадок" в документации по Виртуальной сети WAN или в документации по Palo Alto Networks Cloud NGFW.

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

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