SS科学上网选什么VPS?

254 views
Skip to first unread message

Coiby Xu

unread,
Mar 13, 2016, 4:14:38 AM3/13/16
to USTC_LUG
大家好！

请问下大家用SS是选什么VPS的？

我之前是用DO的新加坡和洛杉矶节点，去年10月还是什么开始，就有问题了，走网络通的教育网出口(0出口)，查资料时不时被恶心下，浏览器提示：
The connection to xxx was interrupted
但ssh还能连过去。

如果用非教育网的网络（如电信、移动），干扰方式不太一样，直接ssh也不上了，ping的话提示timeout。我用LUG提供的SS服务器，也是一样的问题。Github上也有人一直反馈这个问题这几天出现很多端口被干扰的状况 · Issue #410 · shadowsocks/shadowsocks，有人说换小众点的VPS。

之前碰到这种情况，是手动切换到Lantern的代理，现在越觉得麻烦了，请问大家有什么推荐的VPS或其它稳定的科学上网方式吗？

谢谢！

SJ Zhu

unread,
Mar 13, 2016, 4:20:35 AM3/13/16
to USTCLUG-Group
是不是你本地网络的问题，LUG 的 SS 服务器应该没出问题啊。
> --
> -- 来自USTC LUG
> 请使用gmail订阅，不要灌水。
> 更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "USTC_LUG" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ustc_lug+u...@googlegroups.com.
> To post to this group, send email to ustc...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Best regards,
Zhu Shengjing

Coiby Xu

unread,
Mar 13, 2016, 4:34:56 AM3/13/16
to ustc...@googlegroups.com
应该不是我的网络问题，和我一起共用SS服务器的同学也出现这样的问题。

也不能说是LUG SS的服务器问题，应该是GFW升级了，可以看下一个老外最近 体验中国的 GFW的报告。

我猜测是GFW在中间掐断了对话，即分别告诉服务器和用户端，对方连接已经断了。


You received this message because you are subscribed to a topic in the Google Groups "USTC_LUG" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ustc_lug/ORaiPoJKdds/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ustc_lug+u...@googlegroups.com.

To post to this group, send email to ustc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Best regards,
Coiby

SJ Zhu

unread,
Mar 13, 2016, 4:38:59 AM3/13/16
to USTCLUG-Group
你连 LUG SS 的话，入口是在校内的，至于和国外怎么连，用的是其他的协议（最近貌似并没有出现问题

Coiby Xu

unread,
Mar 13, 2016, 4:41:51 AM3/13/16
to ustc...@googlegroups.com
国家级审查者使用深度包检测系统（DPI）去探测和屏蔽翻墙工具的使用。它们是通过协议头或其它应用层网络数据包中的指纹发现此类的翻墙工具。研究人员和 活动人士因此相对应的提出了混淆协议方法。协议混淆工具采用的方法包括随机化所有发送的字节，模仿未封锁的协议如HTTP，通过未屏蔽协议的实现隧道流 量。Tor匿名网络就开发了多种协议混淆，包括obfsprox（obfsproxy3和obfsproxy4）和meek。目前它们都没有遭到DPI的 封锁。但审查者是否可以轻易的改变和部署新的DPI算法去精确的探测这些协议混淆工具？威斯康星大学的研究人员发表了一篇论文《Seeing through Network-Protocol Obfuscation》（PDF），他们给出的答案是肯定的。研究人员发现，现有的协议混淆机制都能很容易的探测出，使用机器学习对流量进行分类，一个国家级的审查者能达到99%的准确率。—http://www.solidot.org/story?sid=45839

