Маршрутизация трафика в виртуальной сети

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

системные маршруты.

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

По умолчанию.

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

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

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

• Интернет: маршрутизирует трафик, указанный префиксом адреса в Интернет. Системный маршрут по умолчанию указывает префикс адреса 0.0.0.0/0. Если вы не переопределяете маршруты Azure по умолчанию, Azure направляет трафик для любого адреса, не указанного диапазоном адресов в виртуальной сети в Интернет. Существует одно исключение для этой маршрутизации. Если целевой адрес предназначен для службы Azure, Azure направляет трафик непосредственно в службу через магистральную сеть Azure, а не маршрутизацию трафика в Интернет. Трафик между службами Azure не проходит через Интернет. Это не имеет значения, в каком регионе Azure существует виртуальная сеть или в каком регионе Azure развертывается экземпляр службы Azure. Можно переопределить системный маршрут Azure по умолчанию для префикса адреса 0.0.0.0/0 с помощью настраиваемого маршрута.

• Нет: трафик, перенаправленный в тип следующего прыжка None , удаляется, а не направляется за пределы подсети. Azure автоматически создает маршруты по умолчанию для следующих префиксов адресов:

  • 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16: зарезервированы для частного использования в RFC 1918.
  • 100.64.0.0/10: зарезервирован в RFC 6598.

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

Необязательные маршруты по умолчанию

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

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

• Шлюз виртуальной сети: если в виртуальную сеть включить шлюз виртуальной сети, добавляется один или несколько маршрутов со шлюзом виртуальной сети, указанным в качестве типа следующего прыжка. Источник также является шлюзом виртуальной сети, так как шлюз добавляет маршруты в подсеть. Если локальный сетевой шлюз обменивается маршрутами BGP с шлюзом виртуальной сети, система добавляет маршрут для каждого маршрута. Эти маршруты распространяются из локального сетевого шлюза. Рекомендуется свести итоги локальных маршрутов к максимальному диапазону адресов, чтобы распространить наименьшее количество маршрутов в шлюз виртуальной сети Azure. Существуют ограничения на количество маршрутов, которые вы можете распространять на шлюз виртуальной сети Azure. Дополнительные сведения см. в разделе об ограничениях Azure.

• VirtualNetworkServiceEndpoint: общедоступные IP-адреса для определенных служб добавляются в таблицу маршрутов Azure при включении конечной точки службы в службу. Конечные точки службы включены для отдельных подсетей в виртуальной сети, поэтому маршрут добавляется только в таблицу маршрутов подсети, для которой включена конечная точка службы. Общедоступные IP-адреса служб Azure периодически изменяются. При изменении адресов Azure автоматически управляет ими в таблице маршрутов. Дополнительные сведения о конечных точках службы виртуальной сети и службах , для которых можно создавать конечные точки службы.

  Примечание.

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

Пользовательские маршруты

Вы создаете настраиваемые маршруты путем создания определяемых пользователем маршрутов (UDR) или обмена маршрутами BGP между локальным сетевым шлюзом и шлюзом виртуальной сети Azure.

Пользовательский

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

По умолчанию таблица маршрутов может содержать до 400 определяемых пользователем пользователей. При настройке маршрутизации Диспетчера виртуальная сеть Azure это число может расшириться до 1000 определяемых пользователем пользователей на таблицу маршрутов. Это увеличение ограничения поддерживает более сложные настройки маршрутизации. Примером является направление трафика из локальных центров обработки данных через брандмауэр к каждой периферийной виртуальной сети в топологии концентратора и периферийной при наличии более высокого числа периферийных виртуальных сетей.

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

При создании UDR можно указать следующие типы следующего прыжка:

