Что такое DPI и как операторы фильтруют трафик
DPI (Deep Packet Inspection, глубокая инспекция пакетов) — это анализ трафика не только по адресу и порту, но и по содержимому на уровне приложения. Оператор смотрит внутрь TLS-рукопожатия, считает размеры и тайминги пакетов, оценивает энтропию потока и репутацию подсети назначения. На этом строятся и точечные блокировки, и троттлинг (замедление) «похожего на VPN» трафика.
Практически фильтрация складывается из нескольких уровней, которые работают одновременно:
| Уровень | Что анализируется | Как проявляется |
|---|---|---|
| IP / подсеть (L3) | адрес назначения, репутация /24 | блок или троттлинг по диапазонам |
| Транспорт (L4) | порт, размеры пакетов, тайминги | ограничение нестандартных портов, UDP |
| SNI / ClientHello (L7) | домен в TLS-handshake, fingerprint | сброс или замедление по домену |
| Сигнатуры протокола | отпечаток рукопожатия, энтропия потока | детект VPN-протоколов и их обрыв |
| Поведение | равномерный поток, длинные соединения | троттлинг долгих «туннельных» сессий |
Ключевой вывод для оператора: DPI различает не «что вы передаёте», а «на что это похоже». Трафик, который для оборудования выглядит как обычное обращение к легитимному веб-ресурсу (например, к CDN), проходит там, где голый VPN-протокол уже отсекается.
Важно не путать DPI с режимом «белого списка». DPI анализирует содержимое и применяется в штатном режиме. Режим белого списка — это отдельный, гораздо более грубый механизм при шатдаунах, где фильтрация идёт уже не по содержимому пакета, а по подсети назначения. О нём — в следующем разделе.
Режим белого списка при шатдаунах: почему VPN напрямую отваливается
Обычная блокировка работает по принципу default-allow: закрыто то, что попало в чёрные списки, остальное открыто. Шатдаун — это противоположный режим, default-deny. При масштабных ограничениях российские мобильные операторы переводят мобильный интернет в режим «белого списка»: достижимы только whitelisted-ресурсы — часть CDN и госсайты, а всё остальное просто недоступно.
В этом режиме VPN, который идёт напрямую к своей ноде на датацентр-IP, отваливается целиком: адрес ноды не в белом списке, и неважно, какой протокол и порт вы используете. Проблема здесь не в детекте конкретного протокола, а в том, что точка входа физически недостижима.
Отсюда инфраструктурная логика: если оператор пропускает обращения к «белому» CDN, то вход VPN нужно поставить за таким CDN-edge. Для оператора связи трафик выглядит как запрос к whitelisted-домену CDN (например, поддомену Yandex CDN), а edge уже проксирует данные на вашу ноду. Так решается не «обход» как услуга, а устойчивость сервиса под ограничениями оператора.
Побочный, но важный эффект того же приёма: даже вне шатдауна, под обычным DPI-троттлингом, обращение к whitelisted-домену CDN выглядит легитимно. Один и тот же вход закрывает сразу две задачи — «нода недостижима в белом списке» и «трафик похож на VPN».
Whitelist привязан к подсетям /24 — как это проверять
Важный нюанс: whitelist привязан не к доменам, а к IP-подсетям, чаще всего на уровне /24. У одного хостера подсети могут быть в белых списках, у соседнего — нет, и статус со временем меняется. Поэтому единственный корректный подход — проверять каждую /24 отдельно и актуально, без опоры на «репутацию бренда» хостера в целом.
| Хостер | Частый статус /24 | Комментарий |
|---|---|---|
| Selectel | часто whitelisted | но проверять конкретную подсеть |
| cloud.ru / SberCloud | часто НЕ whitelisted | вход за таким IP рискован |
| Прочие ДЦ | по-разному | статус меняется, гарантий нет |
Цифры в таблице — это наблюдаемая частая картина, а не гарантия: «навсегда белых» диапазонов не существует, любую /24 нужно перепроверять при изменении картины блокировок.
Практический принцип: за whitelisted-диапазоном должен стоять именно вход (CDN-edge / gateway), а не сама нода. Ноду можно держать на любом удобном хостинге — её IP оператор напрямую не видит, поэтому whitelist-статус подсети ноды значения не имеет. Проверять на белый список нужно диапазон точки входа.
Транспорт под троттлингом: XHTTP через CDN против Reality и Hysteria2
Не каждый протокол переживает прохождение через CDN-edge. Edge терминирует TLS и работает как HTTP-прокси: до origin доходит только то, что укладывается в модель обычных HTTP-запросов. Поэтому под троттлингом и в связке с CDN протоколы ведут себя по-разному.
| Транспорт | Напрямую под троттлингом | Через whitelisted CDN |
|---|---|---|
| XHTTP (mode packet-up) | зависит от диапазона | рабочий подход |
| Reality | часто НЕ проходит | edge обычно не пропускает |
| Hysteria2 (QUIC/UDP) | часто НЕ проходит | edge обычно не пропускает |
Reality опирается на имитацию TLS к чужому сайту, а Hysteria2 — на UDP/QUIC; ни то, ни другое не переживает терминацию и HTTP-семантику edge. XHTTP в режиме packet-up, наоборот, изначально выглядит как поток HTTP-запросов и потому нормально ходит через CDN. Для сценария «вход за whitelisted-CDN» это фактически основной рабочий транспорт — при условии, что uplink размещён правильно (см. следующий раздел).
Критичный нюанс XHTTP через CDN: uplink в теле запроса
Самая неочевидная ошибка при заводе XHTTP за CDN — размещение uplink-данных не там, где надо. Uplink (данные от клиента к серверу) ДОЛЖЕН идти в теле запроса: uplinkDataPlacement: "body". Если положить его в кастомный заголовок (например, X-Payload), туннель порвётся: CDN-edge кастомные заголовки до origin не доносит, и соединение падает с характерной ошибкой unexpected EOF.
Остальные служебные поля распределяются так, чтобы не зависеть от кастомных заголовков:
- session / seq — в cookie (edge их пробрасывает корректно);
- padding — в query-строке;
- полезная нагрузка uplink — только в body.
Отдельно: path и extra должны совпадать точь-в-точь на ноде и в клиентском конфиге. Любое расхождение в пути или дополнительных параметрах — и туннель просто не поднимется, даже если сам edge и файрвол настроены верно. Это тот случай, когда «почти одинаково» не работает вообще.
Нода за CDN: настройка, безопасность origin и учёт трафика
Схема «нода за whitelisted-CDN» одинаково ложится на популярные панели — Remnawave, 3x-ui, Marzban, Hiddify. Нода держит XHTTP-инбаунд (например, на порту 25454), а клиентский конфиг указывает CDN-поддомен как Address / SNI / Host. Данные идут через edge, origin остаётся невидимым для оператора.
Безопасность origin. Origin нужно закрыть файрволом на вход: принимать соединения только с IP gateway (CDN). Дополнительно секрет-заголовок X-Cdn-Auth защищает origin от прямых обращений мимо CDN — если запрос пришёл без валидного секрета, он отклоняется. Так исключается и утечка реального IP, и паразитные прямые подключения.
Номинальная цена за гигабайт мало что говорит: у провайдеров с тарификацией запросов XHTTP-профиль добавляет к счёту отдельную статью, и реальная ставка получается заметно выше прайсовой. Единственный управляемый рычаг здесь — укрупнение POST-ов: чем больше данных уходит одним запросом в body, тем меньше число запросов и ниже итоговый кост. Точные ставки зависят от провайдера и профиля трафика — считайте по своему объёму.
Учёт трафика. Множитель потребления ноды и per-user лимиты — это механизмы панели (например, Remnawave). Множитель 0 на ноде означает, что её трафик не засчитывается против лимита пользователя, при этом нода продолжает работать — удобно для служебных или «белых» маршрутов.
Чего whitelist-CDN НЕ решает: стриминг и резидентные IP
Важно не смешивать две разные задачи. «Пробить троттлинг / шатдаун» и «разблокировать российский стриминг» — это не одно и то же. Whitelist-CDN закрывает первую задачу и никак не помогает со второй.
Сервисы вроде Кинопоиска банят датацентр-IP по репутации: им неважно, через какой CDN пришёл запрос, важно, что финальный выход — это IP дата-центра. Для доступа к такому контенту нужен резидентный IP, и это отдельная инженерная задача, которую whitelist-вход не решает. Если оператор обещает клиентам и то и другое одним механизмом — это ошибка проектирования.
Именно устойчивый whitelisted-вход как инфраструктурный слой и предоставляет Clearway (clear-way.pro): сервис для VPN-операторов даёт «белый» вход перед вашими нодами на CDN-edge (*.whitechannel-x1-cdn.ru), без продажи серверов. Оператор оставляет за собой панель, ноды и учёт, а задачу «оператор должен видеть whitelisted-трафик» закрывает готовым edge-слоем — вопрос резидентных IP при этом решается отдельно.