Ник Пост Дата
ValdikSS

Блокируют по размеру пакетов, возможно, не по абсолютным цифрам, а по соотношению размера отправляемого к принимаемому.

HTTPS-соединения устанавливаются 1 раз из 6-7 (в дампе все неудачные), а HTTP устанавливаются всегда (у них другие размеры пакетов).

shadowsocks-block-tele2-29.04.2024.pcapng (44.7 KB)

Очень похоже на Случайная блокировка игры SCP Secret Laboratory на ТСПУ по UDP протоколу - #28 by ValdikSS

Без обсуждений.
Обсуждение в Обсуждение: неработоспособность ShadowSocks (30.10.2023+)

2024-04-28T22:20:36.211Z
ValdikSS

Нашел как минимум один шаблон блокировки (для TCP):

  1. Клиент отсылает три пакета, каждый из которых содержит 411+ случайных байт
  2. Сервер отсылает произвольное количество любых байт чаще, чем клиент отправляет свои пакеты

shadowsocks-test1-tele2-29.04.2024.pcapng (3.1 KB)

2024-04-29T01:06:13.361Z
fortuna

Where was your test network?

Remote Testing with the Outline SDK

You can use the Outline SDK Tools to test different strategies remotely.

Here I test a fetch from Bee Line:

go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport "$SERVER_BEELINE"  https://ipinfo.io/org
AS16345 PJSC "Vimpelcom"

$SERVER_BEELINE is a socks5://... url pointing to a SOCKS5 server running on Bee Line.

Here is a blocked website:

go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport "$SERVER_BEELINE|override:host=cloudflare.net" -method HEAD -v https://meduza.io
2024/04/29 15:49:50 HTTP request failed: Head "https://meduza.io": EOF

(I’m using override to bypass DNS blocking)

TLS Record fragmentation bypasses blocking:

go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport "$SERVER_BEELINE|override:host=cloudflare.net|tlsfrag:1" -method HEAD -v https://meduza.io
[DEBUG] 2024/04/29 15:50:35.534519 main.go:106: Expires: [Mon, 29 Apr 2024 19:51:05 GMT]
[DEBUG] 2024/04/29 15:50:35.535194 main.go:106: Alt-Svc: [h3=":443"; ma=86400]
[DEBUG] 2024/04/29 15:50:35.535205 main.go:106: Cache-Control: [public, max-age=30]
[DEBUG] 2024/04/29 15:50:35.535211 main.go:106: Last-Modified: [Mon, 29 Apr 2024 19:25:15 GMT]
[DEBUG] 2024/04/29 15:50:35.535215 main.go:106: Cf-Cache-Status: [HIT]
[DEBUG] 2024/04/29 15:50:35.535220 main.go:106: X-Content-Type-Options: [nosniff]
[DEBUG] 2024/04/29 15:50:35.535225 main.go:106: Date: [Mon, 29 Apr 2024 19:50:35 GMT]
[DEBUG] 2024/04/29 15:50:35.535229 main.go:106: X-Cg-Cache-Status: [HIT]
[DEBUG] 2024/04/29 15:50:35.535233 main.go:106: Age: [168]
[DEBUG] 2024/04/29 15:50:35.535237 main.go:106: Strict-Transport-Security: [max-age=31536000; includeSubDomains; preload]
[DEBUG] 2024/04/29 15:50:35.535243 main.go:106: Server: [cloudflare]
[DEBUG] 2024/04/29 15:50:35.535247 main.go:106: Cf-Ray: [87c1d2664d33614a-KJA]
[DEBUG] 2024/04/29 15:50:35.535250 main.go:106: Content-Type: [text/html; charset=utf-8]
[DEBUG] 2024/04/29 15:50:35.535311 main.go:106: Connection: [keep-alive]

Testing Shadowsocks

To fetch with Shadowsocks:

go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport "$OUTLINE_SERVER" https://ipinfo.io/org
AS14061 DigitalOcean, LLC

Where $OUTLINE_SERVER is a ss:// Shadowsocks key.

Now we can do a two-hop test by piping the transports. Here we connect to Bee Line, then fetch ipinfo.io via the Outline Server. We seem to get timeouts for HTTP:

go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport "$SERVER_BEELINE|$OUTLINE_SERVER" http://ipinfo.io/org
2024/04/29 15:58:02 HTTP request failed: Get "http://ipinfo.io/org": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
exit status 1

And HTTPS:

go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport "$SERVER_BEELINE|$OUTLINE_SERVER" https://ipinfo.io/org
2024/04/29 16:00:07 HTTP request failed: Get "https://ipinfo.io/org": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
exit status 1

When I use a prefix that simulates a TLS Handshake Record the HTTP fetch succeeds:

$ go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport "$SERVER_BEELINE|$OUTLINE_SERVER?prefix=%16%03%01" http://ipinfo.io/org
AS14061 DigitalOcean, LLC

$ go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport "$SERVER_BEELINE|$OUTLINE_SERVER?prefix=%16%03%01" https://ipinfo.io/org
AS14061 DigitalOcean, LLC

Note that my Outline Server is running on port 443.

I was able to get 10 successes in a row:

for i in $(seq 1 10); do echo -n "Test $i: "; go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport "$SERVER_BEELINE|$OUTLINE_SERVER?prefix=%16%03%01" https://ipinfo.io/org; done
Test 1: AS14061 DigitalOcean, LLC

Test 2: AS14061 DigitalOcean, LLC

Test 3: AS14061 DigitalOcean, LLC

Test 4: AS14061 DigitalOcean, LLC

Test 5: AS14061 DigitalOcean, LLC

Test 6: AS14061 DigitalOcean, LLC

Test 7: AS14061 DigitalOcean, LLC

Test 8: AS14061 DigitalOcean, LLC

Test 9: AS14061 DigitalOcean, LLC

Test 10: AS14061 DigitalOcean, LLC

But it’s not always successful. I don’t know if that’s an issue with my Bee Line being slow or if it’s inconsistent blocking:

$ for i in $(seq 1 10); do echo -n "Test $i: "; go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport "$SERVER_BEELINE|$OUTLINE_SERVER?prefix=%16%03%01" https://ipinfo.io/org; done
Test 1: 2024/04/29 16:10:14 HTTP request failed: Get "https://ipinfo.io/org": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
exit status 1
Test 2: 2024/04/29 16:10:20 HTTP request failed: Get "https://ipinfo.io/org": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
exit status 1
Test 3: 2024/04/29 16:10:26 HTTP request failed: Get "https://ipinfo.io/org": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
exit status 1
Test 4: AS14061 DigitalOcean, LLC

