DPI Модель противника: как блокируют VPN

Прежде чем учить «как обойти», надо понять что именно детектит современный DPI. Reality, ShadowTLS, AmneziaWG — это конкретные ответы на конкретные техники цензуры. Без модели противника эти решения выглядят магией. С моделью — становятся очевидной инженерией.

Что узнаешь

Что такое DPI и как он встроен в сеть провайдера
Три уровня детекции: passive fingerprinting, active probing, statistical/ML
SNI-инспекция, ALPN, JA3/JA4 fingerprinting — что это и как работает
TLS-in-TLS detection — главная проблема Trojan и почему Reality его не имеет
Архитектура ТСПУ (РФ), GFW (Китай), DPI Ирана — что отличает и что общего
Что они умеют, чего не умеют, куда движутся к 2027

1. Что такое DPI и где он стоит

DPI (Deep Packet Inspection) — это не «один прибор», а класс оборудования, которое читает содержимое пакетов, а не только заголовки. Обычный маршрутизатор смотрит src/dst IP + порт и решает куда отправить. DPI смотрит payload — что именно лежит внутри TCP/UDP-стрима.

Где DPI стоит в сети

DPI ставится в разрыв между провайдером и магистральным интернетом — bump-in-the-wire

В России это ТСПУ — закон 90-ФЗ (2019), стоит у каждого крупного провайдера. В Китае — Great Firewall (GFW), в Иране — комбинация DPIarch, в Туркменистане, Беларуси, КНДР — свои реализации (часто на основе китайских/российских наработок).

2. Уровень 1: Passive fingerprinting — что видно сразу

DPI получает копию пакета и смотрит первые байты. Если узнал шаблон — дальше можно блокировать или маркировать. Это самый дешёвый метод: гигабиты в секунду на ASIC.

SNI-инспекция

Главная техника 2024-2026. Как мы видели в уроке 02, в TLS 1.3 ClientHello имя сайта (SNI) передаётся в открытом виде. DPI:

Видит TCP-handshake (SYN, SYN-ACK, ACK)
Ждёт ClientHello (первый пакет с данными от клиента)
Парсит SNI extension
Сверяет с blacklist
Если совпало — отправляет TCP RST обеим сторонам. Соединение рвётся.

Атака

TCP RST injection

Самый частый механизм цензуры. DPI не блокирует пакет физически — он шлёт обеим сторонам подделанные RST-пакеты с правильными sequence numbers. Стороны думают «другая сторона разорвала соединение» и закрывают сокет. Изящно и не требует in-line блокировки — DPI может работать в режиме mirror/tap, что даёт огромную пропускную способность.

JA3/JA4 fingerprinting

JA3 (Salesforce, 2017) — hash от полей ClientHello: TLS-версия, список cipher-suites, extensions, supported groups, EC point formats. Идея: разные клиенты (Chrome, Firefox, curl, OpenVPN, Trojan, V2Ray) выдают разные комбинации — это уникальный отпечаток.

JA3-string: 771,4866-4867-4865-49196-...,0-23-65281-10-11-...,29-23-24,0 ↑ ↑ ↑ ↑ TLS ver cipher-suites extensions supported curves JA3 hash: b32309a26951912be7dba376398abc3b ← это и есть «отпечаток» Примеры реальных fingerprint: Chrome 120 Windows : cd08e31494f9531f560d64c695473da9 Firefox 121 Linux : 6734f37431670b3ab4292b8f60f29984 curl/8.1.0 : fa6ebccda5e7ca8c1f9b9c4e0d7d4d65 Trojan-Go default : d4e5b18d6b607ef5dafd8a82d937e23a ← легко в blacklist

JA4 (FoxIO, 2023) — улучшение: добавляет ALPN, signature algorithms, делает fingerprint человекочитаемым (t13d1516h2_8daaf6152771_b0da82dd1658) и устойчивым к перестановке полей.

Атака

JA3-blacklist

У DPI есть база JA3-хэшей известных VPN/proxy-клиентов. Trojan, V2Ray, sing-box, голый OpenVPN Go-client, wireguard-go HTTP-обёртки — все имеют узнаваемые fingerprint. Соответствие = блок.

