BGP: как маршрутизируется интернет

Проект ЦИТадель

Предыдущие статьи раздела разбирали отдельное соединение: TLS защищает его, а HTTP/2 и HTTP/3 организуют прикладной обмен. Теперь поднимемся на уровень выше: как пакет находит путь через независимые сети разных операторов? Между ними нет единого администратора, а кратчайший физический путь не всегда соответствует коммерческим отношениям. BGP (Border Gateway Protocol) распространяет сведения о достижимости и позволяет каждой сети применять собственную политику. Эта автономность обеспечивает рост интернета и одновременно объясняет перехваты и утечки маршрутов.

1. Автономные системы

Автономная система (AS) — сеть или группа сетей под общей технической администрацией, которая показывает внешним соседям согласованную политику маршрутизации. Провайдер, оператор дата-центров, университет или крупная организация могут получить номер автономной системы (ASN). IP-префиксы распределяются отдельно: AS может объявлять собственные ресурсы, ресурсы клиента или вообще не объявлять адресов, если использует только чужой транзит.

Внутри AS маршруты распространяют, например, OSPF или IS-IS, а внутренний BGP разносит внешние маршруты между пограничными узлами. Между автономными системами работает внешний BGP. Глобального узла, который вычисляет путь за всех, нет: каждая AS выбирает и экспортирует маршруты согласно своим договорам и фильтрам. Поэтому интернет представляет собой сеть автономных систем, связанных не только кабелями, но и правилами обмена маршрутами.

2. Что передаёт и выбирает BGP

Два BGP-узла устанавливают сеанс поверх TCP, обычно с портом 179, и передают сообщения UPDATE. Маршрут сочетает префикс назначения с атрибутами пути. Например, AS 65010 может получить анонс: «192.0.2.0/24 доступен через AS_PATH 65020 65030». Экспортируя маршрут внешнему соседу, AS обычно добавляет собственный номер слева. Изменения передаются при появлении или исчезновении маршрута, а не полной таблицей через равные интервалы.

AS_PATH выполняет две основные функции. Он описывает последовательность AS, через которые прошёл анонс, и предотвращает петли: узел отвергает маршрут, если видит в пути номер своей AS. Длина пути может участвовать в выборе, но BGP сам не измеряет задержку, пропускную способность, загрузку или потери.

Нужно различать два решения маршрутизатора:

1. Для одного и того же префикса процесс BGP выбирает предпочтительный путь по политике и атрибутам.
2. Для конкретного IP-адреса таблица пересылки выбирает наиболее длинный совпавший префикс. Маршрут /24 поэтому точнее маршрута /16 независимо от длины их AS_PATH.

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

3. Транзит, пиринг и экспорт маршрутов

Политику BGP нельзя отделить от отношений между сетями:

• Транзит — клиент платит провайдеру за достижимость остального интернета. Клиент может получить полную таблицу, её часть или маршрут по умолчанию, а провайдер распространяет допустимые префиксы клиента.
• Пиринг — две сети обмениваются своим трафиком и трафиком клиентов напрямую. Условия бывают бесплатными или платными. Как правило, пир не предоставляет путь между другим пиром и своим провайдером: это превратило бы ограниченный обмен в неоплаченный транзит.
• Точка обмена трафиком (IX) предоставляет общую канальную инфраструктуру, на которой участники устанавливают двусторонние BGP-сеансы или используют сервер маршрутов. IX упрощает пиринг, но не задаёт коммерческую политику участников.

Распространённая модель предпочитает маршрут от клиента маршруту от пира, а маршрут от пира — маршруту от провайдера: получение клиентского трафика приносит доход, пиринг избегает расходов, транзит провайдеру оплачивается. Это не закон протокола и не универсальное правило, а политика, которую оператор кодирует, например, через Local Preference. Экспорт обычно дополняет выбор: клиентские маршруты сообщают всем соседям, а маршруты от провайдера или пира — своим клиентам, но не другим провайдерам и пирам. Нарушение именно этого ограничения часто создаёт утечку.

В результате маршрут может быть не кратчайшим географически и не самым быстрым. Искусственное удлинение AS_PATH (prepending) иногда отводит входящий трафик, но действует только там, где удалённые сети не предпочли иной путь по более важной политике.

4. Как выбирается путь

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

