Народный

Методика

Эволюция ТСПУ 2024-2026: от sigmatch к ML

АК Антон Кравцов · инженер сетевой безопасности · · обновлено 31 мая 2026 г. · ⏱ 12 мин
§ в этой статье — 15 разделов

К маю 2026 ТСПУ — это не «коробка с правилами», как было в 2022, а многослойный inline-движок, где сосуществуют четыре поколения детекции: IP-blacklists, sigmatch на конкретных байтах протокола, JA3-fingerprint TLS-стека и ML-классификатор поведения соединений. Каждый слой добавлялся не вместо предыдущего, а сверху. Чтобы понимать, какие VPN-протоколы выживут в 2027 и почему сегодня работают именно VLESS Reality, AmneziaWG и Hysteria 2, нужно разобрать эволюцию ТСПУ как технического артефакта.

Эта статья — техническая хроника изменений за два года, от первой массовой волны блокировок WireGuard в начале 2024 до behavioral ML, который выкатили в первом квартале 2026. С ссылками на конкретные RFC, IETF-драфты и публичные patent-claims российских вендоров.

Что было до 2024: исходная архитектура

До 2024 года ТСПУ оперировал на двух слоях: IP/AS-blacklists и пакетная инспекция первых байтов. Это система, которую можно описать через формальную грамматику regex по сетевому payload’у. На входе — поток пакетов, на выходе — решение «пропустить / дропнуть / замедлить» на основе матчинга с базой сигнатур.

Архитектурно ТСПУ — это transparent bump-in-the-wire middlebox на магистральном стыке оператора с интернетом. Inline-режим означает, что ТСПУ видит каждый пакет физически и должен принимать решение быстрее, чем пакет достигнет следующего hop’а. Это накладывает жёсткое ограничение на сложность анализа: per-packet latency в районе единиц миллисекунд, иначе оператор получает падение качества сервиса для всего трафика, а не только для VPN. Именно поэтому ML-классификаторы стали возможны только в 2026, когда железо подросло.

К концу 2023 года в базе ТСПУ были sigmatch-правила на OpenVPN (opcode 0x38 в первом байте payload’а), L2TP/IPsec (port-based + ESP-сигнатуры) и PPTP (легаси, но всё ещё в правилах). WireGuard тогда ещё пропускался — его dropp’или только после волны 2024 года.

2024 — первая волна: WireGuard handshake matching

WireGuard стал главной мишенью первой большой волны 2024 года, потому что у него был фатальный для anti-DPI слабый пункт — детерминированный handshake.

В нативном WireGuard первый пакет от клиента — это MessageInitiation (RFC 7539-подобный Noise IK pattern), у которого ровно 148 байт и фиксированная структура: первый байт 0x01 (message_type), три байта zero-padding, четыре байта sender_index, 32 байта ephemeral public key, 48 байт encrypted static key, 28 байт encrypted timestamp, 32 байта MAC1, 16 байт MAC2. См. whitepaper WireGuard, раздел 5.4.2.

Для ТСПУ это означает sigmatch-правило из одной строки: «UDP-пакет ровно 148 байт + первый байт 0x01 + любой destination port». Ложноположительная нагрузка околонулевая — других протоколов с такими параметрами в живом интернете нет. Внедрение этого правила во всех ТСПУ заняло, по нашим наблюдениям, два месяца — с февраля по апрель 2024 года. К маю native WireGuard перестал работать у всех операторов с лицензией.

Контрмера в виде AmneziaWG появилась тем же летом. Команда AmneziaVPN добавила в форк WireGuard три параметра рандомизации: Jc (junk packets count — N пакетов случайного содержимого до handshake), Jmin/Jmax (диапазон длин junk-пакетов), S1/S2/H1-H4 (префиксы и заголовки внутри пакетов handshake’а). Это сломало sigmatch — теперь первый пакет от клиента имеет случайную длину и содержит случайные байты, и хотя по реальной структуре он остался WireGuard’ом, ТСПУ не может его распознать без context-aware анализа. Подробности техники — в статье про padding и junk-пакеты.

2024 (вторая половина): TLS-обфускация и SNI blocking

Параллельно с WireGuard-волной ТСПУ начал агрессивнее работать с TLS-трафиком. Здесь использовались два разных подхода.

