ML-классификаторы против VPN 2026: как нейросети ловят трафик

К маю 2026 ML-классификаторы стали реальной частью arsenal’а ТСПУ — не маркетинговой обёрткой, а production-feature, которая прокатилась через несколько крупных операторов в первом квартале 2026. Это четвёртый слой DPI поверх IP-blacklists, signature matching и TLS-fingerprinting (см. наш разбор эволюции ТСПУ 2024-2026). И это первый слой, который атакует фундаментальное свойство VPN — необнаружимость зашифрованного payload’а — через side-channel: статистические паттерны самого факта существования соединения.

Эта статья — технический разбор: что такое behavioral DPI, какие алгоритмы применяются, какие features извлекаются из трафика, почему это работает, что обходит — DAITA, padding, traffic shaping. С академическими ссылками и кодом, который можно поднять для тестов.

Базовая идея: encrypted traffic classification

Encrypted traffic classification — академическая дисциплина с конца 2000-х. Главный insight: даже если содержимое трафика зашифровано и DPI не может прочитать payload, есть метаданные, которые DPI видит свободно:

• Размеры пакетов
• Время между пакетами (inter-arrival time)
• Направление пакетов (client→server vs обратно)
• Длительность сессий
• Количество flows на (client, server) пару
• Структура TCP/UDP заголовков (window scaling, MSS, TTL)

Каждый класс приложений (Chrome browsing, YouTube streaming, Zoom call, OpenVPN tunnel, VLESS Reality) генерирует distinctive статистический отпечаток в этих метаданных. Chrome с HTTP/2 — много мелких параллельных flows, периодические bursts при загрузке страницы. YouTube — длительные unidirectional flows с большими пакетами и заметным buffering. VPN — один-единственный flow, через который идёт смесь всего, что делает пользователь.

ML-модель обучается на размеченном корпусе и учится отличать классы. Это и есть behavioral classification.

Конкретные алгоритмы

В академической литературе и в публичных patent-claims российских вендоров фигурируют три семейства алгоритмов.

XGBoost (Gradient Boosting Trees). Главный workhorse production ML-DPI. Преимущества для inline-DPI: быстрый inference (миллисекунды на пример), модель помещается в RAM (~100-500 МБ для серьёзной модели), предсказуемое поведение. Главный paper по применению XGBoost для traffic classification — Aceto et al., «MIMETIC: Mobile encrypted traffic classification using multimodal deep learning» (2019). С тех пор есть десятки follow-up.

Random Forest. Альтернатива XGBoost, классическая. Чуть медленнее, чуть менее точный, но проще обучать и tune. Часто используется как baseline для сравнения.

Convolutional Neural Networks (CNN) на packet sequences. Более продвинутый подход — представить первые N пакетов сессии как «изображение» (sequence of feature vectors), пропустить через CNN, получить класс. Работа Wang et al., «End-to-end encrypted traffic classification with one-dimensional convolution neural networks» (2017) — pioneer-paper. Главный недостаток для production-DPI — высокая GPU-нагрузка, что объясняет, почему Yadro Inspecto выбрал GPU-архитектуру.

В РФ-2026 наиболее распространён XGBoost — по косвенным признакам (производительность, заявленный throughput, цены на железо). CNN — пилотные deployments у Yadro.

Features — что именно извлекается

Конкретный feature set публично не известен, но по академической литературе и patent claims примерный список:

Per-packet features:

• Размер пакета (payload size, не включая заголовки)
• Направление (client→server = 1, иначе 0)
• Inter-packet delay (микросекунды от предыдущего пакета)
• TCP flags (для TCP-трафика): SYN, ACK, PSH, FIN
• TLS record type (если виден): handshake, application_data, alert

Per-flow features (агрегированные за первые N пакетов, обычно N=10-30):

• Sum/mean/median/std размеров пакетов
• Sum/mean/median/std inter-packet delays
• Соотношение client/server byte counts
• Burstiness coefficient (стандартное отклонение / среднее inter-arrival time)
• Идентификатор TLS-стека (через JA3-hash)
• Duration session
• Destination port category (well-known / ephemeral)

