2022-blake3-aes-256-gcm加密，又被屏蔽了。

[18o]

前几天开始用2022-blake3-aes-256-gcm，用的3306端口，今天早晨发现被墙了。大概只用了1周的时间
AEAD还是没办法解决被发现的问题么？

下面是配置文件

{
  "server": "8.8.8.8",
  "server_port": 3306,
  "fast_open": true,
  "mode": "tcp_and_udp",
  "password": "xxxxxxxxQ0Mwo=",
  "method": "2022-blake3-aes-256-gcm",
  "locals":[
    {
      "local_address": "10.0.0.5",
      "local_port": 1080,
      "mode": "tcp_and_udp"
    },
    {
      "protocol": "http",
      "local_address": "10.0.0.5",
       "local_port": 1087
    },
    {
      "protocol": "socks",
      "local_address": "10.0.0.5",
      "local_port": 10086,
      "mode": "tcp_and_udp",
      "socks5_auth_config_path": "/opt/ss/auth.json"
    }
  ]

}

[zonyitoo]

It is just an independent case. It would be more helpful if you can provide some of the information about why the port was getting blocked, such as

When it was blocked:

• What did you see in logs?
• Did you see any abnormal requests?
• What destination target you were accessing?
• ...

[MycroftWong]

Same to me, ip was banned by gfw. Then I can't ping my server and connect my server by ssh. And after I stop shadowsocks for minutes, it works again.

So I have to stop using shadowsocks, I am using v2ray with websocket and wireguard.

[sophauer]

same here,my ip was blocked by GFW after 6 days using

logs for your reference,

WARN tcp handshake failed. peer: 60.17.121.184:44818, detected repeated nonce (iv/salt)
WARN tcp handshake failed. peer: 124.235.138.136:39146, invalid timestamp 1660138308 - now 1660138355 = -47
WARN tcp handshake failed. peer: 123.157.192.87:44522, detected repeated nonce (iv/salt)
WARN tcp handshake failed. peer: 111.224.6.107:48080, invalid timestamp 1660140722 - now 1660140780 = -58
WARN tcp handshake failed. peer: 175.152.109.135:52180, invalid timestamp 1660140116 - now 1660141378 = -1262
WARN tcp handshake failed. peer: 123.163.114.165:58770, invalid timestamp 1660140116 - now 1660141379 = -1263
WARN tcp handshake failed. peer: 175.152.109.135:52220, decrypt header chunk failed
WARN tcp handshake failed. peer: 123.163.114.165:58772, invalid timestamp 1660140116 - now 1660141382 = -1266
WARN tcp handshake failed. peer: 124.235.138.69:32774, detected repeated nonce (iv/salt)

[malagebidi]

same here

[MarioJames]

same with me

[sora987]

same here, happened yesterday

[database64128]

For those who think the way the server responds to active probing or replay is the cause of blocking, please try https://github.com/database64128/shadowsocks-go with "rejectPolicy" set to your preferred value:

• "" or "ForceReset": Forcibly resets the connection. This is also how shadowsocks-rust behaves with Shadowsocks 2022.
• "CloseWriteDrain": Keeps reading without replying. This is also how shadowsocks-rust behaves with legacy Shadowsocks (AEAD 2017 and stream).
• "ReplyWithGibberish": Keeps reading and sends random garbage after each read returns. This emulates how a legacy Shadowsocks server without replay protection works, except it doesn't actually relay the replayed payload. This was introduced in database64128/shadowsocks-go@1503d36, and is not in any stable release yet.

[ioridf1]

我目前是用的官方做好的docker（docker pull ghcr.io/shadowsocks/ssserver-rust:v1.15.0-alpha.8），是不是已经没办法再增加--log-config参数了？我用的docker启动命令如下：
docker run -d -p 8988:8988/tcp -p 8988:8988/udp --name ssserver-rust --restart=always -v /etc/shadowsocks-rust:/etc/shadowsocks-rust ghcr.io/shadowsocks/ssserver-rust:latest

[ioridf1]

我目前是用的官方做好的docker（docker pull ghcr.io/shadowsocks/ssserver-rust:v1.15.0-alpha.8），我刚在docker外用了这个命令docker logs --details ssserver-rust，看到的内容如下，但这是没有时间的，很不方便。。。
[root@customplan ~]# docker logs --details ssserver-rust
WARN tcp handshake failed. peer: 223.104.68.81:54381, Connection reset by peer (os error 104)
WARN tcp handshake failed. peer: 223.104.68.81:57604, Connection reset by peer (os error 104)
WARN tcp handshake failed. peer: 223.104.68.81:54678, Connection reset by peer (os error 104)
WARN tcp handshake failed. peer: 223.104.68.81:57606, Connection reset by peer (os error 104)
WARN tcp handshake failed. peer: 87.236.176.227:48137, decrypt length failed
WARN tcp handshake failed. peer: 87.236.176.149:37479, decrypt length failed
WARN tcp handshake failed. peer: 87.236.176.149:39387, decrypt length failed
WARN tcp handshake failed. peer: 87.236.176.72:45133, decrypt length failed

[zonyitoo]

You can just put your customized command via docker run, read docker's document first.

[ioridf1]