Test 5: AS14061 DigitalOcean, LLC

Test 6: AS14061 DigitalOcean, LLC

Test 7: AS14061 DigitalOcean, LLC

Test 8: 2024/04/29 16:10:41 HTTP request failed: Get "https://ipinfo.io/org": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
exit status 1
Test 9: 2024/04/29 16:10:47 HTTP request failed: Get "https://ipinfo.io/org": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
exit status 1
Test 10: AS14061 DigitalOcean, LLC

I’ll see if I can test in more networks. but it would be great if others could test too.

2024-04-29T20:11:33.118Z
fortuna

Did some testing on Megafon:

$ go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport "socks5://$SERVER_MEGAFON"  https://ipinfo.io/org
AS31224 PJSC MegaFon

It’s not completely clear to me if the timeouts are blocking, or just slowness. I’ll need to change the code to configure that.

HTTPS, no prefix, port 443

for i in $(seq 1 10); do echo -n "Test $i: "; go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport "socks5://$SERVER_MEGAFON|$OUTLINE_SERVER" https://ipinfo.io/org; done
Test 1: AS14061 DigitalOcean, LLC

Test 2: 2024/04/29 16:16:13 HTTP request failed: Get "https://ipinfo.io/org": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
exit status 1
Test 3: AS14061 DigitalOcean, LLC

Test 4: AS14061 DigitalOcean, LLC

Test 5: 2024/04/29 16:16:23 HTTP request failed: Get "https://ipinfo.io/org": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
exit status 1
Test 6: AS14061 DigitalOcean, LLC

Test 7: 2024/04/29 16:16:34 HTTP request failed: Get "https://ipinfo.io/org": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
exit status 1
Test 8: AS14061 DigitalOcean, LLC

Test 9: 2024/04/29 16:16:42 HTTP request failed: Get "https://ipinfo.io/org": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
exit status 1
Test 10: AS14061 DigitalOcean, LLC

HTTP, no prefix, port 443

for i in $(seq 1 10); do echo -n "Test $i: "; go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport "socks5://$SERVER_MEGAFON|$OUTLINE_SERVER" http://ipinfo.io/org; done
Test 1: AS14061 DigitalOcean, LLC

Test 2: AS14061 DigitalOcean, LLC

Test 3: AS14061 DigitalOcean, LLC

Test 4: 2024/04/29 16:17:04 HTTP request failed: Get "http://ipinfo.io/org": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
exit status 1
Test 5: AS14061 DigitalOcean, LLC

Test 6: AS14061 DigitalOcean, LLC

Test 7: AS14061 DigitalOcean, LLC

Test 8: AS14061 DigitalOcean, LLC

Test 9: AS14061 DigitalOcean, LLC

Test 10: AS14061 DigitalOcean, LLC

HTTPS, TLS prefix, port 443

for i in $(seq 1 10); do echo -n "Test $i: "; go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport "socks5://$SERVER_MEGAFON|$OUTLINE_SERVER?prefix=%16%03%01" https://ipinfo.io/org; done
Test 1: AS14061 DigitalOcean, LLC

Test 2: AS14061 DigitalOcean, LLC

Test 3: AS14061 DigitalOcean, LLC

Test 4: AS14061 DigitalOcean, LLC

Test 5: AS14061 DigitalOcean, LLC

Test 6: AS14061 DigitalOcean, LLC

Test 7: AS14061 DigitalOcean, LLC

Test 8: AS14061 DigitalOcean, LLC

Test 9: AS14061 DigitalOcean, LLC

Test 10: AS14061 DigitalOcean, LLC

HTTP, TLS Prefix, Port 443

$ for i in $(seq 1 10); do echo -n "Test $i: "; go run github.com/Jigsaw-Code/outline-sdk/x/examples/fetch@latest -transport "socks5://$SERVER_MEGAFON|$OUTLINE_SERVER?prefix=%16%03%01" http://ipinfo.io/org; done
Test 1: AS14061 DigitalOcean, LLC

Test 2: AS14061 DigitalOcean, LLC

Test 3: AS14061 DigitalOcean, LLC

Test 4: 2024/04/29 16:20:20 HTTP request failed: Get "http://ipinfo.io/org": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
exit status 1
Test 5: AS14061 DigitalOcean, LLC

Test 6: 2024/04/29 16:20:32 HTTP request failed: Get "http://ipinfo.io/org": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
exit status 1
Test 7: AS14061 DigitalOcean, LLC

Test 8: AS14061 DigitalOcean, LLC

Test 9: AS14061 DigitalOcean, LLC

Test 10: AS14061 DigitalOcean, LLC
2024-04-29T20:20:54.658Z
fortuna

While the fetch tool doesn’t have a timeout option, you can use our http2transport proxy + curl. I’m now getting more consistent results. I’m not seeing consistent blocking in either Bee Line or Megafon, so I think the timeouts were issues with my remote proxy. Again, it would be great to see direct measurements.

Run the local proxy:

go run github.com/Jigsaw-Code/outline-sdk/x/examples/http2transport@latest -transport "$SERVER_BEELINE|$OUTLINE_SERVER"
2024/04/29 16:42:08 Proxy listening on 127.0.0.1:1080

Then use curl.

Bee Line

HTTP

$ for i in $(seq 1 10); do echo -n "Test $i: "; curl -p -x http://localhost:1080 -sS http://ipinfo.io/org; done
Test 1: AS14061 DigitalOcean, LLC
Test 2: AS14061 DigitalOcean, LLC
Test 3: AS14061 DigitalOcean, LLC
Test 4: AS14061 DigitalOcean, LLC
Test 5: AS14061 DigitalOcean, LLC
Test 6: AS14061 DigitalOcean, LLC
Test 7: curl: (52) Empty reply from server
Test 8: curl: (52) Empty reply from server
Test 9: AS14061 DigitalOcean, LLC
Test 10: AS14061 DigitalOcean, LLC

HTTPS

for i in $(seq 1 10); do echo -n "Test $i: "; curl -p -x http://localhost:1080 -sS https://ipinfo.io/org; done
Test 1: AS14061 DigitalOcean, LLC
Test 2: AS14061 DigitalOcean, LLC
Test 3: AS14061 DigitalOcean, LLC
Test 4: AS14061 DigitalOcean, LLC
Test 5: AS14061 DigitalOcean, LLC
Test 6: AS14061 DigitalOcean, LLC
Test 7: AS14061 DigitalOcean, LLC
Test 8: AS14061 DigitalOcean, LLC
Test 9: AS14061 DigitalOcean, LLC
Test 10: AS14061 DigitalOcean, LLC

