Кривой анонс BGP у аплинка увёл наш трафик в Бразилию

MAATRIX

Задержка до сервера внезапно выросла в разы, но только у части клиентов — сервер жив, аплинк отвечает, метрики зелёные. Знакомая ситуация: полдня уходит на то, чтобы понять, что дело вообще не в вашей инфраструктуре, а где-то в middle-mile, куда у вас нет доступа. Разбираем реальный случай, как мы его нашли и что можно сделать, если такое случилось с вами.

Что заметили клиенты

Первый сигнал пришёл от одного клиента: "сайт стал тормозить, страницы грузятся по 2-3 секунды вместо привычных долей секунды". Через час — ещё двое с похожей жалобой. При этом основной поток тикетов молчал: подавляющее большинство пользователей ничего не замечали.

Первая проверка — банальная. Смотрим на сам сервер:

top - load average: 0.42, 0.38, 0.35

Загрузка в норме. Диск не сыпется, память не течёт, сетевая карта не показывает ошибок:

ip -s link show eth0
RX: errors 0  dropped 0  overrun 0
TX: errors 0  dropped 0  carrier 0

Проверяем прямой аплинк — пинг до ближайшего роутера дата-центра стабилен, джиттера нет. То есть на участке "сервер — первый хоп" всё чисто. Логичный следующий шаг в такой ситуации — предположить атаку: паразитную нагрузку, которая съедает канал только для части направлений. Смотрим графики входящего трафика за последние часы — ни всплеска пакетов, ни роста числа соединений. conntrack -C в норме, ничего похожего на SYN-флуд.

На этом моменте стало ясно, что версия "проблема на нашей стороне" не подтверждается ни одной метрикой. Пора смотреть шире.

Первая зацепка: проблема избирательна

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

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

Мы попросили пострадавших клиентов прислать вывод tracert (Windows) или traceroute/mtr (Linux/macOS) до нашего сервера. И вот тут картина стала куда понятнее.

Что показал traceroute

Один из присланных трейсов выглядел примерно так (адреса и имена хопов изменены, но структура реальная):

 1  192.168.1.1        1 ms
 2  10.20.x.x           4 ms   (провайдер клиента, локальный узел)
 3  border1.isp.local  12 ms
 4  transit-a.upstream 15 ms
 5  gw-sa.upstream-x   145 ms   <-- резкий скачок
 6  core1.saopaulo.br  152 ms
 7  ...                158 ms
 8  our-network-edge   163 ms

Разница между хопом 4 и хопом 5 — больше 100 мс за один переход, причём имя хопа прямо указывает на локацию в Южной Америке. При этом ни сервер, ни его прямой аплинк территориально там никогда не были — обычный маршрут клиента к нам занимал 6-7 хопов и укладывался в разумные десятки миллисекунд.

Для проверки мы сопоставили несколько трейсов от разных клиентов из одного региона — паттерн повторялся с вариациями в именах хопов, но с одним и тем же скачком задержки в середине пути. Дополнительно свели данные с публичными looking-glass серверами нескольких крупных операторов (у многих транзитных провайдеров и IX есть открытая looking-glass-страница, где можно посмотреть их таблицу маршрутов и сделать traceroute с их узла без доступа к их сети). На части этих looking-glass-серверов маршрут к диапазону адресов нашей подсети действительно шёл через оператора, объявлявшего путь через Южную Америку — хотя географически ни сервер, ни клиенты там не находятся.

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

Как работает BGP и почему одна опечатка ломает маршруты

Чтобы понять, что произошло, полезно упрощённо представлять, как вообще работает маршрутизация в интернете.

Интернет — это не единая сеть, а множество независимых сетей (автономных систем, AS), у каждой свой номер и свой администратор — интернет-провайдер, дата-центр, транзитный оператор, крупная компания со своим блоком адресов. Автономные системы не хранят единую центральную карту "куда что идёт" — вместо этого они обмениваются друг с другом объявлениями по протоколу BGP (Border Gateway Protocol): "я обслуживаю такие-то сети (префиксы), и путь до них лежит через меня".

Когда пакет должен попасть из точки A в точку B, он идёт от AS к AS, и на каждом шаге маршрутизатор смотрит в свою таблицу, построенную из объявлений соседей, и выбирает следующий хоп по правилам (обычно — кратчайший путь по числу AS на пути, с поправками на локальные политики оператора). Ключевой момент: BGP в базовом виде работает на доверии. Если сосед объявляет "я обслуживаю префикс X.X.X.0/24", остальные участники обычно принимают это объявление и начинают маршрутизировать трафик к этому префиксу через него — без глубокой проверки, действительно ли этот оператор имеет право обслуживать именно эту сеть.

Отсюда и уязвимость. Если у какого-то оператора в конфигурации BGP случайно (опечатка в фильтре, неверно скопированный конфиг, ошибка при импорте маршрутов от одного из его собственных клиентов) появляется объявление на чужой префикс — часть интернета, до которой это объявление дошло и оказалось привлекательным по метрикам пути, начинает слать трафик именно туда. Более подробно сам протокол и механизм такого рода сбоев разобран в статье что такое BGP и почему один провайдер может уронить половину интернета, а про то, как вообще устроен путь пакета через провайдеров и точки обмена трафиком — в статье как маршрутизируется пакет от дома до сервера в США.