• Виртуальный модуль. Виртуальный модуль — это виртуальная машина, на которой обычно выполняется сетевое приложение, например брандмауэр. Дополнительные сведения о различных предварительно настроенных виртуальных сетевых устройствах, которые можно развернуть в виртуальной сети, см . в Azure Marketplace. При создании маршрута с типом прыжка виртуального устройства также указывается IP-адрес следующего прыжка. одного из таких типов:

  • Частный IP-адрес сетевого интерфейса, подключенного к виртуальной машине. Для такого сетевого интерфейса, который перенаправляет сетевой трафик на адрес, отличный от своего собственного, требуется активировать параметр Azure Enable IP forwarding (Включить IP-пересылку). Параметр отключает проверку источника и назначения сетевого интерфейса Azure. См. дополнительные сведения о способах включения IP-пересылки для сетевого интерфейса. Включение IP-пересылки — это параметр Azure.

    Возможно, потребуется включить IP-пересылку в операционной системе виртуальной машины, чтобы устройство перенаправлялось между частными IP-адресами, назначенными сетевым интерфейсам Azure. Если устройство должно направлять трафик на общедоступный IP-адрес, он должен либо прокси-сервер трафика, либо выполнять преобразование сетевых адресов (NAT) из частного IP-адреса источника в собственный частный IP-адрес. Затем Azure выполняет NAT на общедоступный IP-адрес перед отправкой трафика в Интернет. Чтобы определить требуемые параметры на виртуальной машине, ознакомьтесь с документацией вашей операционной системы или сетевого приложения. См. дополнительные сведения об исходящих подключениях в Azure.

    Примечание.

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

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

  • Частный IP-адрес внутренней подсистемы балансировки нагрузки Azure. Подсистема балансировки нагрузки часто используется в рамках стратегии высокой доступности для сетевых виртуальных устройств.

  Маршрут можно определить с префиксом адреса 0.0.0.0/0 и типом следующего прыжка виртуального устройства. Эта конфигурация позволяет устройству проверять трафик и определять, следует ли пересылать или удалять трафик. Если вы планируете создать UDR, содержащий префикс адреса 0.0.0.0/0, сначала прочитайте префикс адреса 0.0.0.0/0.

• Шлюз виртуальной сети: укажите, когда трафик, предназначенный для конкретных префиксов адресов, следует направлять в шлюз виртуальной сети. Шлюз виртуальной сети должен быть создан с помощью VPN типа. Невозможно указать шлюз виртуальной сети, созданный в качестве типа ExpressRoute в UDR, так как с ExpressRoute необходимо использовать BGP для пользовательских маршрутов. Невозможно указать шлюзы виртуальной сети, если у вас есть виртуальные частные сети (VPN) и ExpressRoute, которые совместно связаны. Вы можете определить маршрут, который направляет трафик, предназначенный для префикса адресов 0.0.0.0/0, в виртуальный сетевой шлюз на основе маршрутов.

  В локальной среде у вас может быть устройство, которое проверяет трафик и определяет, следует ли пересылать или прерывать трафик. Если вы планируете создать UDR для префикса адреса 0.0.0.0/0, сначала прочитайте префикс адреса 0.0.0.0/0. Вместо настройки UDR для префикса адреса 0.0.0.0/0 можно объявить маршрут с префиксом 0.0.0.0.0/0 через BGP, если BGP для шлюза виртуальной сети VPN включен.

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

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

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

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

Теги служб для определяемых пользователем маршрутов

Теперь можно указать тег службы в качестве префикса адреса для UDR вместо явного диапазона IP-адресов. Тег службы представляет группу префиксов IP-адресов из определенной службы Azure. Корпорация Майкрософт управляет префиксами адресов, входящих в тег службы, и автоматически обновляет этот тег при изменении адресов. Эта поддержка сводит к минимуму сложность частых обновлений для определяемых пользователем пользователей и уменьшает количество создаваемых маршрутов. В настоящее время можно создать 25 или меньше маршрутов с тегами службы в каждой таблице маршрутов. В этом выпуске также поддерживается использование тегов служб в сценариях маршрутизации для контейнеров.

Точное совпадение

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

1. Региональные теги (например, Storage.EastUS или AppService.AustraliaCentral)

2. Теги верхнего уровня (например, Storage или AppService)