Megafon

$ go run github.com/Jigsaw-Code/outline-sdk/x/examples/http2transport@latest -transport "socks5://$SERVER_MEGAFON|$OUTLINE_SERVER"
2024/04/29 16:47:08 Proxy listening on 127.0.0.1:1080

HTTP

$ for i in $(seq 1 10); do echo -n "Test $i: "; curl -p -x http://localhost:1080 -sS http://ipinfo.io/org; done
Test 1: AS14061 DigitalOcean, LLC
Test 2: AS14061 DigitalOcean, LLC
Test 3: AS14061 DigitalOcean, LLC
Test 4: AS14061 DigitalOcean, LLC
Test 5: AS14061 DigitalOcean, LLC
Test 6: AS14061 DigitalOcean, LLC
Test 7: AS14061 DigitalOcean, LLC
Test 8: AS14061 DigitalOcean, LLC
Test 9: AS14061 DigitalOcean, LLC
Test 10: AS14061 DigitalOcean, LLC

HTTPS

$ for i in $(seq 1 10); do echo -n "Test $i: "; curl -p -x http://localhost:1080 -sS https://ipinfo.io/org; done
Test 1: AS14061 DigitalOcean, LLC
Test 2: AS14061 DigitalOcean, LLC
Test 3: AS14061 DigitalOcean, LLC
Test 4: AS14061 DigitalOcean, LLC
Test 5: AS14061 DigitalOcean, LLC
Test 6: AS14061 DigitalOcean, LLC
Test 7: AS14061 DigitalOcean, LLC
Test 8: AS14061 DigitalOcean, LLC
Test 9: AS14061 DigitalOcean, LLC
Test 10: AS14061 DigitalOcean, LLC

MTS

go run github.com/Jigsaw-Code/outline-sdk/x/examples/http2transport@latest -transport "socks5://$SERVER_MTS|$OUTLINE_SERVER"
2024/04/29 16:59:14 Proxy listening on 127.0.0.1:1080

HTTP

$ for i in $(seq 1 10); do echo -n "Test $i: "; curl -p -x http://localhost:1080 -sS http://ipinfo.io/org; done
Test 1: AS14061 DigitalOcean, LLC
Test 2: AS14061 DigitalOcean, LLC
Test 3: AS14061 DigitalOcean, LLC
Test 4: AS14061 DigitalOcean, LLC
Test 5: AS14061 DigitalOcean, LLC
Test 6: AS14061 DigitalOcean, LLC
Test 7: AS14061 DigitalOcean, LLC
Test 8: AS14061 DigitalOcean, LLC
Test 9: AS14061 DigitalOcean, LLC
Test 10: AS14061 DigitalOcean, LLC

HTTPS

$ for i in $(seq 1 10); do echo -n "Test $i: "; curl -p -x http://localhost:1080 -sS https://ipinfo.io/org; done
Test 1: AS14061 DigitalOcean, LLC
Test 2: AS14061 DigitalOcean, LLC
Test 3: AS14061 DigitalOcean, LLC
Test 4: AS14061 DigitalOcean, LLC
Test 5: curl: (56) Failure when receiving data from the peer
Test 6: AS14061 DigitalOcean, LLC
Test 7: AS14061 DigitalOcean, LLC
Test 8: curl: (56) Recv failure: Connection reset by peer
Test 9: AS14061 DigitalOcean, LLC
Test 10: AS14061 DigitalOcean, LLC

Note: Shadowsocks doesn’t communicate TCP resets, so those resets are from the proxy in Russia, not the target website.

2024-04-29T20:51:11.167Z
anon57137390

Для многочисленных тестов с подключением к одному dest_addr:dest_port возможен выбор src_addr:src_port из уже блокируемой 4-tuple (src_addr, src_port, dest_addr, dest_port). Новое подключение не отменяет блокировку.

2024-04-30T15:28:58.599Z
ValdikSS

It’s Tele2 cellular, Saint Petersburg.
I’ve also tested Beeline, MTS, Megafon and Yota @ Saint Petersburg, all are blocked.

You need to absolutely make sure that your ClientHello is large enough, as curl with mbedtls for example does not add padding extension and it does not hit 411 bytes length needed to trigger the block.

2024-05-01T15:56:44.314Z
murka(Danil Shaymurzin)

shadowsocks-notblock-yota-28.04.2024.pcapng (105,4 КБ)

Прикрепляю дамп с удачным подключением к серверу Hetzner из Уфы (Yota), подключение к Outline 162.55.42.178:24475 без префикса.

Блокировки прекратились с 30-го апреля на территории Башкортостана и Татарстана по всем провайдерам. Есть клиенты, которые жалуются на подключение с Билайна из Пензы, при этом чистый SS-блочится, а Outline с префиксом ClientHello не блокируется.

2024-05-01T17:34:12.900Z
fortuna

This is Outline traffic from opt-in metrics. You can see a gradual decline, supporting a partial block, and then it starts to go back up, aligning with @murka’s statement that blocking stopped on April 30.

image
image1352×938 30.1 KB

2024-05-02T15:20:20.136Z
fortuna

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-02T15:28:59.451Z
ValdikSS

На 2024-05-05T17:54:00Z блокировки полностью шифрованных протоколов сохраняются на мобильных Теле2, Мегафон, МТС, Билайн и Йота Санкт-Петербург.

Проверял на Shadowsocks, VMESS и собственном генераторе пакетов. Фильтруются все зарубежные направления (Россию не проверял).

2024-05-05T17:55:33.881Z
Dhohbr

Для эксперимента, развернул на московском vps shadowsocks. С мобильного Билайна не работает.

2024-05-06T17:04:17.614Z
artenox

TCP. А UDP проверяли какие-нибудь для интереса?

2024-05-06T17:37:10.666Z
fortuna

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.

2024-05-07T16:05:17.093Z
ValdikSS

5 posts were merged into an existing topic: Обсуждение: неработоспособность ShadowSocks (30.10.2023 +)

2024-05-08T12:24:43.340Z
ValdikSS

A post was merged into an existing topic: Обсуждение: неработоспособность ShadowSocks (30.10.2023 +)

2024-05-08T12:28:29.653Z
ValdikSS

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.

2024-05-08T12:55:54.414Z
ValdikSS