前北邮校长方滨兴等人在《计算机研究与发展》上发表论文《匿名通信系统不可观测性度量方法》（PDF），报告他们能通过观察Tor混淆插件的流量模式将其识别出来。为了躲避深度包检查，研究人员开发出了协议混淆工具，Tor 匿名网络开发的传输层协议混淆插件包括obfsprox（obfsproxy3和obfsproxy4），meek和fte等。研究人员从Tor官网下载 软件，对传输流量进行一番研究后很快发现Tor的混淆插件容易受到时间分析攻击。他们发现，meek、网桥和HTTPS的流量数据包内部时间间隔基本相 同，但meek的数据包在0.5-2秒附近有一个明显的抖动，原因是meek客户端为了与云平台保持长连接而自动在空闲时发送一个心跳包，心跳包是随机在 0.1秒-5秒之间选择一个值。他们还观察到了其它两个数据模式：网桥模式下数据包大小在600B附近比较集中，原因也与Tor的数据包设计有 关；meek模式下客户端到服务数据包大小在200B左右，服务器到客户端400B左右。 —http://www.solidot.org/story?sid=31640

GFW应该对SS流量也有识别能力了。
--
Best regards,
Coiby

Yifan Gao

unread,
Mar 13, 2016, 5:15:27 AM3/13/16
to ustc...@googlegroups.com
SS服务器的确出问题了。原因是用的人太多，到达单进程最大连接数了。该问题现已修复。

LUG的SS服务器在校内。只能在校园网环境中使用。

因此，用户到LUG SS服务器的流量全部都在校内，不会经过GFW，也不会因为GFW升级而受到影响。
signature.asc

Coiby Xu

unread,
Mar 13, 2016, 5:43:37 AM3/13/16
to ustc...@googlegroups.com
太好了，多谢！不用被这麻烦折腾了。同时谢谢SJ Zhu回复！


话说你们是用了什么黑科技吗？好像是流量越大，GFW越容易识别出来去干扰。

Yifan Gao

unread,
Mar 13, 2016, 6:17:20 AM3/13/16
to ustc...@googlegroups.com
没什么黑科技啊。。。。。就是单纯的GRE隧道。

不过最近GRE隧道已经开始受到干扰了
On Mar 13, 2016, at 5:42 PM, Coiby Xu <coib...@gmail.com> wrote:

话说你们是用了什么黑科技吗？好像是流量越大，GFW越容易识别出来去干扰。

signature.asc

Hugo

unread,
Mar 13, 2016, 6:45:04 AM3/13/16
to ustc...@googlegroups.com
最近一段时间都感觉 DO 的东亚服务器是不是被全被认证了，我这边直连 ssh 管理服务器（哪怕是新建的）都十分困难，搭建在上边的网页访问速度也十分酸爽。
2016年 3月13日 18:17
没什么黑科技啊。。。。。就是单纯的GRE隧道。

不过最近GRE隧道已经开始受到干扰了

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
To post to this group, send email to ustc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
2016年 3月13日 17:42
太好了，多谢！不用被这麻烦折腾 了。同时谢谢SJ Zhu回复！


话说你们是用了什么黑科技吗？好像是流量越大，GFW越容易识别出来去干扰。










--
Best regards,
Coiby

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
To post to this group, send email to ustc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
2016年 3月13日 17:15
SS服务器的确出问题了。原因是用的人太多，到达单进程 最大连接数了。该问题现已修复。


LUG的SS服务器在校内。只能在校园网环境中使用。

因此，用户到LUG SS服务器的流量全部都在校内，不会经过GFW，也不会因为GFW升级而受到影响。


2016年 3月13日 16:38
你连 LUG SS 的话，入口是在校内的，至于和国外怎么连，用的是其他的协议（最近貌似并没有出现问题



2016年 3月13日 16:34
应该不是我的网络问题，和我一起共 用SS服务器的同学也出现这样的问题。

也不能说是LUG SS的服务器问题，应该是GFW升级了，可以看下一个老外最近 体 验中国的 GFW的报告。

我猜测是GFW在中间掐断了对话，即分别告诉服务器和用户端，对方连接已经断了。





--
Best regards,
Coiby