Контрмера: uTLS (см. урок 06) — библиотека, которая в Xray/sing-box заставляет клиент шифровать TLS handshake идентично реальному Chrome/Firefox/Safari. JA3 совпадает с настоящим браузером — детект ломается.

ALPN — ещё один indicator

ALPN (Application-Layer Protocol Negotiation) — extension в ClientHello, где клиент сообщает: «я хочу говорить по HTTP/2 или HTTP/1.1». Список протоколов:

h2 — HTTP/2
http/1.1 — HTTP/1.1
h3 — HTTP/3 (QUIC)

Если клиент шлёт ALPN ["h2", "http/1.1"] — это браузер. Если ["xtls"] или нет ALPN вовсе — это уже подозрительно. Современные anti-detect протоколы (XTLS-Vision, Reality) всегда подставляют ALPN как у настоящего браузера.

TLS-in-TLS detection — главная боль Trojan

Самая хитрая техника. Что такое TLS-in-TLS:

Клиент устанавливает TLS-канал с VPN-сервером (внешний TLS — выглядит как HTTPS)
Внутри этого канала пользователь идёт на https://wikipedia.org
То есть внутри зашифрованного канала идёт ещё один TLS-handshake

Атака

Как GFW детектит TLS-in-TLS

Обычный HTTPS-канал к веб-серверу выглядит так: handshake → запрос (300-2000 байт) → ответ (десятки KB) → следующий запрос. Тайминги и размеры специфические.

VPN-канал с TLS внутри: handshake → внутренний handshake (3-4 пакета по ~200 байт за миллисекунду) → потом обычный трафик. Этот «всплеск маленьких пакетов сразу после handshake» — и есть отпечаток TLS-in-TLS. GFW научился это видеть в 2022 — массовые блокировки Trojan в Китае.

Подробно опубликовано в работе GFW Report «How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic» (USENIX Security 2023).

Контрмера

XTLS-Vision и Reality

XTLS-Vision делает «splice»: после внешнего handshake передача переключается на сырой TCP без дополнительного шифрования (зачем шифровать дважды — внутренний TLS уже шифрует). «Всплеск handshake» при этом маскируется паддингом.

Reality идёт ещё дальше: вообще не использует свой TLS-handshake. Клиент ПРОВОДИТ настоящий handshake с настоящим сайтом (например, apple.com), и только в середине handshake происходит «угон». TLS-in-TLS просто отсутствует — нечего детектить. Подробно — урок 07.

3. Уровень 2: Active probing

DPI может не только пассивно слушать, но и сам подключаться к подозрительным IP, чтобы проверить «а это правда веб-сервер или это VPN»?

Как работает GFW

Клиент в Китае подключился к IP 1.2.3.4:443
GFW отметил: «новый адрес, посмотрим внимательнее»
Через несколько секунд GFW сам подключается к 1.2.3.4:443 с разных своих узлов
Шлёт «непонятные» байты — случайные данные, неполный handshake, известные паттерны Shadowsocks/V2Ray
Смотрит реакцию: если сервер ответил «как должен веб-сервер на мусор» (closes connection или 400) — ок. Если ответил «как VPN-сервер» (echo, нестандартное поведение) — IP в blacklist на 24 часа.

Активная атака

Shadowsocks была убита active probing

Оригинальный Shadowsocks (до AEAD) имел уязвимость: при получении «неправильных» байт сервер молча принимал/отвечал нулями. GFW отправлял известные тестовые наборы (PoCs опубликованы в Geneva). По характеру ответа Shadowsocks-сервер опознавался за 5-10 проб. После 2019 Китай массово блокировал любой SS-сервер за 24 часа после первого использования.

Контрмера

Как современные протоколы защищаются

Trojan/Reality: если входящий пакет не имеет правильного «пароля» в первых байтах, сервер маскируется под обычный nginx и отдаёт реальный HTTPS-сайт (это называется «fallback»). Probe видит «обычный сайт» — не подозрительно.

Shadowsocks-AEAD-2022: ввели обязательную проверку timestamp + криптографически сильный pre-shared key. Probe с неправильным ключом получает рандомный мусор обратно (как должен любой HTTPS-сервер). Опознать сервер активным зондом стало невозможно.

4. Уровень 3: Statistical and ML detection

Самая дорогая, но самая опасная техника. DPI собирает статистику по соединению и скармливает модели машинного обучения.