Проверил QUIC (HTTPS-запросами) через Shadowsocks, на этих же каналах (Теле2, Билайн, МТС, Мегафон Санкт-Петербург) блокировки не вижу.

2024-05-08T15:08:41.903Z
artenox

А фильтр проверяет только первые несколько пакетов (как при wireguard блокировках было) или все время за потоком данных следит?

2024-05-08T16:04:43.508Z
ValdikSS

4 posts were merged into an existing topic: Обсуждение: неработоспособность ShadowSocks (30.10.2023 +)

2024-05-12T20:17:49.861Z
ValdikSS

Вроде только начало сессии. Первый (+ возможно, второй) пакет от клиента и как минимум 2 ответных пакета.

2024-05-15T17:38:05.453Z
fortuna

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.

2024-05-16T18:27:49.555Z
fortuna

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.

2024-05-16T18:29:57.704Z
ValdikSS

The dump in the first message is a real ShadowSocks. V2fly on both server and client.

2024-05-16T18:58:33.591Z
fortuna

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):

  • :x: MTS was consistently timing out
  • :warning: MegaFon worked most times, with some timeouts. Inconsistent.
  • :white_check_mark: Tele2 was consistently working
  • :white_check_mark: Bee Line was consistently working

Example:

image
image1547×668 116 KB

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:

image
image1617×744 141 KB

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:

  • :white_check_mark: MTS was consistently working
  • :x: 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.
  • :white_check_mark: Tele2 was consistently working
  • :x: Bee Line was consistently timing out

Example:

image
image1617×668 120 KB

With a Vultr server and small initial packet (300 bytes):

  • :white_check_mark: MTS was consistently working
  • :x: 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.
  • :white_check_mark: Tele2 was consistently working
  • :white_check_mark: Bee Line was consistently working

Example:

image
image1617×668 115 KB

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:

image
image1617×801 144 KB

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:

image
image1617×649 123 KB

2024-05-17T20:47:40.367Z
ValdikSS

3 posts were merged into an existing topic: Обсуждение: неработоспособность ShadowSocks (30.10.2023 +)

2024-05-18T16:19:28.160Z
ValdikSS

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

Screenshot_20240518_194603-fs8
Screenshot_20240518_194603-fs81518×450 78 KB

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

Screenshot_20240518_195026-fs8
Screenshot_20240518_195026-fs81466×428 77.2 KB

2024-05-18T16:51:55.097Z
fortuna

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).

2024-05-18T17:12:57.656Z
fortuna

I was actually able to reproduce this same blocking on MTS above. Did you find any inconsistency with my findings?

2024-05-18T17:18:43.176Z
ValdikSS

That doesn’t work, the censor also expects the replies to be of ServerHello/Certificate template based on packet sizes and amount of reply packets.
There should be at least two reply packets for one request packet, and also another request packet.
In other words, the filter expects:

  1. Client→Server packet with 411+ bytes length (ClientHello)
  2. Server→Client packet (ServerHello, 100+ bytes of length AFAIK, don’t have notes on hand)
  3. Another Server→Client packet (Certificate + ServerKeyExchange continuation)
  4. Client→Server packet (HTTP GET)

Yes — the block is enabled on all cellular operators and all ports.

2024-05-18T17:20:07.966Z
ValdikSS

A post was merged into an existing topic: Обсуждение: неработоспособность ShadowSocks (30.10.2023 +)

2024-05-18T22:04:04.884Z
fortuna

So it’s not only the first packet. That is helpful.
I still don’t fully understand the pattern though.

I was able to reproduce the blocking with HTTPS. However, it doesn’t not always happen. DO port 5555 worked on Bee Line and DO port 443 worked on Tele2.

Here are my results:

socks_port  client_isp      url                    server_net      port   exit_code  ok    output
33333       MTS PJSC        http://ipinfo.io/org   Digital Ocean   443    28         ❌    curl: (28) Operation timed out after 10002 milliseconds with 0 bytes received
33334       PJSC MegaFon    http://ipinfo.io/org   Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33335       Tele2 Russia    http://ipinfo.io/org   Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33336       Bee Line Cable  http://ipinfo.io/org   Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33333       MTS PJSC        http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33334       PJSC MegaFon    http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33335       Tele2 Russia    http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33336       Bee Line Cable  http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33333       MTS PJSC        http://ipinfo.io/org   Hetzner Online  58987  0          ✅    AS24940 Hetzner Online GmbH
33334       PJSC MegaFon    http://ipinfo.io/org   Hetzner Online  58987  52         ❌    curl: (52) Empty reply from server
33335       Tele2 Russia    http://ipinfo.io/org   Hetzner Online  58987  0          ✅    AS24940 Hetzner Online GmbH
33336       Bee Line Cable  http://ipinfo.io/org   Hetzner Online  58987  28         ❌    curl: (28) Operation timed out after 10006 milliseconds with 0 bytes received
33333       MTS PJSC        http://ipinfo.io/org   Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33334       PJSC MegaFon    http://ipinfo.io/org   Vultr           20888  52         ❌    curl: (52) Empty reply from server
33335       Tele2 Russia    http://ipinfo.io/org   Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33336       Bee Line Cable  http://ipinfo.io/org   Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33333       MTS PJSC        https://ipinfo.io/org  Digital Ocean   443    28         ❌    curl: (28) Connection timed out after 10005 milliseconds
33334       PJSC MegaFon    https://ipinfo.io/org  Digital Ocean   443    28         ❌    curl: (28) Connection timed out after 10005 milliseconds
33335       Tele2 Russia    https://ipinfo.io/org  Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33336       Bee Line Cable  https://ipinfo.io/org  Digital Ocean   443    56         ❌    curl: (56) Failure when receiving data from the peer
33333       MTS PJSC        https://ipinfo.io/org  Digital Ocean   5555   56         ❌    curl: (56) Failure when receiving data from the peer
33334       PJSC MegaFon    https://ipinfo.io/org  Digital Ocean   5555   56         ❌    curl: (56) Recv failure: Connection reset by peer
33335       Tele2 Russia    https://ipinfo.io/org  Digital Ocean   5555   56         ❌    curl: (56) Failure when receiving data from the peer
33336       Bee Line Cable  https://ipinfo.io/org  Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33333       MTS PJSC        https://ipinfo.io/org  Hetzner Online  58987  56         ❌    curl: (56) Failure when receiving data from the peer
33334       PJSC MegaFon    https://ipinfo.io/org  Hetzner Online  58987  35         ❌    curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ipinfo.io:443 
33335       Tele2 Russia    https://ipinfo.io/org  Hetzner Online  58987  56         ❌    curl: (56) Recv failure: Connection reset by peer
33336       Bee Line Cable  https://ipinfo.io/org  Hetzner Online  58987  28         ❌    curl: (28) Connection timed out after 10003 milliseconds
33333       MTS PJSC        https://ipinfo.io/org  Vultr           20888  56         ❌    curl: (56) Failure when receiving data from the peer
33334       PJSC MegaFon    https://ipinfo.io/org  Vultr           20888  35         ❌    curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ipinfo.io:443 
33335       Tele2 Russia    https://ipinfo.io/org  Vultr           20888  56         ❌    curl: (56) Recv failure: Connection reset by peer
33336       Bee Line Cable  https://ipinfo.io/org  Vultr           20888  56         ❌    curl: (56) Failure when receiving data from the peer
Here is the script 
for socks_port in 33333 33334 33335 33336; do
  isp="$(curl -s --show-error -p -x 127.0.0.1:1080 --max-time 10 --proxy-header "Transport: socks5://127.0.0.1:$socks_port" https://checker.soax.com/api/ipinfo | jq -r .data.isp)"
  for url in http://ipinfo.io/org https://ipinfo.io/org; do
    for key in $KEY $KEY5555 $KEY_HETZNER $KEY_VULTR; do
      server_net="$(curl -s --show-error -p -x 127.0.0.1:1080 --max-time 10 --proxy-header "Transport: $key" https://checker.soax.com/api/ipinfo | jq -r .data.isp)"
      server_port=$(sed -En 's|.*:([0-9]+).*|\1|p'<<< "$key")
      output="$(curl -s --show-error -p -x 127.0.0.1:1080 --max-time 10 --proxy-header "Transport: socks5://127.0.0.1:$socks_port|$key" "$url" 2>&1)"
      exit_code=$?
      if [[ $exit_code == 0 ]]; then
        img="✅"
      else
        img="❌"
      fi
      echo "$socks_port\t$isp\t$url\t$server_net\t$server_port\t$exit_code\t$img\t$output" 
    done
  done