好的，谢谢老大指明方向，我是一个docker方面的小白，这几天纯是自己瞎倒腾摸索的，您已经告诉我很有价值的信息了，我再多研究一下。。。另外有个疑问，我刚贴出来的上述运行日志内容，是否表示我的服务器在被GFW探测？那些87.236.176开头的IP，地理位置是比利时，显然不是我客户端IP，这个帖子的原始作者给出了他IP被墙的问题，我们现在用的shaodowsocks-rust的版本，还没有解决被GFW主动探测或重放的漏洞么？

[zonyitoo]

This is a question left for you to discover, no one could make a conclusion by just few lines of logs.

[netheril96]

Maybe fast_open is the culprit? TCP Fast Open isn't in widespread use.

[sora987]

My IP has been blocked for a second time today. (Last time on 19 Aug)

I noticed a similar behaviour, immediately before my IP was actually blocked, I started to have trouble accessing https://www.google.com, Firefox started showing PR_CONNECT_RESET_ERROR. However, https://www.google.com.jp or https://www.google.com.au works perfectly fine. (This is not a network congestion issue since my server is connected via CN2 Gia with 0% packet loss)

Both time after some kind of connection interference, the IP was blocked. I did have TCP fast open and TCP NODELAY turned on. I also noticed that if I turn off TCP NODELAY, PR_CONNECT_RESET_ERROR will disappear.

Don't know if this information can be useful for others...

[18o]

我的日志里也出现了多次被其他客户端IP尝试连接的警告，感觉对抗封锁的稳妥办法就是启用IPV6，并准备多个翻墙备用方案。

ipv6不会被墙么？

[ioridf1]

我的日志里也出现了多次被其他客户端IP尝试连接的警告，感觉对抗封锁的稳妥办法就是启用IPV6，并准备多个翻墙备用方案。

ipv6不会被墙么？

这个不一定，不过目前我还没遇到ipv6被墙的情况，最主要是，真要被墙了，ipv6随时换ip就行，这ip池资源很丰富，gfw也无可奈何。

[18o]

那也不是一个一劳永逸的办法，现在我用的稳定的，还是websocket的，暂时没找到其他的

[database64128]

一劳永逸

The only ultimate solution: emigration. It's still possible, as long as you are willing to and have the resources to work on it. 😄

[Gowee]

@sora987 I observed a similar pattern in Oct 2022 when using the broadband of China Broadnet (廣電). But it wouldn't be reproduced if I switched to the cellular network of China Unicom (聯通). At that time, I thought it owed to some strange middleboxes irrelevant to the GFW. Which ISP are you using at that time?

[18o]

加了qtun plugin，今天又开始用ss，看看这次会不会被发现

[ioridf1]

嗯，qtun这个方案我回去也研究下，另外我觉得咱们在这里探讨方案，如果被gfw的人看到了，等于给他们提供了翻墙检测手段和封锁方案，这真是一个矛盾的事情，唉……

[18o]

这倒没必要担心，都是开源的协议和代码，你讨论不讨论，想研究的人都会去研究

[ioridf1]

这段时间你用qtun plugin效果如何？

[18o]

这段时间你用qtun plugin效果如何？

还挺好的，没有被屏蔽，速度也明显比之前用ws快

[ioridf1]

其实我最近用标准ss也没出现啥问题，估计是gfw这段时间放松管制了

[yuedai]

你们没有试过加个白名单么？比如，只允许自己家的Ip连过来。

[pexcn]

试过确实有效，已经稳定使用快1年了

[catscarlet]

你们没有试过加个白名单么？比如，只允许自己家的Ip连过来。

白名单这个我试过了，我讲一下我实现的细节和代码：

• iptables INPUT DROP 掉所有 IP （这是最后一条，兜底）
  iptables -A INPUT -j DROP

• 放行所有 cloudflare 流量（一个cloudflare的ipset） ，cloudflare这端全部代理（隐藏真实IP）

• ipset 创建个空set
  ipset create temporary-allow hash:net timeout 0

• 在网页端通过 cloudflare 绕个圈子向 temporary-allow 添加临时IP，定义一个较短的timeout。（这个比较复杂，就不放代码了）

• iptables ACCEPT放行temporary-allow的特定端口流量，同时写一个 DROP 兜底单抓非 temporary-allow 流量做统计

整体实现大概就是这样：

-A INPUT -i lo -j ACCEPT
-A INPUT -m set --match-set cloudflare src -j ACCEPT
-A INPUT -p tcp -m set --match-set temporary-allow src -m tcp --dport 63524 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 63524 -j DROP
-A INPUT -p udp -m udp --dport 63524 -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -j DROP
-A INPUT -j DROP

曾经的自信之作。

这个别说是主动探测了，这个就算是DDOS都能被丢到黑洞里去。temporary-allow一直是空的，所以所有探测流量都是DROP，只有我想用的时候绕路通过cloudflare访问网页添加临时IP，否则这就是一个空IP。

2022-blake3-aes-256-gcm，完全自用，主要用途就是看youtube的视频，或者github。去年这个时候，没挺过一个星期，IP被认证了3个月，已经被搞怕了。
--dport抓到的主动探测包，我用tcpdump收集起来了，全都是中国境内真实存在的IP，且毫无规律，我导入到ip地址库，查到的都是全国各地的居民区宽带地址。

已经把所有能DROP的流量全DROP了，照旧抵挡不住gfw。我的心态已经输了。