Похоже началась блокировка Shadowsocks: Ставропольский край, проводной Ростелеком и мобильный Билайн.
Любопытно, что утром билайн дал пару минут интернета через SS, затем разом перестали работать все SS-подключения.
Попробовал с десяток разных серверов - не работают все, включая Shadowsocks-2022 (2022-blake3-aes-256-gcm). С теми же серверами по обфусцированным протоколам связь стабильная.
Tele2, чистый SS работает без сбоев.
в Дагестане начали блокировать голый Shadowsocks. работают пока что:
- WireGuard
- Shadowsocks+v2ray (fake tls)
- Shadowsocks+v2ray (quic)
Может быть не только shadowsocks, а весь нестандарт? Там на юге и телега легла (Telegram). Нужно исследование.
На 4pda многие говорят, что пинг есть, а многие SS не пашут. Белый список протоколов или портов?
Как любой DPI, умеет форсить порты для протоколов.
Но без дампов можно только гадать или ждать когда география белых списков увеличится (но похоже не в этот раз).
Пишут, пинг работает, смена порта на 443 не помогает. Помогает TLS. Все еще вопрос это блок именно SS (что должно быть трудозатратно) или нестандарта (белый список протоколов).
Пишут все носки (SS) перестали работать. То, что обещали, кстати. Насчет SS 2022 пока не ясно.
У SS есть одна особенность, запросы к серверу не мультиплексируются. Можно считать число подключений к паре адрес:порт и блокировать при превышении лимитов. Синтетические тесты такую блокировку не выявят. Например, при открытии браузером youtube, число установленных подключений к SS достигает 18, сам браузер открывает максимум 12 (числа взяты из эксперимента и могут отличаться).
Блокировка SS, методом curl через socks, в южных сетях не обнаружена.
Там же нет ICMP. Но может локально ответить процесс который делает tun2socks, если tun поднят. Ответа сервера не требуется. Можно опознать по времени ответа, будут единицы мс.
ЦФО, 500км от Москвы на юг. Веселье на локации с Mullvad:
До середины лета шевелилось “wg с защитой от квантовых атак”, иногда очень даже бодро, изредка и обычный wg пробивался, потом же любой wg сдох совсем.
Со вчерашнего вечера на той же локации перманентные отвалы OVPN-серверов, утром сегодня стало ещё веселее - начали отмирать один за другим OVPN-over-SS.
В той же локации у знакомых телега не пашет на мегафоне и еле2.
Касательно белого списка: Shadowsocks у меня всё ещё не работает, а AWG (Amnezia Wireguard) летает. При этом AWG - это просто Wireguard с дополнительными мусорными пакетами разного размера у разных клиентов. Это косвенно свидетельствует, что нет “белого списка” протоколов и как-то блокируют именно Shadowsocks.
С Хабра:
…согласно последнему GFW Report, детектировать Shadowsocks-2022 не умеют до сих пор даже китайцы, в итоге они просто в период обострений банят все протоколы, которые (не опознаны на DPI) AND (не похожи на простые текстовые).
Вполне возможно, что тут то же самое. Что ещё косвенно указывает на это: все началось вчера с попыток блокировок Telegram в проблемных регионах. У Telegram есть свои прокси, трафик до которых тоже выглядит как “fully encrypted traffic” без каких-либо явных сигнатур. Вполне возможно, что пытались грубым способом заблокировать Telegram-прокси, и из-за этого заодно случайно грохнули Shadowsocks (и ещё кучу всего другого неопознанного). Что объясняет тот факт, что у некоторых работают Wireguard и OpenVPN (которых блокировать научились и начали уже давно), но не работает SS.
Кстати, это же объясняет что продолжает работать AWG - Телеграм-то UDP не использует…
Краснодар, Билайн мобильный. Международные Wireguard, OpenVPN не блокируются. VLESS/Reality не блокируется. Внутрироссийский Shadowsocks-2022 блокируется. На клиенте передано ноль байт, на сервере логи пустые.
По ссылкам, на картинках живой vless.
Точно грохнули неизбирательно все, что попадало под критерии “подозрительного трафика”. Не работает Radmin (долго соединяется, безрезультатно), доступ к микротикам через winbox. С амнезией-WG или муллвадом все работает как часы…
P.S. И нормально работает внутри РФ через свои WG-тоннели.
Да, жалобы были от коллег на проблемы работы телеги через mtproto-proxy даже с ключом dd.
Насчет чистого SS не было возможности проверить, т.к. инфу заметил слишком поздно, а в моем случае SS работает в связке со своим же v2ray плагином в режиме TLS (fake-tls) и веб-сервером на фронтенде. Проблем не было.
obfs4 попал под блокировку?
Уже пару часов как у меня на проводе блокировки прекратились, на мобильном продолжаются.
какой провайдер?
Писал в первом сообщении:
Провод:РТ
Мобильный:Билайн
перестали блокировать примерно в 19:00 по мск. Telegram заработал, голый Shadowsocks тоже. во время блокировки наблюдались проблемы с доступом на некоторые ресурсы (mail.ru, dzen.ru, ok.ru). сейчас все ок.
И никаких подробностей. Хотя бы наблюдаемое в своей точке описали. Сколько сегментов пропускает, как блокирует, влияют ли порты, что считает за протокол, почему и когда нули помогают. Ничего.
Сообщения вида “не работает” можно на форумах пользователей почитать, их там больше, да и пишут чаще. Перезагрузитесь. И протрите экран.
у меня также все блокировки завершились
Краткие выводы, на основе сообщений. Первичные запрос – ответ как правило не деградировали (блокировали). Принятое решение сохранялось для новых, независимых сессий. Ложные срабатывания не отменялись для сессии с заведомо белым протоколом. Вероятно, речь идет о блокировках/разблокировках постфактум для пары адрес:порт. ТСПУ ведет журнал сессий, включая блокированные, где помимо всего фиксируют протокол/сервис. На основе этих данных ведут статистику, строят графики и отчеты. Возможно, эти же данные использовали для “блокировки” неизвестных протоколов. Методы проверки версии понятны.
- Протокол Shadowsocks на трансграничных узлах связи
Хватает мощностей анализировать на большом потоке данных?
Смотря, что они имеют ввиду. Мощностей определить тип трафика хватает, далее методом исключения. Хотя у трансграничных меньше информации, они как правило не видят входящий трафик. Впрочем, в происходивших ранее учениях (для других протоколов) на трансграничных точках принимали участия обычные провайдеры, и блокировали (не) нужное в пределах города/провайдера. Или когда дагестанские события блокировали на условном алтае, например.
Минтранс направил письма в адрес 381 организации транспортной отрасли от 10 ноября. Согласно ему, Роскомнадзор будет блокировать VPN-сервисы, использующие протокол Shadowsocks.
Его создали в Китае для обхода блокировок. В России будут запрещать его работу на трансграничных узлах связи. Также в перечень РКН попала российская программа ItHelper — это сервис для ускорения работы устройств со встроенным VPN.
*Чтобы не нарушить работу компаний, использующих VPN, ведомство запрашивает у них информацию об используемом софте. Из них составят «белый список» ПО, разрешенный к работе.
Глава Ассоциации малых операторов связи утверждает, что блокировка VPN, использующих функцию обфускации (прим. позволяет скрыть ваш VPN-трафик и использование VPN ), приведет к нагрузке на сети операторов и «неизбежно приведет к недоступности ряда легальных сервисов».
Откуда такие выводы? В письме Минтранса Shadowsocks не привязан к сервисам. С другой стороны, Shadowsocks, как протокол, невозможно блокировать выборочно.
Пиздят все, сверху донизу.
Впрочем, Глава Ассоциации малых операторов связи, похоже, всё правильно понял. РКН через Минтранс через утечку объявил о белых списках протоколов. Глухой телефон, который заслужили.
В комментариях к новости, обнаружили, что «VPN сервера в России» это название приложения. Быть может «Протокол Shadowsocks на трансграничных узлах связи» это тоже что-то конкретное.
Если у вас пропали (внереестровые) блокировки, не радуйтесь – вас анализируют. В X много сообщений о периодической работе без впн, и это только от тех кому (не) лень включать-выключать. Похоже, опять активировали сбор/анализ трафика на некоторых точках. На проводах тоже (~25%). Так зоологи изучают диких животных, разбивая площади на сектора и исследуя только часть. Они готовы жертвовать блокировками ради анализа. Значит будут блокировать по адресам, но потом. Интересно, в какой момент используют статистику (больше двух не собираться).
Склонна согласиться с тем, что они сейчас экспериментируют, нарабатывая базу. На локации в ЦФО (город миллионник, проводной ростелеком) внезапно полностью ожил Mullvad на несколько дней, и OVPN (UDP/TCP), и WG (UDP/TCP, SS-bridge). Позже обрубили полностью все хвосты (эксперимент видимо прошёл успешно), пришлось перекатываться на другой рабочий (пока что) вариант.
Помимо ростелекома (где встречалось чаще) наблюдалось на дом.ру, билайне, и множестве других региональных провайдерах. Похоже, как минимум один ТСПУ у каждого провайдера (филиала) не фильтровал трафик, и как минимум один фильтровал. Процент точек без (внереестровой) цензуры и ранее никогда не был нулевым, даже после заявления о 100% закрытии чебурнета, но на этой неделе было что-то необычное.
Мск, ростелеком
Наблюдал на текущей неделе проблемы со скоростью Upload на WG/SS/VLESS, причем на разных клиентах, начиная с роутера, заканчивая смартфонами и ПК.
Скорость резалась к 4 из 5 VPS серверов.
И что еще странно, заметил что при проведении speedtest без wg/ss/vless, и выборе не РУ сервера, а зарубежного, то на большинстве та же проблема с резкой скорости по Upload.
И еще более странно, что эта проблема сейчас решилась путем подключения статического IP. (других полезных свойств его для себя я не нашел - только минусы, особенно в излишней деанонимизации).
При выполнении команды tracert до зарубежных серверов (не моих), без белого IP начинаются пробелы начиная со 2 хопа, далее трассировка проходит примерно до 10-го, затем снова пробелы.
С белым IP 2 хоп проходит нормально, и также до 10, затем пустота.
Странные вещи творятся…
ну хотя бы спидтестовые серверы укажите
Наблюдения продолжаются, лишь меняются точки где идет эксперимент. Можно было бы добавить шума в свой трафик, так чтобы видел наблюдатель с ТСПУ, но игнорировал пир, но это был бы выстрел в ногу. Блокировки же трансграничные. Кроме того, как сообщают, списки адресов для блокировки (проверки на протокол и деградацию) начали отбеливать.
/del
На МТС проводном стал тормозить Outline shadowsocks.
При броузинге и загрузке файлов скорость в районе 250-400кбит.
SpeedTest показывает около 1.5мбит входящую, 25мбит исходящую на 100мбит канале.
Наблюдаются проблемы с подключением к ShadowSocks через Билайн, проблема наблюдается в Казани и Уфе. Проверяли на чистом SS и на Outline + Prefixing
Сервер SS не на этих площадках?
Сайты хостинг-провайдеров Amazon Web Services и GoDaddy заблокировали в России
Западная Сибирь Tеlе2, SS блокировки нет
Hetzner, из других операторов стабильно работает, проблема только с Билайном
Билайн в плане блокировок вообще особенный. Например, только на нем уже несколько месяцев с короткими перерывами не работает https://reddit.com.
Подтверждаю. Якутия, Уфа, Москва билайн есть проблемы с подключением к Shadow. Сейчас смотрим vless, как протестим апдейтну сообщение
UPD: с лесом порядок
У Вас MTPrоxy с параметром dd в Telegram работает? Это я к тому, что блокируют все неизвестное или SS научились блокировать.
Статистика по доступности протоколов есть, правда по мобильному трафику совсем небольшая
Билайн (мобильный):
1 сервер. Есть проблемы с чистым SS (нестандартный порт).
2 сервер. С плагином v2ray в tls режиме с веб-сервером на фронтэнде и строкой подключения (наличие параметра path) на стандартном для tls 443 порту проблем нет.
1 сервер. С плагином v2ray в http режиме без веб-сервера на фронтэнде, со строкой подключения (наличие параметра path) на нестандартном для http порту проблем нет.
2 сервер. Телега с параметром dd к MTproxy подключается и работает.
По проводу (не Билайн, т.к. его не использую для провода) с чистым SS проблем нет.
Добавил прослойку tun2socks: клиент <–> RU <–> EU: чистый SS заработал.
непонятно, клиент на билайне подключается к eu vps ss через сокс на ru vps? проще пробросить порт с ru vps на eu vps если блока ss при подключении к ru vps нет
Может и проще но слишком заметно, когда лишние порты.
У меня такая же схема - все подключения к ru-vps, далее сплит: ru в direct, остальное через ss/vless транки на другие vps…
лишние порты? слишком заметно? что?
Наблюдаются проблемы с подключением к чистому SS у оператора МТС начиная с 9:00 по МСК, Билайн также продолжает блокировку.
Всё так же интересует, ркн по ip блокировку выполняет или по протоколу SS. Сам не столкнулся с блокировкой, SS работает.
Очень большая просьба изучить вот этот тред outline-server keeps being blocked after a while using in china · Issue #1319 · Jigsaw-Code/outline-server · GitHub и проверить помогает ли использование префиксов
Как уже писал ранее, префиксы не помогают
Блокировка только на трафик вне РФ, соединение РФ-РФ не блокируется.
Запишите дамп и посмотрите, как конкретно блокируется.
У меня есть два сервера с OpenVPN + чистый SS + mtproto proxy. OpenVPN блокируется, SS и mtproto работает. Проверяла на Билайн моб. и стац.
Проверил SS - мобильный билайн, проводной Домру работают. Правда, использую mux(+UoT)…
На vps Питер+Москва трансграничный SS - работает.
Вероятно, частный сценарий использования SS попал под одно из странных локальных правил ТСПУ, если блокируют там. Не следуя этому сценарию вы блокировку не воспроизведете даже находясь за одним wifi. Сценарий может включать AS, адреса, порты, шифр (влияет на оверхед), использование tun, настройки TCP/IP стека, способ резолва адресов, проксируемые приложения, производительность DPI (пропуски <> нет-правила), что-то другое.
Докатилось правило блокировки до моего сотового оператора Tele2 Западная Сибирь.
Рукопожатие в SS проходит успешно. В браузере такое уведомление:
С N-ого нажатия “Обновить” страница загружается и начинает работать корректно.
Причем, когда страницы начинают быть доступны, speedtest показывает скорость ~ 20 Mbps.
Для Android какое приложение имеется, на подобии Wireshark? Сходу не нашел.
PCAPdroid. Но в Андроиде может быть только одно активное VPN подключение. Чтобы снифать внешний интерфейс нужен рут.
В SS нет рукопожатия: Protocol
Рута нет на телефоне…
А в приложении SS для Android оно есть 
Это хорошо. Но возможно это лишь рукопожатие HTTPS для тестового url.
Приложение можно настроить на прокси режим. Но тогда потребуется браузер умеющий общаться через прокси, например через расширения Foxyproxy.
У вас браузер когда обновился?
В NekoBox (который судя по скриншоту вы используете) используют HTTPS пробинг для определения работоспособности. По умолчанию это http://cp.cloudflare.com/ но в настройках(в самом низу где прочие настройки) это можно поменять. К протоколам проксирования трафика это не имеет отношения
Моб. Билайн. Владивосток.
Работает SS и SS2022 до Нидерландов
У кого наблюдается блокировка, использовался ли Shadowsocks2022? В панелях по типу x-ui теперь только он вроде как, а вот на счёт чистого, да и в целом, у кого что настроено не уверен
День назад. Одновременно таже проблема возникла и с приложением speedtest завернутым в SS.
Но этот запрос идет через поднятый SS туннель.
На DPIdetector появилось 2 стабильных мобильных (по версии сервиса, дом.ру там тоже сотовый) узла из Томской области, где периодически SS недоступен, включая РФ сервера (по версии сервиса). Кол-во успешных/провальных проверок периодически меняется. Код узла проверяет SS путем одиночного https запроса (Lua-cURL) через прокси (shadowsocks-rust-sslocal), повторяя с интервалом 5 минут (или по указанию сервиса). Детали, включая адреса серверов, выдают узлу при наличии токена.
Снял дамп, http запрос проходит через туннель SS до ntc.party
HTTP/1.1 301 Moved Permanently
Server: nginx/1.24.0
Date: Tue, 23 Apr 2024 19:00:39 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive
Location: https://ntc.party/
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.25.3</center>
</body>
</html>
после редиректа на https соединение закрывается.
Еще такой момент, на том же мобильном Tele2 при раздаче трафика на ноут, SS на ноуте работает корректно. Шифры используются одинаковые.
Сегодня чистый SS работает через мобильный Билайн штатно.
Проблем не наблюдаю.
На мобильном Теле2 проблем с чистым SS не было в принципе (пока они были на мобильном Билайне).
SS использую классический (не 2022).
Рукопожатие в приложении SS не показатель работоспособности туннеля SS. Особенно если SS настроен на работу через пользовательские правила.
Да, в этом и суть HTTP(S) пробинга(поднять туннель, проверить доступность ресурса заданного в настройках и дать вердикт о работоспособности туннеля)
Сегодня перестало работать. 2 - 3 хендшейка прошли, на следующие пишет что сервис не доступен (приложение андроид).
Смена порта на 443 не помогает, даже первый хендшейк не прошел.
Содержимое трафика они знать не могут, оно же шифрованное. Единственное, что можно предположить, что используются какие-то паттерны по последовательности пакетов определенного размера, которая проявляется при установке HTTPS соединения внутри туннеля. И вероятно, это может зависеть от браузера, его версии, применяемого в SS шифрования.
Однако, судя по описанию формата пакетов на оф.сайте, они должны быть рандомного размера для предотвращения подобного рода детектирования.
Правда с оговоркой:
The random salt and header chunks MUST be buffered and sent in one write call to the underlying socket. Separate writes can result in predictable packet sizes, which could reveal the protocol in use.
Может в каком-то из серверов и/или клиентов SS есть недоработка, вытекающая в предсказуемый размер пакетов?
Похоже и на это пофиксили блокировки.
Как понял в SS не всё шифруется, а часть данных. Возможно на это паттерны. Поведение такое, как-будто с dns-запросами проблемы возникают.
Блокируют на ТСПУ. Блокируют не только SS. Первое условие, помимо неизвестного содержимого: размер запроса.
На старом SS нет padding, но размер запроса зависит еще и от длины домена. Приложение может начинать с днс резолва (DoH через SS), а у SS сервера запрашивать подключение уже к IP адресу. Вероятность блокировки похожа на неизвестное распределение от 0 до MSS.Но в районе 600-900 байт блокировка стабильней. Блокировки сосредоточены вокруг определенных точек (100, 500, 600, 900 и прочее), размер ответа влияет на вердикт. Часть диапазонов блокируемых запросов требуют больших ответов. Похоже на попытку заблокировать только HTTP и HTTPS через SS, или трафик конкретного приложения.
Непонятно, влияет ли блокировка на последующие сессии, или это зависит от ТСПУ. Непонятно, влияет ли ответ.
Вы же пишете, что у вас http проходит, а блокировка после редиректа на https.
Чтобы подключиться с сайту, сначала должен пройти dns-запрос, только потом http-запрос, и после этого редирект на https, без повторного dns-запроса.
Меня смутил в дампе открытый адрес ресурса, хотя в настройках системы стоит безопасный dns, это именно после редиректа на https:
Спойлер
это https sni
Как понял в SS не всё шифруется, а часть данных.
Нет, в SS трафик шифруется целиком
Может в каком-то из серверов и/или клиентов SS есть недоработка, вытекающая в предсказуемый размер пакетов?
Насчет этого не слышно, но точно известно, что в некоторых SS-серверах (а возможно даже в большинстве) есть недоработка, позволяющая детектировать их через active probing: Active probing weakness found in the Xray implementation of Shadowsocks · Issue #625 · XTLS/Xray-core · GitHub (там длинное обсуждение, и оно далеко не только про XRay).
Плюс у Shadowsocks без дополнений есть особенность by design что он шлет TCP как TCP и UDP как UDP. То есть на один и тот же IP и порт будут подниматься TCP-сессии и летать короткие UDP-пакеты (как минимум DNS-запросы) - это очень характерный паттерн. И из-за этого же могут быть очень интересные глюки при блокировках, например, когда режут все неизвестные протоколы по TCP, но не трогают UDP, то через SS может открываться только часть сайтов (те, что используют QUIC), а остальные уже нет, ну и соответственно может быть и наоборот.
Именно поэтому советуют 1) использовать Shadowsocks-2022 вместо ванильного Shadowsocks 2) при использовании SS обязательно включать UoT (UDP-over-TCP), благо он сегодня поддерживается во всех приличных клиентах
Кстати, похоже правда про недоработку в ss клиентах: МТС в Мск похоже блокирует впн через outline (на ios сайты не открываются с ошибкой невозможности установки безопасного соединения, при этом работает инстаграм и телега), а через shadowrocket с тем же сервером все работает отлично.
Добралось до меня, исследую.
A post was split to a new topic: Неработоспособность ShadowSocks (25.04.2024 +)
Я опечатался, не “клиентах”, а “серверах”. На клиенте там сложно что-то не так сделать, на самом деле, скорее проблема в чем-то другом.
На Хабре буквально сегодня появилась статья про приколы с IPv6 при использовании прокси, больше похоже вот на это.
2022_blake3 это есть SS2022?
Поведение блокировок аналогично обычному SS описанному выше.
Йота/Мегафон. Блокируется shadowsocks-2022. Подключение проходит, но данные не идут. На проводном - работает.
Блокируются все неклассифицируемые (полностью зашифрованные) протоколы, если шаблон данных напоминает HTTPS.
Завернул shadowsocks-2022 в cloak, работает.
Причем, cloak на нестандартном порту, и этот порт не доступен на домене для редиректа.
Возможно ркн не использует active probing, либо тупо проверяет всегда 443 порт.
И?
Да, похоже блокировка доехала до Москвы. Наблюдаю у себя на МТС моб. и Билайн моб. На проводных провайдерах не наблюдается. Использую чистый SS, сервер shadowsocks-libev, клиенты классический Shadowsocks и Nekobox.
Блокировка наблюдается именно при попытке открытия https сайтов. Причем блокировка не 100% - иногда проходит соединение, иногда - нет, что на это влияет - не понятно.
А блокировка при этом воспроизводится из этой темы?
Есть нюанс. Блокировка из той темы воспроизводится, но только на проводном интернете. А блокировка Shadowsocks, наоборот, только на мобильном.
А блокировка ShadowSocks при этом на проводном есть?
Нет, блокировки Shadowsocks на проводном интернете - нет.
Проверяла в Москве: Билайн и Ростелеком проводные - блокировки нет, Билайн, МТС и Мегафон мобильные - блокировка есть.
Вчера настраивал VLESS+Reality на сервере, на котором до этого работал VLESS+TLS. Столкнулся с блокировкой протокола на мобильном Билайне. На фиксированном Билайне все работало ок. Откатился обратно на VLESS+TLS.
Можете показать конфиг с которым не заработало reality?
Что именно вам показать? Это стандартный конфиг с reality из 3x-ui.
del
Тоже провела эксперименты. Подтверждаю, Shadowsocks внутри РФ тоже не работает. Одновременно с этим замечено, что на IPv6 блокировок нет, как внутри РФ, так и зарубеж. Проверялось на мобильном МТС, на IPv4 все блокируется, на IPv6 - нет.
Мне кажется про обычный Shadowsocks давно пора забыть было уже тогда, когда китайцы научились его детектить и блокировать…Смысл поднимать его на ВПСнике и светить его айпиадресом…на нем потом не развренуть будет скорей всего что-то более устойчивое из текущих инструментов т к он уже в блэклисте будет…
Вопрос остается что с Shadowsocks-2022? Я так понимаю пока его не определяют,но просто тупо блокируют все неопознанное на время ЧП ( как в Дагестане) и тем самым кладут и 2022 ?
Судя по последним сообщениям в теме, тут не только Shadowsocks (включая Shadowsocks-2022), но уже и VMESS, и даже VLESS задели. И все это очень тревожно. На роутере или ПК можно пока что-нибудь придумать (я, например, сейчас экспериментирую с DTLS в качестве транспорта), а что на мобилках делать, не очень ясно.
Да, еще одно наблюдение. На ноуте, подключенном к мобильному интернету, никак не удается воспроизвести блокировку. Чистый Shadowsocks, клиент NekoRay, Пробовались разные варианты: ядро xray и sing-box, режим tun и socks, браузеры Firefox, Edge, Chrome, и при этом все работает. В то же время на смартфоне, с которого раздается интернет, блокировка воспроизводится мгновенно и практически гарантированно.
- Какой домен использовался для маскировки? Пробовали ли другой?
- Задан ли TLS fingerprint в клиенте (uTLS), если да - то какой? Пробовали ли другой?
- Включен ли XTLS-Vision?
- Какой конкретно клиент использовали, версия ядра? Пробовали ли другой?
- Какой alpn задан в клиенте? Если никакой, то пробовали ли задавать например “h2”?
Это все к тому, что Reality имеет свою специфику, и в большинстве случаев то, что выглядит его блокировкой, на самом деле блокировкой не является, а вызвано совершенно другими причинами.
Чтобы точно знать в чем дело, нужно хотя бы иметь логи клиента и логи сервера в моменте подключения, там уже можно довольно много что увидеть, а в идеале ещё и дампы трафика.
и даже VLESS задели
Пока что все встреченные панические сообщения о блокировке VLESS оказывались либо кривой настройкой клиента/сервера, либо проблемами/блокировкой у сайта, под который маскировался сервер
но уже и VMESS
VMESS без дополнительных тнанспортов по принципу очень похож на ShadowSocks, поэтому блокировка одного в большинстве случаев будет сразу означать и блокировку другого, это ожидаемо.
а что на мобилках делать, не очень ясно
KCP (под uTP или DTLS), Hysteria2 (с Salamander) или банальный SSH
- google.com, другой пробовал, без изменений.
- да, chrome, другой не пробовал.
- да включен.
- использовался v2rayNG, версия 1.8.22 и nekoray последней версии.
- h2,http/1.1
Если бы соединение вообще не устанавливалось, можно было бы ожидать, что проблема в настройках. Но когда по Wi-Fi все работало, а при включении мобильного интернета связь сразу обрывалась, напрашиваются определенные выводы.
Логов сервера не осталось случайно?
Сервер не фиксировал подключение клиента через мобильную связь. Логов не осталось.
См. последние сообщения в этой теме. Например так 2024-05-09T21:00:00Z curl виснет после отправки Client Hello:
curl -kv https://google.com --connect-to ::2.19.183.45
curl -kv https://aaa.com --connect-to ::2.19.183.45
Но не так
curl -kv https://aaa.info --connect-to ::2.19.183.45
curl -kv https://aa.com --connect-to ::2.19.183.45
Да, речь только про мобильный Билайн.
Кстати это неплохо объясняет, посему у комментатора выше не работал Reality. Но тут, само собой, дело не в блокировке протокола.
У меня на мобильном Билайне блокировки Shadowsocks прекратились, как внутри России, так и за границу.
У меня пока везде сохраняются.
Похоже временно отключали блокировки, сегодня опять не работает.
Подтверждаю. На десктопной йоте ss работает. На планшете тот-же ss не заводится в приложении Shadowsocks. Сайты не открываются, тест не проходит. Причем трафик какой-то бегает исходящий и входящий в статусе программы Shadowsocks, но показывает ошибку что-то типа end of stream или end of file, не помню. Вот здесь внизу (скрин просто для примера).
Как им это удалось непонятно.
Тариф Йота для модема. 4G модем для дома.
Десктоп (Linux) подключается по Ethernet к модему.
Планшет подключается через раздачу Wi-Fi модема.
Psiphon и Lantern работают, но медленно.
Из трех носков работал только один. Обновил Shadowsocks (без рекламы). Уж не знаю какая версия была. Стала 5.2.6 от 2022 года. Все носки заработали. Поставил Nekobox с GitHub. Тоже все ss, vless, vmess работают. Видимо блочат fingerprint старых клиентов.
Может, это вообще не блок, а какая-то несовместимость со старым клиентом.
Тут все очень просто. То, что “Connected” клиенты обычно пишут без реального подключения к серверу. Клиент начинает устанавливать подключения к серверу только когда какое-то из приложений пытается что-то сделать, а до этого момента он сидит и тупо ждёт, но при этом показывая Connected.
Плюс в ванильном ShadowSocks (без UoT) UDP передаются как UDP, а TCP как TCP. Режут обычно только TCP, а UDP по-прежнему работает, поэтому у вас передается какая-то часть информации туда-обратно (DNS-запросв и возможно QUIC), а остально уже нет. Поэтому вы видите часть переданного и полученного трафика, но в итоге ничего не работает.
Может, это вообще не блок, а какая-то несовместимость со старым клиентом
Может у вас на сервере шифр с “2022-” настроен? Старый клиент их не поддерживает.
Шифры chacha20-ietf-poly1305 и aes-256-gcm. Причем, в старом клиенте один носок с aes-256-gcm работал, а другой носок с aes-256-gcm нет.
Т.е. старый клиент:
- ss1 с aes-256-gcm - не работает
- ss2 с chacha20-ietf-poly1305 - не работает
- ss3 с aes-256-gcm - работает
Новый (2022) клиент и Nekobox:
- ss1 с aes-256-gcm - работает
- ss2 с chacha20-ietf-poly1305 - работает
- ss3 с aes-256-gcm - работает
Да, но я жму “Test”. Shadowsocks клиент должен отправить тестовый запрос, только не знаю по https или http. И вот тогда были ошибки, в браузере тоже.
А DNS разве не перехватывается и в TCP (socks) не превращается?
При нажатии “Test” несколько раз.
Для сравнения, в wireguard 0 во входящих сразу говорит о блоке.
есть возможность проверить ss на втором мобильном устройстве, на которое раздается интернет с другого мобильного устройства?
К сожалению, не получится. Думаете про ttl?
Мне кажется, в моем случае это все-таки не блок, а какая-то несовместимость. По моему, проблемы с коннектом и раньше были в том приложении.
И ведь один ss работает и я не в Мск/Спб.
У меня как раз новый клиент Shadowsocks и Nekobox, и там, и там SS на мобильном интернете блокировалось.
Но в одной из старых версий клиента Shadowsocks действительно была проблема с коннектом, при попытке соединения могло отображаться что сайт недоступен. Но этот баг давно исправлен.
Новый клиент версии v5.3.3 ?
В Google Play старая версия клиента почему-то.
У меня вот эта версия https://play.google.com/store/apps/details?id=xyz.truenight.shadowsocks 5.2.6 от 14 нояб. 2022 г. Соответственно, была старее.
Сайт не показывает, а в Google Play на андроиде в описании указано, что версия без рекламы и телеметрии, поэтому я ее и ставил, не так-то просто было найти версию без рекламы. Но клиент неофициальный.
Я вижу, что всего 50 тыс.+ скачиваний вместо 5 млн.
Upd. Исходный код проги:
https://frolov.dev/projects/shadowsocks
https://github.com/TrueNight/shadowsocks-android
Старых бинарников нет. Но можно увидеть какие компоненты используются (shadowsocks-rust) и собрать самому в docker для теста.
унимание! не обоновляйте nekobox клиент для ондроеда как мин. из магазинов преложений сами разрабы писали в своей телеге что они потеряли доступ к акаунту и теперь какиейто левыйе лбюди выкатывают обновления, сейчас там только реклама (вредоносно нету покачто))
нет, про ttl не думал. была мысль, может оператор подменяет маршруты через dhcp
Запишите трафик в PCAP и посмотрите, соответствует ли сессия блокируемым шаблонам. Без анализа трафика наощупь гадать бесперспективно.
Ха, там все сложнее работает. Клиент использует API операционной системы для DNS, соответственно оно пытается послать UDP-пакет на DNS-сервер. Он попадает на TUN-интерфейс, там работает что-то типа tun2socks, и в итоге да, открывается SOCKS-подключение к shadowsocks-клиенту, оно TCP. Но сам shadowsocks-клиент видит, что ему через SOCKS пытаются отправить UDP-пакет (в SOCKS-протоколе для этого признака специальное поле есть), и поэтому шлет его на прокси-сервер как UDP.
Вот и получается, что когда фильтруются только TCP-подключения, UDP у вас на прокси бегает нормально (домены резолвятся, какой-то небольшой трафик считается), а когда дело доходит до HTTP или HTTPS, так всё.
So is there a way to make Outline work again? Stopped working for me 2 days ago.
Yes. Run on a high port number, or pick a different cloud provider.
I’m not using any of the large cloud providers. I still can ping my server or connect using SS-2022, but when trying to connect using Outline, it just says that the key is invalid. It uses the port number in 30000, so it’s already high enough.
Значит, надо чтобы сначала через shadowsocks побегал какой-нибудь легкий протокол, может мессенджер. А потом, когда проверка отстанет, пускать сайты (или openvpn поверх).
Хотя, как раз на мобильных системах это проблематично из-за tun/vpn характера подключения на местном уровне и фоновой активности приложений и системы.
Т.е. стоит только shadowsocks приложению соединиться с сервером и поднять tun в системе, кто-нибудь непременно отправит https запрос.
На нормальных системах в прокси режиме это можно проконтроллировать.
Shadowsocks это прокси без мультиплексирования соединений. Это не VPN. На каждое соединение от программы создаётся TCP-соединение до прокси-сервера.
Да, но на местном уровне на анроиде это выглядит как псевдовпн, поднимается tun. Все приложения туда отправляются. Использовать shadowsocks в режиме локального прокси на андроиде можно, но весьма нетривиально. И мало какой софт там прокси поддерживает, даже браузеры. Все через tun делается.
VPN терминируется локально, на самом телефоне. Сетевой трафик между телефоном и сервером точно такой же, что и без использования VPN. Соединения не мультиплексируются.
На серверной части да. Но я имел в виду, что на андроидах даже proxy based приложения работают как vpn (локальные). И стоит только такому vpn подняться, какое-нибудь фоновое приложение отправит https через shadowsocks, те же гуглопуши и провайдер заблокирует. А когда на десктопе shadowsocks клиент поднимает локальный прокси, о котором мало кто знает, можно проконтроллировать чтобы только нужные приложения туда ходили. Пустить сначала какой-нибудь мессенджер через прокси. Он мелкие пакеты будет отправлять (вернее shadowsocks по его запросу). Проверка отстанет. А потом можно и браузер, настроенный на прокси запустить. Но такое легко проделать на десктопной системе. А ведь блок в основном на сотовых операторах. Значит, имеет смысл только если десктоп пользуется мобильным интернетом. И это все имеет смысл только если провайдер (или тспу) проверяет только первые несколько пакетов. Я о том, что tun неконтроллируемо пускает всех, а прокси выборочно. Хотя, на андроидах есть раздельное туннелирование.
Проверяется каждое соединение, блокируется соединение, а не IP-адрес. У вас будет работать условный мессенджер, но не веб-сайты.
Кстати, про мультиплексирование уже не раз упоминали в контексте детектирования.
Если у вас и на клиенте и на сервере XRay (там есть mux.cool), или и на клиенте и на сервере Sing-box (там несколько типов mux, можно потестировать, какой лучше), то можно включить мультиплексирование на клиенте, и оно будет работать даже с Shadowsocks. По умолчанию там стоит мультиплексирование до 8 соединений в одно, при необходимости можно увеличить.
Ну и UoT (UDP-over-TCP) заодно включить (оно есть и там и там), как раз сначала будут пролетать легковесные DNS-запросы.
A post was merged into an existing topic: Неработоспособность шифрованных протоколов (ShadowSocks/VMESS) (25.04.2024 +)
Из интересного. Настроил неделю назад vless-tls-gRPC через CloudFlare. Свежекупленный домен, всё такое. Раздал примерно 10 знакомым. Пользовались мало, всего около 15Gb трафика пока что.
Сегодня заблокрировали на мобильных операторах (мегафон в частности), по земле нормально.
Заблокировали по TLS SNI.
Если в Hiddify включить TLS Fragment, то соединяется нормально.
Дальше не разбирался пока.
У нас через Мегафон на майских отваливался vless-reality на хостинге DO, фрагментация не помогала, при этом shadowsocks на высоких портах работал, по 443 тоже глухо было. Потом на неделю блокировку сняли, потом неделю опять по 443 глухо, вот сейчас снова работает.
На мтс все это время влесс продолжал работать.
До этого примерно с февраля влесс в такой конфигурации спокойно работал.
Ну так может в этом и дело? А не во vless+reality блокировке
Да, скорее всего проблема была с блокировкой по vless+хостинг, а не просто vless. Но не чисто только хостинг - SS на высоких портах на этом же сервере продолжал работать
SS начали блокировать, входящий трафик?
На стороне сервера отображается что соединение устанавливается c клиентом:
IPv4 TCP server:port->client:port (ESTABLISHED)
IPv4 TCP server:port->client:port (ESTABLISHED)
upd: MTProto так же отвалился за компанию.
upd2: Webtunnel в ту же компанию попал.
Пишут, что в уральском регионе на мобильных Теле2 и Мегафон блокируют.
Добавление coли помогает обойти блокировку у кого-нибудь?
Интересное состояние: на одной sim-карте отпустили блокировки, на другой sim-карте продолжаются блокировки. Оператор один и тот же.
Похоже на A/B-тестирование. Префикс TLS ClientHello на всякий случай себе добавил, а вам помогает?
Добавил так же, но понять не могу помогло ли, исходя из ситуации описанной выше.
Пора уже осознать что концептуально голый SS устарел и надо смотреть в сторону Reality. Благо в настройке он не сильно сложнее
Я его использую в бесплатном nthLink, выдаёт стабильные 25 Мбит/с. Себе, конечно, я его настраивать не буду.
Но почему-то вместе с блокировкой SS у роскомпозора падает остальное практически всё
Снова данное правило на тспу включили для ss.
Подтверждаю для SS + prefix , но наблюдаю только на мобильном МТС Петербург и проявляется в виде timeout dns запросов, но не всех, часть сайтов например за Cloudflare открываются нормально. На Ростелеком в Питере всё ок на тех же серверах
Мегафон СПБ тоже сегодня отвалились все серваки ss никак не связанные между собой.
Подтверждаю, мтс спб, ss из панели 3u-ix не работает пинг сначала проходит, потом отваливается. Перезагрузка сети и минут через 5 снова отвал.
Outline перестал работать без префиксов. С префиксом работает.
Подтверждаю начало блокировки SS. У знакомого из СБП (мегафон) отвалился. Помог префикс.
Подскажите, как прописать префикс в json конфиг некобокса или хидифай? При копипасте конфига они просто игнорируют его / не парсят. Стандартный аутлайн клиент применяет префикс, но в нем весь трафик заруливается, а это неудобно.
Наверное это уже не так. В омске недавно блочили SS и роняли вместе с ним телегу. В СБП блочат SS и при этом телега не страдает.
Подтверждаю блок ss (в Nekoray). Yota Новосибирск. Вот это да.
Работают только http сайты (браузер Basilisk). Но openvpn tcp:80 через ss не пролез (ошибка EOF).
Однако tor over ss со скрипом всё-таки пролез. А когда пролез, то уже не тормозил. Видимо TLS операции только при начальном коннекте используются (при установлении связи с сетью tor).
А вот arti, натравленный на ss (
proxychains arti proxy) неживой. Безуспешно бьётся с такими же ошибками EOF. Я так понимаю, надо слинковать не с openssl, а с чем-то поменьше, вроде libressl.Это я к тому, как можно оживить ss, чтобы не только http сайты работали.
А можно для непосвящённых, что за префикс? И можно ли его настроить если сервер 3x-ui и клиент nekobox?
Спасибо.
upd: добавление префикса мне не помогло по итогу.
Нет, как я писал выше большая часть DNS запросов внутри Shadowscoks уходит в timeout
За исключением сайтов за cloudflare
Не понял. Т.е. трафик можно гонять внутри SS, но дропает ТОЛЬКО резолвинг?
Ну тогда можно просто резолвить через DOH. На моем примере такого не было. Префикс помог и всё рабоатет.
Да именно резолвинг, на iOS doh не помог
Возможно конечно дело в кривом префиксе, но пробовал разные. Какой у вас заработал?
И да, проблема ТОЛЬКО на мобильном МТС. Но любом проводном всё ок с префиксом
Ну не у меня, а у знакомого из спб: %16%03%01%00%C2%A8%01%01 У меня на ТТК в ЮФО пока и без префикса ок.
Если просто вклчючить в ios DOH, через него же не пойдут запросы, когда запущена прокся. Надо что-то в клиентах пердолить. Плюс другие приложения могут, как в проксю резолвить, так и в системный днс. Я не шарю, для меня это все сильно непредсказуемо выглядит.
Если у вас не работает shadowsocks, пустите поверх него tor или psiphon. Не очень хорошее решение, но лучше, чем ничего.
А префиксы не настроить без доступа к серверу? В Nekoray, Hiddify и Outline клиентах я не видел такой настройки.
Upd: Занимаюсь извращениями. Настроил такую цепочку:
- провайдер - shadowsocks FI - tor - openvpn tcp FR - браузеры и пр. клиенты
tor очень долго устанавливает соединение (зато потом работает нормально) и даже может зависнуть и не завершить коннект. Тогда ему помогает забутстрапиться временно включенный psiphon (cli), ведь он чувствует себя в такой среде гораздо лучше, но т.к. IP shadowsocks нероссийский, psiphon ограничивает скорость до 1 мбит/с - провайдер - shadowsocks FI - psiphon - tor (временно)
Характеристики такие. Тариф 3 мбит/с (обычно скорость 2.5 мбит/с)
После цепочки 1 получается 1.7 мбит/с (даже в однопоток)
Пинг до google.fr 300 мс
До yahoo.com (США) 400 мс
До jahoo.jp (Япония) 500 мс (ощутима видна задержка)
Вот до чего я докатился в РФ. Сначала было:
- openvpn, потом за ним пришли, но я молчал
- shadowsocks - openvpn, пришли за shadowsocks (с tls внутри), но я молчал
- shadowsocks - tor - openvpn
Россия вперёд! Симонян: Ютуб капут. Ибо неча.
Скажите, зачем мне openvpn tcp FR? А он предоставляет очень чистый IP, т.к. малоизвестный, даже википедию позволяет редактировать. И открытый порт (у самого провайдера такого нет), aMule получает HighID. Вот и думай, нужно ли бороться за такой openvpn.
У меня также есть свои сборки tor-nss и tor-libressl (для сборки с libressl нужен патч, можно найти в gentoo). Но особой разницы нет.
Лучше было бы настроить vless - openvpn, конечно, но ведь я не ищу лёгких путей. К тому же, долгоживущие публичные vless мне не попадались. Или выкинуть shadowsocks и использовать obfs4+tor, но obfs4 мрут как мухи.
openvpn блокируют? Я понимаю, что он лекго детектируется и блокируется. Но блокируют ли его на практике? Этот протокол ведь широко используется организациями.
У меня Йота, мобильный провайдер, хоть и на десктопе. Это осложняет дело (зато, с YouTube повезло). Сначала openvpn блокировали до разрывов. Потом какое-то время работало. Потом скорость срезали до неприличных величин (16 кбайт/с, вроде), внеся потери в пакеты (tcp и udp). Работает openvpn с tlscryptv2, кстати, который предоставляет hideme. С третьей попытки. Но я давно не проверял.
Надо бы освоить zapret, всё-таки.
Upd: Сейчас проверил, openvpn работает на Йоте норм. А 1.7 мбит/с это скорость vpn, потому что он живёт на донаты.
Upd 2: Вечером срезали скорость openvpn до 16 кбайт/с, а повторный коннект не удался.
Проводной Билайн и сотовый Мегафон в Москве тоже заблокировали SS без префикса.
Верно, поэтому блокируют, за исключением трафика внутри России.
Ранее я писал, что префикс помогает на домашнем мегафоне в СБП. И вот сегодня/вчера заблочили SS на мобильном мегафоне в волгограде. Префикс уже не помогает. Проверял на двух серверах в разных хостингах.
Мобильный тоже блокирует
Кстати, obfs4 тоже подзадела охота на shadowsocks и нераспознанный трафик. В логе тора есть ошибки failure, а в Wireshark встречаются RST пакеты, хоть obfs4+tor и работает с варнингами.
Или в телеге изменили паттерн или ТСПУ сделали менее агрессивным. Может, IP Telegram в white лист внесли. Нешифрованные http сайты вот через заблокированный shadowsocks работают, и то не всегда. Иногда надо обновлять страницу.
Да, здесь были сообщения, что у кого то уже и prefix не помогает.
Но все же, может кто то встречал реализацию prefix для клиента SS-libev для OpenWrt?
Только запустили прокси на shadowsocks и тут пошли блокировки, в основном москва и питер. Думали что делать, нашли решение в установке плагина v2ray поверх ss, все заработало, даже скорость особо не жрет
Но невозможно найти бесплатный клиент на IOS с поддержкой плагинов поверх протоколов, в частности ss, если кто-то такой видел — посоветуйте плиз
Скажите пожалуйста, как именно добавить префикс и где?
Добавить &prefix=POST%20 в конце ссылки. Например:
ss://AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA@123.123.123.123:36174/?outline=1&prefix=POST%20
Вместо POST%20 можно использовать другие префиксы. Вот здесь написано подробнее:
https://old.reddit.com/r/outlinevpn/wiki/index/prefixing
То есть, в клиенте Outline нужно добавить новый сервер через эту ссылку.
Надо обязательно ставить Outline клиент? Nekoray не подойдёт?
Outline клиент хочет root на линуксе. Он работает как псевдовпн вместо локального прокси? Никак не заставить его работать как прокси?
Я только на Outline тестировал.
В мск теле2 начал блочить shadowsocks. Товарищи, какие варианты есть обойти блокировки с мобильного интернета?
На домашней сети МГТС всё работает (видимо пока)
Стек:
Чистый shadowsocks-libev на сервере за бугром.
Клиент на мобиле shadowrocket
Клиент на десктопе ShadowsocksX-NG
я не очень понимаю, почему вы используете свои ВПС для шэдоусокса… Он еще до Ростелекома в китае блокировался успешно… а SS2022 не переживет блокировки по белым спискаам протоколов… Пора уже давно переходить на полностью рабочие враианты с xtls reality+резерв c mkcp
Outline у меня не запускается после root пароля при установке соединения, пишет: “не удалось запустить Outline”. Дурацкая прога, вообще.
Nekoray и shadowsocks-rust судя по всему префиксы не поддерживают.
В копилку - с 6 Августа не работает Outline у моих “клиентов” в Мск (Ростелеком), Спб (не знаю провайдера) и Самара (Мобильный Билайн). Перепробовал много комбинаций портов + префиксов, ничего не помогло.
Помогло только завернуть outline трафик через vmess туннель между РФ VPS и НЕ РФ VPS.
Тоже от себя добавлю, мои носочки на Теле2 Москва, все, продырявились, добавлял теги, помогало частично, ходил трафик телеги, http (s) нет. На МГТС все хорошо. Время переходить на vless reality
Shadowsocks на смартфоне блочат последние несколько дней(соединяется но трафик практически не идет). Билайн. Иваново. Что удивительно обычный OpenVpn работает прекрасно.
То что уже легко блочится сейчас не блочат. Изучают и добавляют рубильники на новые протоколы…
Вчера SS везде заработал - либо эксперимент не удался, либо все мощности ушли на блокировку Ютуба.
Vless Reality ведь тоже легко выявляется, не панацея.
откуда информация?
TLS-in-TLS, но для этого нужно много ресурсов. Я пока не слышал чтобы кто-то применял это.
Тут интересно описывают The Internet censorship bibliography (Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes)
А тут какой-то китаец написал прокси, для обнаружения прокси)
GitHub - XTLS/Trojan-killer: Detect TLS in TLS.
легитимный - https, так и фингерпринт браузера…
xtls reality не так работает.
Где-то в одной из инструкций читал. То есть, не сам reality определяют, а то, что сервер используется для него, определяя по неким паттернам.
У меня один vps с reality попал в какие-то списки, периодически глушат до невозможности использовать. Переехал на новый.
Xtls как раз отключает TLS-in-TLS и не перешифровывает трафик, котрый уже https. Сервер vless себя никак не выдает. Поймать могут двумя простыми методами - через сервер гонится весь трафик без разделения ru - not ru. Да, палят по маячкам, банкам, ВК и прочим адептам. Либо еще проще - на сервере поднят и используется параллельно другой протокол, например Shadowsocks с включённым UDP портом., который видят сканом.
Ни один сервер на vless пока не спалили, а вот на SS бывает.
Мегафон северо-запад. Ничего не заработало.
На стационарном Ростелекоме и мобильном МТС в Москве:
SS до сих пор работает (в выходные наблюдал проблемы).
Как будто бы есть некоторые проблемы со скоростью, вот не прямо замедление, но что-то такое.
Подтверждаю, в СПб на МТС ss блочится и по ощущениям как будто на некоторое время ip попадает в блок
Домру, ЮФО.
В последние месяцы использовал privateinternetaccess со встроенным там shadowsocks.
Недели 2 назад shadowsocks отвалился полностью. Переключил на время на собственный собственный сервер в Нидерландах с socks5. Несколько дней работало (на удивление, учитывая протокол) потом наглухо тоже начало падать по большинству выходных нод. Часть продолжает работать и через socks5. Выглядит странно, будто что-то недосмотрели, либо Будто для популярных vpn ведётся отдельный список, и если что-то из списка замечено - ломает. Настроил shadowsocks на своём же сервере - из РФ не работает сразу же.
МГТС видит и блокирует v2ray (xray) через ShadowSocks, пару дней назад начал в Москве. На мобильном МТС все нормально.
Shadowsocks с prefix POST%20 перестал грузить видео на YouTube (по сообщениям пользователей, сам не могу проверить) – это вообще возможно? Другие сайты открываются
Tele2, Пермский край
Также могу подтвердить, что МГТС Москва блокируют IP после обнаружения SS. Ping проходит, SSL на порт 443 и даже 8001 - нет. Когда (если) разблокируют - постараюсь отловить сроки. Заблокировали часов 6 назад, все еще не работает.
Со вчерашнего дня на мобильном Мегафоне блокируют SS сразу после подключения, первый тест в клиенте проходит и дальше пакеты перестают доходить до порта сервера.
Другие сервисы не затрагивает и повторяется в 100% случаев на двух независимых серверах без префикса. С префиксом или через других провайдеров пока работает.
У меня пока Shadowsocks + obfs работают нормально на мобильном Билайне.
Притом чистый Shadowsocks блокируется и еще блокируется мобильный браузер Mozilla, похоже его TLS fingerprint не пропускают, а Chrome работает нормально.
Ещё не появилось сторонних клиентов с поддержкой префикса? Может есть патч для мобильного shadowsocks, куда можно захардкодить префикс?
Outline тормозное говнище без сплит-туннеля и IPv6.
Есть новости?
Отловить забыл, но сейчас все работает. Значит, блокировка все же временная, если не пытаться ломиться на домен снова.
Мобильный МТС Москва. Докатилось до меня. ss-libev в Германии блочится глухо (коннект есть, handshake не работает). Такой же ss-libev в датацентре в Москве работает. При этом залогиниться на сам сервер в Германии проблем нет, то есть адрес не блочится.
Получается, что блокировка на каких-то магистральных точках? Если маршрут локальный, местные ТСПУ как-то по-другому настроены?
И работает сейчас например Cloak поверх ss-libev?
МТС Москва, SS не работает ни на домашнем, ни на мобильном интернете. SS2022 работает стабильно на домашнем и мобильном.
Йота, мегафон, Теле2 Москва. Ss отвалился сегодня наглухо. Друзья на мегафоне говорят что у них уже как неделю нестабильная работа.
Vless вроде дышит но есть ощущение что впска в ЧС попала и время от времени ее поддушивают.
На домашнем что удивительно оба протокола ок (алмател).
“Сибирские сети”. Кемеровская обл.
SS, SS-22 уже месяца 2 лежат. По схеме: могут пройти первые пару запросов и потом мертво, через какое-то время может опять пошевелится и опять в даун.
VLESS живой.
Бонусом все гугловские сервисы в вечернее время умирают.
ТП все отрицает.
DPIdetector сообщает о новых блокировках и разблокировках VPN-протоколов в России:
Shadowsocks теперь часто блокируется и на домашнем интернете при трафике зарубеж (месяцем ранее его активно начали блокировать на мобильном). Блокировка фиксируется в большинстве регионов РФ, независимо от оператора связи.
На github подсказывают, что на портах 5222 и 80 Shadowsocks доступен, а добавление префиксов, хоть и не всегда, но помогает обойти блокировку.
Источник - Telegram: Contact @ru_tech_talk
Shadowsocks теперь часто блокируется и на домашнем интернете при трафике зарубеж (месяцем ранее его активно начали блокировать на мобильном)
Snowflake опять начал приростать пользователями в России.
А у вас какие изменения за последние несколько дней?
У меня на йоте shadowsocks (ss) давно заблокировали по протоколу. Работает только если внутри гоняется http. *
80 порт shadowsocks сервера не помогает.
Snowflake работал и ранее, но в логе было много варнингов.
* Там не полный блок, смотрят размеры пакетов и дропают, если подозревают внутри https (особенность openssl). psiphon пролезает через ss. Хотя, в этом мало смысла. Т.к. у ss обычно IP нерусский, а бесплатный psiphon для нерусских IP ограничивает скорость до 1 мбит/с. Однако, учитывая, что psiphon с дефолтной конфигурацией тоже в блоке, даже 1 мбит/с это лучше, чем ничего. Хотя, учитывая, что я на линуксе, psiphon у меня только консольный, может быть не с самым оптимальным конфигом (который я нашёл в интернете). Может быть официальная GUI сборка ведёт себя лучше. Имею в виду, в чистом рунете. Я подчёркиваю с дефолтной конфигурацией. Недефолтные работают в обычном рунете, если явно указать сервер, но не факт, что многие люди это умеют. Но это так, отступление. Чтобы понять есть ли смысл гонять psiphon через ss.
Также через ss удаётся пролезть тору, если он пройдёт bootstrap. bootstrap очень тяжёлый, долгий и болезненный, не всегда успешный. Процентов 80 нод отваливается (end of file), но это так примерно. У свежебутстрапнутого тора (который бутстрапился через чистый интернет) вероятность коннекта выше. После установления соединения с сетью tor, он работает совершенно нормально через ss. Хотя, варнинги проскакивают. Tor как известно тоже активно блочится в РФ. Так что однажды его заведя через ss и не выключая комп и ss, видимо он будет работать. Разве что в этом есть какой-то смысл такого использования.
Всё это я говорю затем, чтобы дать понять, что блок ss не полный. А вот имеет ли смысл гнать через ss другие протоколы, чтобы обойти этот блок (или настроить себе нормальный vless) это другой вопрос. У всех людей разные технические навыки и возможности. Возможно, кого-то заинтересует такое использование. Я же тестил только для интереса. Префиксы хорошая идея, но это только в Outline.
Могу сказать что SS конфигурация от VPN Generator работает на мобильных и проводных провайдерах, на текущий момент, без блокировок. Но только в Outline.
ps: на port 5222 у меня SS не заработал.