Что такое BGP и почему один провайдер может «уронить» половину интернета

MAATRIX

Иногда сайт или сервис становится недоступен не потому, что у него что-то сломалось, а потому, что где-то на другом конце света провайдер неправильно объявил маршрут к его подсети. Для обычного администратора сервера это выглядит как необъяснимый обрыв: пинг не идёт, трафик как будто проваливается в пустоту, а через час всё само чинится. За этим обычно стоит BGP — протокол, на котором держится маршрутизация всего интернета, и у него на удивление мало защиты от ошибок и злого умысла.

Что такое автономная система и зачем ей BGP

Интернет — это не единая сеть, а множество отдельных сетей, которые называются автономными системами (AS, Autonomous System). Автономная система — это блок IP-адресов и оборудования под управлением одной организации: провайдера, дата-центра, крупной компании, университета. У каждой AS есть номер (ASN), например AS13335 у Cloudflare или AS15169 у Google. Внутри своей сети AS сама решает, как маршрутизировать пакеты — это её внутренняя кухня.

Проблема начинается на границах. Когда пакет с вашего сервера в Лондоне должен попасть на сервер в Токио, он проходит через несколько чужих сетей подряд. Ни одна AS не имеет полной карты интернета — она знает только, кто её ближайшие соседи (peers) и что эти соседи говорят о том, какие подсети за ними находятся. Вот эту информацию — «эти подсети доступны через меня» — автономные системы обмениваются друг с другом по протоколу BGP (Border Gateway Protocol), созданному ещё в 1989 году и с тех пор остающемуся стандартом де-факто для межсетевой маршрутизации.

Технически BGP — это протокол на основе TCP (порт 179), по которому маршрутизаторы двух AS устанавливают сессию (BGP peering) и обмениваются анонсами префиксов — блоков адресов вида 203.0.113.0/24. Анонс говорит: «я знаю путь к этой подсети, вот список AS, через которые надо пройти» (AS-path). Получив анонс, сосед решает, использовать ли этот путь, и в свою очередь ретранслирует информацию дальше своим соседям, дописывая себя в AS-path. Так за секунды-минуты информация о новом маршруте расходится по всему миру — это называется конвергенцией BGP.

Как AS объявляют маршруты друг другу

Практический пример. Допустим, вы арендовали сервер и вам выделили подсеть 198.51.100.0/24. Провайдер, у которого вы арендуете сервер, имеет собственную AS и договор о пиринге с несколькими транзитными операторами (upstream). Провайдер настраивает у себя на граничном маршрутизаторе анонс этой подсети — условно так это выглядит в конфигурации BGP-демона (пример для BIRD, применяется на маршрутизаторах провайдеров, не на вашем сервере):

protocol bgp upstream1 {
    local as 65010;
    neighbor 203.0.113.1 as 174;
    ipv4 {
        import none;
        export filter { if net = 198.51.100.0/24 then accept; else reject; };
    };
}

Провайдер экспортирует свой префикс апстриму (в примере — AS174), тот принимает анонс, добавляет себя в AS-path и рассылает эту информацию своим соседям, и так далее по цепочке. Через несколько минут весь интернет «знает», что трафик к 198.51.100.0/24 нужно слать через цепочку AS, ведущую к вашему провайдеру. Если у вас несколько аплинков (multihoming), одна и та же подсеть может анонсироваться сразу нескольким операторам — тогда у разных участков интернета будут разные пути к вам, и BGP выберет для каждого свой оптимальный по метрикам маршрут (длина AS-path, локальные предпочтения оператора и т.д.).

Ключевая деталь: анонс — это просто заявление. Маршрутизатор соседней AS в базовой конфигурации BGP не может самостоятельно проверить, действительно ли анонсирующая сторона имеет право распоряжаться этой подсетью. Он либо доверяет соседу, либо применяет заранее настроенные фильтры (route filters, prefix-lists), которые нужно поддерживать вручную и которые есть далеко не у всех.

Взаимное доверие вместо проверки: главная особенность BGP

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

Есть несколько технологий, которые снижают риск, но ни одна не является обязательной повсеместно:

• IRR (Internet Routing Registry) — базы данных, куда операторы регистрируют, какие префиксы и AS-пути они собираются анонсировать. Соседи могут сверяться с этими записями при настройке фильтров, но актуальность записей никто не гарантирует — база может годами не обновляться.
• RPKI (Resource Public Key Infrastructure) — криптографическая подпись, которая связывает конкретный префикс с конкретной AS через сертификат от регионального регистратора (RIPE, ARIN, APNIC и т.д.). Проверка называется Route Origin Validation (ROV): маршрутизатор может отклонять или понижать приоритет анонсов, не подтверждённых RPKI-записью (ROA). RPKI за последние годы набрала заметное покрытие среди крупных операторов, но полного глобального охвата всё ещё нет, и многие сети продолжают принимать неподписанные анонсы.
• Внутренние prefix-filters у операторов — вручную поддерживаемые списки «от какого соседа какие префиксы принимать». Работают надёжно, но требуют дисциплины и не защищают, если ошибку допустил сам оператор фильтра.

Итог: доверие в BGP распределено и добровольно. Крупный, аккуратный оператор с RPKI и строгими фильтрами хорошо защищён от того, чтобы кто-то *чужой* анонсировал его подсети, — но система в целом остаётся такой, какой её сделают все участники вместе, а не самый ответственный из них.

