Shadowsocks-libev: 莫名其妙

[lovekobeme]

2019.5.30 安装
姿势如下
For Debian 9 (Stretch) users, please install it from stretch-backports: We strongly encourage you to install shadowsocks-libev from stretch-backports. For more info about backports, you can refer Debian Backports.

sudo sh -c 'printf "deb http://deb.debian.org/debian stretch-backports main" > /etc/apt/sources.list.d/stretch-backports.list'
sudo apt update
sudo apt -t stretch-backports install shadowsocks-libev

{
"server":"0.0.0.0",
"mode":"tcp_and_udp",
"server_port":3306,
"local_port":1080,
"password":"FuFu.dgd.fgdfgdfgd.fd.gdf.",
"timeout":60,
"method":"chacha20-ietf-poly1305",
"fast_open":true
}

systemctl start shadowsocks-libev
systemctl restart shadowsocks-libev
systemctl stop shadowsocks-libev

用完就关闭端口，一个人使用，但今天被封掉了.
有写脚本跑正常流量，就是PROXY第三方ip访问自已虚设的网站。今天早上下载了400M左右的zip后立马关掉了，用的长城宽带，当时没有被封掉，刚刚11:10分左右打开一看ssh被断开了，在正常打开网站发现不行要fan qiang才可以访问。

用的够小心翼翼的了，还是卒掉，哎，有心无力，不想搞了。vps是hosthatch。

File.txt

Linux lovekobeme.top 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@lovekobeme:~# service shadowsocks-libev status -l
● shadowsocks-libev.service - Shadowsocks-libev Default Server Service
Loaded: loaded (/lib/systemd/system/shadowsocks-libev.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2019-05-31 22:56:26 CDT; 20min ago
Docs: man:shadowsocks-libev(8)
Main PID: 485 (ss-server)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/shadowsocks-libev.service
└─485 /usr/bin/ss-server -c /etc/shadowsocks-libev/config.json

May 31 22:56:26 lovekobeme.top systemd[1]: Started Shadowsocks-libev Default Server Service.
May 31 22:56:26 lovekobeme.top ss-server[485]: 2019-05-31 22:56:26 INFO: using tcp fast open
May 31 22:56:26 lovekobeme.top ss-server[485]: 2019-05-31 22:56:26 INFO: UDP relay enabled
May 31 22:56:26 lovekobeme.top ss-server[485]: 2019-05-31 22:56:26 INFO: initializing ciphers... May 31 22:56:26 lovekobeme.top ss-server[485]: 2019-05-31 22:56:26 INFO: This system doesn't provMay 31 22:56:26 lovekobeme.top ss-server[485]: Installing the rng-utils/rng-tools, jitterentropy oMay 31 22:56:26 lovekobeme.top ss-server[485]: On virtualized Linux environments, also consider usMay 31 22:56:26 lovekobeme.top ss-server[485]: The service will not start until enough entropy hasMay 31 22:56:26 lovekobeme.top ss-server[485]: 2019-05-31 22:56:26 INFO: tcp server listening at May 31 22:56:26 lovekobeme.top ss-server[485]: 2019-05-31 22:56:26 INFO: udp server listening at lines 1-19/19 (END)

[oakaigh]

2385

[oakaigh]

@lovekobeme #1815

failed to handshake with <malicious_address>: authentication error
crypto: stream: repeat IV detected

Have you seen those messages in the log (by executing journalctl -xe or a non-trivial service <shadowsocks_service_name> status -l)?

[oakaigh]

@madeye
https://github.com/shadowsocks/shadowsocks-libev/blob/5e65dc0fb16a04024838f37663e58b55fe679a4b/src/server.c#L295-L310

https://github.com/shadowsocks/shadowsocks-libev/blob/5e65dc0fb16a04024838f37663e58b55fe679a4b/src/server.c#L762-L766

Personally I think the way shadowsocks handles malicious clients should be more brutal. It should better off handle a TCP connection (do close() and then reset the connection) like a UDP connection when it's confronted with someone who's attempting to do a deep packet inspection, dropping the goddamned packet and free the buffer entirely so that there's no chance that the shadowsocks protocol would be detected.

And here's the idea, we let users to specify the maximum number of retries and if the clients exceed the limit we block em (via update_block_list()).

[madeye]

Add any obfuscation plugin and try again.

1. https://github.com/shadowsocks/v2ray-plugin
2. https://github.com/shadowsocks/simple-obfs

And as discussed many times before, the blocking is following a protocol whitelist approach.

[oakaigh]

@madeye It’s not actually related to the “whitelist approach.” What I’m referring to is the way a shadowsocks server handles TCP connections and the decision-making behind the blocking. The only difference is that the maximum number of retries is no longer hard-coded (although it doesn’t seem that the source code makes sense). It’s determined by users.

https://github.com/shadowsocks/shadowsocks-libev/blob/5e65dc0fb16a04024838f37663e58b55fe679a4b/src/acl.h#L29-L33

[madeye]

Actually I'm replying to the issue reporter.

Please don't post off-topic discussions in other's issue.

[imxiny]

额 特殊时期 过了6号就好了

[abc3660170]

我的 阿里云两台也是昨天他是 ping 不通，客服说你的机器是否安装了违规服务被运营商cut掉了

[lqkfamily]

我阿里云昨天也被封了，用EIP, 换一个新的IP就好了。

[gongshoudao]

这两天我换了三个IP，都又被墙了

[MikeNg2018]

上年有台vps被tcp阻断，就放弃用ss了，改用v2ray