v2ray与openvpn配置过程中的心得与记录

v2ray与openvpn配置过程中的心得与记录:

1.关于v2ray之动态端口:

 经观察,v2ray的动态端口是十分有必要开启的.GFW对于单ip,单端口,同时未加入白名单的ip,将会进行重点探测,并进行限制.当然,越长时间的大流量使用单个ip更加容易造成GFW的”重点关照”,所以,这样看来,动态端口可以在一定的时间内另服务的ip的存活时间更长点,以下是v2ray白话文教程中对于动态端口的描述:

 通常情况下,V2Ray 的服务器端使用一个固定的端口来接收客户端的数据。这个端口由配置文件中的 port 属性指定如果同一端口通信时间过长,或流量过大,则有可能被服务商限速。于是V2Ray 提供了一个功能来动态调整通信端口。

 在新的配置中,V2Ray 服务器端依然使用一个主端口(即上文的 port)接收请求,但可以配置一个绕路(detour)的特性。配置之后,服务器会主动告诉客户端,使用一个新的端口 X 来通信,X 是一个范围(可配置)内随机选取的值。此端的有效期为 Y 分钟,客户端和服务器都会遵守这个时间,到期之后,客户端会继续向服务器请求新的端口来通信。以此循环。

 以下为corpama_HK服务器中v2ray配置的参照样例:
配置文件样例

2.关于v2ray与shadowsocks的性能比较:

 早在我的shaowsocks被封之后,我便在各大论坛上搜索过各个协议,方案的速度与性能比较,现贴出我找到的评测文章中最详细的一篇:

引用于:https://thinkgust.blogspot.hk/

V2Ray 和 Shadowsocks 的比较也是一个常见问题。既然我们有了一个性能测试的工具,那就一起测一下吧。
V2Ray SS CFB: V2Ray 中的 Shadowsocks 实现,AES-128-CFB 加密方式;
SS-Libev CFB: Shadowsocks libev 2.5.6,AES-128-CFB 加密方式,客户端 ss-tunnel,服务器端 ss-server;
SSR-PY CFB: ShadowsocksR 最新的代码(2017-01-20),AES-128-CFB 加密方式。其它的参数都是默认的:auth_aes128_md5、tls1.2_ticket_auth_compatible。
OTA 在所有 Shadowsocks 中都启用了。
实验结果(数据量:10 GB / 连接):
实验数据
解读如下:
VMess 的速度优于 Shadowsocks;
比起 ss-libev 和 ssr-python,V2Ray 在多并发连接的场景中更有优势

3.关于gfw的屏蔽方式:

引用于:https://thinkgust.blogspot.hk/

 GFW的应对措施是三步中最明显的,因为它最直接。GFW的重建过程和协议分析的过程需要耐心的试探才能大概推测出GFW是怎么实现的。但是GFW的应对手段我们每天都可以见到,比如连接重置。GFW的应对目前可以感受到的只有一个目的就是阻断。但是从广义上来说,应对方式应该不限于阻断。比如说记录下日志,然后做统计分析,秋后算账什么的也可以算是一种应对。就阻断方式而言,其实并不多,那么我们一个个来列举吧。

 -封IP

 一般常见于人工检测之后的应对。还没有听说有什么方式可以直接使得GFW的机器检测直接封IP。一般常见的现象是GFW机器检测,然后用TCP RST重置来应对。过了一段时间才会被封IP,而且没有明显的时间规律。所以我的推测是,全局性的封IP应该是一种需要人工介入的。注意我强调了全局性的封IP,与之相对的是部分封IP,比如只对你访问那个IP封个3分钟,但是别人还是可以访问这样的。这是一种完全不同的封锁方式,虽然现象差不多,都是ping也ping不通。要观摩的话ping twitter.com就可以了,都封了好久了。
 其实现方式是把无效的路由黑洞加入到主干路由器的路由表中,然后让这些主干网上的路由器去帮GFW把到指定IP的包给丢弃掉。路由器的路由表是动态更新的,使用的协议是BGP协议。GFW只需要维护一个被封的IP列表,然后用BGP协议广播出去就好了。然后国内主干网上的路由器都好像变成了GFW的一份子那样,成为了帮凶。

方式1