В нашем случае похоже на следующее: где-то в middle-mile — не у нашего хостинг-провайдера напрямую, а у одного из транзитных операторов дальше по цепочке — произошла ошибка конфигурации, из-за которой более специфичный (или просто ошибочно принятый) маршрут к диапазону, включающему нашу подсеть, стал объявляться через путь, физически проходящий через Южную Америку. Для клиентов, чей трафик к нам заворачивался через операторов, принявших это объявление, реальный путь пакета удлинился на тысячи лишних километров — отсюда и задержка в 100+ мс сверху, хотя по прямой линии связи между их провайдером и нашим дата-центром всё было в порядке.

Важно: это не "взлом" и не атака в классическом смысле, а инцидент качества маршрутизации (route leak или mis-origination) — обычно результат человеческой ошибки в конфигурации у одного из операторов на пути, а не злого умысла.

Кто на самом деле должен это чинить

Здесь стоит честно проговорить границы своих возможностей как арендатора сервера. Вы арендуете VPS или выделенный сервер у хостинг-провайдера. У вас есть контроль над:

• операционной системой и сетевыми настройками внутри самого сервера;
• маршрутизацией внутри вашей локальной сети/VPN, если она у вас есть;
• выбором хостинг-провайдера и тарифа.

У вас нет и не может быть прямого контроля над:

• глобальной таблицей BGP-маршрутов в интернете;
• конфигурацией маршрутизаторов транзитных операторов, через которых физически идёт трафик к вам;
• тем, какое объявление примет или не примет конкретный оператор на другом конце света.

Глобальная BGP-маршрутизация — зона ответственности операторов сетей (AS), а не арендаторов VPS. Это не какая-то условность контракта, а техническая реальность: у вас просто физически нет доступа к конфигурации чужих маршрутизаторов. Даже ваш собственный хостинг-провайдер напрямую не управляет BGP-таблицами других операторов — он может только влиять на то, как объявляет свои префиксы сам, и договариваться (или жаловаться) с проблемным оператором через NOC-контакты.

Что реально можно сделать арендатору сервера

Учитывая ограничения выше, набор реальных действий выглядит так.

1. Собрать данные и обратиться в поддержку своего хостинг-провайдера. Не с формулировкой "у меня всё тормозит", а с конкретикой:

• IP-адреса или диапазоны затронутых клиентов (без личных данных, просто регион/провайдер);
• полные выводы traceroute/mtr от нескольких клиентов, желательно с временными метками;
• время начала проблемы и (если получилось) время окончания;
• ссылки на скриншоты looking-glass, если вы успели их снять до восстановления маршрута.

Хороший провайдер по такому тикету может связаться с проблемным транзитным оператором напрямую (у сетевых инженеров есть свои каналы связи между NOC разных AS) либо, если у него самого несколько независимых аплинков, временно приоритизировать трафик через другой в обход проблемного участка — но это доступно только при наличии альтернативного пути, к чему мы вернёмся ниже.

2. Настроить мониторинг задержки из разных географических точек. Если бы у нас заранее стоял мониторинг пинга/latency до сервера с нескольких внешних точек (разные страны, разные операторы), скачок задержки у части маршрутов был бы виден на графике сразу, а не через жалобы клиентов с задержкой в час-два. Практическая реализация — недорогой внешний сервис проверки из нескольких локаций или свой набор точек мониторинга на дешёвых VPS в разных регионах, откуда идёт периодический ping/mtr до основного сервера с записью в Prometheus или похожую систему. Разбор инструментов для мониторинга доступности — в статье мониторинг доступности сайта: инструменты, а ориентировочные цифры задержки между регионами, с которыми можно сверяться, — в таблице ориентиров по задержке между локациями (это именно ориентиры — у конкретного провайдера и маршрута цифры будут отличаться).

3. Признать, что "починить" на уровне одного сервера нельзя. Не существует команды, которую можно выполнить на своём VPS, чтобы исправить чужой BGP-анонс. Можно только:

• ждать, пока проблемный оператор исправит конфигурацию (обычно это часы, реже — сутки, если проблема системная и требует эскалации между операторами);
• через поддержку своего провайдера попросить смену пути, если технически возможно;
• в отдельных случаях — временно опубликовать более специфичный собственный анонс, если у вас есть своя AS и вы сами анонсируете свои префиксы, но это уже сценарий для тех, кто держит собственную сеть, а не для арендатора VPS.

Ниже — сводная таблица, что реально в руках арендатора сервера, а что нет.

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

В нашем случае от первой жалобы клиента до возврата задержки к норме прошло несколько часов — большую часть этого времени заняло не столько исправление на стороне проблемного оператора, сколько наша собственная диагностика: отсеять версии с атакой и перегрузкой, собрать трейсы от клиентов, сопоставить их с looking-glass. Путь трафика выправился сам, как только транзитный оператор отозвал или поправил ошибочное объявление.

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

Главный практический вывод: аплинк должен быть не один

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

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

При выборе провайдера для аренды сервера стоит прямо спрашивать: сколько у вас аплинков и от каких операторов, что происходит при деградации одного из них. Это тот вопрос, ответ на который вы не увидите ни в одном публичном прайс-листе, но который напрямую влияет на устойчивость вашего сервиса к инцидентам вроде описанного выше — когда сам сервер ни в чём не виноват, а трафик всё равно "уезжает" через полмира.

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