done | tee table.txt

echo "socks_port\tclient_isp\tserver_net\tserver_port\turl\texit_code\tok\toutput\n$(sort -s -k 3,5 -k 1n -t $'\t' < table.txt)" | column -t -s $'\t'

Note that you can pass the transport to the http2proxy via a HTTP header, so you don’t need to restart it for different transports. I started it with

go run github.com/Jigsaw-Code/outline-sdk/x/examples/http2transport@latest
2024-05-19T06:56:42.986Z
fortuna

If I use a simple TCP split on byte 5 (split:5), results are mostly the same, except that a couple more cases are successful with HTTPS (4 vs 2 without the split).

socks_port  client_isp      url                    server_net      port   exit_code  ok    output
33333       MTS PJSC        http://ipinfo.io/org   Digital Ocean   443    28         ❌    curl: (28) Operation timed out after 10005 milliseconds with 0 bytes received
33334       PJSC MegaFon    http://ipinfo.io/org   Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33335       Tele2 Russia    http://ipinfo.io/org   Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33336       Bee Line Cable  http://ipinfo.io/org   Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33333       MTS PJSC        http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33334       PJSC MegaFon    http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33335       Tele2 Russia    http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33336       Bee Line Cable  http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33333       MTS PJSC        http://ipinfo.io/org   Hetzner Online  58987  0          ✅    AS24940 Hetzner Online GmbH
33334       PJSC MegaFon    http://ipinfo.io/org   Hetzner Online  58987  52         ❌    curl: (52) Empty reply from server
33335       Tele2 Russia    http://ipinfo.io/org   Hetzner Online  58987  0          ✅    AS24940 Hetzner Online GmbH
33336       Bee Line Cable  http://ipinfo.io/org   Hetzner Online  58987  28         ❌    curl: (28) Operation timed out after 10005 milliseconds with 0 bytes received
33333       MTS PJSC        http://ipinfo.io/org   Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33334       PJSC MegaFon    http://ipinfo.io/org   Vultr           20888  52         ❌    curl: (52) Empty reply from server
33335       Tele2 Russia    http://ipinfo.io/org   Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33336       Bee Line Cable  http://ipinfo.io/org   Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33333       MTS PJSC        https://ipinfo.io/org  Digital Ocean   443    28         ❌    curl: (28) Connection timed out after 10006 milliseconds
33334       PJSC MegaFon    https://ipinfo.io/org  Digital Ocean   443    56         ❌    curl: (56) Failure when receiving data from the peer
33335       Tele2 Russia    https://ipinfo.io/org  Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33336       Bee Line Cable  https://ipinfo.io/org  Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33333       MTS PJSC        https://ipinfo.io/org  Digital Ocean   5555   56         ❌    curl: (56) Failure when receiving data from the peer
33334       PJSC MegaFon    https://ipinfo.io/org  Digital Ocean   5555   56         ❌    curl: (56) Failure when receiving data from the peer
33335       Tele2 Russia    https://ipinfo.io/org  Digital Ocean   5555   56         ❌    curl: (56) Failure when receiving data from the peer
33336       Bee Line Cable  https://ipinfo.io/org  Digital Ocean   5555   56         ❌    curl: (56) Recv failure: Connection reset by peer
33333       MTS PJSC        https://ipinfo.io/org  Hetzner Online  58987  0          ✅    AS24940 Hetzner Online GmbH
33334       PJSC MegaFon    https://ipinfo.io/org  Hetzner Online  58987  35         ❌    curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ipinfo.io:443 
33335       Tele2 Russia    https://ipinfo.io/org  Hetzner Online  58987  0          ✅    AS24940 Hetzner Online GmbH
33336       Bee Line Cable  https://ipinfo.io/org  Hetzner Online  58987  28         ❌    curl: (28) Connection timed out after 10003 milliseconds
33333       MTS PJSC        https://ipinfo.io/org  Vultr           20888  56         ❌    curl: (56) Failure when receiving data from the peer
33334       PJSC MegaFon    https://ipinfo.io/org  Vultr           20888  35         ❌    curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ipinfo.io:443 
33335       Tele2 Russia    https://ipinfo.io/org  Vultr           20888  56         ❌    curl: (56) Failure when receiving data from the peer
33336       Bee Line Cable  https://ipinfo.io/org  Vultr           20888  56         ❌    curl: (56) Recv failure: Connection reset by peer
2024-05-19T07:16:12.377Z
fortuna

