Запустил dpi-checkers на трёх провайдерах, разобрался с методами TCP 16-20 и CIDR-вайтлистами и расскажу, что вообще происходит с вашим трафиком на L4

В последние пару лет любой пользователь рунета научился различать «интернет дома» и «интернет в гостях у бабушки в области». В одном месте YouTube открывается, в другом нет. На одном провайдере Discord работает, на другом висит. Twitter (X) у мобильного оператора на 4G не загружается, а через тот же оператор на проводе идёт нормально. Это ощущается как непредсказуемость, но на самом деле за каждой такой деградацией стоят вполне конкретные технические механизмы — и их можно идентифицировать.

В статье я разберу, что технически делают современные DPI-системы, на примере открытого исследовательского проекта dpi-checkers от автора hyperion-cs. Это набор тестов (часть на Go в виде CLI-утилиты, часть прямо в браузере на JS), которые позволяют понять, какой именно метод фильтрации применяет ваш ISP. Я прогнал проверки на трёх своих подключениях — домашнем (один из крупных федеральных провайдеров), мобильном (один из «большой четвёрки») и через знакомого в другом регионе — и расскажу, что выяснилось.

Сразу оговорка по жанру. Это не инструкция по обходу ограничений. Это разбор того, как работают сами методы фильтрации — что является нормальной темой для технической прессы и многократно обсуждалось в академических работах (статьи net4people, исследования Citizen Lab). Цель — дать читателю понимание, что именно происходит с его пакетами на уровне сети, и какие инструменты позволяют это исследовать в полевых условиях.

Что такое DPI и почему «провайдеры замедляют» — это упрощение

Deep Packet Inspection — это класс сетевых технологий, при которых проходящий через узел трафик анализируется не только по заголовкам L3/L4 (IP, порты), но и по содержимому L7 (что именно передаётся в полезной нагрузке пакета). Современный DPI способен по особенностям TLS handshake определить, к какому сервису обращается клиент, даже без знания IP назначения, и применить к этому трафику политику — пропустить, замедлить, сбросить.

Когда в новостях говорят «провайдеры замедляют YouTube», это упрощение. Технически провайдер не «замедляет YouTube»: он применяет одну из нескольких возможных техник, и в зависимости от техники симптомы у пользователя разные. Перечислю основные методы, которые наблюдаются в РФ-сегменте.

Метод 1: блокировка по IP-подсетям (CIDR-вайтлисты). Регулятор передаёт оператору список разрешённых подсетей — если IP назначения не в этом списке, трафик к нему не пропускается. Как правило, применяется не на «домашних» подключениях, а на мобильных в режиме 5G/4G+ (некоторые тарифы) или для трафика из-за пределов «доверенной зоны». Это самая жёсткая форма блокировки.

Метод 2: TCP 16-20 (он же rps-разрыв). Селективный сброс TCP-соединения после определённого числа байтов в потоке. Чаще всего DPI ждёт первые 16-20 пакетов в установленной TLS-сессии и, если они «подозрительные» (содержат SNI определённых хостов), отправляет одной или обеим сторонам RST-пакет. Соединение разрывается. Клиент видит это как «сайт упал», хотя сервер живой. Это основной метод замедления YouTube в РФ в 2024-2025 годах.

Метод 3: подмена DNS-ответов. Запрос к DNS-серверу перехватывается на уровне провайдера, и ответ заменяется. Вместо настоящего IP сайта пользователь получает заглушку или 0.0.0.0. Старый и грубый метод, легко обходится через DoH/DoT, но всё ещё применяется как первая ступень.

Метод 4: SNI-блокировка. В TLS handshake поле Server Name Indication передаётся в открытом виде до установки шифрованного канала — DPI это видит и сбрасывает соединение, если SNI содержит «нежелательный» домен. Это вариант метода 2, но более универсальный.

Метод 5: QUIC-блокировка. QUIC (HTTP/3) использует UDP, а не TCP. Если DPI настроен только на TCP-фильтрацию, QUIC-соединения проходят. Поэтому отдельно фильтруют UDP-трафик, в первую очередь по портам 443/80 или по характерным заголовкам QUIC.

Все эти методы могут применяться одновременно или избирательно. И симптомы для пользователя выглядят похоже — «сайт не открывается» — а технически это очень разные ситуации, и с точки зрения исследования (или обхода) это совершенно разные задачи.

Что делает dpi-checkers и какие тесты внутри

Проект dpi-checkers — это набор инструментов для детектирования каждого из перечисленных методов на конкретном подключении. Apache-2.0 лицензия, 700+ звёзд на GitHub, активная разработка автора. В репозитории три части:

