Как мы собрали сети Telegram и научили BGP выбирать для них другой путь
В какой-то момент Telegram не исчез полностью. Он начал ломаться кусками.
На одном подключении проходили сообщения, но зависали картинки. На другом приложение долго устанавливало соединение. IPv4 и IPv6 вели себя по-разному, а обычная проверка интернета радостно сообщала, что всё работает.
Самое простое решение лежало на поверхности: отправить через альтернативный маршрут вообще весь трафик. Оно действительно могло бы помочь. Заодно оно добавило бы задержку всем остальным приложениям, увеличило нагрузку и превратило небольшую проблему одного сервиса в новую сетевую архитектуру.
Мы решили сделать наоборот: оставить интернет на привычном пути, а отдельно маршрутизировать только адресное пространство, которое в контролируемых проверках связано с Telegram.
Проблема одного адреса
Для пользователя Telegram выглядит одним приложением. Для маршрутизатора никакого Telegram не существует. Он видит только пакеты, адреса назначения и таблицу маршрутов.
Сам сервис при этом не живёт на одном вечном IP. Есть разные площадки, адресные семейства и сетевые префиксы. Набор меняется, а часть симптомов зависит не только от маршрута, но и от протокола, времени установления соединения и конкретного оператора.
Поэтому список из нескольких адресов, найденный однажды в интернете, был бы не решением, а отсроченной поломкой.
Как собирали набор сетей
Основой стали публичные данные маршрутизации и контролируемые наблюдения за тем, куда действительно подключается приложение. Источники не принимались на веру автоматически: найденные префиксы нормализовались, удалялись дубли, слишком широкие совпадения отбрасывались, а очередное обновление сравнивалось с последним рабочим набором.
У обновления появились простые предохранители. Если число сетей внезапно меняется слишком сильно, новая версия не принимается. Если источник недоступен, остаётся последний проверенный набор. Если новый маршрут не проходит пользовательскую проверку, его можно отозвать одной операцией, не переписывая конфигурацию каждого устройства.
Это важный момент: автоматизация не должна превращать любой ответ из интернета в доверенную сетевую политику.
Зачем здесь BGP
Можно было вручную занести одинаковый список статических маршрутов на каждый роутер. А потом повторять это при каждом изменении, искать расхождения и однажды обнаружить устройство, на котором осталась версия полугодовой давности.
Вместо этого один проверенный набор превращается в маршруты и распространяется внутри сети через BGP. Только нужные пограничные роутеры принимают эту группу маршрутов и направляют её по альтернативному пути. Остальные устройства либо не получают её, либо не импортируют по своей роли.
BGP здесь не угадывает приложение и не обходит блокировку волшебной командой. Он выполняет более скучную и полезную работу: доставляет одинаковое решение тем роутерам, которым оно действительно нужно.
Маршрут по умолчанию остаётся прежним. Обычные сайты, обновления, видео и всё остальное не отправляются в ненужный крюк. IPv4 и IPv6 проверяются отдельно, потому что зелёный результат одного семейства ничего не доказывает про другое.
Что проверяли после раздачи
Свежие маршруты в таблице — ещё не победа. Мы проверяли, что выбран правильный следующий переход, ответ возвращается тем же ожидаемым способом, набор не перехватывает посторонние сети, а приложение выполняет реальное действие: устанавливает соединение, получает сообщения и загружает медиа.
Отдельно проверялся откат. Отзыв группы маршрутов должен вернуть исходное поведение без ручной уборки на каждом роутере. Последний рабочий набор сохраняется, но не становится вечной истиной: его возраст и актуальность тоже контролируются.
Что в итоге
Мы не построили огромный туннель для всего дома и не научили роутеры распознавать логотип приложения. Мы отделили задачу сервиса от остального интернета, собрали проверяемую модель его сетей и использовали BGP как способ согласованно раздать эту модель нужным узлам.
Такой подход не вечен. Адреса и способы подключения меняются, а IP-маршрутизация остаётся приближением к понятию «сервис». Но у приближения теперь есть источник, проверка, версия, ограниченная область действия и понятный откат.
Именно в этот момент набор костылей перестаёт быть случайным. Он становится маленькой системой.
Больше практических историй о сетях, эксплуатации и автоматизации я собираю в AI Blog: https://ai-blog.icez.org/