1. Входные фильтры отклоняют недопустимые анонсы, а локальная политика назначает предпочтение. Стандартный Local Preference и некоторые специфичные для производителя атрибуты обычно учитываются раньше длины пути.
2. Локально созданный маршрут может получить преимущество; затем часто предпочитается более короткий AS_PATH.
3. Далее сравниваются ORIGIN, MED и способ получения маршрута. MED обычно сопоставляют для путей от одной соседней AS, если политика явно не задаёт иное.
4. В конце остаются технические развязки: стоимость пути до NEXT_HOP, идентификаторы маршрутизаторов и адреса соседей.

Этот список объясняет порядок, но не заменяет документацию конкретного маршрутизатора. Результатом обычно становится один лучший BGP-путь к префиксу; многопутевая пересылка требует, чтобы реализация признала пути равноценными и была соответствующим образом настроена. После установки маршрутов применяется правило наиболее длинного префикса из раздела 2 — оно не является ещё одним шагом алгоритма BGP.

Глобальная таблица IPv4 к середине 2020-х имеет порядок миллиона маршрутов, поэтому память и время сходимости остаются эксплуатационными ограничениями. Многие операторы фильтруют в глобальном обмене IPv4-префиксы длиннее /24 и IPv6-префиксы длиннее /48, но это распространённая практика, а не универсальная гарантия протокола.

5. Перехваты и утечки

Базовый BGP сообщает, откуда получен маршрут, но не доказывает право исходной AS объявлять префикс и не подтверждает весь AS_PATH. Защита самого сеанса между соседями не решает эту задачу. Ошибка фильтра или намеренный ложный анонс поэтому может распространиться дальше.

• Перехват маршрута (route hijack): AS объявляет чужой префикс. Анонс того же размера конкурирует с законным по политике BGP, а более специфичный префикс выигрывает при пересылке. В 2008 году Pakistan Telecom, блокируя YouTube внутри своей сети, объявила более специфичный /24; её транзитный провайдер передал маршрут дальше. Значительная часть интернета около двух часов направляла трафик по ложному пути.
• Утечка маршрутов (route leak): AS передаёт допустимые маршруты соседу, которому не должна была их экспортировать. Например, клиент сообщает одному провайдеру полную таблицу, полученную от другого, и внезапно становится транзитом. Путь может выглядеть синтаксически корректным, но нарушает коммерческую роль связи; перегрузка слабой сети нарушает доступность.
• Ограниченная аналогия с византийским отказом. Один участник сообщает противоречащие политике сведения, а остальные должны решить, принимать ли их без общего арбитра. Но BGP не достигает консенсуса между всеми сетями, поэтому это только связь с моделью угроз из главы о византийских отказах, а не экземпляр той же задачи.

6. RPKI и защита от утечек

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

• RPKI и ROA. Владелец адресного ресурса публикует подписанное разрешение Route Origin Authorization: какая AS вправе быть источником и префиксы какой максимальной длины она может объявлять. Route Origin Validation (ROV) даёт результат Valid, Invalid или NotFound. Оператор сам задаёт действие, но распространённая безопасная политика — отклонять Invalid. ROV проверяет происхождение, а не весь путь, и не обнаружит утечку маршрута с законной исходной AS.
• BGPsec стандартизован для криптографической проверки AS_PATH, но широко не развёрнут. ASPA должен позволить проверять отношения «клиент — провайдер» и обнаруживать больше утечек; на август 2026 года профиль ASPA и алгоритмы проверки остаются проектами IETF, хотя реализации и опытная эксплуатация уже существуют.
• BGP Roles и OTC (RFC 9234) позволяют соседям обозначить роль связи и пометить маршруты для предотвращения некоторых утечек. Механизм помогает, когда роли настроены правильно и поддерживаются обеими сторонами; он не заменяет фильтры.
• Операционная гигиена. На границе проверяют префиксы клиента по согласованному списку, ограничивают их число, отклоняют служебные и слишком специфичные маршруты, публикуют свои ROA и применяют ROV. MANRS собирает эти меры в общий набор практик.

7. Практикум: наблюдаем глобальную маршрутизацию

Задание 1. Путь пакета. Выполните traceroute или mtr до нескольких узлов и сопоставьте отвечающие IP-адреса с ASN через whois или сервис IP → ASN. Отметьте границы сетей, но не называйте полученный список AS_PATH: часть маршрутизаторов не отвечает, адрес интерфейса может принадлежать другой стороне связи, а прямой и обратный пути могут различаться.

