todo/DPI/vpn-blocking-wave-forecast-summer-2026.md

---
date: 2026-07-20
fact_checked: 2026-07-20
tags:
  - vpn
  - dpi
  - tspu
  - rkn
  - traffic-analysis
  - fingerprinting
  - throttling
  - censorship
  - forecast
aliases:
  - Стабилизация VPN временная
  - Новая волна блокировок VPN 2026
  - Прогноз Щербакова о VPN
  - Удушение качества VPN
  - Блокировка VPN по таймингам
link: https://www.gazeta.ru/social/news/2026/07/19/28927375.shtml
---

# «Стабилизация временная»: насколько реален прогноз новой волны блокировок VPN

> [!info] О чём статья
> 19 июля 2026 года технический директор «Стахановца» Сергей Щербаков предположил, что относительная стабильность VPN (Virtual Private Network, «виртуальная частная сеть») закончится новой волной ограничений в конце лета или начале осени. Ниже этот прогноз разобран по слоям: что подтверждают спецификации и исследования, что наблюдали в российских сетях, а что пока остается экспертной гипотезой без опубликованного календаря Роскомнадзора.

## TL;DR

- **Техническая часть прогноза реалистична:** WireGuard и OpenVPN оставляют сигнатуры, а вложенные туннели TLS (Transport Layer Security) можно классифицировать по размерам, направлениям и таймингам пакетов без расшифровки содержимого.
- **Селективное ухудшение уже наблюдалось:** полевые тесты 2025–2026 годов описывали заморозку после порога пакетов и временные ограничения после серии параллельных TLS-соединений. Это наблюдения исследователей, а не опубликованные правила технических средств противодействия угрозам (ТСПУ).
- **Инфраструктура для усложнения анализа расширяется:** закон требует от операторов пропускать трафик через ТСПУ, а опубликованные в 2026 году планы связывают автоматизированную систему обеспечения безопасности российского сегмента интернета (АСБИ) с обработкой всего трафика Рунета и ростом мощности до 2030 года.
- **Срок не подтвержден:** версия о сборе статистики в июле и новой волне в августе–октябре 2026 года принадлежит Щербакову. Публичного графика РКН нет.
- **Наблюдения первой половины 2026 года указывают на неодновременный сценарий:** с мая по июль зафиксирована серия непохожих друг на друга эпизодов — от прицельной фильтрации протоколов до сбоев «белых списков» и блокировки публичного DNS. Новые правила появляются по операторам, регионам и группам адресов, затем ослабляются после сопутствующего ущерба. Один общероссийский «рубильник» для всех VPN менее вероятен, чем серия неравномерных волн.

