Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Маршрутизационное намерение в концентраторе виртуальной глобальной сети позволяет настраивать простые и декларативные политики маршрутизации для отправки трафика во встроенные в сеть решения безопасности, такие как 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.
Ниже приведены потоки трафика в такой конфигурации.
Примечание.
Интернет-трафик должен выходить через локальное решение безопасности в концентраторе, так как маршрут по умолчанию (0.0.0.0/0) не распространяется между хабами.
От | к | Виртуальные сети узла 1 | Ветви хаба 1 | Хаб 2 VNets | Узел 2 | Интернет |
---|---|---|---|---|---|---|
Виртуальные сети узла 1 | → | Хаб 1 AzFW или NVA | Хаб 1 AzFW или NVA | Узел 1 и 2 AzFW, NVA или SaaS | Узел 1 и 2 AzFW, NVA или SaaS | Центр 1 AzFW, NVA или SaaS |
Филиалы узла 1 | → | Центр 1 AzFW, NVA или SaaS | Центр 1 AzFW, NVA или SaaS | Узел 1 и 2 AzFW, NVA или SaaS | Узел 1 и 2 AzFW, NVA или SaaS | Центр 1 AzFW, NVA или SaaS |
Хаб 2 VNets | → | Узел 1 и 2 AzFW, NVA или SaaS | Узел 1 и 2 AzFW, NVA или SaaS | Шлюз 2 AzFW, NVA или SaaS | Шлюз 2 AzFW, NVA или SaaS | Шлюз 2 AzFW, NVA или SaaS |
Ответвления концентратора Hub 2 | → | Узел 1 и 2 AzFW, NVA или SaaS | Узел 1 и 2 AzFW, NVA или SaaS | Шлюз 2 AzFW, NVA или SaaS | Шлюз 2 AzFW, NVA или SaaS | Хаб 2AzFW, 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) не распространяется между центрами.
От | к | Виртуальные сети узла 1 | Ветви хаба 1 | Хаб 2 VNets | Узел 2 | Интернет |
---|---|---|---|---|---|---|
Виртуальные сети узла 1 | → | Напрямую | Напрямую | Шлюз 2 AzFW, NVA или SaaS | Шлюз 2 AzFW, NVA или SaaS | - |
Филиалы узла 1 | → | Напрямую | Напрямую | Шлюз 2 AzFW, NVA или SaaS | Шлюз 2 AzFW, NVA или SaaS | - |
Хаб 2 VNets | → | Шлюз 2 AzFW, NVA или SaaS | Шлюз 2 AzFW, NVA или SaaS | Шлюз 2 AzFW, NVA или SaaS | Шлюз 2 AzFW, NVA или SaaS | Шлюз 2 AzFW, NVA или SaaS |
Ответвления концентратора Hub 2 | → | Шлюз 2 AzFW, NVA или SaaS | Шлюз 2 AzFW, NVA или SaaS | Шлюз 2 AzFW, NVA или SaaS | Шлюз 2 AzFW, NVA или SaaS | Шлюз 2 AzFW, NVA или SaaS |
Известные ограничения
- В следующей таблице описывается доступность намерения маршрутизации в разных средах Azure.
- Намерение маршрутизации недоступно в Microsoft Azure, управляемом 21 Vianet.
- Palo Alto Cloud NGFW доступен только в Общедоступной среде Azure. Обратитесь в Palo Alto Networks по вопросу доступности Cloud NGFW в Azure Government и Microsoft Azure под управлением Viacom.
- Виртуальные сетевые устройства недоступны во всех регионах Azure для государственных организаций. Обратитесь к партнеру NVA относительно доступности в Azure для государственных организаций.
Облачная среда | Брандмауэр Azure | Сетевой виртуальный модуль | Решения SaaS |
---|---|---|---|
Общедоступная служба Azure | Да | Да | Да |
Azure для государственных организаций | Да | Ограничено | Нет |
Microsoft Azure, управляемый 21 Vianet | Нет | Нет | Нет |
- Инструмент "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.
Ограничения адресного пространства виртуальной сети
Примечание.
Максимальное количество адресных пространств виртуальных сетей, которые можно подключить к одному Виртуальному глобальному сетевому хабу, можно изменить. Создайте заявку в поддержку Azure для запроса увеличения лимита. Ограничения применимы на уровне концентратора Виртуальной глобальной сети. Если у вас несколько центров виртуальной глобальной сети, для которых требуется увеличение предела, запросите увеличение предела для всех центров виртуальной глобальной сети в вашем развертывании.
При использовании клиентами намерения маршрутизации максимальное количество диапазонов адресов во всех виртуальных сетях, напрямую подключенных к одному концентратору Виртуальной глобальной сети, равно 400. Это ограничение применяется отдельно к каждому концентратору в развертывании Виртуальной глобальной сети. Адресные пространства виртуальных сетей, подключённые к удалённым узлам (другим концентраторам в той же Виртуальной глобальной сети), не учитываются в этом пределе.
Если число напрямую подключенных адресных пространств виртуальных сетей, подключенных к концентратору, превышает ограничение, включение или обновление маршрутизации в Виртуальном концентраторе будет невозможным. Для центров, уже настроенных с намерением маршрутизации, в котором адресные пространства виртуальной сети превышают ограничение в результате операции, такой как обновление адресного пространства виртуальной сети, новое подключенное адресное пространство может не быть маршрутизируемым.
Заранее запрашивайте увеличение лимита, если общее количество адресных пространств во всех локально подключенных виртуальных сетях превышает 90 % от задокументированного ограничения или если у вас есть запланированные операции расширения сети или развертывания, которые увеличат количество адресных пространств виртуальных сетей за пределы лимита.
В следующей таблице приведены примеры вычислений адресного пространства виртуальной сети.
Виртуальный концентратор | количество виртуальных сетей | Адресные пространства на виртуальную сеть | Общее количество адресных пространств виртуальных сетей, подключенных к Виртуальному концентратору | Рекомендуемое действие |
---|---|---|---|---|
Концентратор #1 | 200 | 1 | 200 | Никаких действий не требуется, отслеживайте количество адресного пространства. |
Узел #2 | сто пятьдесят | 3 | 450 | Увеличение ограничения запросов для использования намерения маршрутизации. |
Хаб #3 | 370 | 1 | 370 | Запрос на увеличение лимита. |
С помощью следующего скрипта 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 должны соответствовать этому соглашению.
Стратегия отката
Примечание.
Если конфигурация намерения маршрутизации полностью удалена из концентратора, все подключения к концентратору будут перенаправляться на метку по умолчанию (которая применяется ко всем таблицам маршрутов по умолчанию в Виртуальной WAN). В результате, если вы рассматриваете возможность реализации маршрутизации Intent в Virtual WAN, необходимо сохранить копию существующих конфигураций (шлюзов, подключений, таблиц маршрутов), чтобы вернуть систему к исходной конфигурации при необходимости. Система не восстанавливает предыдущую конфигурацию автоматически.
Намерение маршрутизации упрощает маршрутизацию и настройку путем управления сопоставлениями маршрутов и распространением всех подключений в концентраторе.
В следующей таблице описана связанная таблица маршрутов и распространяемые таблицы маршрутов всех подключений после настройки намерения маршрутизации.
Конфигурация намерения маршрутизации | Связанная таблица маршрутов | Распространяемые таблицы маршрутов |
---|---|---|
Интернет | таблица маршрутов по умолчанию | метка по умолчанию (defaultRouteTable всех центров в виртуальной глобальной сети) |
Частный | таблица маршрутов по умолчанию | ОтсутствуетТаблицаМаршрутов |
Интернет и конфиденциальность | таблица маршрутов по умолчанию | ОтсутствуетТаблицаМаршрутов |
Статические маршруты в defaultRouteTable
В следующем разделе описывается, как функционал маршрутизации управляет статическими маршрутами в таблице маршрутов по умолчанию при активации маршрутизации в узле концентрации. Изменения, внесенные намерением маршрутизации в значение defaultRouteTable, необратимы.
При удалении намерения маршрутизации необходимо вручную восстановить предыдущую конфигурацию. Поэтому перед включением функции маршрутизации рекомендуется сохранить снимок конфигурации.
Диспетчер брандмауэра Azure и портал узла виртуальной глобальной сети.
Если намерение маршрутизации включено в концентраторе, статические маршруты, соответствующие настроенным политикам маршрутизации, создаются автоматически в defaultRouteTable. Эти маршруты:
Имя маршрута | Префиксы | Ресурс следующего прыжка |
---|---|---|
_политика_ЧастныйТрафик | 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 | Брандмауэр Azure |
_политика_ОбщественныйТрафик | 0.0.0.0/0 | Брандмауэр Azure |
Примечание.
Любые статические маршруты в defaultRouteTable, содержащие префиксы, которые не являются точными соответствиями для 0.0.0.0/0 или суперсетей RFC1918 (10.0.0.0/8, 192.168.0.0/16 и 172.16.0.0/12), автоматически объединяются в один статический маршрут с именем private_traffic. Префиксы в defaultRouteTable, соответствующие RFC1918 суперсетям или 0.0.0.0/0, всегда удаляются автоматически после настройки намерения маршрутизации независимо от типа политики.
Например, рассмотрим сценарий, в котором defaultRouteTable имеет следующие маршруты перед настройкой намерения маршрутизации:
Имя маршрута | Префиксы | Ресурс следующего прыжка |
---|---|---|
частный трафик | 192.168.0.0/16, 172.16.0.0/12, 40.0.0.0/24, 10.0.0.0/24 | Брандмауэр Azure |
к_интернету | 0.0.0.0/0 | Брандмауэр Azure |
дополнительный_личный | 10.0.0.0/8, 50.0.0.0/24 | Брандмауэр Azure |
Включение маршрутизации в этом концентраторе приведет к следующему конечному состоянию таблицы маршрутизации по умолчанию. Все префиксы, не RFC1918 или 0.0.0.0/0/0, объединяются в один маршрут с именем private_traffic.
Имя маршрута | Префиксы | Ресурс следующего прыжка |
---|---|---|
_политика_ЧастныйТрафик | 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 | Брандмауэр Azure |
_политика_ОбщественныйТрафик | 0.0.0.0/0 | Брандмауэр Azure |
частный трафик | 40.0.0.0/24, 10.0.0.0/24, 50.0.0.0/24 | Брандмауэр Azure |
Другие методы (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 имеет следующие маршруты перед настройкой намерения маршрутизации:
Имя маршрута | Префиксы | Ресурс следующего прыжка |
---|---|---|
маршрут_фаервол_ 1 | 10.0.0.0/8 | Брандмауэр Azure |
firewall_route_2 | 192.168.0.0/16, 10.0.0.0/24 | Брандмауэр Azure |
маршрут_брандмауэра_3 | 40.0.0.0/24 | Брандмауэр Azure |
к_интернету | 0.0.0.0/0 | Брандмауэр Azure |
Следующая таблица представляет окончательное состояние 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 агрегатным префиксом.
Имя маршрута | Префиксы | Ресурс следующего прыжка |
---|---|---|
_политика_ЧастныйТрафик | 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 | Брандмауэр Azure |
_политика_ОбщественныйТрафик | 0.0.0.0/0 | Брандмауэр Azure |
firewall_route_2 | 10.0.0.0/24 | Брандмауэр Azure |
маршрут_брандмауэра_3 | 40.0.0.0/24 | Брандмауэр Azure |
Объявление префикса для локальной инфраструктуры
В следующем разделе описывается, как Виртуальная глобальная сеть объявляет маршруты в локальную среду после настройки намерения маршрутизации в виртуальном концентраторе.
Политика маршрутизации через Интернет
Примечание.
Маршрут по умолчанию 0.0.0.0/0 не распространяется по виртуальным хабам.
Если вы включите политики маршрутизации Интернета в Виртуальном концентраторе, маршрут по умолчанию 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 к ExpressRoute через устройство брандмауэра в концентраторе с приватными политиками маршрутизации, откройте обращение в службу поддержки Майкрософт. Этот параметр не совместим с Global Reach и требует отключения global Reach, чтобы обеспечить правильную транзитную маршрутизацию между всеми каналами ExpressRoute, подключенными к виртуальной глобальной сети.
- ExpressRoute Global Reach: ExpressRoute Global Reach позволяет двум каналам с поддержкой Global Reach обмениваться трафиком напрямую без прохождения через виртуальный концентратор.
- Политика частной маршрутизации Routing Intent: Настройка политик частной маршрутизации позволяет двум каналам ExpressRoute отправлять трафик друг другу через средство безопасности, развернутое в хабе.
Подключение между каналами ExpressRoute через устройство брандмауэра в концентраторе с политикой маршрутизации с частным намерением доступно в следующих конфигурациях:
- Оба канала ExpressRoute подключены к одному концентратору, а политика частной маршрутизации настроена в этом концентраторе.
- Каналы ExpressRoute подключены к разным концентраторам, а политика частной маршрутизации настроена в обоих центрах. Таким образом, оба центра должны развертывать решение для обеспечения безопасности.
Рекомендации по маршрутизации с помощью ExpressRoute
Примечание.
Приведенные ниже рекомендации по маршрутизации применяются ко всем виртуальным концентраторам в подписках, которые были активированы службой поддержки Microsoft для разрешения подключения 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-устройство должно быть адресом назначения в настроенных правилах.
Параметр правила | Значение |
---|---|
Исходный IP-адрес | 192.168.1.4 и 192.168.1.5 |
Исходный порт | * |
IP-адрес назначения | 10.100.0.4 |
Конечный порт | * |
Протокол | ЛЮБОЙ |
Производительность зашифрованного 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.
Примечание.
Прямая маршрутизация к NVA с двойной ролью, используемой с политиками приватной маршрутизации в Виртуальная WAN, применяется только для трафика между виртуальными сетями и маршрутами, полученными через BGP из NVA, развернутых в центре Виртуальная WAN. Подключение ExpressRoute и VPN для транзитного подключения к локальной сети, связанной с NVA, не направляется напрямую к экземплярам 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.
Перейдите к концентратору виртуальной глобальной сети, на котором вы хотите настроить политики маршрутизации.
В разделе "Безопасность" выберите параметры защищенного виртуального концентратора, а затем выберите "Управление поставщиком безопасности" и параметрами маршрута для этого защищенного виртуального концентратора в диспетчере Брандмауэр Azure.
Выберите в меню концентратор, в котором нужно настроить политики маршрутизации.
Выберите пункт Конфигурация безопасности в разделе Параметры.
Если вам нужно настроить политику маршрутизации интернет-трафика, выберите Брандмауэр Azure или соответствующего поставщика безопасности в раскрывающемся списке Интернет-трафик. В противном случае выберите Нет.
Если вам нужно настроить политику маршрутизации частного трафика (для трафика ветви и виртуальной сети) через Брандмауэр Azure, выберите Брандмауэр Azure в раскрывающемся списке Частный трафик. В противном случае выберите пункт Обходить Брандмауэр Azure.
Если вам нужно настроить политику маршрутизации частного трафика и у вас есть ветви или частные сети с несовместимыми с IANA RFC1918 префиксами, выберите Префиксы частного трафика и укажите диапазоны несовместимых с IANA RFC1918 префиксов в появившемся текстовом поле. Нажмите кнопку Готово.
Выберите для параметра Между концентраторами значение Включено. Включение этого параметра гарантирует, что политики маршрутизации применяются к маршрутизационному намерению этого виртуального концентратора WAN.
Выберите Сохранить.
Повторите действия 2–8 для других защищенных концентраторов виртуальных глобальных сетей, для которых требуется настроить политики маршрутизации.
Теперь все готово для отправки тестового трафика. Убедитесь, что политики брандмауэра настроены соответствующим образом, чтобы разрешить или запретить трафик на основе нужных конфигураций безопасности.
Настройка намерений и политик маршрутизации с помощью портала Виртуальная глобальная сеть
В следующих шагах описывается настройка намерений маршрутизации и политик маршрутизации на виртуальном концентраторе с помощью портала Виртуальная глобальная сеть.
Перейдите по специальной ссылке на портал из сообщения с подтверждением, полученного на 3-м шаге раздела Предварительные требования, перейдите к концентратору Виртуальной глобальной сети, в котором нужно настроить политики маршрутизации.
В разделе "Маршрутизация" выберите Политики маршрутизации.
Если вы хотите настроить политику маршрутизации частного трафика (для филиалов и трафика виртуальной сети), выберите Брандмауэр Azure, сетевое виртуальное устройство или SaaS решения в разделе Частный трафик. В разделе "Ресурс следующего прыжка" выберите соответствующий ресурс следующего прыжка.
Если вам нужно настроить политику маршрутизации частного трафика и у вас есть ветви или частные сети с несовместимыми с IANA RFC1918 префиксами, выберите Дополнительные префиксы и укажите диапазоны несовместимых с IANA RFC1918 префиксов в появившемся текстовом поле. Нажмите кнопку Готово. Убедитесь, что вы добавили один и тот же префикс в текстовое поле префикса частного трафика во всех виртуальных концентраторах, настроенных с помощью политик частной маршрутизации, чтобы убедиться, что правильные маршруты объявляются всем концентраторам.
Если вы хотите настроить политику маршрутизации трафика в Интернет, выберите Брандмауэр Azure, сетевое виртуальное устройство или решение SaaS. В разделе "Ресурс следующего прыжка" выберите соответствующий ресурс следующего прыжка.
Чтобы применить конфигурацию намерений маршрутизации и политик маршрутизации, щелкните Сохранить.
Повторите для всех концентраторов, для которых вы хотите настроить политики маршрутизации.
Теперь все готово для отправки тестового трафика. Убедитесь, что политики брандмауэра настроены соответствующим образом, чтобы разрешить или запретить трафик на основе требуемых конфигураций безопасности.
Настройка намерения маршрутизации с помощью файла Bicep
Сведения о шаблоне и шагах см. в файле Bicep .
Устранение неполадок
В следующем разделе описаны распространенные способы устранения неполадок при настройке намерения маршрутизации и политик в центре Виртуальная глобальная сеть.
Фактические маршруты
Примечание.
Получение эффективных маршрутов, применяемых в виртуальной WAN с использованием намерения маршрутизации, поддерживается только для ресурса следующего прыжка, указанного в политике частной маршрутизации. Если вы используете как частные, так и интернет-маршрутизационные политики, проверьте действующие маршруты на ресурсе следующего узла, указанном в частной маршрутизующей политике, для действующих маршрутов программ Виртуальной WAN в интернет-маршрутизующей политике на ресурсе следующего узла. Если вы используете только политики интернет-маршрутизации, проверьте эффективные маршруты в таблице маршрутов по умолчанию, чтобы просмотреть маршруты, запрограммированные на ресурс следующего узла маршрутизации в Интернете.
При настройке политик частной маршрутизации в Виртуальном концентраторе весь трафик между локальными и виртуальными сетями проверяется файрволом 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.
Следующие шаги
Дополнительные сведения см. в статье Сведения о маршрутизации виртуальных концентраторов. Дополнительные сведения о виртуальной глобальной сети см. в статье, содержащей Часто задаваемые вопросы о ней.