Привет, Хабр! На протяжении последнего года регуляторы значительно усилили блокировку VPN-протоколов. Если совсем давно основной метод сводился к блокировке IP-адресов известных VPN-провайдеров, то сейчас везде применяется глубокий анализ трафика (DPI), позволяющий идентифицировать и блокировать VPN-соединения на уровне протокола.
Сегодня разберемся, как блокируют OpenVPN и WireGuard.
Уточнение
Стоит уточнить, что в России блокируются только зарубежные соединения к этим протоколам. VPN до сервера внутри страны работает, а тот же VPN до сервера в Германии - блокируется. Это позволяет не ломать корпоративные VPN внутри страны, но отрезает выход наружу.
Раньше всех пишем о новых блокировках в России в нашем телеграм
Как работает OpenVPN
(странная картинка)
Для понимания механизмов блокировки стоит немного вспомнить, как протокол устанавливает соединение.
OpenVPN, по сути, создаёт туннель в два этапа: сначала поднимается защищённый контрольный канал через TLS, затем внутри него согласовываются ключи для шифрования данных.
Клиент отправляет init-пакет с опкодом
0x38(P_CONTROL_HARD_RESET_CLIENT_V2)Сервер отвечает своим хардресетом
Происходит TLS-хендшейк - клиент шлёт ClientHello со списком поддерживаемых шифров
Стороны обмениваются ключами по TLS сессии и трафик начинает идти
И вот здесь сразу появляется несколько узких мест:
Первое и самое очевидное - опкоды в заголовке. Первый байт каждого пакета OpenVPN содержит тип сообщения. Эти значения фиксированы в спецификации: 0x38 для инициализации, 0x20 для данных и так далее. DPI достаточно посмотреть на первый байт, чтобы заподозрить использование OpenVPN.
Второе, по чему палится протокол - характерный TLS. OpenVPN использует TLS, но не притворяется браузером. Набор поддерживаемых шифров и пор��док их перечисления очень сильно отличается от тех, что отправляют Chrome или Firefox. Получается уникальный TLS-отпечаток.
Как блокируют OpenVPN
Теперь о том, как всё это используется для блокировки.
Сигнатурный анализ.
Самый понятный и прямолинейный метод детекта для DPI - анализ пакетов и поиск в них характерных байтов в начале.
При таком анализе, наличие опкода 0x38 на первой позиции UDP-пакета или в начале TCP-потока - это сразу флаг, что пакет может использоваться протоколом. Внутри пакета, в зависимости от агрессивности DPI в регионе, проверяют структуру пакета, длину полей, корректность значений.
TLS Fingerprinting
Второй фактор, используемый для блокировки - анализ TLS-отпечатка пакета. Более продвинутый метод.
DPI анализирует ClientHello и сравнивает отпечаток с базой известных. Если отпечаток не совпадает ни с одним популярным браузером - пакет блокируется. При этом неважно, что там внутри TLS-сессии: сам факт нестандартного хендшейка выдаёт протокол.
Поведенческий анализ
Окей, вы можете вполне резонно возразить: так я повешу OpenVPN на 443 порт, и что ты мне сделаешь?
Здесь стоит помнить о том, что DPI могут использовать постоянный анализ пакетов на наличие подозрительных признаков. Даже при попытках маскировки вашего сервера поведенческие паттерны протокола остаются.
Взять те же KeepAlive-пакеты: OpenVPN поддерживает постоянное соединение, регулярно отсылая пакеты фиксированного размера на сервер. Это не очень похоже на обычный веб-сёрфинг.
На практике же все эти методы комбинируются. Если DPI видит, что какой-то клиент отправляет одни и те же пакеты, шифрованные при помощи кастомного TLS, не похожего на браузерный, да еще и с опкодами, характерными VPN.
Такой пакет, конечно, будет ЛИКВИДИРОВАН.
Как работает WireGuard
Перейдём к другому протоколу.
WireGuard появился сильно позже OpenVPN, и изначально создавался для максимально быстрой работы протокола, с упором на производительность и чистоту кода.
Весь протокол состоит буквально из 4000 строк кода против 100 000+ у OpenVPN.
Минимум настроек, один набор криптографии (Curve25519, ChaCha20, Poly1305), а обе стороны заранее знают ключи друг друга. Что может быть лучше для скорости протокола и скорости детекта его при помощи DPI?
Хендшейк WG выглядит примерно так:
Клиент отправляет Handshake Initiation, всегда состоящий из ровно 148 байт
Сервер отвечает Handshake Response, всегда ровно 92 байта
??
profit!
Красота! Всего четыре типа сообщений, фиксированные размеры, предсказуемая структура, а первые 4 байта каждого пакета - это тип сообщения: 0x01000000 для инициализации и0x02000000 для ответа. И все это добро работает только поверх UDP.
Создатели WireGuard и не ставили задачу противостоять DPI. Протокол разрабатывался для скорости, простоты аудита и надёжной криптографии. А устойчивость к блокировкам никто и не задумывал. И это честный выбор, но он делает WireGuard буквально крякми для DPI-спецов.
Как блокируют WireGuard
Думаю, ответ очевиден из вышеперечисленного
Провайдер просто блокирует все UDP пакеты по соответствующим сигнатурам: фиксированный размер секций в пакете позволяет почти идеально точно опознать хендшейк.
Кроме того, он всегда начинается с 0x01, будто специально сделанный для того, чтобы уменьшить количество false-positive'ов у DPI.
В сравнении с OpenVPN, WG даже не позволяет косить под HTTPS трафик, ведь просто не позволяет использовать TCP.
Просуммируем:
OpenVPN |
WireGuard |
|
|---|---|---|
Методы детекта |
TLS fingerprinting + опкоды |
Фиксированные размеры пакетов |
Транспорт |
UDP или TCP |
Только UDP |
Порт 443 под HTTPS |
Можно, но палится по TLS |
Невозможно |
Вариативность |
Много режимов и настроек |
Один режим, одна криптография |
Собственно да, WireGuard блокируется быстрее и надёжнее просто потому, что очень предсказуем.
Методы обхода и методы обхода обхода
Раз стандартные протоколы детектируются, появились инструменты обфускации.
Для WireGuard это обёртки вроде AmneziaWG или swgp-go. Хочется подробнее разобрать проблему второго протокола.
Идея swgp-go была в маскировке WG среди кучи рандомного шума. И некоторые страны его заблокировали, просто «посчитав» отпечаток для этого протокола.
Сделали это так: в DPI добавили правило, считающее количество нулей и единиц в байтах пакета. И если соотношение их количества в пакете примерно одинаково, то это серьезная аномалия, которой не может быть в легитимных протоколах (типа HTTPS).
Это называется анализом энтропии пакета, и применяется для большого количества таких «оберток» вокруг VPN-протоколов.
Honorable mentions
Среди других методов детектирования - Active Probing. Серверы регулятора отправляет запросы на подозрительный сервер, ранее помеченный по другим аномалиям. Если сервер отвечает как VPN или не отвечает так, как должен отвечать легитимный веб-сервер, а сам при этом прячется под 443 портом - соединения к нему на время блокируются.
А уж если бот найдет на адресе впн-панельку то все, прощай, сервачок ;( Сообщение об ужасной технологии на вашем сервере уже летит вашему провайдеру.
Месяц назад, например, AEZA заблокировала несколько серверов своих клиентов, на которых стояли VPN по просьбе РКН
И хорошо, если регулятор не введет Машинное обучение и классификаторы, которые будут учится на паттернах трафика. В таком случае даже если обфускация обманывает статические правила, ML-модель может поймать аномалию по совокупности признаков. А, ой...
Пишем обо ВСЕХ новых блокировках в России раньше всех в нашем телеграм
Последнее время у VLESS проблемы, так что подписывайтесь на наш телеграм, чтобы ничего не пропустить
Комментарии (27)
Sap_ru
20.01.2026 19:12Статья ни о чём. Это не описание реальной работы DPI, а просто какие-то общие рассуждения.
MnsDev Автор
20.01.2026 19:12Похоже, вы ожидаете техническое описание DPI, но статья вообще не про это. Мы писали про механики блокировок протоколов и то, как это проявляется для пользователей/сервисов, а не про внутреннее устройство DPI.
kcalgo
20.01.2026 19:12Статья как раз о том, по каким признакам блокируют конкретно взятые VPN-протоколы и как их детектят. Про DPI у нас есть цикл статей про Китай, кстати, там подробнее :)
SerpentFly
20.01.2026 19:12И если соотношение их количества в пакете примерно одинаково, то это серьезная аномалия, которой не может быть в легитимных протоколах (типа HTTPS).
Некорректное утверждение. У надёжно зашифрованного трафика (HTTPS) нормированная энтропия стремится к 1, так как шифртекст статистически близок к случайному.
MiracleUsr
20.01.2026 19:12Очередная мусорная статья в помоечном блоге. Нейроблев с кучей ошибок, неточности и откровенного бреда.
что в России блокируются только зарубежные соединения к этим протоколам. VPN до сервера внутри страны работает, а тот же VPN до сервера в Германии - блокируется. Это позволяет не ломатькорпоративные VPN внутри страны, но отрезает выход наружу.
В теории оно должно быть так, на практике есть уже довольно много случаев когда блокируются подключения чуть ли не в пределах города, а не наружу
Самый понятный и прямолинейный метод детекта для DPI - анализ пакетов и поиск в них характерных байтов в начале.
И ни слова про режим tls-crypt. Автору двойка
Второй фактор, используемый для блокировки - анализ TLS-отпечатка пакета. Более продвинутый метод.
DPI анализирует ClientHello и сравнивает отпечаток с базой известных.
В теории оно так и давно известно, вот только есть нюанс - РКН на ТСПУ не анализирует фингерпринты на «нестандартность». Там ровно наоборот, в ряде случаев был срабатывание на отдельные и специфичные фингерпринты (например старых версий библиотеки pion для webrtc). Только к OpenVPN никакого отношения это не имеет и никак не влияет.
Здесь стоит помнить о том, что DPI могут использовать постоянный анализ пакетов на наличие подозрительных признаков.
Могут, но не делают, слишком дорого выходит. ТСПУ анализируют только первые пакеты соединения.
В сравнении с OpenVPN, WG даже не позволяет косить под HTTPS трафик, ведь просто не позволяет использовать TCP.
Ну здрасте. Мы в 21 веке живем, в наше время HTTPS вполне себе бегает по UDP. Про QUIC автор видимо не слыхал. И варианты маскировки WG под QUIC как раз существуют.
Сделали это так: в DPI добавили правило, считающее количество нулей и единиц в байтах пакета. И если соотношение их количества в пакете примерно одинаково, то это серьезная аномалия, которой не можетбыть в легитимных протоколах (типа HTTPS).
Вот с этого я дико проорал. Чувак, как раз «примерно одинаковое среднее количество нулей и единиц» именно что должно наблюдаться в протоколах типа HTTPS, потому что там передается зашифрованный трафик.
Видимо нейронка которую насиловал автор ссылается на известное исследование GFW-Report про то как Китай блокировал Shadowsocks, но прочитала его задницей и ничего не поняла (там Китай тупо резал полностью шифрованный трафик незнакомых протоколов, но пропускал то что похоже на человеко-читаемый ASCII-текст, и именно в этом контексте шла речь про нули и единички).
edo1h
20.01.2026 19:12Могут, но не делают, слишком дорого выходит. ТСПУ анализируют только первые пакеты соединения.
ну… ssh-сессии, подвисающие через некоторое время, говорят об обратном
MiracleUsr
20.01.2026 19:12Сам факт что это - SSH определяется в самом начале подключения, дальше вероятно идет уже просто оценка обьемов трафика без детального анализ пакетов
Напротив в случае в WG достаточно заслать «обманки» (маскирующиеся под QUIC) в самом начале и дальше спокойно гонять пакеты WG, которые по факту всетаки отличаются от QUIC определены и признаками. Или можно по TCP обмануть детектирование красивым HTTP-заголовком, а потом слать все что угодно.
Last26
20.01.2026 19:12Я не буду ничего рекламировать, но могу сказать, что как минимум все еще достаточно российских хостингов предлагают готовые решения с иностранными адресами..и они работают ни смотря на то что адреса иностранные. Ну и кроме того классические впн без маскировки очень легко блокировать это так..но есть варианты маскировки которые все еще работают и я думаю будут и далее работать..ну и по моему мнению самый главный вопрос зачем вообще использовать технологии которые не создавались для обхода чего либо если есть специализированные решения..которые еще при этом формально являясь UDP не попадают под всякие шейперы и не теряют свою производительность ..чего нельзя сказать о том же WG который быстрый только в хороших сетях при условии если udp не режется.
Hardoman
20.01.2026 19:12Причём добавлю, что важно, чтобы у этих самых русских провайдеров были сервера и в России, и ASN соответствующие, тогда их не трогают пока что.
alchemist666
20.01.2026 19:12Да и провайдеры давно блокируют и корпоративный трафик на Wireguard и других криптосложных шифрованиях, если их не уведомила организация и соответствующие министерства, законом утвержденном порядке. Могут и не блокировать, а берут и блокируют так как есть постановление.
Psychosynthesis
20.01.2026 19:12Нормально всё работает. Сотрудники, которые к корп. VPN на базе WG подключаются раскиданы по разным провайдерам внутри РФ и даже странам. Иногда проблемы бывают, да, но в среднем за прошедший год отваливалось так чтоб никто нормально работать не мог... может ну... раз пять.
edo1h
20.01.2026 19:12у меня по работе несколько сотен туннелей внутри РФ, в основном openvpn, есть ipsev ikev2 и wg.
в целом всё работает, бывает что-то отваливается, но обычно через несколько часов восстанавливается.никуда ничего не подавал, хотя мысли такие были )
а вот с туннелями за границу всё хуже
GiveMeFreeNickName
20.01.2026 19:12Копирайтеры Фемиды снова забыли сходить в туалет и решили засрать на хабр
Nemoumbra
20.01.2026 19:12Очень много утверждений из статьи - набрасывание на вентилятор. Т.е. тут не пахнет реальностью, хотя в названии статьи глагол в настоящем времени изъявительного наклонения. Ну да, опкод есть на самом деле... Но ведь спецификация OpenVPN значительно сложнее описанного! И встречаются также откровенно странные утверждения, например, про кол-во ноликов и единичек в TLS.
Если бы тут была статистика какая-то, можно бы было хоть о чём-то говорить.
JTNeXuS
20.01.2026 19:12блокируются только зарубежные соединения к этим
И вг на Ростелекоме в северо-западе такой
Ага ага пошел....
TachiSi80
Счастливый программист в кремле играет в доту с пингом 10мс