dpi-ch — основной CLI-инструмент на Go. Сборки под Windows, macOS, Linux (Android в планах). Это «большой брат» остальных проверок — не ограничен песочницей браузера, может работать на низком уровне с TCP-сокетами и формировать пакеты вручную. Самый мощный инструмент в наборе.

TCP 16-20 web-checker — браузерный тест на JS, который проверяет конкретно метод TCP 16-20. Запускается с GitHub Pages, не требует установки. Понятно, ограничен песочницей браузера (не может, например, спуфить SNI), но даёт быстрый ответ «работает или нет».

IPv4 Whitelisted Subnets web-checker — детектор CIDR-вайтлистов. Запускается также из браузера, но требует предварительной фазы кеширования (об этом ниже).

TCP 16-20 DWC (domain whitelist checker) — Python-скрипт для исследования белых списков доменов на уровне DPI. Требует curl, Python 3 и специально настроенного сервера на ограниченной сети. Это инструмент уже для исследователей, не для рядовой проверки.

Я установил dpi-ch и прогнал основные web-проверки на своих подключениях. Дальше расскажу, что вышло.

Установка dpi-ch

Это просто. На странице релизов лежат собранные бинарники для всех платформ:

# Linux x86_64
wget https://github.com/hyperion-cs/dpi-checkers/releases/download/dpich-v0.2.3/dpich_linux_amd64
chmod +x dpich_linux_amd64
mv dpich_linux_amd64 ~/bin/dpich
 
# Запуск
dpich --help

Никаких зависимостей, конфигов, прав root для базовых проверок не нужно. Утилита работает с обычного пользователя, обращается к сети через стандартные TCP-сокеты.

Конфигурация задаётся через флаги командной строки или YAML-файл. Базовая проверка домена выглядит так:

dpich \
  --target www.youtube.com \
  --mode tcp16-20 \
  --timeout 15s

На выходе — отчёт по конкретному методу: получилось ли TLS-соединение, на какой стадии разорвалось, был ли RST от клиента или сервера, сколько байт передалось до разрыва.

Как технически работает тест TCP 16-20

Это самая интересная часть, и стоит разобраться подробнее.

При установке TLS-соединения клиент посылает на сервер ClientHello. Это первый пакет, в котором передаётся, среди прочего, поле SNI — имя хоста, к которому клиент собирается обратиться. В современных TLS 1.2/1.3 без ECH это поле передаётся в открытом виде (только TLS 1.3 с Encrypted Client Hello его прячет, но ECH в продакшене ещё редкость).

DPI на стороне провайдера читает SNI, проверяет, нет ли его в чёрном списке, и при совпадении выполняет одну из двух тактик:

Тактика A: немедленный сброс — DPI шлёт RST обоим сторонам соединения, клиент сразу получает «connection reset».

Тактика B (TCP 16-20): соединение пропускается, но через 16-20 пакетов в потоке (числа условные, в реальности параметр настраиваемый и варьируется по операторам) DPI отправляет RST. Это даёт DPI возможность сначала пропустить ClientHello/ServerHello, увидеть полное содержимое TLS handshake, и уже принять решение позже.

Тактика B хитрее. Симптомы для пользователя:

• DNS-резолв проходит (подмены нет)

• TCP-handshake проходит (SYN, SYN-ACK, ACK)

• TLS handshake начинается (ClientHello уходит)

• Соединение разрывается через секунду-две (после нескольких MTU-размерных пакетов) Это создаёт впечатление, что «сервер тормозит» или «связь нестабильная», хотя на самом деле RST приходит от посредника на пути.

Web-чекер tcp-16-20 проверяет, ведёт ли себя ваше подключение именно так на типовых ресурсах. Я прогнал его на домашнем провайдере. Получил такой результат:

youtube.com         RESET after 18 packets   ← блокируется TCP 16-20
googlevideo.com     RESET after 17 packets   ← тот же метод
twitter.com         OK (response received)
discord.com         RESET after 16 packets   ← TCP 16-20
medium.com          OK (response received)

Картина классическая: блокировки направлены на YouTube-инфраструктуру (главный домен + CDN), плюс Discord. Twitter в этот вечер у меня в Москве работал, но это нестабильно — на следующий день мог не работать.

Тест на CIDR-вайтлисты

Это интереснее. CIDR-блокировка — более тяжёлая форма ограничений: целые подсети интернета становятся недоступными независимо от того, какой именно сервис на них хостится. Применяется обычно в специальных режимах — некоторые мобильные тарифы, доступ из конкретных регионов.

