Да, речь только про мобильный Билайн.
Кстати это неплохо объясняет, посему у комментатора выше не работал 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 действительно была проблема с коннектом, при попытке соединения могло отображаться что сайт недоступен. Но этот баг давно исправлен.
У меня вот эта версия 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.