3. AzureCloud региональные теги (например, AzureCloud.canadacentral или AzureCloud.eastasia)

4. AzureCloud Тег

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

$param = @{
    Name = 'StorageRoute'
    AddressPrefix = 'Storage'
    NextHopType = 'VirtualAppliance'
    NextHopIpAddress = '10.0.100.4'
}
New-AzRouteConfig @param

Та же команда для Azure CLI:

az network route-table route create \
    --resource-group MyResourceGroup \
    --route-table-name MyRouteTable \
    --name StorageRoute \
    --address-prefix Storage \
    --next-hop-type VirtualAppliance \
    --next-hop-ip-address 10.0.100.4

Типы следующего прыжка в инструментах Azure

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

Протокол BGP

Локальный сетевой шлюз может обмениваться маршрутами с шлюзом виртуальной сети Azure с помощью BGP. Использование BGP с шлюзом виртуальной сети Azure зависит от типа, выбранного при создании шлюза:

• ExpressRoute: необходимо использовать протокол BGP, чтобы объявить локальные маршруты для пограничного маршрутизатора Майкрософт. Вы не можете создать определяемые пользователем UDR, чтобы принудительно использовать трафик к шлюзу виртуальной сети ExpressRoute, если развернуть шлюз виртуальной сети, развернутый в качестве типа ExpressRoute. Вы можете использовать определяемые пользователем правила для принудительного трафика из экспресс-маршрута, например виртуального сетевого устройства.
• VPN: при необходимости можно использовать BGP. Дополнительные сведения см. в статье BGP с VPN-подключениями типа "сеть — сеть".

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

Вы можете отключить распространение маршрутов ExpressRoute и Azure VPN-шлюз в подсети с помощью свойства в таблице маршрутов. При отключении распространения маршрутов система не добавляет маршруты в таблицу маршрутизации всех подсетей с отключенным распространением маршрутов шлюза виртуальной сети. Этот процесс применяется как к статическим маршрутам, так и к маршрутам BGP. Подключение с VPN-подключениями достигается с помощью пользовательских маршрутов с типом следующего прыжка шлюза виртуальной сети. Дополнительные сведения см. в разделе "Отключение распространения маршрутов шлюза виртуальной сети".

Как Azure выбирает маршрут

При отправке исходящего трафика из подсети Azure выбирает маршрут на основе конечного IP-адреса с помощью самого длинного алгоритма сопоставления префикса. Например, таблица маршрутов имеет два маршрута. Один маршрут задает префикс адреса 10.0.0.0/24, а другой маршрут задает префикс адреса 10.0.0.0/16.

Azure направляет трафик, предназначенный для 10.0.0.5, к типу следующего прыжка, указанному в маршруте с префиксом адреса 10.0.0.0/24. Этот процесс происходит, так как 10.0.0.0/24 является более длинным префиксом, чем 10.0.0.0/16, даже если 10.0.0.5 попадает в оба префикса адреса.

Azure направляет трафик, предназначенный для 10.0.1.5, к типу следующего прыжка, указанному в маршруте с префиксом адреса 10.0.0.0/16. Этот процесс происходит, так как префикс адреса 10.0.0.1.5 не включен в префикс адреса 10.0.0/24, который делает маршрут с префиксом адреса 10.0.0.0/16.

Если несколько маршрутов содержат один и тот же префикс адреса, Azure выбирает тип маршрута на основе следующего приоритета:

1. определяемый пользователем маршрут;

2. маршрут BGP;

3. Системные маршруты

Например, таблица маршрутов содержит следующие маршруты:

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

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

Префикс адреса 0.0.0.0/0

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

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

При переопределении префикса адреса 0.0.0.0/0 исходящий трафик из подсети передается через шлюз виртуальной сети или виртуальное устройство. Следующие изменения также происходят с маршрутизацией по умолчанию Azure:

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

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

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

  Если включить конечную точку службы для службы, Azure создает маршрут с префиксами адресов для службы. Трафик к службе не направляется к типу следующего прыжка в маршруте с префиксом адреса 0.0.0.0/0. Префиксы адресов для службы длиннее 0.0.0.0/0/0.