Yang Luo

unread,
Mar 13, 2016, 8:16:11 AM3/13/16
to USTC_LUG


在 2016年3月13日星期日 UTC+8下午4:14:38，Coiby Xu写道：
租了一个bandwagon的vps，一年不到70yuan，不过现在这个套餐没有了。bandwagon的挺便宜，而且用起来稳定 

Bojie Li

unread,
Mar 13, 2016, 9:30:37 AM3/13/16
to USTC_LUG
我司买的是有带宽保证的专线，然而还是怕网络流量分析（不是怕被墙，是怕被监听）。据说应对方法很简单：一个全零的源源不断的数据流作为载波，把欲传输的信息调制在上面，再加密传输出去。这样在网络上看到的就是以专线带宽不停发送的大 UDP 包，欲传输信息的流量特征不会在网络上有任何的体现。调制就是个异或操作，不会造成带宽损失。顺便还能监控专线质量，如果带宽缺斤短两了马上就能发现。

理论上，只要把欲传输的信息异或调制在一个 stream cipher 上面，直接封包发送出去就行了。然而实际网络中是有丢包和错包的，发生丢包和错包的时候对面就解不出来了，所以要每个包独立加密，并且有 HMAC 验证的机制，就像 shadowsocks 的做法。

当然一般人没有买专线这么土豪，而且长时间全速发送的 UDP 流还是容易被认为不正常，因此可以封装到 HTTP 请求里面。在网络监控者看来，就是在上传一个大文件。请求的内容部分作为载波，也就是没有数据要传的时候是全 0，有数据要传的时候就是数据本身，再加密一下发出去。加密算法保证了发出去的数据在统计上没有信息量，而载波保证了数据包的大小和间隔与要传输的信息无关。如果觉得一个 HTTP 请求不够快，还可以多搞几个并发连接。我不知道现在有没有开源工具能做到这件事。

怕没解释清楚，写一点伪代码，这里 plainStream 可以来自一个虚拟的网络设备（例如 OpenVPN 的 tun0），也就是把该虚拟网卡收到的 IP 包想成一个数据流。这个假定了 HTTP 连接是可靠的。由于明文流量可能超过载波带宽，plainStream 里要有一个 buffer，buffer 满的时候，虚拟网卡就要丢包了。

def SendConfidentialStream(plainStream, server, preSharedSecret):
    req = CreateHttpRequest(server)
    req.SendHttpHeader(CreateFakeHTTPHeader())
    enc = CreateEncryptStream(preSharedSecret)
    while plainStream.NotEof():
        carrier = GenZeroBlock()
        if plainStream.HasPendingData():
            plain = plainStream.ReadPendingData(len(carrier))
            carrier[0:len(plain)] = [chr(ord(p) ^ ord(c)) for p,c in zip(plain,carrier)]
        encrypted = enc.EncryptBlock(carrier)
        req.SendBody(encrypted)
    req.CloseConnection()

蒲肖肖

unread,
Mar 13, 2016, 10:29:57 AM3/13/16
to USTC_LUG
https://github.com/bigeagle/gohop

这里面提出的抵御网络流量分析的方法感觉挺有道理的，不知道各位大神怎么看？

在 2016年3月13日星期日 UTC+8下午9:30:37，Bojie Li写道：

Justin Wong

unread,
Mar 13, 2016, 10:55:53 AM3/13/16
to ustc...@googlegroups.com
作者在此……
 
只能抵抗包长攻击并且overhead太大。我自己都不开包长混淆了。
更严重的问题是GFW看到加密的udp就直接丢包。
 
--
Justin Wong
 

蒲肖肖

unread,
Mar 13, 2016, 11:08:52 AM3/13/16
to USTC_LUG
不知道 GoHop 跳端口的频率是多少？受你的论文的启发，我实现了一个  stateless VPN，0.5 秒跳一次端口，通过压缩和随机 padding 改变包长，似乎没观察到太多的丢包，不过也可能与网络环境相关，只在家里的移动宽带和阿里云、美团云上使用过。