如果我们使用traceroute去检查这种被全局封锁的IP就可以发现,IP包还没有到GFW所在的国际出口就已经被电信或者联通的路由器给丢弃了。这就是BGP广播的作用了。

 -DNS劫持

 这也是一种常见的人工检测之后的应对。人工发现一个不和谐网站,然后就把这个网站的域名给加到劫持列表中。其原理是基于DNS与IP协议的弱点,DNS与IP这两个协议都不验证服务器的权威性,而且DNS客户端会盲目地相信第一个收到的答案。所以你去查询facebook.com的话,GFW只要在正确的答案被返回之前抢答了,然后伪装成你查询的DNS服务器向你发错误的答案就可以了.

方式2

 -TCP RST阻断

 TCP协议规定,只要看到RST包,连接立马被中断。从浏览器里来看就是连接已经被重置。我想对于这个错误大家都不陌生。据我个人观感,这种封锁方式是GFW目前的主要应对手段。大部分的RST是条件触发的,比如URL中包含某些关键字。目前享受这种待遇的网站就多得去了,著名的有facebook。还有一些网站,会被无条件RST。也就是针对特定的IP和端口,无论包的内容就会触发RST。比较著名的例子是https的wikipedia。GFW在TCP层的应对是利用了IPv4协议的弱点,也就是只要你在网络上,就假装成任何人发包。所以GFW可以很轻易地让你相信RST确实是Google发的,而让Google相信RST是你发的。

方式3

 -封端口

 GFW除了自身主体是挂在骨干路由器旁路上的入侵检测设备,利用分光技术从这个骨干路由器抓包下来做入侵检测 (所谓 IDS),除此之外这个路由器还会被用来封端口 (所谓 IPS)。GFW在检测到入侵之后可以不仅仅可以用TCP RST阻断当前这个连接,而且利用骨干路由器还可以对指定的IP或者端口进行从封端口到封IP,设置选择性丢包的各种封禁措施。可以理解为骨干路由器上具有了类似“iptables”的能力(网络层和传输层的实时拆包,匹配规则的能力)。这个iptables的能力在CISCO路由器上叫做ACL Based Forwarding (ABF)。而且规则的部署是全国同步的,一台路由器封了你的端口,全国的挂了GFW的骨干路由器都会封。一般这种封端口都是针对翻墙服务器的,如果检测到服务器是用SSH或者VPN等方式提供翻墙服务。GFW会在全国的出口骨干路由上部署这样的一条ACL规则,来封你这个服务器+端口的下行数据包。也就是如果包是从国外发向国内的,而且src(源ip)是被封的服务器ip,sport(源端口)是被封的端口,那么这个包就会被过滤掉。这样部署的规则的特点是,上行的数据包是可以被服务器收到的,而下行的数据包会被过滤掉。
 如果被封端口之后服务器采取更换端口的应对措施,很快会再次被封。而且多次尝试之后会被封IP。初步推断是,封端口不是GFW的自动应对行为,而是采取黑名单加人工过滤地方式实现的。一个推断的理由就是网友报道,封端口都是发生在白天工作时间。
在进入了封端口阶段之后,还会有继发性的临时性封其他端口的现象,但是这些继发性的封锁具有明显的超时时间,触发了之后(触发条件不是非常明确)会立即被封锁,然后过了一段时间就自动解封。目前对于这一波封SSH/OPENVPN采用的以封端口为明显特征的封锁方式研究尚不深入.

方式4

 -HTTPS间歇性丢包

 对于Google的HTTPS服务,GFW不愿意让其完全不能访问。所以采取的办法是对于Google的某些IP的443端口采取间歇性丢包的措施。其原理应该类似于封端口,是在骨干路由器上做的丢包动作。但是触发条件并不只是看IP和端口,加上了时间间隔这样一个条件。

4.关于OpenVPN在国内的使用:

 经过多次的实验,openvpn以及它的附属衍生项目softether均不可在国内正常使用,使用时间只要超过十分钟便会触发GFW的检测机制,进而导致服务器的ip被封,所以,在国内使用单纯的openvpn是绝对不可行的,即使你是在国内两台服务器之间建立加密隧道也会被掰,其原因已在之前引用的文段中说明,同时因为省级骨干网络也部署有GFW,所以这导致即使是国内的服务器间的加密通讯也是不可的,所以,openvpn在国内的使用时必须对其进行魔改,而其基本思路便是利用v2ray的加密与混淆功能为openvpn流量套上一层外壳,并混淆后再发出,以增加GFW的检测难度,较详细的配置过程已放在:利用V2Ray混淆加密OpenVPN流量以规避GFW的干扰与探测中.