Можно ли, не имея доступа к маршрутизаторам провайдера, повлиять на выбор его upstream для своего трафика?

matvey — Sat, 12 Sep 2026 18:18:58 +0000

В этой статье я расскажу о своём небольшом Computer Science исследовании и отвечу на вопрос: «Можно ли управлять маршрутом своего интернет-трафика?»

Спойлер: Частично.

Просмотр Upstreams в bgp.tools

Точкой отсчета стала проверка в bgp.tools наличия разных upstream-провайдеров, т.к это ключевой момент эксперимента.

На скриншоте (см. выше) мы видим наличие два upstream, а именно:

🇷🇺 AS20485 TransTeleCom JSC
🇬🇧 AS9002 RETN Limited

Коротко о каждом:

🇷🇺 AS20485 TransTeleCom JSC - АО «Компания ТрансТелеКом» (ТТК), один из крупнейших магистральных провайдеров телекоммуникационных услуг в России.
🇬🇧 AS9002 RETN Limited - RETN Limited, крупный международный магистральный оператор связи (Tier-2/NSP) со штаб-квартирой в Великобритании.

Вопрос - главная часть исследования

После анализа upstream'ов я задался вопросом:

Можно ли выбрать конкретный upstream (в нашем случае RETN) и направить весь трафик через него?

Изучив теорию BGP-маршрутизации, я выяснил, как провайдеры выбирают оптимальный путь. В алгоритме BGP (Best Path Selection) ключевую роль играют два параметра:

Local Preference — наивысший приоритет, который сетевые инженеры задают вручную (например, если с RETN есть прямой выгодный стык).
AS-PATH Length — длина пути в автономных системах. Если Local Preference у маршрутов одинаковый, роутер BGP автоматически выбирает путь с наименьшим количеством промежуточных звеньев (Shortest AS-PATH).

Таким образом, если найти целевой IP-адрес, до которого путь через RETN выигрывает по длине AS-PATH (или имеет больший LocalPref у провайдера), трафик гарантированно пойдет через RETN.

Первые замеры

В приведенных ниже тестах будет использоваться утилита NexTrace — open-source визуальный трекер маршрута.

Первый тест проведем с помощью сервиса Looking Glass от RETN:

По результатам видно, что трассировка прошла исключительно по инфраструктуре RETN с минимальной задержкой.

На основе этого теста у меня сформировалась гипотеза: если подобрать VPS-хостинг с IPv4-адресом из подсети, которая анонсируется через инфраструктуру RETN, домашний провайдер выберет маршрут через RETN (из-за наименьшего AS-PATH Length или правил Local Preference), что обеспечит минимальный пинг. Для организации постоянного канала потребуется настроить VPN-туннель.

Однако оставалось сомнение: не сработает ли динамический балансировщик трафика у провайдера? При высокой нагрузке на канал RETN провайдер потенциально мог переключить маршрут на более выгодный или менее загруженный для себя путь (например, TTK).

Поиск хостинг-провайдера с нужным IP-адресом

Благодаря возможностям поиска Google Gemini Deep Research подходящую площадку удалось найти достаточно быстро. Мой выбор пал на хостинг-провайдера EDIS Global, у которого маршрутизация некоторых локаций идет именно через инфраструктуру RETN, что я подтвердил с помощью NextTrace.
В качестве кандидатов для экспериментов я отобрал несколько локаций:

Локация 🇱🇻 Латвия, Рига:

Локация 🇪🇪 Эстония, Таллин:

Локация 🇦🇺 Австралия, Сидней

Из вышеперечисленных вариантов для практической работы я выбрал Эстонию (Таллин). Далее в ход пойдет инструмент Trippy для детального анализа MTR-пакетов, чтобы ответить на главный вопрос:

Будет ли большой объем трафика стабильно и без сбоев идти через апстрим RETN?

Практическая часть и выводы

P.S. Во время написания статьи мне предоставили сервер, который также маршрутизировался через инфраструктуру RETN, поэтому мы с уверенностью можем переходить к практике.

После быстрой настройки VPN заворачиваем весь Steam-трафик в туннель и запускаем Trippy.

Trippy наглядно показывает текущий путь отправки пакетов. Нам это нужно для того, чтобы отслеживать, не переключает ли провайдер апстрим с RETN на TTK во время высокой нагрузки.

По результатам скачивания 15 ГБ контента маршрут остался абсолютно стабильным. Это подтверждает два главных тезиса:

Наш трафик действительно успешно зашел в туннель через AS RETN — нам удалось косвенно повлиять на выбор магистрального оператора.
Маршрутизация на уровне BGP осталась неизменной: провайдер не переключал апстрим «на лету», так как объемы одного пользователя не влияют на глобальные политики BGP-маршрутизации.

Вывод:

Управлять маршрутом косвенно — реально. Подбирая VPS с IP-адресами из подсети, маршрутизируемой через нужную AS (в нашем случае RETN), и заворачивая туда трафик через VPN, можно повлиять на итоговый путь, добиться оптимальной задержки и избежать перегруженных узлов.

Стабильность канала. Эксперимент показал, что маршрутизация остается абсолютно стабильной даже при активной прокачке трафика (15 ГБ во время загрузки через Steam).

Зачем это нужно на практике. Такой подход полезен не только для исследований, но и для применения в реальной жизни — например, для снижения пинга в онлайн-играх или обхода проблемных и перегруженных магистральных стыков конкретного провайдера.

DEV Community: matvey