Prefixes seem to really help.

Using POST%20, almost all connections succeeded. Tele2 was completely successful. Megafon had only one HTTP timeout with DigitalOcean 443. On MTS, HTTP and HTTPS timed out with DigitalOcean 443. On Bee Line HTTP and HTTP timed out on Hetzner.

This reinforces that the blocking is based on random-looking traffic.

Results, sorted by ISP, server network and port:

socks_port  client_isp      url                    server_net      port   exit_code  ok    output
33333       MTS PJSC        http://ipinfo.io/org   Digital Ocean   443    28         ❌    curl: (28) Operation timed out after 10006 milliseconds with 0 bytes received
33333       MTS PJSC        https://ipinfo.io/org  Digital Ocean   443    28         ❌    curl: (28) Connection timed out after 10005 milliseconds
33333       MTS PJSC        http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33333       MTS PJSC        https://ipinfo.io/org  Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33333       MTS PJSC        http://ipinfo.io/org   Hetzner Online  58987  0          ✅    AS24940 Hetzner Online GmbH
33333       MTS PJSC        https://ipinfo.io/org  Hetzner Online  58987  0          ✅    AS24940 Hetzner Online GmbH
33333       MTS PJSC        http://ipinfo.io/org   Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33333       MTS PJSC        https://ipinfo.io/org  Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33334       PJSC MegaFon    http://ipinfo.io/org   Digital Ocean   443    28         ❌    curl: (28) Operation timed out after 10003 milliseconds with 0 bytes received
33334       PJSC MegaFon    https://ipinfo.io/org  Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33334       PJSC MegaFon    http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33334       PJSC MegaFon    https://ipinfo.io/org  Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33334       PJSC MegaFon    http://ipinfo.io/org   Hetzner Online  58987  0          ✅    AS24940 Hetzner Online GmbH
33334       PJSC MegaFon    https://ipinfo.io/org  Hetzner Online  58987  0          ✅    AS24940 Hetzner Online GmbH
33334       PJSC MegaFon    http://ipinfo.io/org   Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33334       PJSC MegaFon    https://ipinfo.io/org  Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33335       Tele2 Russia    http://ipinfo.io/org   Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33335       Tele2 Russia    https://ipinfo.io/org  Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33335       Tele2 Russia    http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33335       Tele2 Russia    https://ipinfo.io/org  Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33335       Tele2 Russia    http://ipinfo.io/org   Hetzner Online  58987  0          ✅    AS24940 Hetzner Online GmbH
33335       Tele2 Russia    https://ipinfo.io/org  Hetzner Online  58987  0          ✅    AS24940 Hetzner Online GmbH
33335       Tele2 Russia    http://ipinfo.io/org   Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33335       Tele2 Russia    https://ipinfo.io/org  Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33336       Bee Line Cable  http://ipinfo.io/org   Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33336       Bee Line Cable  https://ipinfo.io/org  Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33336       Bee Line Cable  http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33336       Bee Line Cable  https://ipinfo.io/org  Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33336       Bee Line Cable  http://ipinfo.io/org   Hetzner Online  58987  28         ❌    curl: (28) Operation timed out after 10003 milliseconds with 0 bytes received
33336       Bee Line Cable  https://ipinfo.io/org  Hetzner Online  58987  28         ❌    curl: (28) Connection timed out after 10003 milliseconds
33336       Bee Line Cable  http://ipinfo.io/org   Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33336       Bee Line Cable  https://ipinfo.io/org  Vultr           20888  0          ✅    AS20473 The Constant Company, LLC

I got the exact same results when using a TLS prefix that looks like a fragmented record ( %16%03%01%00%C2%A8%01%01).

When using the DNS over TCP prefix (%05%C3%9C_%C3%A0%01%20), the results were worse, but still better than no prefix. It seems it triggered the HTTPS blocking in some cases, but not all cases. This can help figure out the detection rules.

Results:

socks_port  client_isp      url                    server_net      port   exit_code  ok    output
33333       MTS PJSC        http://ipinfo.io/org   Digital Ocean   443    28         ❌    curl: (28) Operation timed out after 10005 milliseconds with 0 bytes received
33333       MTS PJSC        https://ipinfo.io/org  Digital Ocean   443    28         ❌    curl: (28) Connection timed out after 10004 milliseconds
33333       MTS PJSC        http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33333       MTS PJSC        https://ipinfo.io/org  Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33333       MTS PJSC        http://ipinfo.io/org   Hetzner Online  58987  0          ✅    AS24940 Hetzner Online GmbH
33333       MTS PJSC        https://ipinfo.io/org  Hetzner Online  58987  56         ❌    curl: (56) Failure when receiving data from the peer
33333       MTS PJSC        http://ipinfo.io/org   Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33333       MTS PJSC        https://ipinfo.io/org  Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33334       PJSC MegaFon    http://ipinfo.io/org   Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33334       PJSC MegaFon    https://ipinfo.io/org  Digital Ocean   443    56         ❌    curl: (56) Failure when receiving data from the peer
33334       PJSC MegaFon    http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33334       PJSC MegaFon    https://ipinfo.io/org  Digital Ocean   5555   56         ❌    curl: (56) Recv failure: Connection reset by peer
33334       PJSC MegaFon    http://ipinfo.io/org   Hetzner Online  58987  52         ❌    curl: (52) Empty reply from server
33334       PJSC MegaFon    https://ipinfo.io/org  Hetzner Online  58987  35         ❌    curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ipinfo.io:443 
33334       PJSC MegaFon    http://ipinfo.io/org   Vultr           20888  52         ❌    curl: (52) Empty reply from server
33334       PJSC MegaFon    https://ipinfo.io/org  Vultr           20888  35         ❌    curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ipinfo.io:443 
33335       Tele2 Russia    http://ipinfo.io/org   Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33335       Tele2 Russia    https://ipinfo.io/org  Digital Ocean   443    56         ❌    curl: (56) Failure when receiving data from the peer
33335       Tele2 Russia    http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33335       Tele2 Russia    https://ipinfo.io/org  Digital Ocean   5555   56         ❌    curl: (56) Failure when receiving data from the peer
33335       Tele2 Russia    http://ipinfo.io/org   Hetzner Online  58987  0          ✅    AS24940 Hetzner Online GmbH
33335       Tele2 Russia    https://ipinfo.io/org  Hetzner Online  58987  0          ✅    AS24940 Hetzner Online GmbH
33335       Tele2 Russia    http://ipinfo.io/org   Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33335       Tele2 Russia    https://ipinfo.io/org  Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33336       Bee Line Cable  http://ipinfo.io/org   Digital Ocean   443    0          ✅    AS14061 DigitalOcean, LLC
33336       Bee Line Cable  https://ipinfo.io/org  Digital Ocean   443    56         ❌    curl: (56) Failure when receiving data from the peer
33336       Bee Line Cable  http://ipinfo.io/org   Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33336       Bee Line Cable  https://ipinfo.io/org  Digital Ocean   5555   0          ✅    AS14061 DigitalOcean, LLC
33336       Bee Line Cable  http://ipinfo.io/org   Hetzner Online  58987  28         ❌    curl: (28) Operation timed out after 10001 milliseconds with 0 bytes received
33336       Bee Line Cable  https://ipinfo.io/org  Hetzner Online  58987  28         ❌    curl: (28) Connection timed out after 10002 milliseconds
33336       Bee Line Cable  http://ipinfo.io/org   Vultr           20888  0          ✅    AS20473 The Constant Company, LLC
33336       Bee Line Cable  https://ipinfo.io/org  Vultr           20888  56         ❌    curl: (56) Failure when receiving data from the peer
2024-05-19T07:44:38.144Z
blanche.hermine(blanche.hermine)