• Вы больше не можете напрямую обращаться к ресурсам в подсети из Интернета. Вы можете получить доступ к ресурсам в подсети из Интернета косвенно. Устройство, указанное в следующем прыжке для маршрута с префиксом адреса 0.0.0.0/0, должно обрабатывать входящий трафик. После того как трафик проходит через устройство, трафик достигает ресурса в виртуальной сети. Если маршрут содержит следующие значения для типа следующего прыжка:

  • Виртуальный модуль. Модуль должен:

    • Будьте доступны из Интернета.
    • У него назначен общедоступный IP-адрес.
    • Нет правила группы безопасности сети, связанного с ней, которая препятствует обмену данными с устройством.
    • Не запрещать обмен данными.
    • Вы можете переводить и пересылать сетевой адрес или прокси-трафик к целевому ресурсу в подсети и возвращать трафик обратно в Интернет.

  • Шлюз виртуальной сети. Если шлюз является шлюзом виртуальной сети ExpressRoute, локальное устройство, подключенное к Интернету, может передавать и пересылать сетевой адрес, а также передавать трафик целевому ресурсу в подсети через частный пиринг ExpressRoute.

Если виртуальная сеть подключена к шлюзу Azure VPN, не связывайте таблицу маршрутов с подсетью шлюза, включающей маршрут с назначением 0.0.0.0/0. Это может привести к неправильной работе шлюза. Дополнительные сведения см. в статье "Почему некоторые порты открыты на VPN-шлюзе?".

Сведения о реализации при использовании шлюзов виртуальной сети между Интернетом и Azure см. в разделе "DmZ" между Azure и локальным центром обработки данных.

Пример маршрутизации

Чтобы проиллюстрировать основные понятия в этой статье, описаны следующие разделы:

• Сценарий с требованиями.
• Настраиваемые маршруты, необходимые для удовлетворения требований.
• Таблица маршрутов, которая существует для одной подсети, которая включает стандартные и настраиваемые маршруты, необходимые для удовлетворения требований.

Требования

1. Реализуйте две виртуальные сети в одном регионе Azure и настройте ресурсы для обмена данными между виртуальными сетями.

2. Включите локальную сеть для безопасного взаимодействия с обеими виртуальными сетями через VPN-туннель через Интернет. Кроме того, можно использовать подключение ExpressRoute, но в этом примере используется VPN-подключение.

3. Для одной подсети в одной виртуальной сети:

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

4. Разрешите весь трафик между всеми подсетями и виртуальными сетями.

Внедрение

На следующей схеме показана реализация с помощью модели развертывания Resource Manager, которая соответствует предыдущим требованиям.

Стрелки показывают поток трафика.

Таблицы маршрутов

Ниже приведены таблицы маршрутов для предыдущего примера маршрутизации.

Подсеть 1

Таблица маршрутов для Подсети1 на предыдущей схеме содержит следующие маршруты:

Ниже приведено описание каждого идентификатора маршрута:

• Идентификатор 1. Azure автоматически добавил этот маршрут для всех подсетей в виртуальной сети-1 , так как 10.0.0.0/16 — это единственный диапазон адресов, определенный в адресном пространстве виртуальной сети. Если вы не создаете UDR в идентификаторе маршрута 2, трафик отправляется в любой адрес от 10.0.0.1 до 10.0.255.254 в виртуальной сети. Этот процесс происходит, так как префикс длиннее 0.0.0.0/0 и не попадает в префиксы адресов других маршрутов.

  Azure автоматически изменил состояние "Активный" на "Недопустимый", когда добавлен идентификатор 2, UDR. Он имеет тот же префикс, что и маршрут по умолчанию, а определяемые пользователем маршруты переопределяют маршруты по умолчанию. Состояние этого маршрута по-прежнему активно для подсети2 , так как таблица маршрутов, в которую находится UDR, ID2, не связана с Подсетью2.

