Запишите трафик в 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 на высоких портах на этом же сервере продолжал работать