Осваиваем самый прогрессивный способ обхода блокировок и сокрытия подключения к серверу VPN: Shadowsocks, обернутый в websocks-tls и пропущенный через Cloudflare CDN.

В чем его прогрессивность?

В том, что он скорость не режет.

VPN или прокси без промежуточных серверов будет отзывчивее, быстрее и надёжнее. Использование описанного вами способа оправдано в странах, где выявляют и блокируют VPN, но для частного использования в России это избыточно и задействует сторонний сервис (Cloudflare), который можно бы было не задействовать.

совершенно верно, но все еще впереди)

Note Shadowsocks is not HTTP based and thus cannot be proxied by Cloudflare CDN. It is, however, possible to use Cloudflare Spectrum with Shadowsocks.

A more common approach is to use WebSocket based protocol(e.g, V2Ray) or HTTP-based protocol(anyone recall good ol GoAgent https://en.wikipedia.org/wiki/GoAgent ?) with Cloudflare.

Of course your remark is true. Nevertheless, you need to follow the link and read the article. Also keep in mind that Cloudflare Spectrum for any TCP/UDP traffic is available only for the Enterprise plan, and this is in no way suitable for individual use.

Прошло всего-ничего - полтора года. И как все поменялось.

Прошло ещё полгода. И как всё поменялось

преимущество shadowsocks+cloudflare в том, что не светится адрес самого прокси-сервера. следовательно, ркн и ребята в черном не смогут вычислить адрес подключения, а будут видеть лишь адреса cloudflare. следовательно, заблокировать такой прокси-сервер не представляется возможным, если конечно не блокнут весь cloudflare

Это преимущество не самого прокси, а данной конкретной его реализации. Сам по себе Shadowsocks не предполагает проксирование через CDN.

под shadowsocks+cloudflare понимается shadowsocks over v2ray over cloudflare

При этом в ClientHello светится домен, на который идут запросы прокси, так что заблокировать труда не составляет. Призванный решить проблему eSNI с фиктивным нешифрованным SNI толком же не поддерживается нигде, как и чистый eSNI, который ещё и отлавливается DPI.

Конечно светится, это же легитимный https-трафик. Он и не должен прятаться.

А раз он не прячется, то ничто не мешает продвинутому DPI пройти по этому самому домену, ни у кого из других пользователей в логах не замеченного, и не обнаружить ничего, что могло бы создать большие объёмы трафика.

Очевидно, вы не знаете, как работают блокировки. Что блокировать определяет не оператор, и даже не “продвинутый DPI”. Блокировки централизованы, что блокировать определяют т. н. “суды”, генпрокуратура, роскомпараша и т. д. Им дела нет до ваших объемов трафика.

Пока что.

Прикрутил AdGuard Home вместо Unbound.

Наконец-то дошли руки попробовать. Делал все по инструкции, работает отлично. Жаль что quic не завернуть в ss.
Можно доработать момент с названием домена. Т.е подбирать название близко к названию сайта на который будем проксировать товарища майора. Понятно что это overkill в текущей ситуации, но теоритически защитит от ручной проверки.

quic нельзя завернуть в связку ss+v2ray-plugin, а в сам ss должно быть можно (не проверял). насчет имени домена - это не панацея от ручной проверки, т. к. первее вас выдаст объем трафика.

Если перенаправлять в прокси только заблокированные домены/ip (без ютуба или чего-то очень объемного) то разницы практически не будет.

я не сторонник такого подхода, учитывая то, что данный прокси легко справляется с любым объемом трафика (с очевидными исключениями, конечно).

А что вам не нравится в выборочном обходе блокировок?

Время не то, страна не та. Использование Интернета сегодня в России - это отягчающее обстоятельство. Про СОРМ 2 и 3, Яровую слышали?
Это вообще не вопрос “обхода блокировок”. Это вопрос безопасности.

Самый полный гайд теперь на Medium

Будто гайд с двача читаю. У либев уже устарел, лучше использовать оффициальную сборку на расте, она сейчас активно поддерживается. Зачем использовать v2ray, если есть xray? UDP в xray работает гораздо лучше и в целом гайд не выглядит свежим. Xchacha не рекоммендуется, в раст версии отсутствует. Лучше взять гайд xray и сделать более доступный гайд для масс, сделать установку скриптом.

Не вижу смысла в скриптах если есть GitHub - vaxilu/x-ui: 支持多协议多用户的 xray 面板, xray + cdn можно поднять за минуту.
Вот как он выглядит

image899×644 34 KB

image895×706 28.4 KB

Очень красиво, а можно без китайского языка?

Сделайте) а мы все оценим.

