Total Pageviews

Saturday, 15 May 2021

在centos vps上,用snap安装Shadowsocks-libev

 首先安装snap:

yum install epel-release -y
yum install snapd -y
(snap可执行文件在此:/usr/bin/snap)

systemctl enable --now snapd.socket

mkdir /snap

ln -s /var/lib/snapd/snap /snap

snap install core

显示:

2021-05-15T14:15:11-04:00 INFO Waiting for automatic snapd restart...

Warning: /var/lib/snapd/snap/bin was not found in your $PATH. If you've not

         restarted your session since you installed snapd, try doing that.

         Please see https://forum.snapcraft.io/t/9469 for more details.

core 16-2.50 from Canonical installed

(参考https://snapcraft.io/install/core/centos)


snap install shadowsocks-libev --edge

显示:

Warning: /var/lib/snapd/snap/bin was not found in your $PATH. If you've not

         restarted your session since you installed snapd, try doing that.

         Please see https://forum.snapcraft.io/t/9469 for more details.


shadowsocks-libev (edge) 3.3.5-1 from Max Lv (max-c-lv) installed

[root@racknerd-7b97d8 snap]# ls /var/lib/snapd/snap/bin

shadowsocks-libev.ss-local    shadowsocks-libev.ss-server

shadowsocks-libev.ss-manager  shadowsocks-libev.ss-tunnel

shadowsocks-libev.ss-redir

[root@racknerd-7b97d8 snap]#





---------------------------------------------------------------------

如何部署一台抗封锁的Shadowsocks-libev服务器


这篇教程记录了如何安装,配置并维护一台Shadowsocks-libev服务器。 这篇教程的亮点在于, 按照这里的配置建议,你的Shadowsocks-libev服务器可以抵御各种已知的攻击, 包括来自GFW的主动探测和封锁以及partitioning oracle攻击。 我们还在教程的最后加入了常见的有关Shadowsocks-libev部署的常见问题。

我们致力于更新和维护这篇教程。如果今后发现了新的针对Shadowsocks-libev的攻击,我们将在第一时间在这篇教程中加入缓解攻击的办法。 因此请考虑将这个页面加入到你的收藏夹中。 另外,我们希望这篇教程对技术小白同样友好,因此如果你在任何步骤卡住了,请联系我们,或在下方评论区留言。我们会对教程作相应改进。

安装

安装Snap应用商店

通过Snap应用商店安装Shadowsocks-libev是官方推荐的方式。

  • 如果你的服务器运行Ubuntu 16.04 LTS及以上的版本,Snap已经默认安装好了。
  • 如果你的服务器运行了其他的Linux发行版,你只需跟着对应的发行版安装Snap core

现在来检测一下你的服务器已经安装了需要的snapd和Snap core:

sudo snap install core

安装Shadowsocks-libev

现在我们安装最新的Shadowsocks-libev:

sudo snap install shadowsocks-libev --edge

配置

下面是我们推荐的Shadowsocks-libev服务器配置:

{
    "server":["::0","0.0.0.0"],
    "server_port":8388,
    "encryption_method":"chacha20-ietf-poly1305",
    "password":"ExamplePassword",
    "mode":"tcp_only",
    "fast_open":false
}

注意,你需要把里面的ExamplePassword替换成一个更强的密码。 强密码有助缓解最新发现的针对Shadowsocks服务器的Partitioning Oracle攻击。 你可以用以下命令在终端生成一个强密码:openssl rand -base64 16

你还可以考虑将server_port的值从8388改为102465535之间的任意整数。

现在打开通过Snap安装的Shadowsocks-libev默认的配置文件:

sudo nano /var/snap/shadowsocks-libev/common/etc/shadowsocks-libev/config.json

将上方替换过密码的配置信息复制粘贴到配置文件后, 按Ctrl + x退出。 退出时,文本编辑器将问你"Save modified buffer?",请输入y然后按回车键。

可以看到,通过Snap安装的Shadowsocks-libev默认的配置文件路径太长了,不便于记忆。同时默认配置路径又没有在官方文档中标出。 我们因此建议你收藏此页面,以备今后查找。

防火墙

我们使用ufw来管理Shadowsocks服务器的防火墙。

在基于Debian的服务器上,可以通过如下命令安装ufw

sudo apt update && sudo apt install -y ufw

然后开放有关sshShadowsocks-libev的端口。 请注意,以下命令假设你在/var/snap/shadowsocks-libev/common/etc/shadowsocks-libev/config.json中的server_port的值为8388。 如果你的server_port用了其他的值,请对以下命令作相应的修改:

sudo ufw allow ssh
sudo ufw allow 8388/tcp

现在我们启动ufw:

sudo ufw enable

启动时如果弹出Command may disrupt existing ssh connections. Proceed with operation (y|n)?,请输入y并按回车键。

最后,请用sudo ufw status检查一下你的配置是否和下面的一样:

Status: active

To                         Action      From
--                         ------      ----
SSH                        ALLOW       Anywhere
8388/tcp                   ALLOW       Anywhere
SSH (v6)                   ALLOW       Anywhere (v6)
8388/tcp (v6)              ALLOW       Anywhere (v6)

运行Shadowsocks-libev

现在我们启动Shadowsocks-libev:

sudo systemctl start snap.shadowsocks-libev.ss-server-daemon.service

记得设置Shadowsocks-libev开机自启动:

sudo systemctl enable snap.shadowsocks-libev.ss-server-daemon.service

维护

检查运行状态和日志

以下命令可以查看Shadowsocks-libev的运行状态:

sudo systemctl status snap.shadowsocks-libev.ss-server-daemon.service

如果你看到绿色的Active: active (running),那么你的Shadowsocks-libev服务器就在正常的运行; 如果你看到红色的Active: failed,请用跳至如下命令journalctl -u snap.shadowsocks-libev.ss-server-daemon.service的尾部查看问题出在哪里了。

重新加载配置文件

每当你修改过配置文件后,请用如下命令重启Shadowsocks-libev以加载修改后的文件:

sudo systemctl restart snap.shadowsocks-libev.ss-server-daemon.service

常见问题

Q:为什么我用了教程里的配置,服务器还是被封了?

A: 通常来讲,这种事情不会发生,因为通过这篇教程配置的Shadowsocks-libev服务器已经可以抵御已知的所有来自GFW的主动探测。但如果你的服务器确实被封锁了,那么很有可能审查者使用了未知的攻击手段。请将你的封锁情况汇报给我们,我们会认真地调查。

Q: 我应不应该从发行版的仓库下载安装Shadowsocks-libev?

A: 发行版仓库里的Shadowsocks-libev不一定是最新版的。比如,截止2021年1月,Debian buster仓库的Shadowsocks-libev的版本为v3.2.5。而这个版本的Shadowsocks-libev是不够防御来自GFW的主动探测的(详见Figure 10)。

Q: 我应该怎样更新用Snap安装的Shadowsocks-libev?

A: 因为Snap会每天自动更新通过其安装的软件,因此通常情况下你不需要手动更新。如若需要手动更新,请用: sudo snap refresh

Q: 为什么用chacha20-ietf-poly1305作为加密方式?

A: 因为它是其中一种AEAD ciphers。而AEAD ciphers可以抵御来自GFW的主动探测。它同时也是Shadowsocks-libev及OutlineVPN的默认加密方式。

Q: 我应该用Shadowsocks的stream cipher吗?

A: 完全不应该。因为Shadowsocks的stream cipher有着不可接受的安全隐私漏洞,并且可以被准确的主动探测。如Figure 10所示,即使是最新版的Shadowsocks-libev,在使用stream cipher时同样可以被准确识别。更具灾难性的是,在不需要密码的情况下,攻击者可以完全解密被记录下来的Shadowsocks会话

Q: 但为什么我用的机场仍在使用stream cipher?

A: 这清楚地说明你的机场缺乏安全意识和安全措施。请把这篇教程这个演讲,和这篇总结,分享给你的机场主。

Q: 我应该把配置中的server_port改为像443这样的常见端口吗?

A: 不应该。因为不论你使用哪个端口,GFW都会检测并怀疑你的Shadowsocks流量。

Q: 为什么配置文件使用tcp_only模式?

A: 这是为了缓解最新发现的Partitioning Oracle攻击,文中指出 “Shadowsocks的开发者们已经采取措施,禁用了本默认开启的UDP代理模式(“the Shadowsocks developers took immediate action to disable UDP proxying where it was enabled by default.")。当然,如Vinicius所指出的,如果你使用了长的随机密码,那么partitioning oracle攻击就不能成功。因此也就不需要禁用UDP代理模式。开启UDP代理模式可能会让经过Shadowsocks代理的视频通话质量更佳。

Q: 为什么配置文件禁用了fast_open?

A: 我们推荐你阅读这里的讨论

联系

这篇报告首发于GFW Report。我们鼓励您或公开地或私下地分享您的评论或疑问。我们私下的联系方式可见GFW Report的页脚。

Good article! I think it better to avoid hardcoding the port 8388 (i am afraid that beginners will simply copy and use this...) State it more clearly like, "in your deployments you'd better use another random port, ..." would be better.

Anonymous

Thank you for your suggestion. We added the following sentence to the post: 你还可以考虑将server_port的值从8388改为1024到65535之间的任意整数。 Note that, for now, we find no evidence that the GFW is biased against any port; however, if this tutorial becomes popular later, the GFW might consider servers using a certain port number suspicious.

匿名

What's the difference between shadowsocks-libev and shadowsocks-rust?

匿名

首先我们想说明,我们的工作中只研究了Shadowsocks-libev和OutlineVPN两款Shadowsocks实现。但这不证明其他的Shadowsocks实现没有类似的问题。相反,我们推荐所研究的这两款实现,因为它们是被积极维护的,它们的最新版都已经解决了发现的问题。

其次,虽然在Shadowsocks-libev的About上写着“Bug-fix-only libev port of shadowsocks. Future development moved to shadowsocks-rust”,但这不意味着Shadowsocks-rust的抗封锁能力已经比Shadowsocks-libev强了。比如说,Shadowsocks-rust的开发者承认,这个实现的成熟还有赖于更多来自社区的支持("I am totally open for you guys to make this project to be actually 'production ready'")。举例来讲,我们看到这个open issue。如果理解正确的话,这个问题Outline之前有过,而现在已经修复。这个问题会导致客户端和服务端发送的第一个数据包的长度完全固定,导致被流量分析的可能。

最后,如果你不确定你喜欢的Shadowsocks实现是否做到了这篇文中我们给翻墙软件开发者的建议, 不妨把文章分享给开发者,看看开发者们怎么说。我们很乐于和他们交流沟通想法。

匿名

"举例来讲,我们看到这个open issue。如果理解正确的话,这个问题Outline之前有过,而现在已经修复。这个问题会导致客户端和服务端发送的第一个数据包的长度完全固定,导致被流量分析的可能。"

这里是我们理解错了,问题其实已经被解决,并且被加入到Shadowsocks协议文档:"For better obfuscation purposes, both local and remote SHOULD send the handshake data along with some payload in the first packet."。那个issue之所以open,是因为另一个需要修复的地方

我们下载了目前最新稳定版的Shadowsocks-rust(v1.8.23},确认客户端发送到服务端的第一个数据包的长度是变化的,其荷载长度为:IV + addressing + data

匿名

请问要不要加混淆(TLS)和安装 BBR 呢?

匿名

这篇教程推荐的配置,就已经足够抵抗目前的识别和封锁了。

我们还没有研究加入混淆后的流量特征,但以往的经验是,如果混淆不当,反而会有更容易被识别的特征暴露出来。

匿名

请问客户端该如何配置?

匿名

我使用了该教程展示的方法,但是很不幸地,服务器仍然被防火墙阻挡了。 我还有一台使用TLS相关协议的服务器,运行完好。 我的ufw版本:ufw 0.35 我的ufw配置(xxx是被故意隐去的数字):


22/tcp ALLOW Anywhere
24xxx ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)
24xxx (v6) ALLOW Anywhere (v6)

我的SS-Libev版本:shadowsocks-libev 3.3.5-1 751 latest/edge max-c-lv -

我的加密方式:chacha20-ietf-poly1305

我的SS-Libev密码:采用openssl rand -base64 18生成。

封锁情况:昨天晚上短暂无响应,但马上恢复。今天早上彻底被阻挡,无法ping通。

敬请作者予以调查,你们是反审查的希望。

另外我有一点想问,现在的日期,防火墙有没有可能激进到只要怀疑是Shadowsocks就封锁,而不管主动探测的结果?

匿名

我是这一层的层主,来补充一些信息。我的SS-Libev采用和作者推荐的一致的TCP_Only模式,但UFW在设置过程中,开放的SS-Libev端口没有只允许TCP(可以看层中的UFW配置)。

匿名

为何不设置只运行TCP?

匿名

因为忘记了

匿名

用随机长密码也可以不设置只允许TCP

匿名

我之前的感觉也是,开obfs-tls混淆,尤其是本身就是用tls协议的知名端口,基本上比较安全。

单独开AEAD还是容易被探测封锁。

匿名

我按照此教程部署的服务器昨天也出现了约半个小时的中断无响应,恢复后到现在一直正常,您的服务器现在恢复了吗?我认为难以确定阻断和协议有关

匿名

我已经更换了IP和协议。

匿名

非常感谢您详细的汇报。我们将您的情况总结在了这篇帖子中:https://github.com/net4people/bbs/issues/69

请问您的服务器大概被至少屏蔽了多久?是像其他两位用户汇报的只是短暂的屏蔽,又或是至少持续数天的屏蔽?

匿名

由于我在服务器被屏蔽不到一天就更换了IP,因此难以回答屏蔽是否有持续数天,抱歉。但是屏蔽时间从上午开始使用时立即发现到下午更换IP完成至少有6小时。 另外有一点要提,我使用了中转服务器,Shadowsocks服务部署在落地服务器上,由中转服务器端口转发。事发时,中转服务器到落地服务器和我地网络直连落地服务器均是断线的,且中转服务器和我地网络并非同一家运营商。

匿名

感谢你详实的汇报。我们已经在帖子中做了更新。

张三

我的v2ray两年前开始使用,单vmess加密,几乎天天用,前几个月在某次大规模封机场中被墙过一晚上,第二天又能正常使用了。我想知道我到现在还能使用我的v2ray是我运气好还是已经被gfw破解了被监视中。ps:我的uuid曾经发到过微信上

匿名

非常感谢分享,我的SS被屏蔽了多次,现在总算知道原因了!

我有个问题,在这里讨论会不会导致这个域名被墙?

匿名

请问多端口文件怎么配置

安全上网

I built it completely according to the teaching in this article, and it can be used normally but cannot pass the whatleaks detection. PING will detect that I am using a proxy. Is there a way to solve this?

匿名

We suggest you using the Tor Browser over Shadowsocks to protect your online anonymity. Shadowsocks is not designed for anonymity.

匿名

您好,我按照教程步骤部署了,也成功链接上了,但是一旦重启服务器,我的shadowsocks就无法与服务端链接了。我通过这条命令sudo systemctl enable snap.shadowsocks-libev.ss-server-daemon.service查看了服务器上的shadowsocks,看起来是正常在运行,显示绿色的Active: active (running),但就是无法连接。请问这是什么问题,该怎么解决?

匿名

我按此文设置的SS服务器已经稳定运行了两个多月,没有出现任何问题。请问使用多长的随机密码后就可以打开UDP代理了?

匿名

“我按此文设置的SS服务器已经稳定运行了两个多月,没有出现任何问题。”

感谢您的反馈。报告使用正常和报告封锁同样重要。

“请问使用多长的随机密码后就可以打开UDP代理了?”

随机密码由文中推荐的命令行生成的就足够了:openssl rand -base64 16

匿名

请问libev是不支持aes-256-gcm吗? 我用chacha20-ietf-poly1305能正常使用换成aes-256-gcm就会连接不上

匿名

Shadowsocks-libev是支持aes-256-gcm的。

有没有可能是客户端和服务端配置不一致?比如服务端修改过配置后忘记重新加载配置文件

匿名

请问根据此教程,用哪个命令能查看当前使用的ss-libev版本? 之前都是从backports安装,直接ss-server -v就行了,但是从snap安装似乎有别的命令可以查看ss-libev的版本信息?

匿名

可以使用如下命令查看当前版本: snap run shadowsocks-libev.ss-server -h

当然,如果觉得不容易记住的话,也可以考虑添加别名:

sudo snap alias shadowsocks-libev.ss-server ss-server

这样以后就可以直接使用你熟悉的命令了:

ss-server -h

另外,其他通过snap安装的二进制文件也可以用如下命令找到:

ls -l /snap/bin

匿名

你好, 国外单IP 多端口同时与中国不同ip通讯是否会被GFW怀疑为shadowsocks代理IP?如果存在这种可能,启用tls插件并通过443端口为一个几千人的群体提供服务,也就是单端口多用户是否可以在最新版本的shadowsocks(rust/libev)上实施?我了解到ss的连接方式是不同用户使用不同的端口来进行用户的区分.


from https://gfw.report/blog/ss_tutorial/zh/

-------


related post: https://briteming.blogspot.com/2021/02/gfw.html

No comments:

Post a Comment