Задание 2. Анонсы из нескольких точек. В RIPEstat, RIPE RIS или RouteViews найдите префикс своей сети либо известного сервиса. Запишите исходную AS, несколько наблюдаемых AS_PATH и статус RPKI. Сравните точки наблюдения: разные лучшие пути являются нормальным следствием локальной политики.

Задание 3. Инцидент YouTube 2008 года. В разборе RIPE NCC найдите законный 208.65.152.0/22, ложный 208.65.153.0/24, AS 17557 и провайдера AS 3491. Объясните отдельно, почему анонс распространился и почему трафик выбрал /24. Затем проверьте контрмеры: ROA для /22 с maxLength=22 сделал бы /24 Invalid при ROV, а входной фильтр провайдера не позволил бы клиенту объявить чужой префикс. Это два независимых рубежа.

Задание 4. Границы RPKI. Найдите примеры Valid, Invalid и NotFound и объясните каждый результат через ASN, длину префикса и maxLength. Затем рассмотрите маршрут с законным origin, но неожиданным промежуточным провайдером: почему ROV не способен признать его утечкой? Сопоставьте ответ с назначением ASPA.

Задание 5* (лабораторное). Перехват и фильтр. В контейнерах с FRRouting или BIRD соберите четыре AS на отдельных соединениях: транзит T (65000), законный источник L (65010), нарушитель A (65020) и наблюдатель O (65030). L объявляет 10.10.0.0/16, A — свой 10.20.0.0/16, T передаёт клиентские маршруты O. Для команды network добавьте на источниках соответствующие статические маршруты в Null0, иначе реализация может не анонсировать префикс, отсутствующий в локальной таблице.

1. На O сохраните вывод show bgp ipv4 unicast и маршрут к 10.10.1.1.
2. Добавьте на A ложный 10.10.1.0/24 и проследите его AS_PATH через T. На O отдельно покажите, что для адреса 10.10.1.1 победил более специфичный /24, а для остальной части 10.10.0.0/16 сохранился законный путь.
3. На входе T от A примените список префиксов, разрешающий только назначенный A блок 10.20.0.0/16. Обновите входные маршруты или сеанс и убедитесь, что /24 исчез у T и O.
4. Повторите опыт с ложным 10.10.0.0/16. Теперь длина префикса одинакова: зафиксируйте, какие атрибуты выбрали путь, и измените Local Preference так, чтобы результат поменялся.

Лаборатория разделяет два механизма, которые легко смешать: фильтрацию и выбор BGP-пути для одинакового префикса, а затем наиболее длинное совпадение при пересылке пакета.

Итоги

• BGP распространяет префиксы и атрибуты между автономными системами; единого вычислителя глобальных маршрутов нет.
• AS_PATH помогает применять политику и предотвращать петли, но не измеряет качество канала и не доказывает полномочия участников.
• BGP выбирает путь среди маршрутов к одному префиксу, а таблица пересылки затем выбирает наиболее длинный совпавший префикс для адреса.
• Транзит, пиринг и правила экспорта определяют путь не меньше технических атрибутов; нарушение роли связи приводит к утечкам.
• RPKI/ROV проверяет исходную AS и допустимую длину префикса, но не весь AS_PATH. BGP Roles и OTC ограничивают часть утечек, BGPsec и ASPA решают другие части задачи с разной степенью внедрения.
• Фильтры соседей, ограничения числа префиксов, ROA и наблюдение через коллекторы нужны одновременно: одного механизма защиты недостаточно.

Литература

1. RFC 4271, «A Border Gateway Protocol 4 (BGP-4)» — базовая спецификация; RFC 7454, «BGP Operations and Security» — операционные рекомендации.
2. RFC 6811: BGP Prefix Origin Validation, RFC 8205: BGPsec и RFC 9234: BGP Roles and OTC.
3. IETF Datatracker: профиль ASPA — актуальный статус проекта спецификации.
4. RIPE NCC: разбор перехвата YouTube в 2008 году; RIPEstat — наблюдение маршрутов и RPKI.
5. MANRS, Mutually Agreed Norms for Routing Security — практики безопасной маршрутизации.
6. Материалы ЦИТадели: «TLS: как устроено защищённое соединение», «HTTP/2 и HTTP/3» и «Византийские отказы».

Материалы по теме

• Сети и телекоммуникации — оглавление подраздела.
• Сетевая адресация: MAC, IPv4, IPv6, CIDR и DNS.
• Контейнеры: устройство и экосистема.