SNI-based blocking. При установлении TLS-соединения клиент шлёт ClientHello, в котором в открытом виде указан Server Name Indication — DNS-имя сервера, к которому он хочет подключиться. ТСПУ парсит SNI и проверяет по whitelist/blacklist. Для VPN это означало, что любой сервер с известным VPN-доменом блокировался независимо от протокола внутри. Подробности — в глоссарии про SNI и про SNI-блокировки.

TLS-stack fingerprinting через JA3. JA3 — это хэш от набора параметров ClientHello: версия TLS, cipher suites, extensions, elliptic curves, EC point formats. Поскольку каждая TLS-библиотека имеет уникальный набор по умолчанию, JA3 эффективно отличает curl от Chrome от Go’s crypto/tls от OpenVPN-TLS. ТСПУ начал собирать базу «легитимных» JA3 (Chrome, Firefox, Safari, мобильные браузеры) и блокировать остальные на критичных портах. Это убило все VPN, использовавшие нестандартные TLS-стеки — например, шpadowsocks-over-TLS со встроенным TLS-обёртчиком.

Контрмера — uTLS, библиотека для Go, которая permits программе подделывать ClientHello под конкретный браузер. Если ваш VLESS-клиент использует uTLS с профилем Chrome 121, его JA3 совпадает с JA3 настоящего Chrome. ТСПУ не может отличить. Сейчас uTLS — фактический стандарт для всех serious VPN-клиентов: xray-core, sing-box, NekoBox, Hiddify — все собирают TLS через uTLS, см. issue tracker uTLS для актуального состояния профилей.

2025 — JA3 entropy и active probing

В 2025 ТСПУ перешёл от static JA3 matching к двум более продвинутым техникам.

Динамический JA3 anomaly detection

Когда uTLS стал массовым, простой match по JA3-hash перестал работать — слишком много легитимного трафика идёт через эмулированные браузерные fingerprint’ы. ТСПУ стал смотреть на entropy: какие JA3 встречаются у пользователя в течение сессии. Реальный пользователь генерирует разнообразный набор JA3 (открытие десятков сайтов, разные SNI, разные пути в Chrome — Cookie, скрипты, fetch’и). Пользователь VPN — один и тот же JA3 на единственный destination IP, постоянно, часами.

Это уже не sigmatch, а статистика — и впервые требует state-tracking на уровне «сессия клиента к destination в течение часа». В IETF есть draft-ietf-tls-ech и связанные обсуждения, в которых эта проблема явно описана как мотивация для ECH.

Active probing

Вторая техника 2025 — active probing. ТСПУ время от времени самостоятельно подключается к destination IP, на который шёл подозрительный TLS-handshake, и проверяет, есть ли там реальный веб-сервер с нормальным контентом. Если сервер отвечает мусором, шлёт reject на простой GET / или отвечает только на специально-сформированные пакеты — это маркер VPN-сервера.

Active probing — это не российская инновация: техника описана в работах GFW исследователей, в частности в Censored Planet и в работе «How China Detects and Blocks Shadowsocks» от Alice Filastò et al. ТСПУ перенял подход примерно в третьем квартале 2024 и расширил в 2025.

Контрмера — Reality от xray-core. Reality proxies первые пакеты TLS-handshake’а от настоящего whitelist’ового origin’а (microsoft.com, mail.ru, любой другой большой сайт), и только после успешной аутентификации клиента переключает на VPN-payload. Active probing видит реальный microsoft.com и считает destination легитимным.

2026 — behavioral ML и packet-timing classification

Главное изменение 2026 года — внедрение ML-классификаторов на packet-level features. По публичным заявкам российских вендоров DPI (см. секцию про вендоров ниже) и косвенным данным из эмпирических тестов, в первом квартале 2026 в ТСПУ появился новый слой: behavioral classifier на градиентном бустинге (XGBoost или аналог) по features:

  • Размеры первых N пакетов соединения (типично N=10–20)
  • Междупакетные интервалы (inter-packet delay)
  • Направление байт (client→server vs server→client ratio в первые секунды)
  • TCP window scaling в первых SYN/SYN-ACK
  • TLS record sizes после handshake
  • Длительность idle-фаз
  • MTU/MSS heuristics