Inter-session features (если ТСПУ ведёт state по клиенту):

• Количество одновременных flows
• Распределение destination IPs
• Частота новых connections

Полный feature engineering — research-level задача. Главные открытые ресурсы:

• Academic dataset: ISCXVPN2016 (University of New Brunswick) — общественный корпус VPN-vs-non-VPN, на котором обучаются почти все ML-классификаторы
• Repository: traffic-classification — collection алгоритмов и features
• Paper: «An End-to-End Pipeline for Encrypted Traffic Classification» от UCL, 2022 — обзор state-of-art

Точность и performance

На research-benchmarks (ISCXVPN2016) современные ML-классификаторы достигают:

• VPN vs non-VPN: ~95-98% accuracy
• Конкретный VPN-протокол (OpenVPN vs WireGuard vs VLESS): ~80-90%
• Конкретный VPN-провайдер: ~60-75% (сложнее, потому что разные провайдеры могут использовать один протокол)

В production-условиях ТСПУ accuracy ниже из-за noise: разные операторы, разное packet loss, разные RTT, мобильный vs проводной трафик. Реалистичная production-accuracy для отличия «VPN vs не-VPN»: ~85-92%.

Это даёт интересную дилемму для оператора. Если ставить порог высокий (95%+), классификатор будет пропускать значительную долю VPN. Если ставить низкий (70-80%), будут ложноположительные блокировки legitimate трафика — например, Microsoft Teams call может статистически похож на VPN.

В мае 2026 наблюдается следующая практика: ТСПУ использует ML-классификатор не для прямой блокировки, а для rate-limiting. Если флаг сработал — соединение замедляется (TCP throttling, packet drop с вероятностью X%). Это даёт пользователю поведение «медленно работает», что коррелирует с blame на «плохой интернет», а не на блокировку. См. ту же тактику Замедления YouTube с 2024 — это та же philosophy.

Что обходит ML — традиционные техники

ML-классификаторы работают на features, которые genericallyDescribe «как себя ведёт зашифрованное соединение». Чтобы обойти ML, нужно сделать так, чтобы метаданные VPN-трафика статистически совпадали с метаданными легитимного трафика. Есть несколько подходов.

Padding до константной длины пакета

Самая простая контрмера: все пакеты приводятся к одному размеру. Например, всегда 1280 байт (для MTU 1500 минус overhead). Если payload меньше — заполняется padding’ом. Если больше — режется на куски.

Эффективность: убивает features «размер пакета», но оставляет features «inter-arrival time», «burstiness», «count». Один padding недостаточен.

Применяется в: Shadowsocks-2022 (опционально), Cloak, ряд кастомных решений на основе xray-core. См. глоссарий про padding.

Constant-rate transmission

Клиент шлёт пакеты в строго фиксированном ритме — например, ровно каждые 10 мс, независимо от реальных application-данных. Если реальных данных нет — отправляется dummy-traffic. Если данных много — они режутся на chunk’и и отправляются в темпе ритма.

Эффективность: убивает features «inter-arrival time», «burstiness». Оставляет features «соотношение client/server» и «count».

Применяется в: Tor pluggable transports (некоторые), экспериментальные форки xray.

Traffic shaping под реальный профиль

Самая продвинутая техника: вместо абстрактного «constant rate» имитировать конкретный класс легитимного трафика — например, Chrome browsing на популярном сайте, или Netflix streaming. Pattern-matching фактического трафика к real-world профилю.

Эффективность: при качественной реализации обходит большинство ML-классификаторов. Минусы — высокая сложность реализации, bandwidth overhead.

Применяется в: research-проектах, экспериментально в Mullvad DAITA.

DAITA — Defence Against AI-guided Traffic Analysis