I also tried using the POST%20 prefix and it worked. ISP: Tattelecom.

2024-05-19T15:21:52.170Z
fortuna

FY, I put the results on the following Gist, which allow you to more easily see all the results and filter by ISP, server network, HTTPS, etc:

image
image1352×1490 404 KB

2024-05-19T16:01:44.325Z
qwelias(Ilia Baryshnikov)

had similar symptoms on Tele2 about a month ago, fixed by enabling v2ray plugin

2024-05-20T02:52:31.543Z
fortuna

Here is a better dataset with all the measurements in one table:

And here is the decision tree based on that dataset that characterizes the blocking (open in a new tab):

decision_tree_comparison_optimized_multiline_no_prefix

2024-05-21T00:55:00.472Z
Anonimno(Anonimno)

Судя по

блок мешающий работе SS откатили. На T2 так же работает, подтверждаю

2024-05-22T09:31:33.903Z
Anonimno(Anonimno)

И снова включили, поведение аналогичное, с N-го раза ресурсы открываются.

2024-05-28T12:45:37.523Z
altea(Ирина)

Сегодня днем проявилось на проводном ЭрТелеком, сайты открываются с четвертого-пятого пинка. В telegram текстовые сообщения идут без проблем, но тормозит загрузка медиа.
Перешла на VLESS пока, с ним все хорошо.

2024-05-28T14:03:19.939Z
ValdikSS

На мобильных операторах у меня не проявляется, но теперь проявляется на:

ISP AS Location
Rostelecom AS12389 Orenburg
JSC Ufanet AS60095 Nizhny Novgorod
Rostelecom AS12389 Perm region
2024-05-28T16:34:28.683Z
ValdikSS

A post was merged into an existing topic: Обсуждение: неработоспособность ShadowSocks (30.10.2023 +)

2024-05-28T17:07:20.735Z
altea(Ирина)

Днем на проводном эртелеком: SS и SS2022, nekoray под windows, hiddify next на дебиане и hiddify next на андроид (через вайфай) - до двух разных серверов на digital ocean (мой и коллеги). На серверах xray, поднятый по инструкции с хабра. Взяла первый попавшийся рабочий носок с 4пда - та же картина, вроде работает, но через три раза на четвертый, так что вроде блок не по хостингу только.

Вечером на проводном Ростелеком: те же клиенты, тот же сервак (уже только мой). SS не пашет, VLESS (xtls-REALITY) нормально.
Регион Нижний Новгород

Да, на мобильных SS на высоких портах продолжал работать все это время

2024-05-28T16:45:55.767Z
ValdikSS

A post was merged into an existing topic: Обсуждение: неработоспособность ShadowSocks (30.10.2023 +)

2024-05-28T17:07:41.251Z
basososas
ISP AS Location
JSC Ufanet AS24955 Republic of Bashkortostan

Начали блокировать сегодня. При чем пытаются дропать соединение присылая в ответ [RST, ACK]. Но и настоящий ответ при этом не приходит. Тип шифра кажется значения не имеет.

Dpidetector в принципе эту информацию подтверждает. Соединение пока что пробивается с нескольких попыток.

2024-05-28T17:38:46.484Z
ash

Здравствуйте)
Кемерово, МТС, замедлен до неработоспособности чистый SS-2022, телега тоже, ощущение, что начали “замедлять” все, что не могут распознать. Xtls-reality c VLESS на той же впске работает отлично.

2024-07-26T08:21:54.612Z
initial_void

Существует и применяется 2 техники блокировок/замедлений разных протоколов и vpn:

  1. распознавание на лету и принятие решения
  2. то, что быстро не распозналось на лету как обычные протоколы - попадает в список, откуда потом производится сканирование ендпоинта, куда раньше ходили - и если распознается какой либо вид vpn или протокол на той стороне - сразу блочится ip или port.

вторая - самая неприятная блокировка. к ней все и движется. отсюда вы наблюдаете “начало работать” “перестало работать”. То есть они просто обходят ваши vpn ендпоинты потом и блочат.

В виду всех этих тенденций нужно приступать к разработке обертки протокола vpn с полной эмуляцией другого легитимного протокола. Скажем outline на 443 нужно научить работать как обычный веб сервер ДО определенных кондиций со второны клиента. Например: после 3го get запроса 4й должен быть определенным и тогда сервер перейдет от эмуляции nginx на shadowsocks.
тоже самое с другими протоколами.
иными словами, приближается время когда нужно будет заканчивать борьбу за нераспознаваемость протоколов, и начинать борьбу за ложную распознаваемость, мимикрию. потому что они перейдут к тактике “замедлять всё что не можем распознать”. Нужно делать так что бы распознали.

2024-10-01T18:32:37.907Z
tor_master(tor_master)

Мегафон. Блокируют ноды obfs4
obfs4_block.pcapng (757,9 КБ)

2024-11-11T09:02:12.963Z
tor_master(tor_master)

не по ip а конкретно протокол

2024-11-11T09:06:19.481Z
tor_master(tor_master)

snowflake тоже не работает. Все также проходят несколько пакетов DTLS и зависание

2024-11-11T09:11:37.332Z
denium

