Oh, I missed that the 411 bytes was required. With the Outline SDK, we can add a split to the Shadowsocks stream. The Outline Client doesn’t support that yet, but we want to move towards that. Perhaps the client can automatically try different splits if the connection fails.
На 2024-05-05T17:54:00Z блокировки полностью шифрованных протоколов сохраняются на мобильных Теле2, Мегафон, МТС, Билайн и Йота Санкт-Петербург.
Проверял на Shadowsocks, VMESS и собственном генераторе пакетов. Фильтруются все зарубежные направления (Россию не проверял).
Для эксперимента, развернул на московском vps shadowsocks. С мобильного Билайна не работает.
TCP. А UDP проверяли какие-нибудь для интереса?
How did you test Shadowsocks?
I tested Outline Shadowsocks on Tele2, Megafon, MTS and Beeline in St Petersburg, and was not able to observe blocking.
I tested using soax.com, an Outline Server, and the Outline SDK fetch tool. I tried both fetching a HTTPS page and a HTTP page. The HTTPS fetch doesn’t trigger the 411 bytes in the first packet, but the HTTP fetch was done with padding headers to force over 800 bytes in the first packet, and I still couldn’t trigger the block.
5 posts were merged into an existing topic: Обсуждение: неработоспособность ShadowSocks (30.10.2023 +)
A post was merged into an existing topic: Обсуждение: неработоспособность ShadowSocks (30.10.2023 +)
I’m using proxies on a probe (you have access to it) with v2fly configured with shadowsocks over probe’s proxy as an upstream, and sending the requests with regular curl (built with openssl) to HTTPS websites.
HTTP websites indeed do not trigger the block because the filter expects at least two client-server packets with sufficient amount of data (first is ClientHello, second is HTTP request), and HTTP has only one.
Check the PCAP in the top post.
Проверил QUIC (HTTPS-запросами) через Shadowsocks, на этих же каналах (Теле2, Билайн, МТС, Мегафон Санкт-Петербург) блокировки не вижу.
А фильтр проверяет только первые несколько пакетов (как при wireguard блокировках было) или все время за потоком данных следит?
4 posts were merged into an existing topic: Обсуждение: неработоспособность ShadowSocks (30.10.2023 +)
Вроде только начало сессии. Первый (+ возможно, второй) пакет от клиента и как минимум 2 ответных пакета.
I think that pcap was for your random packet generator, given the two packets with exactly 411 bytes.
It would be helpful to see the packets with the Shadowsocks set up.
Whether it triggers is heavily dependent on the implementation, and I have no idea what your set up is doing.
Some implementations will send IV, connect request and application data as 3 separate packets. Some will merge the first two, and some, such as Outline, will merge the 3 of them.
I don’t think the IV+connect reaches 411 bytes, so it shouldn’t trigger the block. Is the pattern detected after the first packet?
It would be really nice to reproduce the blocking with Outline code. I wasn’t able to.
I think the blocking may also be affected by the port number. The servers I tried were on ports 80 and 443, so they may not be affected by this blocking.
The dump in the first message is a real ShadowSocks. V2fly on both server and client.
I ran some tests with the Outline SDK, which may work differently than other implementations. It looks like the blocking depends on the location of the server. It also depends on the port number. I was also able to confirm that the initial packet size makes a difference, but only in some ISPs.
- Bee Line seems to be the only one considering the packet size, but only for the Vultr server, not DigitalOcean.
- MTS blocked Shadowsocks access to a server on DigitalOcean, but not Vultr. They are likely using the IP address.
- Blocking on DigitalOcean only happened for the key on port 443. No blocking for the key on the same server, but on port 5555.
- MegaFon blocked Shadowsocks access to a server on Vultr, but not on DigitalOcean. They are likely using the IP address as well.
- The packet size didn’t make a difference for MegaFon and MTS
- Tele2 is not blocking.
Tests
The tests used port 443 for the DigitalOcean server and port 20888 for the Vultr server.
I was not able to reproduce blocking on Tele2. Results for Bee Line depended on the initial packet. Results for MTS and Megafon depended on where the server was.
With a DigitalOcean server and large initial packet (over 800 bytes):
MTS was consistently timing out
MegaFon worked most times, with some timeouts. Inconsistent.
Tele2 was consistently working- Bee Line was consistently working
Example:
Using a smaller initial packet didn’t seem to make a difference.
However, when using a key on a different port, 5555, on the same DigitalOcean server, I could consistently connect to the server on all ISPs:
I was also able to connect to the management API on that server, on another high port number.
With a Vultr server and large initial packet:
- MTS was consistently working
- MegaFon was consistently blocked. Not a timeout. I was getting an EOF from the SOCKS5 service I was using, so the Shadowsocks client probably got a FIN or a RESET.
- Tele2 was consistently working
- Bee Line was consistently timing out
Example:
With a Vultr server and small initial packet (300 bytes):
- MTS was consistently working
- MegaFon was consistently blocked. Not a timeout. I was getting an EOF from the SOCKS5 service I was using, so the Shadowsocks client probably got a FIN or a RESET.
- Tele2 was consistently working
- Bee Line was consistently working
Example:
ISPs are targeting specific cloud providers, as reported in April.
I was able to demonstrate that www.digitalocean.com, which runs on Cloudflare, is blocked by SNI. You observe timeouts:
I did manage to successfully fetch the page on Tele2 once.
If you use TLS Record Fragmentation, you can successfully, and consistently fetch the page:
3 posts were merged into an existing topic: Обсуждение: неработоспособность ShadowSocks (30.10.2023 +)
Outline SDK fetch tool produces small TLS ClientHello of 329 bytes, the first encrypted Shadowsocks packet is less than 411 bytes, that’s why you don’t see the block.
$ go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport 'socks5://127.0.0.1:33333|ss://xxx…' https://ifconfig.co
You can use your http2transport + curl to trigger the block.
$ go run github.com/Jigsaw-Code/outline-sdk/x/examples/http2transport@latest -transport 'socks5://127.0.0.1:33333|ss://xxx…' -localAddr 127.0.0.1:44111 &
$ curl -x 127.0.0.1:44111 https://ifconfig.co
curl: (56) Failure when receiving data from the peer
Note that in my tests I was actually fetching HTTP with a padding header to make the first packet larger with -H "Padding: $(printf %800s | tr ' ' 'X')".
I need to check the fetch tool again to make sure the first packet is indeed large. I tested it before with the http2proxy tool and that trick to make the first packet bigger worked after I made a fix to the code (some issue with the HTTP client buffering).
I was actually able to reproduce this same blocking on MTS above. Did you find any inconsistency with my findings?