Это classic encrypted-traffic classification, известный по академическим работам ещё с 2010-х. Главный ресурс — обзор «A Survey on Encrypted Network Traffic Analysis» от Velan et al., 2015, и более свежие работы от UCL и UNSW (2022–2024).

Принцип: ML-модель обучается на размеченном корпусе трафика — образцы Chrome browsing, Netflix streaming, Zoom video-calls, OpenVPN, WireGuard, VLESS Reality, Shadowsocks. Модель учится отличать классы по статистическим паттернам. На production-выходе она классифицирует unknown-соединения с какой-то confidence-score’й. ТСПУ дропает соединения с score’й выше порога, либо замедляет, либо сигнализирует на следующие слои.

Что обходит ML — DAITA и traffic shaping

Главная контрмера 2026 года — DAITA (Defence Against AI-guided Traffic Analysis), предложенная Mullvad и реализованная в их клиенте с конца 2023, и затем интегрированная в Hysteria 2 и в свежие версии xray-core.

DAITA работает на двух направлениях:

  1. Constant-rate padding. Клиент шлёт пакеты в строго фиксированном ритме (например, каждые 10 мс), независимо от реального application-трафика. Если реальных данных нет — отправляется padding. Если данных много — они режутся по фиксированным chunk’ам. Это сглаживает packet timing features до уровня constant.

  2. Packet-size normalization. Все пакеты приводятся к одному из небольшого набора размеров (например, 64, 512, 1280, 1500 байт), независимо от реального payload’а. Это убивает features «размер первых N пакетов».

Цена — bandwidth overhead 20-40% и фиксированный baseline-трафик даже когда вы не используете VPN. Но behavioral classifier на DAITA-трафик выдаёт confidence около 50% — то есть случайный шум.

Подробнее про эти техники — в нашей отдельной статье про ML-классификаторы и VPN.

Хронология одной таблицей

ПериодГлавная новая фича ТСПУЧто упалоКонтрмера
2022 — нач. 2023IP-blacklists коммерческих VPNNordVPN, Proton, Expressself-hosted VPS
Конец 2023OpenVPN sigmatch (opcode 0x38)OpenVPN nativeOpenVPN-over-stunnel (временно)
Q1-Q2 2024WireGuard handshake sigmatch (148-byte UDP, 0x01)native WireGuardAmneziaWG (Jc/Jmin/Jmax)
Q3-Q4 2024SNI-blacklist + JA3 static matchShadowsocks-over-TLS, custom VLESSuTLS + Reality
Q1-Q2 2025JA3 entropy + active probingстарые Trojan, Shadowsocks-PlainReality v2, ShadowTLS v3
Q3-Q4 2025TCP window/timing heuristicsOpenVPN-XOR, naive VLESSHysteria 2 (QUIC), padding
Q1 2026Behavioral ML на packet timingsVPN без shapingDAITA, constant-rate padding

Каждая новая волна не отменяет старые — это аддитивный slot stack. Поэтому в 2026 году протокол должен одновременно: иметь нормальный uTLS-fingerprint, проксировать через Reality, рандомизировать handshake (как AmneziaWG), и в идеале применять DAITA. Не каждый клиент-протокол комбинация выполняет всё четыре, поэтому существует «иерархия выживаемости» — какие протоколы прошли больше волн.

Чем вооружены вендоры

ТСПУ — это не один продукт. Это термин для класса middlebox’ов, поставляемых несколькими российскими вендорами с государственным финансированием. Главные имена в 2026: EcoFilter, RDP.RU (часть «Ростелекома»), «Группа Яндра», ZTE-локализованные продукты. Каждый предлагает разный feature set и разные performance-характеристики. Детальный разбор — в нашей статье про российских DPI-вендоров 2026.

С точки зрения эволюции движка важно знать одно: за каждой волной стоит конкретный вендор, который продаёт оператору обновление прошивки или новую модель. Когда в 2024 году пошла WireGuard-волна — её катили в основном через RDP.RU. ML-классификатор 2026 — это совместная разработка нескольких вендоров с участием российских ML-лабораторий.

Как меняется операторская сторона

