В 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 +)