Надежный обход блокировок в 2024. О том какие VPN - протоколы работают, а какие уже не стоит использовать.
Спойлер: самый совершенный на сегодняшний день алгоритм обхода блокировок - это VLESS. Проверить работу можно тут https://t.me/VlesVPNbot?start=ul
Итак, начнем с того, чем в наше время пользоваться уже не стоит:
Обычный SOCKS — изначально не предусматривает шифрования, поэтому цензоры легко увидят, куда вы подключаетесь и заблокируют соединение.
OpenVPN — его научились блокировать уже давно в России, Китае, Иране и много где еще. Не помогает ни смена TCP/UDP, ни смена порта на нестандартный, ни более навороченные опции в конфиге. Точнее не так, в некоторых случаях они помогают, но, как говорил один известный персонаж отечественной истории, «это не ваша заслуга, а наша недоработка», и в любой момент это все может перестать работать, благо технические возможности для этого давно уже есть.
IPSec — аналогично, детектируется блокируется на раз‑два.
Wireguard и все что основано на нём — он очень популярен, но, к сожалению, тоже совершенно не устойчив к блокировкам, в чем мы уже неоднократно убедились.
Tor — адреса входных нод доступны в публичном реестре, и поэтому могут быть легко заблокированы. Бриджи (bridges) пока работают, но РКН в прошлом неоднократно их выборочно банил (видимо, запрашивая списки, прикидываясь обычным пользователям и внося полученные адреса в блок), к тому же их протокол выглядит как рандомный поток байт, и блокировку по белым спискам протоколов не переживет. Snowflake — после некоторых исправлений более‑менее работает, можно пользоваться, однако поиск бриджа для входа там выполняется через один известный домен на CDN, который как‑то раз уже тоже блокировали. WebTunnel — пока работает, но таких бриджей мало.
Что еще пока работает, но с оговорками:
SSTP, Softherher, AnyConnect и OpenConnect — это уже гораздо лучше, поскольку выглядят как HTTPS‑трафик. Проблемы есть две: их можно детектировать методом active probing (и как я говорил выше, Роскомнадзор такому уже учится), потому что при заходе на них браузером по определенным адресам (описанным в стандартах этих протоколов) они демаскируют себя, и вторая проблема — характерный TLS fingerpring (отпечаток) их клиентов. Первая проблема частично решена в новых версиях OpenConnect с включением специального метода «camouflage». Однако вторая проблема, к сожалению, пока не имеет решения ни у одного из них. Тем не менее, OpenConnect‑клиент, теоретически, можно пересобрать с использованием OpenSSL вместо GnuTLS, что снижает вероятность обнаружения.
Shadowsocks, Shadowsocks-2022, а также Outline. SS — известная разработка от китайских товарищей, SS-2022 — более новая версия протокола, в которой исправлен ряд уязвимостей, а Outline — удобный и простой в настройке клиент/сервер, основанный на Shadowsocks. На сегодняшний день вполне работает, можно пользоваться. Одно но: так как трафик SS представляет из себя совершенно рандомный набор байт без каких‑либо узнаваемых сигнатур, блокировку по белым спискам протоколов (см. выше) он не переживет, поэтому я бы рассматривал его как запасной, но не как основной вариант. Существует так же протокол VMess, который по своему принципу очень похож на Shadowsocks с теми же недостатками.
AWG, оно же AmneziaWG — улучшение протокола Wireguard, разработанное командой проекта Amnezia VPN, чтобы сделать Wireguard устойчивым к детектированию оборудованием DPI, при этом сохранив его преимущества. Он действительно работает, и работает неплохо. Минус тот же, как и SS — поскольку оборудование ТСПУ этот протокол не распознаёт, то блокировку по белым спискам протоколам в случае чего он не переживет.
SSH — скажу кратко, пока работает. Правда, есть довольно много свидетельств, что в Китае, видя «нецелевое» использование SSH (может быть, анализируя объемы и тайминги передаваемых туда‑сюда данные и паттерны поведения нейросетями?), ограничивают скорость передачи настолько, что пользоваться им для серфинга становится невозможным, тормозит даже консоль.
И наконец. Что работает и вероятно будет продолжать работать:
VLESS — самый распространенный и перспективный на сегодняшний день протокол, от создателей известного клиента‑сервера XRay. Работает поверх TLS, искуссно маскируясь под обращение к какому‑нибудь безобидному веб‑сайту. Поддерживается в очень многих десктопных и мобильных клиентах, и именно на его основе строятся всевозможные схемы обхода блокировок. Вместе с ним вы можете встретить также большое количество других слов, обычно обозначающие его расширения или отдельные фичи. Рассмотрим основные из них:
uTLS — изменение TLS‑fingerprint клиента; например, можно заставить выглядеть исходящие подключения как подключения от браузеров Chrome, Firefox, Safari, или вообще генерировать каждый раз новый рандомный фингерпринт;
XTLS‑Vision — специальный режим работы, затрудняющий детектирование TLS‑inside‑TLS. Когда это режим включен, если прокси‑сервер определяет подключение к удаленному серверу по TLS 1.3, то шифруется только хендшейк, а после этого уже зашифрованные (TLS между вашим браузером и удаленным сервером) данные передаются без повторного слоя шифрования (отключается TLS между прокси‑клиентом и прокси‑сервером). Такая схема совершенно безопасна (данные в любом случае шифруются как минимум один раз и не видны стороннему наблюдателю), но ломает TLS‑inside‑TLS эвристики, а заодно экономятся ресурсы процессора;
XUDP — специальное расширение для передачи UDP‑пакетов через прокси, реализует полный Full Cone NAT с сохранением номера порта. Без этого расширения в некоторых случаях могут не работать аудио‑видео‑звонки в месседжерах, оно было создано именно для решения этой проблемы;
XTLS‑Reality — вот это самое крутое. То что VLESS работает поверх TLS и маскируется под какой‑то веб‑сайт, означает что у вас должен быть домен и TLS‑сертификат для него. А еще в случае блокировок по белым спискам, ваш никому неизвестный сайт (домен) врядли окажется в списке разрешенных ресурсов.
XTLS‑Reality решает обе эти проблемы: вам не нужен свой домен и сертификат, с XTLS‑Reality сервер очень достоверно маскируется под какой‑нибудь известный и популярный сайт (например, google.com, vk.com, и т. д.), и представляется его аутентичным TLS‑сертификатом.
Работает это так: в момент установления подключения, клиент «подмешивает» в поля хендшейка определенные данные, определить наличие которых можно только зная секретный ключ, при этом со стороны хендшейк выглядит обычно. Прокси‑сервер, зная секретный ключ, может определить, был ли запрос на установку соединения послан от прокси‑клиента или же от кого‑то другого (например, цензора, желающего проверить, что там на сервере). В первом случае установится подключение для передачи данных через прокси, во втором случае прокси начнет прозрачно пересылать запросы на сервер сайта, под который мы маскируемся, в результате чего цензор увидит самый настоящий сертификат этого сайта, и вообще поведение нашего сервера будет полностью соответствовать поведению сервера этого сайта.
Иногда в интернете можно встретить утверждения, что «VLESS не имеет своего механизма шифрования, а значит он не безопасен». Это не совсем так. \"Голый\" VLESS действительно не зашифрован, но VLESS никогда не используется так в чистом виде - и по рекомендациям авторов протокола и во всех популярных инструкциях (и в этой тоже!), и в примерах конфигов в репе XRay, он всегда используется с TLS в качестве транспорта - в итоге при правильной настройке подключения через VLESS всегда как минимум один раз шифруются. VLESS действительно не имеет дополнительных механизмов шифрования, потому что стандартного TLS для цели защиты данных более чем достаточно и нет нужды городить сверху что‑то еще, от этого будет только хуже. Более того, даже когда используется XTLS‑Vision, который определяет наличие TLS‑внутри‑TLS и отключает один из слоев шифрования, передаваемые данные между вами и конечным сервером все равно всегда будут зашифрованы хотя бы один раз.
Проверить работу VLESS можно тут https://t.me/VlesVPNbot?start=ul2
Trojan — более старый аналог VLESS, работает примерно по таким же принципам. Каких‑либо особых преимуществ по сравнению с VLESS не имеет. Может использоваться с uTLS, XTLS‑Vision и XTLS‑Reality, и более того, должен использоваться с ними, потому что без XTLS‑Vision он детектируется по принципу поиска TLS‑in‑TLS вообще элементарно.
Cloak — протокол, очень сильно похожий по принципам работы на XTLS‑Reality (маскировка именем и настоящим сертификатом популярного веб‑сайта). Используется не сам по себе, а для заворачивания в него Shadowsocks, OpenVPN и вообще всего что захочется. Shadowsocks‑over‑Cloak и OpenVPN‑over‑Cloak поддерживают, например, клиент и сервер Amnezia VPN.
#vless
#vpn
Надежный обход блокировок в 2024. О том какие VPN - протоколы работают, а какие уже не стоит использовать.
Спойлер: самый совершенный на сегодняшний день алгоритм обхода блокировок - это VLESS. Проверить работу можно тут https://t.me/VlesVPNbot?start=ul
Итак, начнем с того, чем в наше время пользоваться уже не стоит:
Обычный SOCKS — изначально не предусматривает шифрования, поэтому цензоры легко увидят, куда вы подключаетесь и заблокируют соединение.
OpenVPN — его научились блокировать уже давно в России, Китае, Иране и много где еще. Не помогает ни смена TCP/UDP, ни смена порта на нестандартный, ни более навороченные опции в конфиге. Точнее не так, в некоторых случаях они помогают, но, как говорил один известный персонаж отечественной истории, «это не ваша заслуга, а наша недоработка», и в любой момент это все может перестать работать, благо технические возможности для этого давно уже есть.
IPSec — аналогично, детектируется блокируется на раз‑два.
Wireguard и все что основано на нём — он очень популярен, но, к сожалению, тоже совершенно не устойчив к блокировкам, в чем мы уже неоднократно убедились.
Tor — адреса входных нод доступны в публичном реестре, и поэтому могут быть легко заблокированы. Бриджи (bridges) пока работают, но РКН в прошлом неоднократно их выборочно банил (видимо, запрашивая списки, прикидываясь обычным пользователям и внося полученные адреса в блок), к тому же их протокол выглядит как рандомный поток байт, и блокировку по белым спискам протоколов не переживет. Snowflake — после некоторых исправлений более‑менее работает, можно пользоваться, однако поиск бриджа для входа там выполняется через один известный домен на CDN, который как‑то раз уже тоже блокировали. WebTunnel — пока работает, но таких бриджей мало.
Что еще пока работает, но с оговорками:
SSTP, Softherher, AnyConnect и OpenConnect — это уже гораздо лучше, поскольку выглядят как HTTPS‑трафик. Проблемы есть две: их можно детектировать методом active probing (и как я говорил выше, Роскомнадзор такому уже учится), потому что при заходе на них браузером по определенным адресам (описанным в стандартах этих протоколов) они демаскируют себя, и вторая проблема — характерный TLS fingerpring (отпечаток) их клиентов. Первая проблема частично решена в новых версиях OpenConnect с включением специального метода «camouflage». Однако вторая проблема, к сожалению, пока не имеет решения ни у одного из них. Тем не менее, OpenConnect‑клиент, теоретически, можно пересобрать с использованием OpenSSL вместо GnuTLS, что снижает вероятность обнаружения.
Shadowsocks, Shadowsocks-2022, а также Outline. SS — известная разработка от китайских товарищей, SS-2022 — более новая версия протокола, в которой исправлен ряд уязвимостей, а Outline — удобный и простой в настройке клиент/сервер, основанный на Shadowsocks. На сегодняшний день вполне работает, можно пользоваться. Одно но: так как трафик SS представляет из себя совершенно рандомный набор байт без каких‑либо узнаваемых сигнатур, блокировку по белым спискам протоколов (см. выше) он не переживет, поэтому я бы рассматривал его как запасной, но не как основной вариант. Существует так же протокол VMess, который по своему принципу очень похож на Shadowsocks с теми же недостатками.
AWG, оно же AmneziaWG — улучшение протокола Wireguard, разработанное командой проекта Amnezia VPN, чтобы сделать Wireguard устойчивым к детектированию оборудованием DPI, при этом сохранив его преимущества. Он действительно работает, и работает неплохо. Минус тот же, как и SS — поскольку оборудование ТСПУ этот протокол не распознаёт, то блокировку по белым спискам протоколам в случае чего он не переживет.
SSH — скажу кратко, пока работает. Правда, есть довольно много свидетельств, что в Китае, видя «нецелевое» использование SSH (может быть, анализируя объемы и тайминги передаваемых туда‑сюда данные и паттерны поведения нейросетями?), ограничивают скорость передачи настолько, что пользоваться им для серфинга становится невозможным, тормозит даже консоль.
И наконец. Что работает и вероятно будет продолжать работать:
VLESS — самый распространенный и перспективный на сегодняшний день протокол, от создателей известного клиента‑сервера XRay. Работает поверх TLS, искуссно маскируясь под обращение к какому‑нибудь безобидному веб‑сайту. Поддерживается в очень многих десктопных и мобильных клиентах, и именно на его основе строятся всевозможные схемы обхода блокировок. Вместе с ним вы можете встретить также большое количество других слов, обычно обозначающие его расширения или отдельные фичи. Рассмотрим основные из них:
uTLS — изменение TLS‑fingerprint клиента; например, можно заставить выглядеть исходящие подключения как подключения от браузеров Chrome, Firefox, Safari, или вообще генерировать каждый раз новый рандомный фингерпринт;
XTLS‑Vision — специальный режим работы, затрудняющий детектирование TLS‑inside‑TLS. Когда это режим включен, если прокси‑сервер определяет подключение к удаленному серверу по TLS 1.3, то шифруется только хендшейк, а после этого уже зашифрованные (TLS между вашим браузером и удаленным сервером) данные передаются без повторного слоя шифрования (отключается TLS между прокси‑клиентом и прокси‑сервером). Такая схема совершенно безопасна (данные в любом случае шифруются как минимум один раз и не видны стороннему наблюдателю), но ломает TLS‑inside‑TLS эвристики, а заодно экономятся ресурсы процессора;
XUDP — специальное расширение для передачи UDP‑пакетов через прокси, реализует полный Full Cone NAT с сохранением номера порта. Без этого расширения в некоторых случаях могут не работать аудио‑видео‑звонки в месседжерах, оно было создано именно для решения этой проблемы;
XTLS‑Reality — вот это самое крутое. То что VLESS работает поверх TLS и маскируется под какой‑то веб‑сайт, означает что у вас должен быть домен и TLS‑сертификат для него. А еще в случае блокировок по белым спискам, ваш никому неизвестный сайт (домен) врядли окажется в списке разрешенных ресурсов.
XTLS‑Reality решает обе эти проблемы: вам не нужен свой домен и сертификат, с XTLS‑Reality сервер очень достоверно маскируется под какой‑нибудь известный и популярный сайт (например, google.com, vk.com, и т. д.), и представляется его аутентичным TLS‑сертификатом.
Работает это так: в момент установления подключения, клиент «подмешивает» в поля хендшейка определенные данные, определить наличие которых можно только зная секретный ключ, при этом со стороны хендшейк выглядит обычно. Прокси‑сервер, зная секретный ключ, может определить, был ли запрос на установку соединения послан от прокси‑клиента или же от кого‑то другого (например, цензора, желающего проверить, что там на сервере). В первом случае установится подключение для передачи данных через прокси, во втором случае прокси начнет прозрачно пересылать запросы на сервер сайта, под который мы маскируемся, в результате чего цензор увидит самый настоящий сертификат этого сайта, и вообще поведение нашего сервера будет полностью соответствовать поведению сервера этого сайта.
Иногда в интернете можно встретить утверждения, что «VLESS не имеет своего механизма шифрования, а значит он не безопасен». Это не совсем так. \"Голый\" VLESS действительно не зашифрован, но VLESS никогда не используется так в чистом виде - и по рекомендациям авторов протокола и во всех популярных инструкциях (и в этой тоже!), и в примерах конфигов в репе XRay, он всегда используется с TLS в качестве транспорта - в итоге при правильной настройке подключения через VLESS всегда как минимум один раз шифруются. VLESS действительно не имеет дополнительных механизмов шифрования, потому что стандартного TLS для цели защиты данных более чем достаточно и нет нужды городить сверху что‑то еще, от этого будет только хуже. Более того, даже когда используется XTLS‑Vision, который определяет наличие TLS‑внутри‑TLS и отключает один из слоев шифрования, передаваемые данные между вами и конечным сервером все равно всегда будут зашифрованы хотя бы один раз.
Проверить работу VLESS можно тут https://t.me/VlesVPNbot?start=ul2
Trojan — более старый аналог VLESS, работает примерно по таким же принципам. Каких‑либо особых преимуществ по сравнению с VLESS не имеет. Может использоваться с uTLS, XTLS‑Vision и XTLS‑Reality, и более того, должен использоваться с ними, потому что без XTLS‑Vision он детектируется по принципу поиска TLS‑in‑TLS вообще элементарно.
Cloak — протокол, очень сильно похожий по принципам работы на XTLS‑Reality (маскировка именем и настоящим сертификатом популярного веб‑сайта). Используется не сам по себе, а для заворачивания в него Shadowsocks, OpenVPN и вообще всего что захочется. Shadowsocks‑over‑Cloak и OpenVPN‑over‑Cloak поддерживают, например, клиент и сервер Amnezia VPN.
#vless
#vpn
1
1
1