Технологическая эволюция ТСПУ — это только половина истории. Вторая половина — операционная: как операторы внедряют новые волны, насколько единообразно и с каким временным лагом.

По нашим наблюдениям, в РФ-2026 существует трёхуровневая иерархия внедрения. Первый уровень — Москва, СПб, ЦФО: ТСПУ обновляется в первые 2-4 недели после релиза вендором. Если EcoFilter выпустил обновление сигнатур в начале квартала — у московского Ростелекома и МТС оно появится в первые две недели. Это даёт security-сообществу узкое окно, чтобы зафиксировать новый pattern и доработать контрмеры.

Второй уровень — региональные центры, города-миллионники: 1-2 месяца лаг. Например, Новосибирск, Екатеринбург, Казань получают апдейты через ~6 недель после Москвы. У части операторов второго эшелона — на 3 месяца позже.

Третий уровень — малые города, сельские районы, удалённые регионы: 3-6 месяцев лаг или вообще отсутствие новых волн. Это объясняет почему в малых городах часть VPN, не работающих в Москве, ещё работает. Региональные операторы либо физически не имеют новых моделей DPI, либо не успевают подключить.

Практический вывод для anti-DPI разработчиков: тестирование протоколов нужно вести минимум в трёх локациях — Москва/СПб + крупный региональный центр + малый город. Один-локационное тестирование даёт неполную картину.

Эффект на ecosystem VPN-провайдеров

ML-волна 2026 года катит серьёзный отбор на рынке VPN-провайдеров для РФ. Провайдеры разделяются на три категории.

Категория 1: глобальные с anti-DPI focus. Mullvad с DAITA, Proton с обфусцированным OpenVPN, ExpressVPN с Lightway-stealth. Эти провайдеры активно инвестируют в behavioral-резистентные протоколы. Их клиенты выживают через volнy 2026 года.

Категория 2: РФ-ориентированные с custom-stack. Durev VPN, Red Shield, PlusOne, AmneziaVPN — провайдеры, выросшие из российского рынка с глубоким опытом ТСПУ. Они быстрее реагируют на новые волны (часто в течение дней), потому что либо размещают серверы в РФ-юрисдикции, либо имеют тесную связь с локальным DPI-research community. См. наш рейтинг — главная страница.

Категория 3: классические провайдеры без anti-DPI. Большинство массовых сервисов из США/EU, которые «продают VPN как идею privacy», но не имеют технических средств обхода ТСПУ. Их клиенты массово не работают в РФ-2026. Это NordVPN, CyberGhost, частично Surfshark — все они исторически блокированы и не вкладываются в anti-DPI разработку.

Эволюция ТСПУ — это структурный фильтр отрасли. После каждой волны рынок «зачищается» от провайдеров без serious anti-DPI stack’а.

Что будет в 2027

Прогноз — три ветки развития.

Ветка 1: дальнейшее углубление ML. Подключение DNS-correlation (классификатор смотрит, какой домен резолвили перед TLS-connection, и если домена не было — флаг). Это требует сопряжения DPI с DNS-логами оператора, что технически возможно, но политически сложно — операторы не хотят давать ТСПУ доступ к billing-системам.

Ветка 2: повышение SNI-цензуры через ECH-blocking. Когда Encrypted Client Hello станет массовым (Cloudflare уже включил, IETF финализировал draft в 2024), ТСПУ окажется перед выбором: либо разрешить ECH и потерять SNI-видимость, либо блокировать любой TLS с ECH-extension. По публичной риторике РКН — будут блокировать. Это спровоцирует следующую гонку.

Ветка 3: ужесточение требований к VPS-провайдерам. Не техническая эволюция ТСПУ, а смежная — попытка регулировать сам факт наличия VPS вне РФ. Уже сейчас идёт давление на платёжные системы. Если введут реестр зарубежных VPS-провайдеров и обяжут банки блокировать платежи на них — self-hosted VPN станет проблематичным для масс-аудитории. Это уже не про DPI, а про инфраструктуру.

Архитектурные ограничения, которые не уйдут

Несмотря на нарастающую сложность ТСПУ, у любого inline middlebox’а есть фундаментальные ограничения, которые держат окно для VPN открытым. Понимать их важно — это даёт основу для прогноза «что точно НЕ заблокируют».