Ничего удивительного. obfs4 выглядит как random, так же как shadowsocks, который давно режут на мобильном интернете. И раньше obfs4 покашливал в лог.
Могу посоветовать забутстрапить tor через чистый интернет и быстро переключиться на obsf4 (чтобы был горячий запуск). Т.к. по наблюдениям секут только bootstrap по размерам пакетов openssl.

2024-11-11T10:36:30.977Z
tor_master(tor_master)

и чтото с этим планируется делать?. obfs4 позиционировали себя как супер-пупер протокол который никогда не заблокируют. А теперь оказывается у фашистких режимов есть вполне действующие средства.

2024-11-11T10:45:13.166Z
denium

obfs4 слабенький протокол, режется белым списком протоколов. Попробуйте другие более современные, которые маскируются под разрешённые.

2024-11-11T10:46:42.655Z
tor_master(tor_master)

какой snowflake так же не работает

2024-11-11T10:47:25.527Z
denium

webtunnel попробуйте.

2024-11-11T10:48:18.981Z
anon9001(anon)

Ему уже 10 лет. Тогда он был расчитан на то что неизвестный и до того как цензоры в китае научились блочить нойз. Это сам факт нойза. “Не правильно ведешь себя в тюрьме, слишком вызывающе ходишь. Зэки тебя нагнут если не наденешь ватник.”

Сам разраб сказал что obfs4 говно. Даже ванильные мосты сейчас лучше работают.

2024-11-11T10:49:44.658Z
tor_master(tor_master)

ванильные мосты работают ровно 1 час. Они их блочат по ip

2024-11-11T10:51:42.008Z
tor_master(tor_master)

webtunnel вообще не работает

2024-11-11T10:53:04.939Z
anon9001(anon)

Сам фронт мог войти в оффлайн, донеры же не будут гонять эти мосты постоянно (и слава богу) там ротация может быть, особенно если они видят что траффик больше не идет = заблочились. Ты дигом и курлом проверь домен сначала.

2024-11-11T10:57:46.950Z
tor_master(tor_master)

На проводных провайдерах ничего не блокируют. блокировка конкретно тор идет с мегафона и мтс

2024-11-11T11:00:40.718Z
denium

Да, серьёзно за tor взялись. Но оно и понятно, в голове тех, кто затевает блокировки, это самый популярный шпионский инструмент :grin:. Ну, попробуйте yggdrasil мосты.

2024-11-11T11:00:56.419Z
tor_master(tor_master)

у меня симки мтс мегафон

2024-11-11T11:01:49.438Z
anon9001(anon)

На мобильных очень не любят webrtc из-за разговорного траффика. Тор тут не причем. Тариф при том

2024-11-11T11:02:46.927Z
tor_master(tor_master)

тоесть о тупо рубят webrtc трафик?

2024-11-11T11:03:42.836Z
tor_master(tor_master)

но obfs4 работают по другому протоколу

2024-11-11T11:04:28.665Z
anon9001(anon)

Могут как и битторрент. Для них траффик как золото, они на нем выгоду везде ищут. Даже с безлимитами будут тебя замедлять

2024-11-11T11:04:37.055Z
tor_master(tor_master)

здесь уже ответили что obfs4 это говно

2024-11-11T11:07:47.365Z
tor_master(tor_master)

фашисткие режимы нам не дадут свободно общатся

2024-11-11T11:08:59.754Z
meeeeeh

Мосты как блокируются, так и разблокируются - постоянно. Я пользуюсь на паре инсталляций tor-relay-scanner, который раз в час-два подкидывает три десятка свежих обычных доступных релеев в конфиг torrc на маршрутизаторе. Работает с 2022-го года без каких-либо телодвижений, буквально zero maintenance.

webtunnel отлично работает - другое дело, что мосты достаточно быстро мрут, и их в целом немного. У меня на мобиле работает без каких-либо проблем, и бутстрапится исключительно быстро. В конфиг насыпано ~10 разных мостов.

2024-11-11T11:23:01.034Z
denium

В некоторых странах, например Саудовской Аравии, ОАЭ тоже режут webrtc, чтобы звонили через оператора или с разрешённых платных местных сервисов.

2024-11-11T11:23:54.304Z
tor_master(tor_master)

конфирурацию для webtunnel сообщи я попробую

2024-11-11T11:28:51.713Z
tor_master(tor_master)

torrc

2024-11-11T11:29:29.335Z
meeeeeh

https://bridges.torproject.org/options или http://yq5jjvr7drkjrelzhut7kgclfuro65jjlivyzfmxiq2kyv5lickrl4qd.onion/options в помощь.

Выбираете там вариант “webtunnel” в ниспадающем списке, забираете два моста, вставляете в список мостов в мобильном или десктопном приложении.

На десктопе: Settings → Connection → Bridges → Add new bridges
На андроиде: Configure connection → Config Bridge → Use a Bridge → Provide a Bridge I know

CLI-клиент:

UseBridges 1
ClientTransportPlugin webtunnel exec <абсолютный путь до бинарника client>
Bridge <строка с адресом и параметрами моста, как есть с bridges.torproject.org для варианта webtunnel>

На каждый мост - новая строка “Bridge”.

2024-11-11T11:31:47.286Z
tor_master(tor_master)

вы мне предлогаете ipv6. IPv6 он есть но там очень серьзные тормоза. там весь травфик идет через брокера

2024-11-11T11:37:08.187Z
meeeeeh

Нет. Эти мосты абсолютно нормально работают через IPv4.

2024-11-11T11:38:06.674Z
odyxz

Yota. Snowflake перестал работать где-то пару дней назад. Клиент посылает оферы без ответа. Перенастроил на использование AMP cache – работает как и прежде. На торовском форуме не нашёл новости что брокер не работает, возможно какие-то блокировки в сторону cdn77.com.

2024-11-11T12:32:49.035Z
anon9001(anon)

Похоже со сноуфлейком действительно что-то не то. Snowflake partially blocked in Russia 2024-11 (#40407) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab

Сегодня ночью в логе моего демона так же обнажил что целый час демон давал stale connections.

log

offer created
broker rendezvous peer received
connected
через ровно 20 секунд
trying a new proxy: no messages received, closing stale connection

Но мне кажется они добъют тор не этим, а убив брокеров после запрета всех сдн.

2024-11-12T12:32:03.348Z
denium

Йота. Много ретрансмиссий, но всё-же соединяется неспеша.

2024-11-12T14:09:24.746Z
q1LLa(Vladimir)

Есть у кого-нибудь свежая информация по рабочим префиксам + портам на ShadowSocks (Outline VPN) ?

2024-11-24T20:00:33.034Z