使用 blake3 系列的加密方式会导致端口被临时屏蔽 #955
Comments
|
Related: #888 You might be interested in shadowsocks-go's reject policy |
@zonyitoo Rust 版可以实现此功能吗？ |
|
Maybe you should experiment with different reject policies and post the results to make for a more convincing feature request. 😄 |
|
晚点测试一下😅 |
@database64128 每一个选项都测试过，端口也一样会被临时屏蔽 |
|
我开过阿里云国际的vps有遇到这个情况，新开的机器，也直接会遇到这个状况，不过用的加密方式是chacha20-ietf-poly1305 这种AEAD的，不是最新的2022的。 |
我今天试了 chacha20-ietf-poly1305 和 aes-128-gcm, 也有这样的问题。但是就那一个 VPS 有这样的问题，其余正常 |
我猜测是ip段或者什么被重点监控了，应该是识别到了ss，具体和哪种加密方式没有关系，不过我没去折腾v2之类的，也无法验证，纯猜测，后面转去Amazon了，就正常，虽然偶尔会被gfw封ip。 |
|
@nasaboy 我还测试了 mtg (tls 模式), 这个能正常使用。可能是（对某些 IP 段）识别不了的流量就会被屏蔽？ |
|
@pexcn Well, that was not unexpected. shadowsocks/shadowsocks-org#204 (comment) should be the solution to your problem. It's not in any stable release yet so you have to build it yourself or grab the binaries from GitHub Actions. |
|
我也遇到了此类问题 阿里云日本 |
Update: A new release is out. @pexcn Are you interested in testing whether this feature works for you? |
|
@database64128 我有空再试试😅 |
|
新IP，搭了两天直接被封IP了 |
刚刚测试了一下，不管有没有使用 ( shadowsocks-go v1.4.0 和 shadowsocks-rust v1.15.0-alpha.9 都能正常使用 ) |
|
So the conclusion is that the GFW stopped interfering with your proxy traffic? 😄 |
😂噢... 并不是，我刚刚又试了下， UPDATE: 好像没测清楚。。不通的情况也许只是有丢包，我这两天再看看，有情况再反馈😅 我的配置是这样的： root@SJCX ~/ss-go # cat server.json
{
"servers": [
{
"name": "ss-2022",
"listen": ":1778",
"protocol": "2022-blake3-aes-128-gcm",
"enableTCP": true,
"listenerTFO": true,
"enableUDP": true,
"mtu": 1500,
"psk": "************************"
}
],
"udpPreferIPv6": false
} |
|
There are no behavioral differences between shadowsocks-rust's TCP server and shadowsocks-go's TCP server (without custom reject policy or the unsafe features). I suggest you run 3 servers on 3 different ports:
This should make testing easier and help you get more accurate results. |
|
@database64128 刚刚又按照上述方法测了一下，开了三个端口， unsafe 那个特性我是直接用这里提供的参数，不知道配置有没有问题 {
"servers": [
{
"name": "socks5",
"listen": ":1080",
"protocol": "socks5",
"enableTCP": true,
"listenerTFO": true,
"enableUDP": true,
"mtu": 1500
}
],
"clients": [
{
"name": "ss-2022-unsafe",
"endpoint": "*********:****",
"protocol": "2022-blake3-aes-128-gcm",
"enableTCP": true,
"dialerTFO": true,
"enableUDP": true,
"mtu": 1500,
"psk": "**********************",
"unsafeRequestStreamPrefix": "R0VUIC8gSFRUUC8xLjENCkhvc3Q6IGxvY2FsaG9zdA0KDQo=",
"unsafeResponseStreamPrefix": "SFRUUC8xLjEgMjAwIE9LDQpDb25uZWN0aW9uOiBjbG9zZQ0KDQo="
}
]
} |
|
What about combining unsafe stream prefix with unsafe fallback? And use the fallback domain as part of the prefix. For example, if the fallback address is We might also need longer prefixes to further lower the entropy of the first TCP segment. Try something like: printf 'GET / HTTP/1.1\r\nHost: example.com\r\n\r\n000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' | base64
printf 'HTTP/1.1 200 OK\r\nConnection: close\r\n\r\n000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' | base64And the config will be like: {
"servers": [
{
"name": "socks5",
"listen": ":1080",
"protocol": "socks5",
"enableTCP": true,
"listenerTFO": true,
"enableUDP": true,
"mtu": 1500
}
],
"clients": [
{
"name": "ss-2022-unsafe",
"endpoint": "*********:****",
"protocol": "2022-blake3-aes-128-gcm",
"enableTCP": true,
"dialerTFO": true,
"enableUDP": true,
"mtu": 1500,
"psk": "**********************",
"unsafeFallbackAddress": "example.com:80",
"unsafeRequestStreamPrefix": "R0VUIC8gSFRUUC8xLjENCkhvc3Q6IGV4YW1wbGUuY29tDQoNCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMA==",
"unsafeResponseStreamPrefix": "SFRUUC8xLjEgMjAwIE9LDQpDb25uZWN0aW9uOiBjbG9zZQ0KDQowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA="
}
]
}On startup, both server and client will print the "unsafe ... feature taints the server/client" message. |
|
我设置了 详细的配置如下： {
"servers": [
{
"name": "ss-2022-unsafe",
"listen": ":1778",
"protocol": "2022-blake3-aes-128-gcm",
"enableTCP": true,
"listenerTFO": true,
"enableUDP": true,
"mtu": 1500,
"psk": "*********************",
"unsafeFallbackAddress": "bing.com:80",
"unsafeRequestStreamPrefix": "R0VUIC8gSFRUUC8xLjENCkhvc3Q6IGJpbmcuY29tDQoNCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMA==",
"unsafeResponseStreamPrefix": "SFRUUC8xLjEgMjAwIE9LDQpDb25uZWN0aW9uOiBjbG9zZQ0KDQowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA="
}
],
"udpPreferIPv6": false
} |
|
Thank you for bearing with me and keeping the experiment going! 😄 At this point it's still not clear what characteristics are triggering the blocking. gfw-report/shadowsocks-rust@d1cf917 adjusts the 1/0 ratio if it's within (0.7, 1.4). Maybe our prefixes are still too short to be effective. Let's bump it up to 512 bytes and remove the fake HTTP header. for _ in {0..511}; do printf '0'; done | base64 -w0 |
|
@database64128 仍然有这个问题。多次 同时日志里出现： 2022-10-29T20:04:33.069+0800 WARN service/tcp.go:249 Two-way relay failed {"server": "socks5", "listenAddress": ":1080", "clientAddress": "[::ffff:192.168.1.100]:53158", "targetAddress": "github.com:443", "nl2r": 517, "nr2l": 0, "error": "read tcp 192.168.1.10:35648->**.**.**.**:****: read: connection reset by peer"}我的配置的 unsafe 部分如下： "unsafeFallbackAddress": "bing.com:80",
"unsafeRequestStreamPrefix": "MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA=",
"unsafeResponseStreamPrefix": "MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA=" |
|
This does not seem like how the GFW blocks things. Can you also check the corresponding server log message? |
服务端总共的日志只有这些： root@SJCX ~/ss-go # cat ss.log
2022-10-29T20:02:12.561+0800 WARN service/server.go:95 Unsafe stream prefix taints the server {"name": "ss-2022-unsafe"}
2022-10-29T20:02:12.562+0800 WARN service/server.go:110 Unsafe fallback taints the server {"server": "ss-2022-unsafe", "fallbackAddress": "bing.com:80"}
2022-10-29T20:02:12.562+0800 INFO service/tcp.go:95 Started TCP relay service {"server": "ss-2022", "listenAddress": ":1777"}
2022-10-29T20:02:12.562+0800 INFO service/udp_session.go:146 Started UDP session relay service {"server": "ss-2022", "listenAddress": ":1777"}
2022-10-29T20:02:12.562+0800 INFO service/tcp.go:95 Started TCP relay service {"server": "ss-2022-unsafe", "listenAddress": ":1778"}
2022-10-29T20:02:12.562+0800 INFO service/udp_session.go:146 Started UDP session relay service {"server": "ss-2022-unsafe", "listenAddress": ":1778"}
2022-10-29T20:03:17.456+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:48688", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:17.633+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:48688", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
2022-10-29T20:03:20.002+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:48696", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:20.202+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:48696", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
2022-10-29T20:03:21.274+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:48706", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:21.454+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:48706", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
2022-10-29T20:03:22.002+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46482", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:22.179+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46482", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
2022-10-29T20:03:23.170+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46486", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:23.351+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46486", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
2022-10-29T20:03:23.871+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46490", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:24.054+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46490", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
2022-10-29T20:03:24.526+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46500", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:24.711+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46500", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
2022-10-29T20:03:25.436+0800 INFO service/tcp.go:237 Two-way relay started {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46504", "targetAddress": "208.95.112.1:80", "initialPayloadLength": 74}
2022-10-29T20:03:25.621+0800 INFO service/tcp.go:261 Two-way relay completed {"server": "ss-2022-unsafe", "listenAddress": ":1778", "clientAddress": "[::ffff:**.**.**.**]:46504", "targetAddress": "208.95.112.1:80", "nl2r": 74, "nr2l": 1367}
root@SJCX ~/ss-go # |
|
I found a Vultr server in the same situation as yours, and experimented with it. A few things I've found out about so far:
The key seems to be surviving the 3 blocking/unblocking cycles. You'll observe that the proxy works for 3 minutes, then gets blocked for 3 minutes, then gets unblocked for another 3 minutes... It keeps going until the third time it's unblocked. |
|
这个和我之前开阿里云国际的机器结果一样，开启server只要一连服务器，就会被封3分钟，3分钟后会解封，然后连了又继续封，我当时的宽带是移动的，我以为是移动的问题，后来新开了服务器，用联通4G也测试到了一样的情况，换加密方式也没用，所以我当时得出的结论是要不网段被特殊照顾了或者ss协议被识别了。 |
|
我这个是 virmach 的 vps, 差不多也是这种情况😂 |
|
ipv6 please |
服务端版本：shadowsocks-rust v1.15.0-alpha.8
客户端版本：shadowsocks-android v5.3.1-preview
操作过程：
tcping -t <ip> <ss_port>来持续 ping ssserver 的端口，可以发现端口一直是通的备注：
测试了 chacha20-ietf-poly1305, aes-128-gcm 无此问题（刚刚又测试了，chacha20-ietf-poly1305 也受影响）服务端日志：
CC @madeye @zonyitoo @database64128
The text was updated successfully, but these errors were encountered: