Связаться с намиПодключиться

Маршрутизация

Статья создана
Обновлена 20 февраля 2025 г.

При подключении инфраструктуры клиента через Yandex Cloud Interconnect обычно требуется настроить маршрутизацию трафика между ресурсами в облаке и ресурсами в инфраструктуре клиента.

Маршрутизация — это набор инструментов для управления движением трафика в Yandex Cloud.

Общие рекомендации по маршрутизации в Cloud Interconnect

  • Тщательно планируйте распределение IP-адресации до развертывания облачных ресурсов. Адресация IP-подсетей в Yandex Cloud не должна пересекаться с адресацией IP-подсетей в инфраструктуре клиента.

  • Всегда организовывайте два канала подключения через две точки присутствия.

  • Для упрощения настройки отказоустойчивой BGP-маршрутизации на клиентских маршрутизаторах рекомендуется использовать одинаковый номер BGP ASN, если со стороны клиента используются несколько маршрутизаторов для подключения к услуге Cloud Interconnect. Допускается использовать разные номера BGP ASN, например, при организации подключений через операторов связи. Следует помнить, что настройка сетевого оборудования клиента и оператора связи лежит вне зоны ответственности Yandex Cloud.

  • Каждый клиентский маршрутизатор, который устанавливает BGP-связность с оборудованием Yandex Cloud по протоколу eBGP, должен также устанавливать BGP-связность с другими клиентскими маршрутизаторами по протоколу iBGP.

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

    • длина префикса /8 (короткий префикс) соответствует самому низкому приоритету маршрута;
    • длина префикса /32 (длинный префикс) соответствует самому высокому приоритету маршрута.

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

  • Допускается совместное использование Cloud Interconnect и NAT-шлюза, если клиентские маршрутизаторы не анонсируют маршрут «по умолчанию» 0.0.0.0/0 по протоколу BGP в направлении Yandex Cloud. В случае анонса маршрута по умолчанию 0.0.0.0/0 по протоколу BGP со стороны клиентских маршрутизаторов в направлении Yandex Cloud использование NAT-шлюза не допускается.

  • Сейчас в Yandex Cloud нет возможности распределять исходящий трафик из облачных подсетей в направлении инфраструктуры клиента на основе метода BGP community.

Внимание

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

Равномерное распределение трафика (Active-Active)

Ниже представлен пример схемы с равномерным распределением трафика через два приватных соединения, организованных через две точки присутствия.

Префикс из инфраструктуры клиента 10.0.0.0/8 анонсируется по протоколу BGP клиентскими маршрутизаторами через две точки присутствия в направлении Yandex Cloud. Yandex Cloud будет делать ECMP-балансировку и распределять трафик между точками присутствия.

Следует обратить внимание, что такой режим балансировки может приводить к асимметричности в прохождении трафика. Например, запрос из инфраструктуры клиента к облачным ресурсам может поступить через точку присутствия M9, а ответ на этот запрос будет отправлен через точку присутствия NORD.

Асимметрия трафика допускается и корректно обрабатывается на оборудовании Yandex Cloud, но может быть недопустима для отдельных типов оборудования в инфраструктуре клиента, например, для межсетевых экранов.

Для разрешения асимметричной передачи трафика со стороны Yandex Cloud необходимо отключить механизм RPF на сетевых элементах, обрабатыващих трафик в инфраструктуре клиента. Это позволит использовать все активные соединения Cloud Interconnect с резервированным подключением через две или более точки присутствия.

Приоритизация трафика по направлению (Active-Standby)

Для приоритизации трафика по направлению в рамках услуги Cloud Interconnect можно использовать методы:

Метод Longest Prefix Match имеет больший приоритет в алгоритме выбора лучшего маршрута на маршрутизаторах по сравнению с методом BGP AS-Path Prepend. Рекомендуется выбрать только один из предложенных методов и не применять оба метода одновременно.

Метод Longest Prefix Match (LPM)

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

Короткий префикс из инфраструктуры клиента 10.0.0.0/8 анонсируется по протоколу BGP клиентским маршрутизатором через точку присутствия NORD в направлении Yandex Cloud.

Два длинных (более специфичных) префикса из инфраструктуры клиента 10.0.0.0/9 и 10.128.0.0/9 анонсируются по протоколу BGP клиентским маршрутизатором через точку присутствия M9 в направлении Yandex Cloud.

Анонсы через точку присутствия M9 будут восприниматься в Yandex Cloud как более специфичные (приоритетные).

Таким образом, для всего трафика из облачных подсетей 172.16.1.0/24, 172.16.2.0/24 и 172.16.3.0/24 в направлении инфраструктуры клиента будет выбираться приватное подключение в направлении точки присутствия M9. В случае отказа данного подключения трафик будет автоматически переключен на приватное подключение в направлении точки присутствия NORD.

Метод BGP AS-Path Prepend

Ниже представлен пример схемы с приоритизацией трафика через два приватных соединения, организованных через две точки присутствия, с помощью метода BGP AS-Path Prepend.

Идея метода BGP AS-Path Prepend описана в этом документе.

Префикс 10.0.0.0/8 анонсируется из инфраструктуры клиента по протоколу BGP клиентским маршрутизатором R1 через точку присутствия M9 в направлении Yandex Cloud. По умолчанию, значение атрибута BGP AS-Path будет равным 65001, а длина пути AS-Path (количество значений номеров автономных систем) будет равна 1.

Этот же префикс 10.0.0.0/8 анонсируется из инфраструктуры клиента по протоколу BGP другим клиентским маршрутизатором R2 через точку присутствия NORD в направлении Yandex Cloud.

Перед тем как анонсировать префикс, политика BGP-маршрутизации на маршрутизаторе R2 добавляет номер автономной системы клиента (BGP ASN) в значение BGP-атрибута AS-Path и оно станет равным 65001 65001, а длина пути AS-Path станет равна 2. Это изменение делает префикс с такой длиной AS-Path менее предпочтительным для внешних BGP-маршрутизаторов.

Таким образом, со стороны Yandex Cloud для префикса 10.0.0.0/8 будет выбран наилучший маршрут через точку присутствия M9, а маршрут через точку присутствия NORD будет резервным, поскольку длина пути AS-Path у него будет больше.

Для всего трафика из облачных подсетей 172.16.1.0/24, 172.16.2.0/24 и 172.16.3.0/24 в направлении инфраструктуры клиента будет выбираться приватное подключение в направлении точки присутствия M9. В случае отказа данного подключения трафик будет автоматически переключен на приватное подключение в направлении точки присутствия NORD.

Резервирование трафика через VPN-шлюз

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

Два длинных префикса из инфраструктуры клиента 10.0.0.0/9 и 10.128.0.0/9 анонсируются по протоколу BGP клиентским маршрутизатором через точку присутствия M9 в направлении Yandex Cloud.

Резервное подключение из Yandex Cloud в инфраструктуру клиента организуется с помощью развертывания VPN-шлюза с поддержкой технологии IPSEC в зоне доступности ru-central1-b и настройкой статической маршрутизации в облачной сети (VPC).

Для каждой из подсетей с облачными ресурсами во всех трех зонах доступности используется одна таблица маршрутизации со статическим маршрутом (префиксом) 10.0.0.0/8 через 172.16.2.10. Поскольку данный маршрут (префикс) является более коротким /8 по сравнению с анонсируемыми по BGP более длинными /9 префиксами, он будет проигрывать, пока работает Cloud Interconnect соединение.

В случае отказа Cloud Interconnect соединения, более длинные /9 префиксы будут удалены из облачной сети, и весь трафик в инфраструктуру клиента будет автоматически маршрутизироваться по более короткому /8 префиксу через статический маршрут в направлении VPN-шлюза.

Приоритет статического маршрута

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

Короткий префикс из инфраструктуры клиента 10.0.0.0/8 анонсируется по протоколу BGP клиентским маршрутизатором через точку присутствия M9 в направлении Yandex Cloud.

Длинный префикс из инфраструктуры клиента 10.10.10.0/24 с помощью статической таблицы маршрутизации облачной сети настраивается для передачи трафика в направлении VPN-шлюза с IP-адресом 172.16.2.10, развернутого в зоне доступности ru-central1-b.

Таким образом, весь трафик из облачной сети в направлении инфраструктуры клиента 10.0.0.0/8 будет передаваться через соединение Cloud Interconnect, а трафик в подсеть 10.10.10.0/24 будет передаваться через VPN-шлюз.

Равномерное распределение трафика для маршрута 0.0.0.0/0

В отдельных случаях, например, для связи облачных ресурсов с интернет через инфраструктуру клиента, необходимо настроить на клиентских маршрутизаторах анонс маршрута 0.0.0.0/0 по протоколу BGP в направлении Yandex Cloud.

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

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

Приоритизация трафика по направлению для маршрута 0.0.0.0/0

Для приоритизации трафика по направлению в рамках услуги Cloud Interconnect можно использовать методы:

Метод Longest Prefix Match имеет больший приоритет в алгоритме выбора лучшего маршрута на маршрутизаторах по сравнению с методом BGP AS-Path Prepend. Рекомендуется выбрать только один из предложенных методов и не применять оба метода одновременно.

Метод Longest Prefix Match (LPM)

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

Маршрут по умолчанию из инфраструктуры клиента 0.0.0.0/0 анонсируется по протоколу BGP клиентским маршрутизатором через точку присутствия NORD в направлении Yandex Cloud.

Два длинных (более специфичных) префикса из инфраструктуры клиента 0.0.0.0/1 и 128.0.0.0/1 анонсируются по протоколу BGP клиентским маршрутизатором через точку присутствия M9 в направлении Yandex Cloud.

Анонсы через точку присутствия M9 будут восприниматься в Yandex Cloud как более специфичные (приоритетные).

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

Метод BGP AS-Path Prepend

Ниже представлен пример схемы с приоритизацией трафика через два приватных соединения, организованных через две точки присутствия, с помощью метода BGP AS-Path Prepend.

Идея метода BGP AS-Path Prepend описана в этом документе.

Маршрут по умолчанию из инфраструктуры клиента (0.0.0.0/0) анонсируется по протоколу BGP клиентским маршрутизатором через точку присутствия M9 в направлении Yandex Cloud. По умолчанию, значение атрибута BGP AS-Path будет равным 65001, а длина пути AS-Path (количество значений номеров автономных систем) будет равна 1.

Этот же префикс 0.0.0.0/0 анонсируется из инфраструктуры клиента по протоколу BGP другим клиентским маршрутизатором R2 через точку присутствия NORD в направлении Yandex Cloud.

Перед тем как анонсировать префикс, политика BGP-маршрутизации на маршрутизаторе R2 добавляет номер автономной системы клиента (BGP ASN) в значение BGP-атрибута AS-Path и оно станет равным 65001 65001, а длина пути AS-Path станет равна 2. Такое изменение делает префикс с такой длиной AS-Path менее предпочтительным для внешних BGP-маршрутизаторов.

Таким образом, со стороны Yandex Cloud для префикса 0.0.0.0/0 будет выбран наилучший маршрут через точку присутствия M9, а маршрут через точку присутствия NORD будет резервным, поскольку длина пути AS-Path у него будет больше.

Для всего трафика из облачных подсетей в направлении инфраструктуры клиента будет выбираться приватное подключение в направлении точки присутствия M9. В случае отказа данного подключения трафик будет автоматически переключен на приватное подключение в направлении точки присутствия NORD.

Взаимодействие с группами безопасности

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

Правила в группах безопасности должны настраиваться для префиксов, которые анонсируют клиентские маршрутизаторы в направлении Yandex Cloud. Например, для разрешения доступа из инфраструктуры клиента к веб-приложению (порт 443), развернутому в Yandex Cloud, группа безопасности должна быть настроена следующим образом:

ingress {
      protocol       = "TCP"
      port           = 443
      description    = "Allow ingress traffic from Interconnect to Web server"
      v4_cidr_blocks = ["172.16.1.5/32"]
    }
egress {
      protocol       = "ANY"
      description    = "We allow any egress traffic"
      v4_cidr_blocks = ["10.0.0.0/8"]
    }

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

При необходимости можно использовать более гранулярные правила, открывая доступ только к отдельным IP-адресам или подсетям и портам:

ingress {
      protocol       = "TCP"
      port           = 443
      description    = "Allow ingress traffic from Interconnect to Web server"
      v4_cidr_blocks = ["172.16.1.5/32"]
    }
egress {
      protocol       = "TCP"
      port           = 3389
      description    = "Allow RDP traffic to server behind Interconnect"
      v4_cidr_blocks = ["10.10.10.10/32"]
    }

Примеры использования

Предыдущая
Публичное соединение
Следующая
Мониторинг