在 2016年3月13日星期日 UTC+8下午10:55:53，Justin Wong写道：

Justin Wong

unread,
Mar 13, 2016, 11:10:09 AM3/13/16
to ustc...@googlegroups.com
每个包都跳，比较naive
求你的代码看看

蒲肖肖

unread,
Mar 13, 2016, 11:13:43 AM3/13/16
to USTC_LUG
在此，代码比较乱，轻拍 https://github.com/XiaoxiaoPu/muon
每个包都跳，那服务端和客户端如何保持端口是一致的？我的端口跳跃是受 https://twitter.com/shell909090/status/644078463528206336 启发，类似于 TOTP，所以不需要协商

在 2016年3月13日星期日 UTC+8下午11:10:09，Justin Wong写道：

Coiby Xu

unread,
Mar 14, 2016, 12:50:46 AM3/14/16
to ustc...@googlegroups.com
多谢提供详尽的思路！  目前对TCP/UDP通信编程基本不了解，等哪天被逼急了，试试看，

对了，昨天查方案，看到一个新工具V2ray

动态端口，可以在5min时间内使用一个端口，时间过了就会向客户端发起端口请求，约定一个端口，然后使用另一个端口通信，这样可以有效防止GFW的骚扰！

基于时间的验证，就是说服务器的时间和客户端的时间不能相差大于2min，超出了可能就会无法通信！

VPS中转，这个就不用说了，它可以中转流量，前提是你要有一个国内的服务器，然后让所有的流量通过国内的服务器，这样可以有效突破运营商限制！

自带路由表，就像PAC模式一样，客户端不需要设定，服务器可以分配路由！

—新出炉的爬墙姿势

Bojie Li

unread,
Mar 14, 2016, 7:56:24 AM3/14/16
to USTC_LUG
大鹰你这都敢发 paper，太厉害了……

这个伪装包长特征的思路感觉蛮不错的，只要 GFW 的机器学习没有专门训练识别这种伪装（利用时间特征和双向流量差），应该是挺难识破的。

至于加密 UDP 包被封的问题，可以尝试用 HTTP 绕过，只是会慢一些（由于 TCP 拥塞控制和丢包重传，不过 socks5 也有同样的问题）。

通过跳端口号来对抗流量特征分析，我觉得 GFW 应该能发现异常。跳端口号的特征很像是端口扫描，大多数防火墙都能检测出来。识别端口扫描就是要记录每个目标 IP 有多少个 distinct 端口被访问了，如果只是要粗略统计的话，sketch-based 的算法比较高效，比如这篇 paper：
Minlan Yu et al., Software Defined Traffic Measurement with OpenSketch, NSDI'13

端口扫描检测的参考实现 (Count-Min sketch with 3 hash banks, each entry is a 64-bit bitmap sketch)
static uint count_zero(ulong x)
{
    uchar ret = 0;
    for (int i = 0; i < 64; ++i)
        if (x & ((ulong)1 << i))
            ret++;
    return ret;
}

bool detect_port_scan(port, ip) {
    ulong hp = 1 << hash0(port);
    uint i1 = hash1(ip);
    uint i2 = hash2(ip);
    uint i3 = hash3(ip);
    ulong curh1 = h1[i1] | hp;
    uchar cnt1 = count_zero(curh1);
    ulong curh2 = h2[i2] | hp;
    uchar cnt2 = count_zero(curh2);
    ulong curh3 = h3[i3] | hp;
    uchar cnt3 = count_zero(curh3);          

    h1[i1] = curh1;
    h2[i2] = curh2;
    h2[i3] = curh3;

    uchar cnt = min(min(cnt1, cnt2), cnt3);
    return (cnt >= threshold);
}
Reply all
Reply to author
Forward
0 new messages