Ограничение 1: per-packet latency budget. ТСПУ должен принять решение по каждому пакету за единицы миллисекунд. Это исключает heavy ML с сотнями миллионов параметров. CNN-классификаторы на 100M параметров — это GPU-inference на 50-200 мс per packet, что приемлемо для post-hoc анализа, но не для inline. Это ставит ceiling на сложность моделей.

Ограничение 2: false positive cost. Каждый false positive — это блокировка реального пользователя legitimate-трафика. Если порог классификатора стоит слишком низко, оператор получает массовые жалобы. Это держит классификаторы на conservative settings — лучше пропустить VPN, чем заблокировать обычного юзера.

Ограничение 3: encrypted payload. Сам payload зашифрован. ТСПУ не может прочитать сообщения в Telegram, не может видеть содержимое VPN-туннеля. Все техники строятся на side-channels — метаданных, размерах, таймингах. Любая контрмера, которая нормализует side-channels (DAITA, padding, traffic shaping), приближает классификатор к random guess.

Ограничение 4: операторская кооперация. Не все операторы одинаково усердны. Региональные провайдеры могут отставать на полгода в обновлениях. Какой-то ISP с лицензией СОРМ может игнорировать тонкости и держать в правилах только базовые сигнатуры. Это означает, что всегда есть какой-то оператор, через которого проходит больше. Этот фактор даёт фундаментальную negotiating leverage для VPN-индустрии.

Ограничение 5: международные стандарты. Когда ECH, MASQUE, HTTP/3 становятся IETF-стандартами и default’ами в Chrome/Firefox/Safari — ТСПУ не может их блокировать массово без обвала веб-трафика. Это даёт VPN-протоколам бесплатное прикрытие.

Связанные материалы

§ FAQ

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

[ + ] Чем ТСПУ 2026 отличается от ТСПУ 2024?
Концептуально — переходом от static signature matching к статистической классификации. В 2024 году ТСПУ был набором regex-подобных правил: ловил по фиксированным байтовым последовательностям (OpenVPN opcode 0x38, WireGuard message_type 0x01). В 2025 добавился TLS-fingerprinting через JA3 и JA3S — сравнение наборов cipher suites и extensions с whitelist'ом легитимных браузеров. В 2026 движок дополнился вероятностной классификацией по packet-level features: размеры первых N пакетов, междупакетные интервалы, направление байт. Это не отменяет старые слои, но добавляет четвёртый — поведенческий. Из практических следствий: даже идеально замаскированный TLS-handshake может быть выявлен по неестественной длительности idle-фаз между пакетами.
[ + ] Может ли ML-классификатор поймать VLESS Reality?
В мае 2026 — нет, или с ложноположительной нагрузкой, неприемлемой для оператора. Reality по дизайну mimics реальный TLS к whitelisted-домену (например, microsoft.com) и проксирует первые байты handshake от реального origin'а — packet sizes и timing совпадают с легитимным трафиком на тот же домен. Чтобы ML отделил Reality от настоящего пользователя, идущего на microsoft.com, нужны features, которых попросту нет в сетевом слое: содержимое уже зашифровано, и поведение после ClientHello трудно сопоставить с поведением реального браузера, который ходит на статику. На прямой вопрос «когда ТСПУ научится» ответ: только когда подключит на корреляционный анализ DNS-запросы, длительность сессий и historical-данные по пользователю — а это уже не inline-классификация, а post-hoc анализ.
[ + ] Что будет дальше — после behavioral ML?
По публичным docs IETF и патентам российских вендоров просматривается три направления. Первое — DNS-correlation: классификатор смотрит, какой домен пользователь резолвил перед TLS-connection. Если домена не было — флаг. Второе — fleet-wide anomaly detection: статистика по AS и подсетям, ловят VPS-провайдеров, где аномально много TLS-соединений на странные SNI. Третье — encrypted traffic analysis с side-channel features: jitter в acknowledgement'ах, паттерны retransmission, MTU heuristics. Все три — экстенсии того же ML-подхода, не качественный скачок. Качественный скачок будет, когда введут обязательную регистрацию SNI у операторов или клиентскую сертификацию, но это уже не DPI, а другой режим интернета.

читать дальше

Похожие статьи