DPI-фильтрация у российских провайдеров: что происходит с вашим трафиком

YouTube открывается дома, но не у бабушки в области — это не случайность и не нестабильность сети. За каждой такой деградацией стоит конкретный технический механизм. Разбираю, как именно работает DPI-фильтрация у российских провайдеров и как её можно детектировать с помощью open-source инструментов.

Когда в новостях пишут «провайдеры замедляют YouTube» — это упрощение. Технически провайдер не замедляет конкретный сервис: он применяет один из нескольких методов фильтрации трафика, и симптомы у пользователя выглядят похоже, а природа у них совершенно разная. Это важно понимать, если вы отвечаете за корпоративную сеть или просто хотите разобраться, что происходит с пакетами на уровне L4.

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

В российском сегменте сети наблюдается несколько основных методов. Они могут применяться одновременно или избирательно — в зависимости от оператора, региона и типа подключения.

• Блокировка по IP-подсетям (CIDR-вайтлисты) — если IP назначения не входит в список разрешённых подсетей, трафик не пропускается. Жёсткий метод, чаще встречается на мобильных подключениях.

• TCP 16-20, или rps-разрыв — DPI пропускает первые 16–20 пакетов установленной TLS-сессии, анализирует SNI и затем отправляет RST-пакет обеим сторонам. Клиент видит «сайт упал», хотя сервер живой. Это основной метод воздействия на YouTube в 2024–2025 годах.

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

• SNI-блокировка — в TLS handshake поле Server Name Indication передаётся в открытом виде до установки шифрованного канала. DPI читает его и сбрасывает соединение при совпадении с чёрным списком.

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

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

DPI читает SNI и выбирает одну из двух тактик. Тактика A — немедленный сброс: RST отправляется обеим сторонам, клиент сразу получает «connection reset». Тактика B (собственно TCP 16-20) — соединение пропускается, DPI наблюдает за потоком, и только через 16–20 пакетов отправляет RST. Это позволяет сначала увидеть полный TLS handshake, а решение принять позже.

Симптомы для пользователя при тактике B выглядят так: DNS-резолв проходит, TCP-handshake проходит, TLS handshake начинается — и соединение разрывается через секунду-две. Создаётся ощущение нестабильного сервера, хотя RST приходит от посредника на пути, а не от самого сервиса.

На Хабре разобран open-source проект dpi-checkers от автора hyperion-cs — набор инструментов для детектирования каждого из описанных методов на конкретном подключении. Apache-2.0, 700+ звёзд на GitHub, активная разработка.

В репозитории четыре компонента. Основной — CLI-инструмент dpi-ch на Go, собранный под Windows, macOS и Linux. Работает на уровне TCP-сокетов, формирует пакеты вручную, не ограничен браузерной песочницей. Рядом — браузерный TCP 16-20 web-checker на JS (запускается с GitHub Pages, без установки), детектор CIDR-вайтлистов и Python-скрипт для исследования белых списков доменов на уровне DPI.

Базовая проверка конкретного домена через CLI выглядит просто: указываешь цель, метод и таймаут. На выходе — отчёт: прошло ли TLS-соединение, на какой стадии разорвалось, был ли RST от клиента или сервера, сколько байт передалось до разрыва. Никаких зависимостей и прав root для базовых проверок не нужно.

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

Понимание механизма напрямую определяет решение. Проблема в DNS — решается через DoH/DoT. Проблема в SNI — нужен ECH или другой подход. Проблема в CIDR-вайтлисте — это уже разговор с оператором или смена провайдера для критичного трафика. Без диагностики на уровне L4 компания будет бесконечно «перезагружать роутер».

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

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

—

[ВКонтакте](https://vk.com/ciologia)

[Одноклассники](https://ok.ru/group/70000049644223)

[Дзен](https://dzen.ru/ciologia)

[Сетка](https://setka.ru/users/4e7ada8b-279e-41e9-846d-291aa630d204)

[Telegram](https://t.me/CIOlogia)

[Habr](https://habr.com/ru/users/CIOlogia/posts/)

[TenChat](https://tenchat.ru/ciologia)

[LinkedIn](https://www.linkedin.com/in/vladislav-prokopovich-bb808376/)