OpenVPN over HTTP 突破Layer 7 QoS的宽带网速限制

Why

我家里用的是一家三线的便宜小区宽带,标称有几个M的带宽,虽说有些资源确实能达到这个速度,但发现直连VPN的速度从来都没上去过,大概30k/s,不难猜测到,ISP在链路上做了手脚,即所谓的Layer 7 Priority QoS。因为入线是100M进宅然后PPPoE,不像ADSL那样直接物理链路就限制了连接速度,在链路层做QoS也很合理。平时HTTP打开网页、下载到合适链路的话很容易达到满速,而OpenVPN的TCP/UDP包估计就被当成P2P流量被限制了,所以网速一点都不给力。

用OpenVPN科学上网是最稳定最灵活的方式了,它基于udp/tcp的协议,比pptp、l2tp等直接跑IP包的开销虽说大一点,但好处就是容易把数据流重新封装,避开链路的关卡。显然它也支持HTTP代理,所以把OpenVPN变成HTTP协议,就可以在家里跑上满速的VPN。

How

OpenVPN要过HTTP代理,只能用TCP协议,这个需要服务端和客户端都要稍作修改。

Polipo as Tunnel Proxy

首先在VPS上安装一个http proxy,我选择polipo,比较轻量级。

apt-get install polipo

配置也是很简单的,编辑/etc/polipo/config,原来的配置文件基本全都是注释,直接在文件底部加上:

proxyAddress = "0.0.0.0"
proxyPort = 8128
authCredentials = "user:password3.141592654"
tunnelAllowedPorts = 1194
  • polipo默认只监听本地的127.0.0.1,要拿来做服务就要监听外网
  • polipo默认监听8123,为了不让扫代理的盯上,自己随便写个端口
  • 加上http basic验证,这个密码不要紧,后面让openvpn自动应答
  • 允许管道模式连接openvpn的1194端口

OpenVPN

Server

服务端倒是不需要很多配置,确定是tcp模式监听连接(我是多开一个openvpn server,子网错开,个人喜欢吧)

Client

客户端就要指定使用代理的方式:

remote 127.0.0.1 1194
http-proxy YOUR.VPS.IP.HERE.com 8128 pw.txt
http-proxy-retry

这个pw.txt是上述的HTTP的认证信息,用户名密码各一行。

现在连接OpenVPN,可以看到连接过程的Log有这么几句,基本就确定OpenVPN over HTTP成功了!

Sun Mar  4 19:12:58 2012 Attempting to establish TCP connection with 199.101.103.107:8192 [nonblock]
Sun Mar  4 19:12:59 2012 TCP connection established with [IPADDR]:8128
Sun Mar  4 19:12:59 2012 Send to HTTP proxy: 'CONNECT 127.0.0.1:1194 HTTP/1.0'
Sun Mar  4 19:12:59 2012 Attempting Basic Proxy-Authorization
Sun Mar  4 19:13:00 2012 HTTP proxy returned: 'HTTP/1.1 200 Tunnel established'

Related

最后透露一下我的科学上网环境是在跑OpenWRT的路由器上跑VPN,然后配合chnroute的路由表,当然dnsmasq也经过配置负责把国内常用域名的解释交给国内的114.114.114.114服务器,这样基本一回家手机kindle电脑等全都是翻墙环境,而且速度非常良好。

Reference

文章分类 Networking, Unix/Linux 标签: , , ,
16 comments on “OpenVPN over HTTP 突破Layer 7 QoS的宽带网速限制
  1. 小梦说道:

    问下VPS的用的是哪家的主机?价格如何?

  2. 小梦说道:

    amazon不好吗?rackspace的怎么样呢?
    我想找个地方做我网站的主基地

    • BOYPT说道:

      amazon不便宜。如果你不在意这个价钱,linode应该不错,19刀/m起表,东京机房,国内过去延时较低。

      • 小梦说道:

        3u

        • 小梦说道:

          我个人比较讨厌xen的VM,原因如下:
          1.xen的半虚拟层对于初期创业的成本,比较有价格优势。但是,如果Xen的虚拟化程度过高,则有可能导致性能问题。

          2.一旦选择一家,个人很难将大量数据迁出。海外运营就更不可能。这样会陷入xen虚拟化提供商的泥潭,手中有把柄在人家手中 ,议价优势丧尽。

          3.网站一旦做上去,xen的流量收费成本过高。这样会使网站利润下降。这个负担太恐怖。

          hadoop这样的数据存储很容易提供XEN所不能低成本的HA的数据存储解决方案。
          如果不满意主机提供商,则可以直接把硬盘走人。貌似很有议价能力。
          但是这个初期成本会比较高阿,而且跨国高可用服务很难提供。

          • BOYPT说道:

            这些结论是在啼笑皆非,如果对虚拟化技术不了解且存疑虑,尽可避免使用;

            既然不计成本还考虑数据把柄,大可自己去开个数据中心。

            hadoop是数据方案,xen是虚拟层方案,风马牛不相及。

          • yegle说道:

            Is this a joke? Seriously this is a sick joke.

      • 小梦说道:

        你用iperf测试过吗?有数据结论?

  3. 小梦说道:

    请问主人对这个问题有什么想法呢?

  4. yegle说道:

    这不蛋疼了么…有http代理还跑个VPN over它一下…

  5. tony说道:

    你这个能实现吗? 带宽速度不是idc限制好了吗? 如果要翻墙,vpn拨通了就没有内容限制了,至于你说的突破速度限制,这个理论上行不通吧??

    • BOYPT说道:

      现在的网络接入设备先进好多了,知道你每个链接是什么应用发起的,这就是所谓layer 7 QoS。 我文章说的情况是,限制了p2p的任意端口tcp/udp通信,限速在30K/s,检测到HTTP特性则放宽,500K/s+

      • tony说道:

        现在的电信带宽都没有p2p限制了,只是带宽速度限制了,所以,这个也就不实用了。

  6. Birdke说道:

    我也正好遇到这个问题,自己用的是小区宽带,只要openvpn的流量一上去就马上丢包。我用公司的网络就很正常。。。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*