BGP hijack и route leak: в чём разница

Два термина, которые часто путают, хотя механизм у них общий — неправильный анонс, — а причины разные.

BGP hijack (перехват маршрута) — ситуация, когда AS анонсирует чужой префикс как свой, намеренно или по ошибке. Классические причины:

• Опечатка в конфигурации: инженер скопировал не тот блок адресов или забыл ограничивающий фильтр, и роутер вместо своей подсети анонсировал чужую (или сразу тысячи чужих, если по ошибке экспортировал всю таблицу маршрутизации, полученную от кого-то другого).
• Более специфичный префикс: BGP всегда предпочитает анонс более узкой подсети (/24 перебьёт /16 на тот же диапазон), поэтому даже маленькая ошибочно анонсированная подсеть может увести часть трафика от легитимного владельца более крупного блока.
• Злонамеренные действия: перехват специально используют для перенаправления трафика с целью перехвата данных, атаки на криптовалютные сервисы (подмена маршрута к DNS или к узлам обмена) или для рассылки спама с чужого «чистого» IP-пространства.

Route leak (утечка маршрутов) — когда AS ретранслирует дальше маршруты, которые должна была оставить только для внутреннего использования, нарушая договорённости о пиринге. Типичный случай: сеть получает маршруты от одного апстрима и по ошибке анонсирует их другому апстриму, превращаясь в незапланированный транзитный узел между двумя крупными операторами. Трафик начинает идти по нелепо длинному и перегруженному пути или вовсе не проходит, если промежуточная сеть не рассчитана на такой объём.

В обоих случаях эффект похож: часть интернета внезапно перестаёт видеть правильный путь к пострадавшей подсети или начинает ходить туда кружным, перегруженным или вовсе тупиковым маршрутом. Если пострадавшая подсеть принадлежит крупному облаку, DNS-провайдеру или CDN, инцидент затрагивает не один сайт, а сотни и тысячи сервисов, которые от этой инфраструктуры зависят, — отсюда и заголовки вида «упала половина интернета». Точные даты, масштабы и виновников конкретных громких инцидентов приводить не буду — это тема отдельного расследования с проверенными источниками, а не то, что стоит пересказывать по памяти.

Как это выглядит со стороны обычного сервера

Если вы администрируете один-два сервера, BGP-инцидент на другом конце света вы, скорее всего, не увидите вовсе — вас касаются только те, что затрагивают маршруты до вашей подсети или до сервисов, от которых вы зависите (upstream DNS, платёжный шлюз, API нейросети и т.п.). Симптомы обычно такие:

• Сервер недоступен только для части интернета. Ваш мониторинг из одной точки показывает «всё в порядке», а пользователи из другого региона жалуются на обрывы. Это первый признак маршрутной, а не хостовой проблемы — сам сервер жив, просто до него не всем есть дорога.
• Traceroute обрывается или уходит по неожиданному пути. Обычный путь через 8-10 хопов внезапно идёт через незнакомые AS, а дальше просто не отвечает — пакеты уходят «не туда» и теряются.
• Проблема появляется и исчезает волнами. Пока анонс не разошёлся по всему интернету (конвергенция BGP), одни сети уже видят ошибочный маршрут, другие ещё нет, — поэтому доступность может «мигать» в течение 10-30 минут, а иногда и дольше, если проблему долго не замечают.
• Одновременно рвётся доступ к нескольким несвязанным сервисам. Если хайджек задел крупный DNS-резолвер или облачного провайдера, у вас разом «падает» и сайт, и почта, и сторонний API — хотя ваш собственный сервер ни при чём.

Первым делом в такой ситуации полезно снять traceroute или mtr до проблемного адреса с самого сервера и, если есть возможность, с другой точки (например, с домашнего компьютера через другого провайдера), и сравнить пути. Если пути расходятся кардинально и один из них обрывается на незнакомой AS — это повод смотреть публичные BGP-мониторы, а не искать проблему в конфигурации своего сервера. Если же обрыв связи с сервером совпадает с резким скачком входящего трафика, а не с посторонними маршрутами, вероятнее банальный DDoS — тут пригодится разбор первых действий при DDoS-атаке, а не поиск виноватого провайдера.

Где смотреть публичные BGP-мониторы

Есть несколько бесплатных публичных инструментов, которые показывают текущие и исторические анонсы BGP без необходимости иметь собственный маршрутизатор с полной таблицей:

Практический алгоритм проверки: смотрите whois на подсеть, к которой пропала связь (whois 198.51.100.0/24 покажет legit-владельца и его ASN), затем сверяете этот ASN с тем, что показывает traceroute и RIPE Stat на момент проблемы. Если AS-path в реальном трафике проходит через AS, которой там быть не должно, — это симптом хайджека или утечки на стороне чужой инфраструктуры, и на своём сервере вы это не почините: остаётся ждать, пока пострадавший оператор или его апстримы поправят фильтры, и переключаться на резервные каналы, если они у вас есть. Для постоянного контроля за доступностью собственных сервисов на такие волновые обрывы хорошо ложится связка из внешнего мониторинга — например, разбор в статье про инструменты мониторинга доступности сайта — и алертов, приходящих раньше, чем жалобы пользователей.

Частые вопросы