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

Из этой статьи вы узнаете, как 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 автоматически управляет ими в таблице маршрутов. Дополнительные сведения о конечных точках службы виртуальной сети и службах , для которых можно создавать конечные точки службы.

  Примечание.

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

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

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

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

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

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

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

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

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

$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.1.5 не включен в адресный префикс 10.0.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, должно обрабатывать входящий трафик. После того как трафик проходит через устройство, трафик достигает ресурса в виртуальной сети. Если маршрут содержит следующие значения для типа следующего прыжка:

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

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

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

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

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

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

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

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

Требования

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

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

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

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

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 автоматически изменил состояние с Активный на Недопустимый, когда был добавлен ID2, УДР. Он имеет тот же префикс, что и маршрут по умолчанию, а определяемые пользователем маршруты переопределяют маршруты по умолчанию. Состояние этого маршрута по-прежнему активно для подсети2 , так как таблица маршрутов, в которую находится UDR, ID2, не связана с Подсетью2.

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

  Этот маршрут переопределяет маршрут по умолчанию для префикса 10.0.0.0/16 (ID1), который автоматически направляет в виртуальной сети трафик, адресованный на 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. Этот маршрут эффективно переопределяет маршрут ID2 для трафика в Subnet1. Этот маршрут существует в соответствии с требованием 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, а UDR переопределяют маршруты по умолчанию. Состояние маршрутов в идентификаторах 4 и 5 по-прежнему активно для Подсети2 , так как таблица маршрутов, в которой определяемые пользователем маршруты из идентификаторов 6 и 7, не связана с Подсетью2. Пиринг виртуальных сетей был создан в соответствии с требованием 1.

• ID5: То же объяснение, что и для ID4.

• 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. Эти маршруты переопределяют маршруты ID4 и ID5 для трафика, покидающего подсеть 1. Маршруты ID6 и ID7 существуют для выполнения требования 3, чтобы отбрасывать трафик, предназначенный для другой виртуальной сети.

• ID7: То же объяснение, что и в ID6.

• ID8: 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. Этот маршрут переопределяет ID8. Маршрут направляет весь трафик, предназначенный для локальной сети, на сетевое виртуальное устройство для проверки, вместо того чтобы направлять его непосредственно на локальную сеть. Этот маршрут был создан в соответствии с требованием 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 был добавлен в Subnet1.

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

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