В конце 2017-начале 2018 года Роскомнадзор провёл тестирование 12 комплексов DPI для провайдеров, с целью проверки эффективности блокировок, правильной работы комплексов с реестром, выявления и документирования пропусков заблокированных сайтов.
В документах содержатся типовые схемы подключения DPI в сеть, информация о разных моделях, режимах работы и пропускной способности.
Кое-где можно встретить более глубокие технические подробности.
На всякий случай, прикладываю результаты тестирования всех DPI, если их вдруг удалят с сайта. Перегнал все TIFF’ы в PDF.
Поставляется в виде программно-аппаратного комплекса
До 80 Gbit/s (на сайте написано про 80, в документе — до 160).
Поддерживает режимы подключения: in-path, двусторонний on-path («пассивный» DPI, в который зеркалируется и входящий, и исходящий трафик оптическим сплиттером или программно), односторонний on-path (зеркалируется только исходящий клиентский трафик)
Помимо блокировок может осуществлять QoS, кеширование, родительский контроль и внедрение рекламы
Поставляется в виде ISO-образа для установки на обычные серверы
Перенаправляет трафик на себя через BGP или DNS RPZ
3 разных варианта подключения: облачный, прокси у провайдера, программно-аппаратный комплекс
25+ Gbit/s (в случае программно-аппаратного комплекса. Видимо, имеется в виду общая пропускная способность провайдера, а не возможности обработки ПАК.)
Запросы пользователя перенаправляются на фильтрующий сервер. Перенаправление может осуществляться через маршрутизацию (основной способ) или через DNS RPZ (дополнительный способ).
Фильтрующий сервер проверяет наличие запрашиваемого ресурса в реестрах запрещенных сайтов и либо пропускает запрос, либо выводит сообщение, что ресурс заблокирован.
Как обрабатываются протоколы отличные от HTTP/HTTPS ?
если перенаправление произошло через маршрутизацию и ресурс НЕ блокируется по IP, то запрос пропускается (с использованием NAT)
если перенаправление произошло через DNS RPZ, то запрос блокируется
Как обрабатывается HTTPS ?
запросы к сайтам, которые размещены на тех же IP, что и ресурсы из реестра - пропускаются
запросы к сайтам из реестра блокируются без вывода сообщения (вывод сообщения может быть настроен дополнительно, но браузер пользователя будет «ругаться» на сертификат)
Поставляется в виде программно-аппаратного комплекса
До 80 ГБит/с
Устанавливается только in-path
Также реализует родительский контроль и QoS
Поддержка HTTP/2 и QUIC
Фильтрация WEB-ресурсов выполняется путем поиска соответствия в списке Роскомнадзора по IP-адресу, доменному имени и полному указателю страницы.
Список Роскомнадзора выгружается раз в час через XML-интерфейс.
Блокировка по доменному имени выполняется в случае, если в XML-списке отсутствует полный указатель страницы. Блокировка по IP-адресу выполняется, если в XML-списке отсутствует и полный указатель страницы, и доменное имя ресурса.
Проверка выполняется для фрагментированных IP-пакетов и сегментированных блоков данных на уровне TCP.
ZapretService
«Игрушечный» комплекс от компании ZapretService. Доступна пробная версия, ISO-файл свободно скачивается с веб-сайта производителя! zapretservice_readme.pdf (969.0 KB)
Поставляется в виде ISO-образа для установки на обычные серверы
Поставляется в виде ISO-образа для установки на обычные серверы
Предназначен для обработки ~10 Гбит/с
Устанавливается только on-path
Осуществляет блокировку записей, заблокированных по IP-адресам и диапазонам, через BGP/OSPF, blackhole.
Блокирует доменную зону целиком (если в реестр внесён домен второго уровня, то любой поддомен этого домена будет блокироваться)
Имеет интересный модуль «Избежание частичных блокировок популярных ресурсов», исключающий из DNS-ответов заблокированные IP-адреса, если ответ содержит несколько адресов (заблокированных и незаблокированных в одном ответе).
Assuming this software runs on a standard PC or server, it could make a good subject for study. Perhaps you could install it (on an isolated network) and test how it handles various types of traffic. I would be interested in testing ValdikSS’s final bullet point:
Actually I tested it several (2-3?) years ago a bit, in a VM. I remember running blockcheck on it, maybe goodbyedpi too.
The software didn’t have functionality to detect unknown traffic at that time.
I believe they’ve added it when Telegram started to use MTProto proxies, because the wiki says:
"Euristic DPI" option
With this option you can improve filtering quality of complex protocols, like the encrypted messengers’ traffic.
With the aid of proactive analysis, Carbon Reductor DPI X is able to block only what’s needed, which would improve your customers’ Internet quality, decreasing the number of blocks due to indecent resources. We’re discussing the details of this option with Roscomnadzor right now.
Roscomnadzor was blocking my unencrypted HTTP proxy servers since November to the end of July, once in every 4-14 days. They’ve silently added IP addresses of the proxy servers to the registry, insisted that my IP addresses are used in Telegram infrastructure and refused to provide any details or proofs. I was running an experiment to understand what’s going on, how do they detect proxy servers and what triggers the detection.
At that time, I had two hypotheses: either they get dump of all IP addresses and ports the customers visit (netflow), and then recheck every IP-port combination as HTTP proxy without authentication, or they get some kind of exported data from DPI manufacturer or from DPI itself (Telegram, if used with HTTP proxy, has a very distinct fingerprint: it just uses HTTP Post request with the pattern of POST http://1.2.3.4:80/api, at least the desktop version at that time).
I tend to believe the latter during my experiment, and now I’m sure it was either Carbon Reductor or EcoDPI (Roscomnadzor’s “recommended DPI system”) data.