• Id2: Azure добавил этот маршрут, когда uDR для префикса адреса 10.0.0.0/16 был связан с подсетью Subnet1 в виртуальной сети 1 виртуальной сети. UDR указывает 10.0.100.4 в качестве IP-адреса виртуального устройства, так как адрес является частным IP-адресом, назначенным виртуальной машине виртуального устройства. Таблица маршрутов, в которой этот маршрут существует, не связана с Подсетью2, поэтому маршрут не отображается в таблице маршрутов для Subnet2.

  Этот маршрут переопределяет маршрут по умолчанию для префикса 10.0.0.0/16 (маршрут 1), который автоматически направляет трафик, адресованный 10.0.0.1 и 10.0.255.254 в виртуальной сети, с помощью типа следующего прыжка "Виртуальная сеть". Этот маршрут существует для удовлетворения требования 3, который заключается в принудительном принудительном переборе всего исходящего трафика через виртуальное устройство.

• Id3: Azure добавил этот маршрут, когда uDR для префикса адреса 10.0.0.0/24 был связан с подсетью Subnet1 . Трафик, предназначенный для адресов от 10.0.0.1 до 10.0.0.254, остается в подсети. Трафик не направляется на виртуальное устройство, указанное в предыдущем правиле (ID2), так как он имеет более длинный префикс, чем маршрут ID2.

  Этот маршрут не связан с подсетью 2 и поэтому не отображается в таблице маршрутов подсети 2. Этот маршрут эффективно переопределяет маршрут 2 для трафика в подсети 1. Этот маршрут существует в соответствии с требованием 3.

• Id4: Azure автоматически добавил маршруты в идентификаторы 4 и 5 для всех подсетей в виртуальной сети-1 при пиринге виртуальной сети с виртуальной сетью-2. Виртуальная сеть-2 имеет два диапазона адресов в адресном пространстве, 10.1.0.0/16 и 10.2.0.0/16, поэтому Azure добавил маршрут для каждого диапазона. Если вы не создаете определяемые пользователем идентификаторы маршрутов 6 и 7, трафик отправляется в любой адрес от 10.1.0.1 до 10.1.255.254 и 10.2.0.1-10.2.255.254 направляется в пиринговую виртуальную сеть. Этот процесс происходит, так как префикс длиннее 0.0.0.0/0 и не попадает в префиксы адресов других маршрутов.

  При добавлении маршрутов в идентификаторы 6 и 7 Azure автоматически изменяет состояние "Активный " на "Недопустимый". Этот процесс возникает, так как они имеют одинаковые префиксы, что и маршруты в идентификаторах 4 и 5, а определяемые пользователем маршруты переопределяют маршруты по умолчанию. Состояние маршрутов в идентификаторах 4 и 5 по-прежнему активно для подсети2 , так как таблица маршрутов, в которой определяемые пользователем идентификаторы в идентификаторах 6 и 7 не связаны с подсетью2. Пиринг виртуальных сетей был создан в соответствии с требованием 1.

• 5. То же касается и маршрута 4.

• Id6: Azure добавил этот маршрут и маршрут в ID7, когда определяемые пользователем адреса для подсети 10.1.0.0/16 и 10.2.0.0/16 были связаны с подсетью Subnet1 . Azure удаляет трафик, предназначенный для адресов от 10.1.0.1 до 10.1.255.254 и 10.2.0.1-10.2.255.254, а не направляется в пиринговую виртуальную сеть, так как определяемые пользователем маршруты переопределяют маршруты по умолчанию. Эти маршруты не связаны с подсетью 2 и поэтому не отображаются в таблице маршрутов подсети 2. Эти маршруты переопределяют маршруты 4 и 5 трафика, выходящего из подсети 1. Маршруты 6 и 7 существует в соответствии с требованием 3, чтобы прервать трафик, предназначенный для другой виртуальной сети.

• 7. То же касается и маршрута 6.