Web-чекер ipv4-whitelisted-subnets работает в две фазы.

Фаза 1: кеширование «эталонного списка». Чекер запускается на «нормальном» подключении (например, домашнем Wi-Fi без CIDR-блокировок) и собирает список IPv4-подсетей, которые он считает «потенциально могут быть в вайтлисте». Это делается через анализ автономных систем (AS) в BGP — выбираются AS, чьи подсети вероятнее всего будут разрешены регулятором (популярные CDN, инфраструктура крупных российских компаний, банковские IP-блоки). Список сохраняется в localStorage браузера.

Фаза 2: проверка с целевого подключения. Чекер запускается уже с подключения, которое тестируется. Для каждой подсети из эталонного списка делается выборочная проверка нескольких хостов на доступность по 443 порту. Если хосты отвечают — подсеть в вайтлисте. Если нет — заблокирована.

Параметры в URL:

Я прогнал чекер на мобильном оператора в режиме 5G+ — там у меня по тарифу есть некоторые ограничения. Из 1200 проверенных подсетей живыми оказались 380. То есть около 70% подсетей этих AS были недоступны с моего соединения на 443 порту, хотя обычно эти же подсети открыты с домашнего интернета.

Это в чистом виде CIDR-фильтрация. Никакой DPI не нужен — провайдер просто маршрутизирует трафик так, чтобы в публичный интернет уходила только часть подсетей, а остальные либо блокируются на NAT, либо не объявляются вообще.

Кстати, важный нюанс из документации чекера, который мне понравился: он явно указывает, что не работает для случаев, когда поверх CIDR ещё применяется SNI-блокировка. Браузерная песочница не позволяет подменить SNI, поэтому если соединение заворачивается на этапе TLS, чекер не может это отличить от CIDR-блокировки. Это честное ограничение, и его автор репозитория документирует.

DPI-CH: что умеет «большой брат»

Браузерные чекеры удобны, но ограничены. В частности, они не могут:

• спуфить SNI (использовать поддельное имя в TLS handshake)

• работать на низком уровне с TCP (например, отправлять кастомные TCP-флаги)

• тестировать UDP/QUIC (CORS не позволяет)

• проводить долгие тесты с массой соединений Для всего этого нужен dpi-ch — нативный CLI на Go. Я погонял его на домашнем подключении со следующими сценариями.

Сценарий 1: проверка, точно ли блокировка работает по SNI, а не по IP.

Делаем два теста: один с настоящим SNI, второй с фейковым (но к тому же IP):

# Тест 1: настоящий SNI
dpich --target www.youtube.com --mode tcp16-20
 
# Тест 2: тот же IP, но SNI заменён на нейтральный
dpich --target www.youtube.com --sni-override example.com --mode tcp16-20

В первом случае — RST через 18 пакетов. Во втором — соединение проходит до конца. Это подтверждает: блокировка идёт по SNI, IP не в чёрном списке. Это типичный паттерн TCP 16-20 в РФ-сегменте.

Сценарий 2: измерение «магического числа» N в TCP 16-20.

Утилита может отправлять данные по байту/пакету и засекать, на каком именно пакете приходит RST. Это позволяет понять параметры конкретной DPI-системы у вашего провайдера:

dpich --target www.youtube.com --mode tcp16-20-probe --packet-size 64

У меня вышло, что на домашнем провайдере N=18, на мобильном операторе N=20. Это разные DPI-системы, либо одна и та же с разной конфигурацией. По форумам подобной тематики (net4people/bbs) это коррелирует с разными вендорами оборудования у разных операторов.

Сценарий 3: проверка DNS-подмены.

dpich --target www.youtube.com --mode dns-check

Чекер делает запросы на разные DNS-серверы (8.8.8.8, 1.1.1.1, 77.88.8.8, провайдерский), сравнивает ответы и проверяет валидность через DoH (DNS-over-HTTPS, то есть запрос, который провайдер не может перехватить). У меня DNS-подмены нет ни на одном из тестируемых подключений — это подтверждает, что мой провайдер использует DPI-методы, а не древние DNS-фильтры.

Что я увидел в итоге

Сводная картина по моим трём подключениям:

Это даёт более точную картину, чем «у меня YouTube тормозит». На моём конкретном домашнем подключении применяется один основной метод (TCP 16-20 с параметром N=18), плюс частичная QUIC-фильтрация. Никаких CIDR-блокировок и DNS-подмен. То есть DPI работает на L7 по содержимому ClientHello.

