ТСПУ и замедление Twitter: что мы увидели на корпоративном трафике

10 марта Роскомнадзор объявил о замедлении Twitter через ТСПУ - технические средства противодействия угрозам. Это оборудование устанавливается у провайдеров по закону об устойчивом интернете с 2019 года, но до сих пор применялось преимущественно для блокировок, а не замедления. Теперь - первый публичный эксперимент именно с throttling'ом конкретного ресурса.

Мы это почувствовали на клиентском трафике раньше, чем прочитали официальное сообщение РКН.

Как мы это обнаружили

У нескольких клиентов есть мониторинг качества соединений по ключевым внешним адресам. Twitter используют как минимум три команды - для корпоративных аккаунтов, мониторинга упоминаний, и один клиент гоняет туда уведомления через webhook. Примерно в 9 утра по московскому времени у части из них пошли таймауты и деградация.

Первая мысль была банальной - авария у самого Twitter. Но Twitter работал, просто медленно. Очень медленно. Причём не у всех одинаково.

Картина у разных провайдеров

Вот что мы увидели, прогнав диагностику по нескольким точкам:

• Ростелеком (магистраль) - замедление выраженное, особенно на загрузку медиа. RTT к Twitter вырос в разы, потери пакетов при передаче больших объёмов.
• МТС - схожая картина, но чуть мягче. ТСПУ есть, работает, но поведение немного другое - меньше потерь, больше задержек.
• Один из региональных операторов, работающих через аренду магистральной ёмкости - замедление практически не ощущалось в первые часы. Это интересно само по себе.
• Каналы через иностранные точки обмена трафиком - там Twitter работал нормально. Что, собственно, и объясняет, почему VPN снимал проблему.

Неравномерность объясняется тем, что ТСПУ - это оборудование, которое устанавливается у конкретных операторов связи. Не везде оно стоит в одной и той же точке цепочки, не везде настроено одинаково, и не все транзитные пути через Россию им покрыты в полной мере. Это не централизованный рубильник - это распределённая система, у которой есть зазоры.

Как работает DPI в этой схеме

ТСПУ на основе DPI (Deep Packet Inspection) умеет определять трафик к конкретным ресурсам даже по HTTPS - по SNI в TLS handshake, по IP-адресам из реестра, по характеристикам трафика. Для замедления применяется traffic shaping: полоса к Twitter режется до установленного порога. Механика на уровне провайдера выглядит примерно так:

Входящий трафик
    -> DPI-анализ (SNI/IP-lookup)
    -> совпадение с реестром РКН
    -> шейпинг: ограничение полосы
    -> доставка замедленного трафика

Тонкость в том, что HTTPS шифрует содержимое, но не скрывает SNI при установке соединения (если не используется ECH/ESNI, а большинство клиентов его не поддерживают). Twitter в SNI - достаточно для срабатывания правила.

При этом QUIC/HTTP3, который некоторые клиенты поддерживают по UDP, ведёт себя по-другому - его шейпить сложнее, и в первые часы часть соединений по UDP проскакивала без замедления.

Что это значит для SD-WAN

Мы работаем с SD-WAN решениями у нескольких клиентов, и этот инцидент поставил несколько конкретных вопросов.

Первый. Классический SD-WAN с выбором канала по метрикам RTT и потерям пакетов отреагировал на ситуацию по-разному. Там, где есть несколько аплинков с разными провайдерами, оркестратор SD-WAN правильно переключился на канал, где Twitter работал лучше. Это ровно то, для чего такие решения и существуют. Там, где аплинк один - помочь было нечем.

Второй. Замедление ТСПУ - это не авария, а регуляторное действие. Формально с точки зрения SD-WAN это «деградация канала», и система обрабатывает её как техническую проблему. Но с точки зрения реакции - она правильная. Если второй канал через другого провайдера или через зарубежную точку присутствия - трафик уйдёт туда.

Третий, неудобный. Если РКН применит замедление к ресурсу, который использует SD-WAN оркестратор для контроля качества тоннелей - это может привести к нежелательному failover'у. Это гипотетический сценарий, но его стоит проработать при настройке политик.

Что делали с клиентами

Там, где были webhook'и и критичные интеграции с Twitter API - временно подняли запросы через корпоративный VPN-шлюз, который выходит через канал без ТСПУ-фильтрации. Долгосрочное решение это не решение, но на время инцидента сработало.

Ни один клиент не потерял критичную функциональность - именно потому, что у всех есть резервные каналы и мониторинг. Без мониторинга они бы узнали о проблеме от пользователей.

Промежуточный итог

РКН показал, что ТСПУ работает как инструмент замедления, а не только блокировки. Работает неравномерно - и это сейчас факт, а не оценка. Для корпоративных сетей с зависимостями от внешних API это новый класс рисков: ресурс доступен, но нестабилен, и эта нестабильность - управляемая.

Нас интересует дальнейшая динамика: как будет меняться покрытие ТСПУ у операторов, появятся ли правила для UDP-трафика, и как на это отреагируют сами сервисы. Пока наблюдаем.