ТСПУ и DPI: как в России технически устроена фильтрация трафика

«Роскомнадзор заблокировал» — формулировка, которая почти ничего не объясняет. Чтобы понимать, почему у вас Telegram отваливается на мобильном, но живёт на домашнем Wi-Fi, а у знакомого в соседнем доме всё наоборот, нужно представлять, где именно стоит оборудование и по каким признакам оно принимает решения. Разбираем без публицистики.

Два разных механизма, которые постоянно путают

В России параллельно работают две системы, и они устроены совершенно по-разному.

Реестр запрещённой информации появился в 2012 году. Это список адресов и доменов; оператор обязан сам закрыть к ним доступ. Механизм грубый: блокировка по IP или по имени домена, обходится тривиально, ломает всё лишнее, что живёт на том же адресе. Именно им пытались закрыть Telegram в 2018 году, и именно поэтому тогда легли попутно банки и магазины.

ТСПУ — технические средства противодействия угрозам — введены законом о «суверенном интернете» в 2019 году. Это уже не список, а железо, установленное непосредственно в сети оператора и управляемое централизованно, минуя оператора. Оператор обязан его поставить, пропустить через него абонентский трафик и не имеет доступа к правилам, по которым оно работает.

Разница принципиальная: реестр говорит «не пускай туда», ТСПУ — «смотри на весь трафик и делай с ним то, что я скажу».

Где физически стоит оборудование

ТСПУ включается «в разрыв» на стыке между сетью оператора и остальным интернетом — там, где проходит весь абонентский трафик. Схематично путь пакета такой:

ваше устройство
   ↓
базовая станция / домовой коммутатор
   ↓
районный узел агрегации
   ↓
магистральный маршрутизатор оператора
   ↓
[ ТСПУ ]  ← здесь принимается решение
   ↓
точка обмена трафиком → внешний интернет

Из расположения следуют два практических вывода. Первый: трафик внутри сети оператора через ТСПУ может не проходить — поэтому внутренние сервисы и локальные пиринги иногда работают, когда «интернет не работает». Второй: оборудование обрабатывает поток целиком, в реальном времени, на скоростях в сотни гигабит. Это накладывает жёсткие ограничения на глубину анализа — времени на каждый пакет крайне мало, и это объясняет, почему методы распознавания именно такие, как описано ниже.

Четыре метода распознавания

1. По адресу назначения

Самый дешёвый способ: сверить IP-адрес получателя со списком. Работает мгновенно, ошибается часто — на одном адресе в облаке живут тысячи не связанных между собой сервисов. Отсюда классическая картина «заблокировали один сервис, отвалилось двадцать посторонних».

2. По имени сайта в рукопожатии

При установке HTTPS-соединения клиент в открытом виде сообщает, к какому домену обращается, — это поле SNI, и оно не зашифровано. Оборудование читает его и решает, пропускать ли. Дёшево, точно, применяется массово.

Технология ECH (Encrypted Client Hello) шифрует в том числе и это поле — и именно поэтому соединения с ECH в российских сетях часто рвутся: то, что нельзя прочитать, проще не пропустить. Reality решает задачу иначе и умнее: он не прячет имя домена, а подставляет настоящее имя настоящего популярного сайта, к которому претензий нет.

3. По подписи протокола

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

4. По поведению потока

Самый дорогой и самый неприятный метод. Содержимое не разбирается вовсе — анализируется форма трафика: распределение размеров пакетов, интервалы между ними, соотношение отданного и принятого, длительность сессии.

Голосовой звонок узнаётся по ровному потоку мелких UDP-пакетов с постоянным интервалом — независимо от того, каким мессенджером он сделан и как зашифрован. Видеострим — по характерной «пиле» загрузки сегментов. Именно поэтому звонки в мессенджерах ломаются даже там, где переписка ходит нормально: их выдаёт не содержимое, а ритм.

Что оборудование делает после того, как распознало

Заблокировать — самый заметный вариант и потому не самый частый. Арсенал шире:

• Срезать полосу. Соединение живёт, но полоса ограничена до единиц процентов. Формально доступ есть — пользоваться нельзя. Ключевой приём: выглядит как проблемы у самого сервиса.
• Ронять соединение через N секунд. Видеозвонок устанавливается, идёт восемь секунд и обрывается. Классическая примета фильтрации по поведению: решение принимается не сразу, а когда накопилась статистика потока.
• Терять часть пакетов. Скажем, каждый двадцатый. TCP воспримет это как перегрузку сети и сам снизит скорость — вмешательство при этом почти не отследить.
• Резать только один тип содержимого. Текст в мессенджере ходит, картинки не грузятся: под ограничение попали крупные потоки, а мелкие пропускаются.
• Отвечать сбросом соединения. Соединение обрывается так, будто это сделала удалённая сторона.

Общая логика везде одна: чем меньше происходящее похоже на блокировку, тем лучше. Замедление не порождает ни сообщений об ошибке, ни поводов для жалобы — «просто плохо работает».

Почему у всех по-разному

Самый частый вопрос — и на него есть внятный ответ. Команды приходят централизованно, а исполняет их разное оборудование в разных сетях:

• Разные поставщики железа. ТСПУ разных вендоров различаются и по возможностям, и по агрессивности эвристик.
• Мобильные сети жёстче фиксированных. В мобильной сети трафик и так проходит через глубокую цепочку обработки, встроить в неё фильтрацию проще. Отсюда типичная картина: на сотовом не работает, на домашнем Wi-Fi работает.
• Разная нагрузка. Анализ поведения потоков — дорогая операция. В час пик оборудование может её упрощать или, наоборот, резать агрессивнее. Отсюда «утром нормально, вечером нет».
• Разные точки выхода. Крупный федеральный оператор и небольшой региональный подключены к внешнему интернету по-разному, и путь трафика различается физически.

Как разложить это по конкретным операторам — в разборах для Москвы и Петербурга и регионов.

Что из этого следует для обхода

Разложим по методам, против чего что помогает:

Отсюда практический вывод. Классические VPN-протоколы проигрывают уже на третьем пункте — их выдаёт форма рукопожатия, и никакая настройка это не лечит. Работают только протоколы, у которых собственной подписи нет в принципе. Как это устроено внутри — подробно в статье про VLESS Reality.

Проверить, что именно происходит конкретно у вашего оператора, можно самостоятельно — методика с командами в статье «Как проверить, что провайдер режет трафик».

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

У всех, кто обслуживает существенное число абонентов, — это требование закона о «суверенном интернете» от 2019 года. У мелких региональных операторов оборудование может быть проще и настроено менее агрессивно, отсюда заметная разница в поведении.

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

Нет, и разница принципиальная. При блокировке соединение не устанавливается вовсе. При замедлении оно работает, но полоса срезается до единиц процентов от нормальной: формально всё доступно, практически — нет. Второе применяется чаще, потому что выглядит как «плохая связь».

Содержимое соединений, защищённых современным TLS, оборудование не читает. Ему доступны метаданные: адреса, объёмы, тайминги, имя запрашиваемого сайта в открытых полях рукопожатия. Этого достаточно для фильтрации, но не для чтения сообщений.