Что смотрят:

Распределение размеров пакетов. У браузера много мелких + редкие большие. У VPN — равномерные (MTU − overhead).
Тайминги. HTTPS — пакеты идут «волнами» (запрос → ответ). VPN — непрерывный поток с обеих сторон одновременно (bidi flow).
Энтропия первых N байт. Зашифрованный трафик имеет почти максимальную энтропию. Реальные HTTP/TLS-заголовки — нет.
Соотношение upload/download. Веб-серфинг: 10:90. VPN с активным видеозвонком: 50:50. Подозрительно.
Длительность сессии. Браузер закрывает соединение через секунды. VPN держит часами.

2024-2026 тренд

«Fully encrypted traffic detection»

GFW Report 2023: у GFW есть классификатор, который маркирует любой «неклассифицируемый» зашифрованный поток. Просто «не похоже ни на одно из 10 000 известных приложений» = подозрительно = на повторную проверку или блок. Это убивает «бесформенные» обфускации типа obfs4.

Решение: протокол должен выглядеть как что-то знакомое, а не как «случайный шум». Поэтому новые протоколы (Reality, Trojan, ShadowTLS) маскируются под HTTPS к настоящим сайтам.

5. Кто против тебя: ТСПУ vs GFW vs Иран

	ТСПУ (РФ)	GFW (Китай)	Иран
Что умеет	SNI block, IP block, WG signature, OpenVPN signature, ML-классификатор (с 2024)	Всё перечисленное + active probing + TLS-in-TLS detection + fully encrypted detection	SNI, IP, ALPN, иногда active probing. Слабее GFW, но активнее блокирует крупные сервисы (Telegram, Twitter)
Active probing	Редко, начали в 2024	Постоянно, агрессивно	Иногда
ML/статистика	Развивается с 2024 (нацпроекты)	В продакшне с 2023	Базово
Что работает	Reality, Hysteria 2, AmneziaWG, ShadowTLS	Reality + uTLS (mimicking Chrome), Hysteria 2 (порт-хоппинг), TUIC	Любой современный stealth-протокол (Reality, ShadowTLS, Hysteria, Cloak)
Период блокировок	Часто разовые, после крупных событий	Перед партсъездами и юбилеями — «полное затемнение»	Перманентно, периодически «full shutdown» (BGP отключают)
Особенность	Закон требует SORM-логирования — но это другая система	Активная блокировка целых ASN зарубежных хостингов	Whitelist подход в моменты «затемнения» (только госсайты)

Под капотом

Почему ТСПУ медленнее GFW в разработке

GFW существует с 1998, имеет команды R&D и тысячи академических работ по реверс-инжинирингу VPN-протоколов. У них есть собственные публикации на USENIX, S&P, NDSS — главных конференциях по security. ТСПУ запущен официально в 2019, разработка китайскими вендорами (так и есть, с Huawei/ZTE), активно догоняет, но отстаёт на 2-3 года. Это окно — то, что сейчас даёт жить Reality и AmneziaWG в РФ.

6. Сводная «модель противника»

Чтобы протокол выжил в 2026, он должен пройти ВСЕ три уровня:

Passive: ClientHello как у настоящего браузера (uTLS), нормальный SNI, нормальный ALPN, JA3 в whitelist, ничего «магического» в первых байтах.
Active probing: сервер на подозрении должен прикидываться настоящим веб-сайтом — fallback на nginx/Apache, отдавать настоящий контент по непровоцированным запросам.
Statistical: распределение пакетов и тайминги похожи на реальный HTTPS-трафик (browsing pattern), не на «равномерный поток».

Сегодня этим всем требованиям соответствует ровно один протокол — VLESS + Reality + Vision. Hysteria 2 заходит с другой стороны (UDP/QUIC, маскируется под HTTP/3-видеостриминг).

7. Что дальше

Теперь у нас есть модель противника. В следующих уроках разбираем конкретные протоколы:

Урок 06: Xray-core и его протоколы (VMess, VLESS, Trojan, XTLS-Vision)
Урок 07: Reality — пиковое решение 2024-2026
Урок 08: Hysteria 2 и TUIC — UDP-альтернатива
Урок 09: Shadowsocks-AEAD-2022, ShadowTLS, AmneziaWG