Спустя 2 года обновился плагин v2ray до версии 1.3.2 Releases · shadowsocks/v2ray-plugin · GitHub

В режие QUIC v2ray кто-то пробовал? Что-то с производительностью, при высокой нагрузке, например, видео HD, зависает, не грузит. Потом отвисает через какое-то время.

Я пробовал 2 года назад, производительность ниже, чем у websocket, поэтому не вижу смысла.

Видимо, с тех пор и не оптимизировали. Кстати, в форке GitHub - teddysun/v2ray-plugin: A SIP003 plugin based on v2ray реализовано с gRPC TLS. Особо разницы не заметил с WebSocket TLS.

Да, тут плагин активнее обновляется

Кстати, есть неплохой GUI. V2Ray-Desktop. И еще Qv2ray.
Shadowsocks, V2Ray/VMESS, Trojan.

Для простого shadowsocks: Shadowsocks-Qt5. Но для новых шифров надо собирать самому (с botan 2). На линуксе не трудно.

я ставил ShadowsocksR. Так получилось, что у меня оказалось два VPS сервера. Один от ihor, другой от FirstByte. Оба с европейским хостингом. Так и не смог выбрать какой-то один из них

Роскомсвобода сообщает:

Судя по всему продолжается тестирование блокировки протоколов VPN.

Наши друзья VPN-провайдеры сообщают, что пользователи из восточных регионов России (Алтай, Бийск, Омск, Новосибирск и другие) не могли подключиться к серверам с помощью популярных VPN протоколов, хотя при этом IP-адреса серверов VPN не блокировались.

Мы не знаем как Роскомнадзор оценивает эффективность этих блокировок, очевидно, что для РКН важно не только заблокировать VPN, но и не заблокировать лишнего. В любом случае к блокировкам популярных VPN-протоколов надо готовиться.

Поэтому не ждем, а готовимся!

VPN-провайдеры сообщают

с помощью популярных VPN протоколов, хотя при этом IP-адреса серверов VPN не блокировались

Это и есть блокировка на современном этапе. Блокируют точечно по содержимому. Трейсы, пинги, ssh такую блокировку не выявят.

У блокировки для всех есть конкретный недостаток — вывезут не все блокировщики. При переводе в stateless режим развалится всё оставшееся. Точечные блокировки скорее закончатся блэкаутом/ir,tm сценарием/белыми списками, чем блокировкой VPN-протоколов для домашнего сервера.

Да

Про блокировки протоколов VPN

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

А как подобную схему реализовать на lighttpd а не nginx?
Мне даже Cloudflare не нужен. Нужно лишь спрятать v2ray за адресной строкой.

Вот так

{
    "server":["127.0.0.1"],
    "mode":"tcp_only",
    "server_port":my_v2ray_port_number,
    "password":"my_strong_pass",
    "timeout":60,
    "method":"aes-128-gcm",
    "plugin":"/my_path_to_v2ray-plugin/v2ray-plugin",
    "plugin_opts":"server;path=/my_long_path"
}

# ssl-letsencrypt
server.modules += ("mod_openssl")
$SERVER["socket"] == ":443" {
  ssl.engine = "enable"
  ssl.pemfile = "/my_path_to_letsencrypt_cert_dir/fullchain.pem"
  ssl.privkey = "/my_path_to_letsencrypt_cert_dir/privkey.pem"
}

# v2ray-plugin-proxy
server.modules += ( "mod_proxy" )
$HTTP["url"] =~ "^/my_long_path" {
    proxy.server = ( "" => ( ( "host" => "127.0.0.1", "port" => "my_v2ray_port_number" ) ) )
    proxy.header = ( "upgrade" => "enable" )
}

В plugin_opts на сервере отсутствует опция tls (как и пути к сертификатам), т.к. функцию tls берет на себя lighttpd.
В клиенте опция tls естественно должна присутствовать.

На удивление, решение до сих пор актуально в условиях жесточайщего троттлинга YouTube.

Вчера вечером, около 20.30 прикрыли лавочку. Пришлось развертывать VLESS.

Кто?

Видимо, ТСПУ. Больше некому. На 2-х операторах одна картина.