На мобильном 5G+ всё гораздо тяжелее: помимо тех же DPI-методов, активна CIDR-фильтрация, и QUIC-трафик режется полностью. Это объясняет, почему многие сервисы на мобильнике вообще не работают, тогда как на проводе с теми же ограничениями работают через QUIC.

Зачем вообще это знать с инженерной точки зрения

Здесь стоит остановиться и проговорить, для кого это полезно. Я выделяю несколько групп.

Сетевые инженеры на стороне B2B-сервисов. Если ваш SaaS теряет клиентов из-за того, что какие-то из них не могут до него достучаться, понимание методов фильтрации позволяет не просто констатировать «провайдеры виноваты», а точно понять, что именно мешает соединению. Из этого следуют конкретные технические решения: переехать на свой домен, сменить хостинг-провайдера, добавить альтернативные эндпоинты в IP-диапазонах вайтлистов, перевести трафик на QUIC.

Разработчики приложений с реальной аудиторией в РФ. Если вы делаете мобильный или веб-сервис и хотите, чтобы он работал стабильно, нужно понимать ограничения сетевой среды. Полная зависимость от одного домена с уникальным SNI — рискованная архитектура; распределение трафика через CDN с пулом IP в разных AS — устойчивая.

Исследователи интернет-цензуры. Это самостоятельная академическая область — Citizen Lab, OONI, Berkman Klein Center собирают данные о применении DPI по миру. dpi-checkers — один из инструментов, который исследователь может предложить добровольцам в России для сбора полевых данных.

Просто любопытствующие, кто хочет понять, что происходит. Это нормальная позиция. Знать, как устроена технология, через которую проходит ваш трафик — базовая цифровая грамотность.

Что не является целью этой статьи — это инструкция по обходу. Там это отдельная и большая тема, со своими инструментами (Zapret, GoodbyeDPI, разные shadowsocks-форки), и она требует отдельного материала. Здесь я хочу показать только: вот методы, вот как их детектировать, вот как разобраться, что у вас на сети.

Ограничения и нюансы инструмента

Чтобы не выглядеть рекламно, отмечу слабые места dpi-checkers.

Браузерные чекеры медленные. Полная проверка CIDR-вайтлистов может идти 30-40 минут. Это не баг — это архитектура (нужно проверять много подсетей с таймаутом). Но если у вас нет терпения, лучше идти сразу в dpi-ch.

Документация на русском, частично на английском. Главный README на английском, но описания конкретных тестов — на русском. Для международных пользователей это может быть барьером.

Только IPv4. Если у вас IPv6 (а в крупных городах он часто есть), отдельных тестов на IPv6-фильтрацию нет. С другой стороны, в РФ-сегменте DPI преимущественно атакует IPv4 — это и историческая инерция, и просто более широкое распространение.

False negative возможны. Если в вашей AS подсетей мало или они нестандартные, чекер может пропустить интересные случаи. Автор открыто пишет про это в README. Для серьёзного исследования нужно дорабатывать списки AS под свой регион.

Сборка под Android в планах, но её ещё нет. Соответственно, на Android можно прогнать только web-чекеры.

Главная мысль

Современная сетевая фильтрация — это не «провайдер замедляет YouTube». Это конкретные технические методы: DNS-подмена, CIDR-вайтлисты, TCP 16-20, SNI-блокировка, QUIC-фильтрация. Каждый метод имеет свою сигнатуру, и каждый можно детектировать конкретным инструментом.

Понимание этих методов — базовая инженерная грамотность для любого, кто работает с интернет-сервисами в РФ-сегменте. Это позволяет говорить о проблемах в технических терминах, а не в эмоциональных. И это позволяет принимать осмысленные технические решения там, где раньше было «мы ничего не можем сделать, провайдеры творят дичь».

Инструменты вроде dpi-checkers закрывают пробел между «академическими работами по DPI» и «обычным пользователем» — позволяют каждому разобраться, что именно происходит с его собственным трафиком. Это нормальная open-source гражданская технология, и её существование — хороший признак того, что сообщество способно создавать инструменты исследования сложных систем без участия крупных корпораций или государства.

Полезные ссылки:

• Репозиторий: github.com/hyperion-cs/dpi-checkers

• Web-чекеры: hyperion-cs.github.io/dpi-checkers

• Обсуждение методов TCP 16-20 в исследовательском сообществе: github.com/net4people/bbs/issues/490

• OONI Probe — академический инструмент для измерения интернет-цензуры: ooni.org

• Citizen Lab Internet Censorship Reports: citizenlab.ca