• 8. Azure автоматически добавляет этот маршрут для всех подсетей в виртуальной сети 1 при создании шлюза виртуальной сети типа VPN. Azure добавляет общедоступный IP-адрес шлюза виртуальной сети в таблицу маршрутов. Трафик, отправленный на любой адрес между 10.10.0.1 и 10.10.255.254, направляется в шлюз виртуальной сети. Префикс длиннее, чем 0.0.0.0/0, и не находится внутри префиксов адресов других маршрутов. Шлюз виртуальной сети был создан в соответствии с требованием 2.

• Id9: Azure добавил этот маршрут при добавлении UDR для префикса адреса 10.10.0.0/16 в таблицу маршрутов, связанную с Subnet1. Этот маршрут переопределяет маршрут 8. Маршрут отправляет весь трафик, предназначенный для локальной сети, в сетевое виртуальное устройство для проверки, а не маршрутизацию трафика непосредственно в локальной среде. Этот маршрут был создан в соответствии с требованием 3.

• 10. Azure автоматически добавляет этот маршрут в подсеть, когда для нее настраивается конечная точка службы для службы Azure. Azure направляет трафик из подсети на общедоступный IP-адрес службы через сеть инфраструктуры Azure. Префикс длиннее, чем 0.0.0.0/0, и не находится внутри префиксов адресов других маршрутов. Конечная точка службы была создана для удовлетворения требования 3, чтобы включить трафик, предназначенный для служба хранилища Azure, напрямую в служба хранилища Azure.

• 11. Служба Azure автоматически добавила этот маршрут в таблицу маршрутов всех подсетей в виртуальной сети 1 и виртуальной сети 2. Префикс адреса 0.0.0.0/0 является наиболее коротким. Любой трафик, отправленный адресам с более длинными префиксами, направляется согласно другим маршрутам.

  По умолчанию Azure направляет весь трафик, предназначенный для адресов, отличных от адресов, указанных в одном из других маршрутов в Интернет. Azure автоматически изменил состояние "Активный" на "Недопустимый" для подсети Subnet1, когда uDR для префикса адреса 0.0.0.0/0 (ID12) был связан с подсетью. Состояние этого маршрута по-прежнему активно для всех других подсетей в обеих виртуальных сетях, так как маршрут не связан с другими подсетями в других виртуальных сетях.

• Id12: Azure добавил этот маршрут, когда uDR для префикса адреса 0.0.0.0/0 был связан с подсетью Subnet1 . UDR указывает 10.0.100.4 в качестве IP-адреса виртуального устройства. Этот маршрут не связан с подсетью 2 и поэтому не отображается в таблице маршрутов подсети 2. Весь трафик для любых адресов, не включенных в префиксы адресов других маршрутов, отправляется на виртуальный модуль.

  Добавление этого маршрута изменило состояние маршрута по умолчанию для префикса адреса 0.0.0.0/0 (ID11) с "Активный " на недопустимый для Subnet1 , так как UDR переопределяет маршрут по умолчанию. Этот маршрут существует в соответствии с требованием 3.

Подсеть 2

Таблица маршрутов для Подсети2 на предыдущей схеме содержит следующие маршруты:

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

Azure удалил маршруты для префиксов адресов 10.0.0.0/8, 192.168.0.0/16 и 100.64.0.0/10 из таблицы маршрутов Subnet1 , когда UDR для префикса адреса 0.0.0.0/0/0 был добавлен в Подсеть1.

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

• Создайте таблицу UDR с маршрутами и сетевым виртуальным устройством.
• Настройте BGP для VPN-шлюз Azure.
• Используйте BGP с ExpressRoute.
• Просмотр всех маршрутов для подсети В таблице UDR отображаются только определяемые пользователем UDR, а не маршруты BGP для подсети. Просмотр всех маршрутов показывает значения по умолчанию, BGP и UDR для подсети, в которой находится сетевой интерфейс.
• Определите тип следующего прыжка между виртуальной машиной и IP-адресом назначения. Вы можете использовать функцию следующего прыжка Azure Наблюдатель за сетями, чтобы определить, покидает ли трафик подсеть и направляется в место, где вы считаете, что это должно быть.