Индикатор VPN-клиента показывает успешное подключение, переключатель загорается зеленым, но страницы в браузере зависают, изображения не отображаются, а передача файлов останавливается. Пользователь списывает это на сбой провайдера, слабый сигнал или перегруженный сервер. Между тем фильтрация может выглядеть именно так: оборудование ТСПУ (технические средства противодействия угрозам), использующее глубокий анализ трафика (DPI, Deep Packet Inspection), пропускает первоначальное рукопожатие, позволяет приложению установить связь, а затем начинает отбрасывать пакеты. Сценарий ухудшения качества вместо полного разрыва описал технический директор компании «Стахановец» Сергей Щербаков в беседе с [«Газетой.Ru»](https://www.gazeta.ru/social/news/2026/07/19/28927375.shtml) 19 июля 2026 года. По его оценке, период относительной стабильности может смениться новой волной ограничений в конце лета или начале осени 2026 года. Исследования и код открытых анализаторов подтверждают техническую возможность распознавать зашифрованные туннели, а полевые измерения документируют отдельные способы их заморозки и замедления. Версия о том, что регулятор уже собирает статистику для осенних блокировок, остается предположением эксперта.

> [!warning] Ограничения фактчека
> РКН и операторы связи не публиковали графиков обновления ТСПУ на конец лета или осень 2026 года. Приведенные ниже пороговые значения фильтрации получены в полевых тестах, поэтому они могут различаться в зависимости от оператора, региона и даты наблюдения.

## Четыре уровня уверенности

| Утверждение | Статус на 20 июля 2026 года | На чём основано |
|---|---|---|
| WireGuard и OpenVPN можно распознавать без расшифровки трафика | Хорошо подтверждено | Спецификации протоколов, исходный код nDPI, исследование OpenVPN на сети провайдера |
| Зашифрованные туннели можно искать по таймингам и направлениям пакетов | Подтверждена техническая осуществимость | USENIX Security 2024: пассивный классификатор на 110 млн потоков в сети американского провайдера |
| В российских сетях применялись пороги по числу пакетов и частоте TLS-соединений | Подтверждено полевыми наблюдениями, но не официальной документацией | net4people, июнь 2025; воспроизводимый тест Петра Осетрова, июнь 2026 |
| Июльское затишье нужно для сбора статистики, а новая волна начнется в конце лета или начале осени | Прогноз одного эксперта | Публикация «Газеты.Ru» от 19 июля 2026 года; независимых подтверждений календаря нет |

Открытый классификатор nDPI доказывает, что сигнатурный детект можно реализовать в программном коде, но не подтверждает использование именно этого кода в ТСПУ. По той же причине академическая точность детектора не равна точности национальной системы фильтрации: отличаются оборудование, набор трафика, бюджет вычислений и допустимый уровень сопутствующего ущерба.

## За ширмой шифрования

Даже стойкое шифрование защищает только полезную нагрузку пакетов, оставляя видимой саму форму сетевого потока. Сетевой анализатор фиксирует IP-адрес сервера, тип транспорта, направление движения пакетов, их точный размер и время прохождения. Для идентификации туннеля фильтрам не нужно дешифровать данные, им достаточно сопоставить внешние метрики сессии с известными признаками протоколов. Например, WireGuard обнаруживает себя из-за фиксированной структуры служебных сообщений. Этот протокол создавали для производительности и безопасности, а не для маскировки под обычный веб-трафик, поэтому первые UDP-пакеты сессии имеют строго определенный формат, задокументированный в [официальной спецификации](https://www.wireguard.com/protocol/) и [исходном коде ядра Linux](https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireguard/messages.h).

| Сообщение WireGuard | Направление | Первые четыре байта | Размер UDP-payload |
|---|---|---:|---:|
| Handshake Initiation | клиент → сервер | `01 00 00 00` | 148 байт |
| Handshake Response | сервер → клиент | `02 00 00 00` | 92 байта |
| Cookie Reply | сервер → клиент | `03 00 00 00` | 64 байта |
| Transport Data | в обе стороны | `04 00 00 00` | от 32 байт |

Каждое сообщение начинается с типа пакета и трех резервных нулевых байтов. Запрос на установку связи содержит `sender_index`, а ответ возвращает сопоставленный с ним `receiver_index`. Сетевой фильтр может сверить эту последовательность: если за пакетом типа 01 размером 148 байт возвращается пакет типа 02 размером 92 байта с согласованными индексами, поток приобретает характерный профиль WireGuard. Случайные UDP-пакеты могут совпасть по размеру, но они не воспроизводят логику взаимного обмена. Этот принцип использует классификатор открытой библиотеки [nDPI](https://github.com/ntop/nDPI/blob/dev/src/lib/protocols/wireguard.c), проверяя заголовки, фиксированные длины сообщений и соответствие индексов. Смена стандартного порта 51820 на UDP-порты 80 или 443 помогает лишь против простейшей блокировки по номеру порта: структура WireGuard не меняется. При этом сам порт ничего не доказывает, поскольку легитимный QUIC тоже работает поверх UDP/443; DPI приходится сопоставлять весь профиль потока с ожидаемым протоколом.

Для изменения формы потока разработчики используют обфускацию трафика. В версии 2.0 протокола [AmneziaWG](https://docs.amnezia.org/ru/documentation/amnezia-wg/) применяются настраиваемые значения заголовков, мусорные префиксы к пакетам и отправка маскировочных пакетов перед установкой связи. Это нарушает поиск по жестким сигнатурам длин 148 и 92 байта. Тем не менее у туннеля остаются поведенческие маркеры, включая длительные UDP-сессии, регулярные пакеты поддержания соединения и распределение размеров данных. Поэтому обфускация переводит задачу распознавания с сигнатурного анализа на статистический.

Смена порта работает только против правила, которое учитывает сам номер порта или ограничивает анализ выбранным диапазоном. Если классификатор уже проверяет структуру рукопожатия WireGuard, перенос с UDP/51820 на UDP/443 или UDP/80 не меняет первые байты и длины сообщений. Совет «поменять 443 на 80» из исходной публикации может помочь в отдельной сети и в конкретный день, но не является универсальной контрмерой.

## Структурные маркеры OpenVPN

Протокол OpenVPN имеет собственный узнаваемый профиль. В режиме TLS первый байт пакета делится на два поля: пять старших бит кодируют операцию (`opcode`), три младших — идентификатор ключа (`key_id`). Первое клиентское сообщение V2 с `opcode 7` и `key_id 0` начинается с `0x38`, а серверный сброс с `opcode 8` — с `0x40`. Управляющие пакеты содержат видимый 64-битный `session_id`, а при работе поверх TCP перед каждым пакетом добавляется двухбайтовое поле длины. Эти особенности зафиксированы в [сетевой спецификации OpenVPN](https://build.openvpn.net/doxygen/network_protocol.html). Детектор nDPI собирает цепочку параметров, отслеживая чередование кодов операций, постоянный идентификатор сессии и длину ответов; этот алгоритм реализован в [диссекторе OpenVPN библиотеки nDPI](https://github.com/ntop/nDPI/blob/dev/src/lib/protocols/openvpn.c). Опции `tls-auth` и `tls-crypt` усложняют сигнатурный анализ управляющего канала, однако комбинированные детекторы учитывают также распределение длин и реакцию сервера на проверочные запросы (active probing).

В 2022 году авторы исследования [OpenVPN is Open to VPN Fingerprinting](https://www.usenix.org/conference/usenixsecurity22/presentation/xue-diwen) на конференции USENIX Security проверили эффективность комбинированного анализа. Экспериментальный детектор в сети крупного провайдера распознал 85,9% тестовых сессий классического OpenVPN, определив 1718 из 2000 потоков в 39 из 40 различных конфигураций. Обфусцированные варианты определились в 34 из 41 конфигурации при минимальном количестве ложных срабатываний. Эти результаты зависят от структуры сети, но они показывают, что шифрование полезной нагрузки не скрывает сам факт работы протокола OpenVPN.

## Распознавание еще не означает блокировку

Путь от подозрительного пакета до неработающего VPN в [[DPI/dpi-analysis-pipeline|конвейере DPI]] состоит как минимум из трёх стадий. Сначала классификатор присваивает потоку метку и степень уверенности: например, «похож на WireGuard». Затем политика решает, достаточно ли этой уверенности для действия и нужны ли дополнительные признаки, такие как подсеть дата-центра, частота соединений или результат активного зондирования. Только после этого модуль воздействия выбирает реакцию: пропуск, замедление, отбрасывание пакетов, временную заморозку или блокировку адреса.

Такое разделение объясняет, почему один и тот же протокол работает у одного оператора и перестает работать у другого. Операторы могут использовать разные версии оборудования и топологию включения ТСПУ, а централизованное правило можно раскатывать постепенно. Даже внутри одной сети политика способна затрагивать только часть адресов, протоколов или периодов пиковой нагрузки.

Проще говоря: наличие сигнатуры отвечает на вопрос «можно ли узнать протокол», но не на вопросы «применяет ли ТСПУ этот детектор» и «какое действие последует после совпадения». Прогноз Щербакова относится прежде всего к третьей стадии: вместо явного разрыва выбранный поток можно сделать медленным и нестабильным.

## Запоминание сессий

Быстрый поиск сигнатур в рамках одного пакета не требует много ресурсов от сетевого оборудования. Сложнее устроен поведенческий анализ, отслеживающий историю сессий абонента, интервалы времени и частоту новых подключений. Полевые тесты показывают поведение систем фильтрации, совместимое с хранением состояния соединений. В июне 2026 года Пётр Осетров опубликовал на [Хабре](https://habr.com/ru/articles/1044396/) разбор блокировок, использующих поведенческие критерии; тот же июньский эпизод со стороны обходных средств подробно разобран в заметке [[VLESS/dpi-tls-june-2026|о «заморозке» VLESS+REALITY]]. Фильтр активировался при совпадении целевой подсети, отпечатка TLS ClientHello, поля SNI (Server Name Indication, имя запрашиваемого сайта в TLS) и высокой частоты запросов. Во время тестов три профиля браузера Chrome, одновременно открывавшие TLS-соединения к серверу FirstVDS, успешно получали ответ ServerHello, но при добавлении четвертого профиля соединения уходили в тайм-аут. По модели автора, триггером служили более трёх параллельных попыток установить TLS-соединение к одному SNI с интервалами менее примерно 350–400 миллисекунд; счетчик учитывал события в окне последних 60 секунд. После срабатывания новые попытки подключения замораживались примерно на две минуты.

Для восстановления доступа автору приходилось менять имя хоста в поле SNI или ждать окончания двухминутного окна. Первоначально он также наблюдал дополнительную заморозку на 600 секунд при смене TLS-отпечатка после срабатывания, но в обновлении от 16 июня 2026 года отметил, что этот длинный штраф, вероятно, убрали. Изменение параметров за несколько дней показывает, почему полевой тест нельзя превращать в постоянную спецификацию ТСПУ. Простые программы обхода без мультиплексирования при открытии страницы создают десятки новых TCP- и TLS-рукопожатий, тогда как HTTP/2 и HTTP/3 позволяют передавать множество запросов внутри одной долгой сессии. Шквал коротких хэндшейков еще не доказывает использование VPN, однако в сочетании с подсетью, SNI и отпечатком ClientHello становится дополнительным признаком.

## Негласный лимит на объем данных

Технические средства могут воздействовать на сетевые сессии незаметно, избегая явного обрыва связи. При таком подходе рукопожатие завершается, клиент сообщает об успешном подключении, но последующая передача данных останавливается. Устройство пользователя многократно пытается отправить пакеты повторно (TCP retransmissions), превышает время ожидания и закрывает соединение. В обсуждениях сообщества net4people зафиксировано подобное поведение под индексами [tcp 16-20 и l4-25](https://github.com/net4people/bbs/issues/490). Исследователи отметили остановку TCP-потоков после передачи первых 15–20 килобайт данных. Фильтр пропускал первые 25 пакетов (около 16 КБ полезной нагрузки) в любую сторону, после чего полностью блокировал трафик в рамках этого соединения.

Короткие текстовые запросы успешно укладываются в этот лимит, но загрузка крупных файлов прекращается. Попытка делить файлы на фрагменты менее 16 КБ требует создания тысяч новых соединений, что приводит к блокировке из-за превышения частоты хэндшейков. Ограничения такого типа бьют по передаче больших объемов информации. Метод управляемого замедления трафика по SNI и отбрасыванию пакетов применялся в России в 2021 году для ограничения доступа к Twitter до 130–150 Кбит/с, что подтвердило исследование проекта [Censored Planet](https://censoredplanet.org/throttling). На такой скорости скачивание файла размером 100 МБ занимает около полутора часов или дольше, поэтому видео, видеозвонки и обновления становятся практически недоступны. Синхронное поведение фильтров на сетях разных операторов согласовывалось с централизованным управлением. Не получая подтверждений приема (ACK), стек TCP снижает размер окна отправки и повторяет передачу сегментов, из-за чего VPN-клиент продолжает показывать статус подключения, хотя передача данных остановилась.

## Уязвимость вложенных соединений

Даже после обфускации заголовков сетевой поток выдает себя характерным распределением пакетов: их длиной, направлением и временными интервалами. Классификатор DPI собирает эти параметры в вектор признаков, куда входят объем первого пакета клиента, время полного обмена туда и обратно (RTT, round-trip time) и количество раундов рукопожатия перед началом передачи полезной нагрузки. По отдельности эти маркеры не дают высокой точности, но их комбинация позволяет распознать туннель. Эта уязвимость характерна для систем с вложенным шифрованием, таких как протокол VLESS внутри TLS-туннеля. Внутреннее сообщение ClientHello скрыто внешним шифрованием, однако его отправка создает характерный всплеск трафика от клиента, за которым следует пауза на время прохождения сигнала, встречный всплеск ответов от сервера и последующие раунды согласования. Шифрование меняет байты в пакетах, но оставляет неизменными тайминги и общую форму рукопожатия. На основе анализа этих временных характеристик классификаторы DPI способны идентифицировать замаскированные соединения.

В исследовании [Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes](https://www.usenix.org/conference/usenixsecurity24/presentation/xue-fingerprinting) на конференции USENIX Security 2024 описан метод обнаружения вложенных TLS-соединений. Разработанный авторами детектор протестировали в реальной сети на 110 миллионах потоков. В стандартных конфигурациях он распознавал более 70 % потоков четырёх самых распространённых обфусцированных протоколов — vmess, shadowsocks, vless и trojan, — а верхняя оценка доли ложных срабатываний составила 0,0544 %. Случайное заполнение пакетов (padding) в условиях эксперимента снижало распознавание, но не спасало от него: для vmess поверх WebSocket и TLS полнота падала с 0,859 до 0,687 — авторы связывают это с тем, что у vmess набивка берётся из узкого диапазона 0–63 байта. Общая же причина слабости приёма в другом: набивка меняет размеры, но не порядок и направление пакетов, а «дописать» она умеет только в большую сторону. Из проверенных контрмер лучше всего сработало встроенное в клиент мультиплексирование, меняющее форму потока: у голого vmess объединение двух прикладных потоков снижало полноту распознавания с 0,771 до 0,225 — более чем на 70 %, — а vmess поверх WebSocket и TLS при восьми параллельных потоках опускался до 0,125. Существенная оговорка авторов: когда активен один-единственный прикладной поток, перемешивать нечего и защита мультиплексирования сходит на нет.

Эксперимент проходил на зеркальной копии трафика американского провайдера: исследователи извлекали признаки, но не вмешивались в маршрутизацию и не блокировали соединения. Работа доказывает осуществимость пассивной классификации в масштабе сети с более чем миллионом пользователей. Она не доказывает, что такой алгоритм уже работает в российских ТСПУ, и не измеряет его точность на распределении трафика российских операторов.

## Цена ложного срабатывания

Внедрение глубокого поведенческого анализа на общенациональном уровне сдерживается риском сопутствующего ущерба. Легитимное корпоративное программное обеспечение, игровые клиенты и веб-браузеры тоже создают параллельные соединения и передают зашифрованные пакеты. Слишком жесткие правила блокируют обычные сайты, а мягкие пропускают инструменты обхода. В сетевой статистике эта проблема известна как ошибка базовой частоты (base rate fallacy): редкое событие на фоне гигантского объема данных порождает лавину ложных блокировок. Если из 10 миллионов TLS-потоков только 0,5% (50 тысяч) приходятся на VPN, то детектор, выявляющий 95% таких туннелей, найдет 47 500. Однако при уровне ложных срабатываний всего в 1% система ошибочно заблокирует 99 500 легитимных сессий — вдвое больше, чем обнаруженных VPN. Для промышленного применения требуются алгоритмы, сводящие ложные детекты к минимуму.

С технической точки зрения период затишья можно использовать для перенастройки правил: сузить целевые подсети, обновить сигнатуры и измерить сопутствующий ущерб. Публичных данных о том, что инженеры ТСПУ именно этим занимаются в июле 2026 года, нет. Промышленные системы фильтрации часто строят каскадом: дешевый первичный фильтр отбирает подозрительный трафик, сигнатурный модуль проверяет структуру рукопожатий, а ресурсоемкий stateful-анализатор изучает тайминги и частоту подключений только у выбранной группы сессий. Поэтому фраза Щербакова о том, что оборудование «захлебывалось от ложных срабатываний», требует уточнения. Ложные блокировки вызывают жалобы и нарушают доступность сайтов, а нагрузку на оборудование создает необходимость хранить состояние миллионов сессий и выполнять глубокий разбор пакетов.

Часть июльского затишья может объясняться адаптацией пользователей. Современные приложения обхода нередко поддерживают несколько протоколов и автоматическое переключение между ними. Если один транспорт перестает отвечать, клиент переходит на другой, и пользователь замечает лишь короткую паузу. Сбоев от этого не становится меньше, но они реже выглядят как окончательная поломка VPN; базовые протоколы без маскировки по-прежнему уязвимы для обнаружения.

## Инфраструктура позволяет менять правила централизованно

[Федеральный закон № 90-ФЗ](https://publication.pravo.gov.ru/document/view/0001201905010025) от 1 мая 2019 года создал правовую основу централизованного управления сетью связи. Пункт 5.2 [статьи 46 закона «О связи»](https://www.consultant.ru/document/cons_doc_LAW_43224/16bb16c212b64fca3cd16dac9f4f1f2c2fd34083/) обязывает интернет-операторов пропускать трафик через технические средства противодействия угрозам. Поэтому синхронное появление похожего правила у нескольких операторов технически и организационно возможно. Закон, однако, не раскрывает конкретные сигнатуры, пороги и даты их включения.

Долгосрочный вектор виден в документах и планах, о которых СМИ сообщили весной 2026 года. По данным [The Bell](https://thebell.io/roskomnadzor-udalil-dokumenty-o-planakh-blokirovki-vpn-v-rossii-na-92), удаленные позднее с сайта РКН документы о субсидиях Главному радиочастотному центру (ГРЧЦ) содержали целевой показатель: 92% среднего уровня эффективности ограничения VPN за счет сигнатур к концу 2030 года. Методика этого процента не опубликована. [«Коммерсантъ»](https://www.kommersant.ru/doc/8533998) со ссылкой на план Минцифры писал, что в 2026 году АСБИ должна обрабатывать 100% трафика Рунета, а ее пропускную способность планируют увеличить до 954 Тбит/с к 2030 году. Подробно расхождения между показателями и статус документов разобраны в [[DPI/rkn-vpn-2030-roadmap|заметке о планах РКН и Минцифры до 2030 года]].

Эти планы повышают правдоподобие общего курса на более глубокую фильтрацию, но не подтверждают прогноз на август–октябрь 2026 года. Рост мощности может обслуживать фильтрацию, отражение распределённых атак отказа в обслуживании (DDoS) и естественный рост трафика одновременно. Из долгосрочного бюджета нельзя вывести дату запуска конкретного правила.

## Волна не первая: ритм ограничений в 2026 году

Прогноз о «новой волне» звучит правдоподобнее на фоне уже прошедших. За первую половину 2026 года российские сети пережили несколько отдельных эпизодов ограничений, и они заметно различались по механизму — от прицельного удара по конкретным протоколам до сопутствующего ущерба при обновлении фильтров. Именно эта неоднородность и есть аргумент в пользу серии неравномерных волн, а не одного общероссийского «рубильника» для всех VPN сразу.

| Период | Характер ограничения | Что ломалось | Разбор в хранилище |
|---|---|---|---|
| 21–25 мая 2026 | Прицельная фильтрация протоколов и блокировка по ASN дата-центров | MTProto, VLESS, WireGuard, XHTTP, gRPC, Hysteria | по данным Meduza, май 2026 года |
| 6 июня 2026 | Поведенческий фильтр: подсеть дата-центра + TLS-отпечаток + частота соединений | легитимные сайты на российских облаках, VLESS+REALITY | [[DPI/tspu-false-blocks-june-2026\|Ложные блокировки ТСПУ]], [[VLESS/dpi-tls-june-2026\|заморозка VLESS+REALITY]] |
| 23 июня 2026 | Сбой списков исключений при обновлении «белого списка» ТСПУ | Twitch, Discord, PUBG, GitHub, часть облачных подсетей | [[DPI/tspu-whitelist-cloudflare-june-2026\|инцидент 23 июня]], [[DPI/subnet-whitelist-blocking-2026\|ковровая блокировка подсетей]] |
| 3 июля 2026 | Блокировка публичного DNS 8.8.8.8 по TCP (DoH/DoT) | VPN-клиенты с внешним DNS-резолвером | [[DPI/google-dns-8888-block-july-2026\|блок 8.8.8.8]] |

Ни один из этих эпизодов не совпадает с другим ни по цели, ни по механизму: майская волна прицельно давила VPN-протоколы, июньская задевала обычные сайты как побочный эффект поведенческого фильтра, а инциденты 23 июня и 3 июля выглядели как ошибки при обновлении «белых списков» и правил обработки DNS. Так и должна выглядеть «серия неравномерных волн» из прогноза — разные удары в разное время по разным группам адресов, а не единовременное отключение. При этом не каждый сбой того периода был фильтрацией: в начале июня инфраструктура сервиса Amnezia пережила DDoS-атаку, а европейский дата-центр — отключение питания (по сообщению SecurityLab, июнь 2026 года). Это ещё раз показывает, почему волну нельзя опознавать по одним лишь жалобам пользователей.

Масштаб происходящего задаёт фон для прогноза. К концу февраля 2026 года Роскомнадзор ограничивал доступ к 469 сервисам обхода блокировок (по сообщению РИА Новости от 26 февраля 2026 года со ссылкой на регулятор), а перечень фильтруемых протоколов с декабря 2025 года расширяли за счёт SOCKS5, VLESS и L2TP. На этом фоне заявление о «новой волне» осенью описывает продолжение уже идущего процесса, а не принципиально новый сценарий. Поэтому техническая часть прогноза выглядит правдоподобно, а неизвестной остаётся именно дата следующего эпизода.

## Как отличать селективное ограничение от перегрузки сервера

Один зависший сайт или медленный файл не доказывает вмешательство [[DPI/tspu-false-blocks-june-2026|ТСПУ]]. Нужны повторяемость и контрольное сравнение: тот же сервер, тот же момент времени, но другая сеть или транспорт. Чем больше независимых признаков совпадает, тем сильнее версия о фильтрации.

| Наблюдение | Больше похоже на обычную перегрузку | Больше похоже на селективную фильтрацию |
|---|---|---|
| Охват | Проблема видна из разных стран и сетей | Проблема повторяется у выбранного российского оператора или региона, а контрольная сеть работает |
| Зависимость от протокола | Одновременно деградируют все сервисы на узле | Один транспорт или профиль стабильно ломается, другой на том же сервере продолжает работать |
| Форма сбоя | Скорость плавает вместе с загрузкой CPU, канала или диска | Рукопожатие завершается, затем поток каждый раз замирает после сходного числа пакетов, объема или серии соединений |
| Время восстановления | Сервис улучшается по мере снижения серверной нагрузки | После триггера наблюдается похожее окно ожидания, затем новые соединения снова проходят |
| Захват пакетов | Потери и задержки распределены без устойчивой границы | Видна повторяемая граница: ответ на рукопожатие приходит, после нее пакеты одного направления перестают достигать клиента |

> [!warning] Домашняя диагностика не устанавливает виновника
> Даже совпадение нескольких признаков показывает только наличие промежуточного сетевого воздействия. Похожую картину могут создавать неверный MTU (максимальный размер передаваемого пакета), защита от DDoS, ограничение частоты запросов у хостера, перегруженный пиринг или неисправный маршрутизатор. Для уверенного вывода нужны измерения из нескольких сетей, телеметрия сервера и захват пакетов с обеих сторон соединения.

## Пределы прогноза

Заявления Щербакова согласуются с известными механизмами фильтрации. Упомянутые им цифровые отпечатки — это фиксированные длины пакетов WireGuard и коды операций OpenVPN. Частота переподключений указывает на поведенческие лимиты TLS-сессий, проблемы с крупными файлами следуют из блокировок по объему данных, а интервалы между пакетами лежат в основе статистических классификаторов. Упомянутые признаки могут участвовать в классификации и последующем воздействии на выбранный поток. Сергей Щербаков занимает должность технического директора компании «Стахановец», которая разрабатывает системы защиты от утечек данных (DLP) и анализирует поведение сотрудников. Этот опыт работы с корпоративной телеметрией и анализом аномалий объясняет его понимание методов классификации трафика.

При этом разработка офисных DLP-систем отличается от создания операторских платформ DPI масштаба страны. Данные о причастности «Стахановца» к проектированию ТСПУ или о доступе Щербакова к внутренним планам Роскомнадзора отсутствуют. Его технические аргументы согласуются с возможностями систем фильтрации, но названные сроки новой волны ограничений в конце лета или начале осени 2026 года, как и предположение о текущем сборе данных для этой цели, остаются прогнозом эксперта, а не подтвержденным графиком регулятора.

## Почему назван именно осенний срок

«Конец лета или начало осени» — срок не только про перенастройку ТСПУ. У осеннего окна есть причины, лежащие вне фильтрующего оборудования, и их стоит учитывать при проверке прогноза. Во-первых, потребление трафика в России сезонно: спад приходится на март–июль, а рост — на осень и зиму, поэтому любое узкое место в сети обостряется именно к концу года. Во-вторых, на тот же период указывает отдельный, нетехнический рычаг давления — [[DPI/economic-filter-foreign-channels-2026|«экономический фильтр» зарубежного трафика]]. С марта 2026 года Минцифры ввело согласительный порядок расширения зарубежных каналов связи, а первые заметные последствия этого ограничения телеком-эксперты ожидали к августу–сентябрю 2026 года (по материалам РБК, июнь 2026 года). VPN-трафик по определению зарубежный, поэтому сужение самой «трубы» ухудшает его без всякого DPI.

Отсюда следует осторожный вывод для фактчека: осеннее падение качества VPN может совпасть по времени с прогнозом Щербакова, но иметь другую причину — сезонный пик нагрузки и экономическое ограничение каналов, а не новую сигнатуру или поведенческое правило ТСПУ. Поэтому рост числа жалоб осенью сам по себе не подтвердит именно версию о новой волне DPI-фильтрации. Разделить причины помогает тот же контрольный приём — сравнить тот же сервер из другой сети и через другой транспорт (см. раздел о признаках селективной фильтрации выше).

## Как проверить прогноз после осени

Фраза «конец лета или начало осени» не содержит точной границы. Для последующего фактчека этой статьи разумно считать проверочным окном период с 1 августа по 15 октября 2026 года. Это редакционное определение, а не срок из слов Щербакова или документа РКН.

Прогноз получит сильное подтверждение, если в этом окне независимые измерения зафиксируют повторяемую волну на нескольких несвязанных операторах: одинаковый класс протоколов или поведенческих признаков, завершение рукопожатия перед деградацией, сходные пороги и устойчивое отличие от контрольных сетей. Дополнительным подтверждением станут опубликованные изменения чекеров, отчеты операторов или документы, связывающие сбои с новыми правилами ТСПУ.

Календарная часть прогноза ослабнет, если до 15 октября не появится воспроизводимого многооператорного изменения, а заметные сбои будут объясняться нагрузкой отдельных VPN-серверов, маршрутами или авариями. Это не опровергнет техническую возможность поведенческой фильтрации и долгосрочный курс на усиление АСБИ; оно покажет лишь, что названный срок не подтвердился.

## Реалистичный механизм без подтвержденного календаря

Спецификации и исследования, доступные к июлю 2026 года, показывают уязвимость популярных протоколов к классификации. WireGuard и OpenVPN можно распознавать без привязки к номерам портов. Системы DPI способны классифицировать туннели по размерам пакетов, таймингам хэндшейков и ответам серверов. В России документирован управляемый троттлинг Twitter, а отдельные полевые тесты 2025–2026 годов фиксировали пороги объема и частоты соединений.

Версия о том, что регулятор собирает статистику для проведения новой волны ограничений в конце лета или начале осени 2026 года, не имеет документальных подтверждений. Текущую стабильность можно объяснить доработкой правил ТСПУ после ложных блокировок, неравномерным обновлением оборудования на сетях провайдеров, переходом пользователей на новые версии протоколов или обычным снижением нагрузки после предыдущей волны.

Зеленый индикатор VPN сам по себе говорит лишь о том, что клиент завершил начальный обмен с сервером. После этого фильтр технически способен замедлить поток, заморозить его после порога данных или применить ограничение к серии новых соединений; отдельные варианты такого воздействия задокументированы в исследованиях и полевых тестах. Осенний срок в этой картине остается предположением Щербакова: публичного графика новой волны блокировок РКН и операторы не раскрывали.

## Источники и материалы

Исходный прогноз опубликован в [«Газете.Ru»](https://www.gazeta.ru/social/news/2026/07/19/28927375.shtml) (копия на [Дзене](https://dzen.ru/a/al2Bq9VlSA969LUZ)). Структура пакетов описана в спецификациях [WireGuard](https://www.wireguard.com/protocol/) и [OpenVPN](https://build.openvpn.net/doxygen/network_protocol.html), сигнатуры — в исходниках [nDPI для WireGuard](https://github.com/ntop/nDPI/blob/dev/src/lib/protocols/wireguard.c) и [OpenVPN](https://github.com/ntop/nDPI/blob/dev/src/lib/protocols/openvpn.c). Описание механизмов маскировки взято из документации [AmneziaWG](https://docs.amnezia.org/ru/documentation/amnezia-wg/).

Академические исследования: [распознавание OpenVPN](https://www.usenix.org/conference/usenixsecurity22/presentation/xue-diwen) (USENIX Security 2022) и [анализ вложенных TLS-хэндшейков](https://www.usenix.org/conference/usenixsecurity24/presentation/xue-fingerprinting) (USENIX Security 2024). Данные полевых тестов в РФ: [разбор июньских ограничений 2026 года](https://habr.com/ru/articles/1044396/) на Хабре и обсуждение [tcp 16-20 / l4-25](https://github.com/net4people/bbs/issues/490). Отчет о троттлинге Twitter в РФ подготовлен проектом [Censored Planet](https://censoredplanet.org/throttling).

Правовой и инфраструктурный контекст: [Федеральный закон № 90-ФЗ](https://publication.pravo.gov.ru/document/view/0001201905010025), [статья 46 закона «О связи»](https://www.consultant.ru/document/cons_doc_LAW_43224/16bb16c212b64fca3cd16dac9f4f1f2c2fd34083/), публикация [The Bell об удаленных документах РКН и KPI 92%](https://thebell.io/roskomnadzor-udalil-dokumenty-o-planakh-blokirovki-vpn-v-rossii-na-92) и материал [«Коммерсанта» о плане расширения АСБИ](https://www.kommersant.ru/doc/8533998).

## 📚 См. также

- [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: от SYN до поведенческой классификации]] — полный конвейер признаков и решений фильтра.
- [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY]] — подробный разбор июньских TLS-ограничений 2026 года.
- [[DPI/tspu-false-blocks-june-2026|Ложные блокировки ТСПУ]] — почему агрессивные правила задевают обычные сайты.
- [[DPI/statistical-morphing-concept|Статистический морфинг трафика]] — как можно менять не заголовок, а всю форму потока.
- [[DPI/rkn-vpn-2030-roadmap|Курс на 2030: планы по VPN и фильтрации трафика]] — государственная программа и бюджетный контекст.
- [[DPI/economic-filter-foreign-channels-2026|Экономический фильтр зарубежного трафика]] — как дефицит и удорожание зарубежных каналов давят на VPN без всякого DPI.
- [[DPI/mincifry-whitelist-vpn-hosting-august-2026|Белый список ЦМУ ССОП и хостеры (август 2026)]] — административный рычаг вместо технического: адрес лишают иммунитета от фильтрации, а скорость санкции привязывают к уровню идентификации клиента.

---

> [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ
> При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/DPI/vpn-blocking-wave-forecast-summer-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main).