DAITA — флагман среди anti-ML-DPI техник 2026 года. Разработан Mullvad VPN совместно с университетом Karlstad (Швеция) и реализован в Mullvad-клиенте с конца 2023. К 2026 — портирован в Hysteria 2, частично в sing-box.

Архитектура DAITA. Это hybrid из трёх техник:

1. Constant-rate scheduling. Пакеты планируются на отправку в discrete time slots (например, каждые 10 мс). Если в slot есть реальные данные — отправляются они. Если нет — отправляется dummy-packet.

2. Packet padding to discrete sizes. Все пакеты приводятся к одному из небольшого набора размеров (например, {64, 256, 512, 1280}). Реальные данные дополняются padding’ом до ближайшего большего размера.

3. Defensive cover traffic. Помимо constant-rate, периодически инжектируется burst dummy-traffic’а в random patterns. Это рандомизирует features «sequence shape».

Главный механизм — machine generating realistic noise. DAITA вначале строилась как защита от deep-learning-based DPI, поэтому сама использует small ML-model на стороне клиента, которая генерирует cover traffic, статистически неотличимый от обычного веб-серфинга.

Mullvad опубликовал DAITA-подход в своём блоге (декабрь 2023) и в академической работе «DAITA: Defence Against AI-guided Traffic Analysis» (USENIX 2024). См. также Mullvad open-source repo — DAITA-implementation в открытом коде.

Цена DAITA. Bandwidth overhead 20-40%. Если у вас 100 Мбит/с линия — DAITA-туннель выдаст 60-80 Мбит/с реального throughput’а. Для веб-серфинга и чатов это нормально, для 4K-стриминга — заметно.

Эффективность. По публичному тестированию Mullvad на ISCXVPN2016 — DAITA уменьшает accuracy ML-классификаторов с ~95% до ~52% (то есть до random guess для бинарной задачи). Это существенно: ML, который дает 50%, бесполезен для production-DPI, потому что false-positive rate в 50% разрушает любой operational workflow.

XTLS-Vision и низкоуровневый shaping

XTLS-Vision — другой подход, изначально разработанный в xray-core для VLESS. Это не constant-rate как DAITA, а умная packet reshaping на TLS-уровне.

Идея: первые N TLS-record’ов после handshake приводятся к размерам, типичным для HTTPS-страниц популярных сайтов. Это не constant-rate, а «realistic burst» — несколько пакетов разного размера в начале сессии, имитирующие загрузку веб-страницы. После — низкая активность.

Эффективность ниже DAITA, но overhead меньше — XTLS-Vision добавляет ~5% bandwidth overhead и заметно сложнее детектируется на короткие сессии. Подробности — в нашей статье про uTLS и глоссарии XTLS.

Открытые проблемы и forecast

ML-классификаторы — относительно новый слой DPI. Несколько открытых проблем.

Adversarial examples. В академическом ML есть концепция: специально-построенные образцы трафика, которые целенаправленно «ломают» классификатор. Это пока больше research-тема, но в 2027-2028 ожидаются продвинутые anti-ML техники, специально дизайненные под конкретные классификаторы ТСПУ.

Model drift. ML-модели нужно регулярно re-training на свежих данных, иначе они «деградируют» — мир меняется быстрее модели. У ТСПУ это означает необходимость постоянной разметки трафика, что дорого. Если разметка реже чем VPN-провайдеры обновляют свои протоколы — accuracy падает.

Differential privacy в Apple/Google. Apple iCloud Private Relay и Google проверяют технологии traffic anonymization на masс-уровне. Если они станут default’ом на iOS/Android — большая часть мобильного трафика будет MASQUE-туннелями, и ML-классификатор не сможет отличить «легитимный private relay» от «vpn». Это de-facto разрушает behavioral DPI на mobile.

Forecast 2027. К концу 2027 ожидается:

• ТСПУ будет использовать combined-stack: signature + JA3 + behavioral ML + ECH-correlation
• В anti-DPI протоколах DAITA или аналоги станут стандартом
• Появится несколько open-source реализаций defensive ML-traffic-generation (типа Mullvad DAITA, но для self-hosted)
• Бизнес-VPN (Apple, Google) станут transparently частью anti-censorship landscape, прячут VPN-трафик в массе

Cat-and-mouse: динамика рынка

ML-классификаторы запустили новый темп в гонке между DPI и anti-DPI. Если для signature matching цикл «новая сигнатура → контрмера в протоколе» занимал 3-6 месяцев, то для ML-классификаторов он гораздо короче и асимметричнее.

Со стороны DPI. ТСПУ нужно регулярно re-training моделей: каждый месяц или чаще, потому что VPN-протоколы эволюционируют, и старая модель «деградирует». Re-training требует свежей размеченной даты — а это либо ручная разметка (дорого), либо semi-supervised на flow logs (риск contamination).

Со стороны anti-DPI. Разработчики протоколов отслеживают новые ML-pattern’ы через тестирование на реальных операторах. Когда видят что accuracy упала — добавляют новый shaping в протокол. Цикл такого обновления — недели.

В итоге ML-волна 2026 года, в отличие от signature-волн 2024-2025, не имеет «финального» состояния. Это постоянная инфраструктурная гонка, в которой обе стороны вкладывают ресурсы в обнаружение / маскировку статистических паттернов. Это меняет экономику anti-censorship — теперь нужны постоянные R&D-инвестиции, а не одноразовая контрмера.

Side-channels, которые сложно скрыть

Даже DAITA не решает всех problem. Есть несколько side-channels, которые сложно нормализовать:

DNS-correlation. Перед TLS-соединением клиент резолвит домен. Если DNS-резолв происходит за миллисекунды до connect — это сигнал. Чтобы скрыть, нужно либо использовать DoH (как iCloud Private Relay), либо ходить на статичные IP без DNS-резолва.

TCP timestamp. В TCP-options есть Timestamp option, который заполняется клиентом и leak’ает внутренние часы. Это feature, по которому можно «отличить устройства» (включая определение, что одно и то же устройство использует разные IP). Для VPN — это путь к correlation between VPN-сервером и реальным клиентом. Для QUIC эта проблема меньше (нет TCP options), но в QUIC v1 есть spin bit, который тоже leak’ает информацию.

Behavioral patterns на application-layer. Даже если packet timings normalized DAITA, у пользователя есть consistent application-patterns: какой браузер, как часто refresh страниц, какие сайты в каком порядке. ML-классификатор может коррелировать эти паттерны через стороны туннеля, если получает данные с обоих endpoints (source-side через flow records у оператора, destination-side через correlated traffic от других пользователей).

Total volume. Long-running tunnel генерирует характерное total bytes/sessions ratio. Реальный пользователь делает 1000 коротких сессий в день, VPN-юзер — одну сессию на 12 часов с большим volume. Это очевидный, но трудно скрываемый сигнал.

Все эти side-channels — research-теmas, активно обсуждаются в академических группах. Полностью anti-ML протокол должен бороться со всеми, что делает его дорогим в дизайне.

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

Если выбираете VPN в РФ-2026 с расчётом на 2027:

1. Предпочитайте провайдеров с DAITA или аналогом. Mullvad, Proton (частично), несколько emerging VPN-сервисов с anti-ML focus.
2. Для self-hosted — используйте Hysteria 2 с salamander obfuscation, AmneziaWG с агрессивными junk packets, VLESS Reality с XTLS-Vision.
3. Не полагайтесь только на signature matching обхода — это вчерашний фронт. ML-волна идёт.
4. Mix multiple протоколов в одном клиенте (sing-box умеет switch между протоколами). Это усложняет classification как минимум потому, что устойчивость к ML-volna коррелирует с разнообразием fingerprint’ов.

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

• Эволюция ТСПУ 2024-2026
• Российские DPI-вендоры 2026
• TLS 1.3 + ECH
• QUIC и будущее VPN-протоколов 2026
• Padding и junk-пакеты
• uTLS и JA3 fingerprint
• VLESS Reality 2026