方院士近况(三)

时隔一年,看看最新的变化,总的来说,情况变的更坏了。
最明显的发现就是仅仅有一个好的 tunnel 是远远不够的,尤其像我用的这个号称 20M 的连通,半月丢一周包的网络,再牛逼的 tunnel,遇到这种只有到了凌晨通向亚太以及太平洋西海岸的丢包率才会下降到 10% 以下的烂网只能洗洗睡了,现在从这个小区出去的,10% 的丢包已经是很乐观的情况了,当然访问大中华局域网是没有任何问题的。
所以,除了一个好的 tunnel 之外,一个 ping 了不丢包或者在高峰时期丢很少的包的网络是非常非常重要的,因此,我最终放弃了之前在 US、JP 以及其他几个地区持有的 VPS,转战到了欧洲以及香港等非主流区域,但是依然难免会遇到丢包的情况。
其实这跟方院士没太大关系,主要还是连通的国际出口太烂,具体体现在带宽太小,或者机器的处理能力太烂,公司电信的出口则不存在这个问题。最初我投诉一下,他们修复一下,过了半个月继续丢包我继续投诉,后来实在没这空跟一群猪脑耗着,索性不投诉了,靠他们解决问题母猪真的会上树了。

要解决这个问题,唯一的办法就是你在海外有足够多的节点资源,哪里坏了切哪里。这事不少服务商都在做,我从前年开始,除了自己搞一套之外,还陆陆续续的试了几个。都能 work,但是做的都比较的 dirty。

  1. 最有代表性的就是 VPN/SSH 之类的,这个没什么技术含量,哪个节点连接不上了切换就好了
  2. 后来还用了几个月的 "highly sophisticated yet extremely easy-to-use Web and Apps accelerator",设置确实很简单,但是离我想要的还差很远
  • 无法做白名单,我需要绝大部分的都走 proxy,很少的走默认的路由
  • 每个月的流量对我来说太少,因此不能走全局模式,依然是上面的问题
  • 没想象中的智能,节点挂了照样没法智能的切换
  • 最悲伤的是,Twitter 上了 SPDY,据说是因为 iOS 无法做 proxy 了,于是该服务就没法用 Twitter,这对我来说就等于是废了

总结一下,要持续的跟方院士做斗争,需要:
1. 好的基础网络环境,低丢包率的小众低调私有 tunnel,没有比这个更重要更基础的了。其实上面的还不是最坏的情况,最坏的情况是什么了?好不容易国内的不丢包了,国际出口也不丢包了,HE 却在狂丢包 :-(

2. 作为备份,一个完备的商业 proxy 服务,这个需要平时多用多发现

希望我写方院士近况(四)的时候内容只有三个字「肉翻了」。

使用 tunnel 浏览网页的重要性

(下一代)防火墙、上网行为管理、应用网关什么的就不说了;IPS、IDS 也已经出现了好多年了;在内网方台设备你的 gmail 信息就被一览无余了;随便一个监管单位都可以在 IDC 放(数十)台审查设备。下面介绍一些相对较时髦高端的东西,应该都是运营商级别的。没有做不到只有想不到,花这么大人力财力物力干嘛了?看看这几个(1, 2)。

结合乌云上的这篇《你们以为运营商只是HTTP插点广告而已么,图森破啊,呵呵》看看就知道了。

之前读书的时候,人见人骂的那家,dr.com,可以看看他们做的产品,尤其是这个

所以说,使用 tunnel,不仅仅是为了保证信息的流通,同时也是保证信息安全的一个重要的手段。

方院士近况(二)

唉。

1. obfsproxy
在编译安装 obfs 之前需要安装下面这些编译工具:
# apt-get install automake build-essential pkg-config

安装最新版本的 libevent2:
# mkdir /usr/local/libevent2/
# wget https://github.com/downloads/libevent/libevent/libevent-2.0.21-stable.tar.gz
# ./configure --prefix=/usr/local/libevent2/
# make && make install

obfsproxy server 端的部署:
# git clone https://git.torproject.org/obfsproxy.git
# cat /etc/bash.bashrc

export libevent_CFLAGS=-I/usr/local/libevent2/include
export libevent_LIBS="-L/usr/local/libevent2/lib -levent"
export LD_LIBRARY_PATH=/usr/local/libevent2/lib
# ./autogen.sh
# ./configure
# make
# make install

假设服务器监听本地的 ssh 65534 端口:
# obfsproxy --log-min-severity=info obfs2 --shared-secret=password --dest=127.0.0.1:65534 server 210.XX.XX.XX:2222

对于客户端,mac 下使用 brew 安装:
# brew tap mtigas/tor
# brew install mtigas/tor/obfsproxy
# obfsproxy --log-min-severity=info obfs2 --dest=210.XX.XX.XX:2222 --shared-secret=password client 127.0.0.1:8022
# ssh user@127.0.0.1 -p 8022 -D 65533

obfs 其实是一个单独的项目,除了给 ssh 做混淆,还可以给 vpn 等做混淆,这两篇(1, 2)文章还给出了 vpn 的混淆方法。

Continue reading

方院士近况(一)

1. tls_process, killed expiring key
在客户端开启 OpenVPN 过一段时间出现如下的 log:
"TLS: tls_process, killed expiring key"

然后就『断网』了。
假设排除方院士的强大威力,查看了文档得知,OpenVPN 每 60min 会商量一次静态密钥也就是对称密钥用来加密端对端的通讯。当两端过了 60min 重新商讨静态密钥时,就会出现上面的情况。
需要注意的是,重新商讨并不会重启 OpenVPN,默认情况下,old key 会被继续使用一段时间,默认是 60min,这个由 tran-window 决定。两个参数的单位都是 s。
另外还有一点,reneg-sec 可以两端都设置,以最小的那个作为整个重新协商时间的间隔,因此如果客户端设置了 86400,而服务端没有设置,则还是 60min 协商一次,因此需要两端都协商,或者将一端置为 0 将其禁用,然后在另一端设置协商的时间间隔。

现在把方院士的因素考虑进去,这个问题之前也有遇到过,不过并没有导致『断网』的现象发生,最近经常是遇到该 log 后,就彻底拜拜了。

2. TLS Error: TLS key negotiation failed
Wed Oct 24 15:31:07 2012 MULTI: multi_create_instance called
Wed Oct 24 15:31:07 2012 122.122.139.193:37929 Re-using SSL/TLS context
Wed Oct 24 15:31:07 2012 122.122.139.193:37929 LZO compression initialized
Wed Oct 24 15:31:07 2012 122.122.139.193:37929 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Wed Oct 24 15:31:07 2012 122.122.139.193:37929 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Oct 24 15:31:07 2012 122.122.139.193:37929 Local Options hash (VER=V4): '14168603'
Wed Oct 24 15:31:07 2012 122.122.139.193:37929 Expected Remote Options hash (VER=V4): '504e774e'
Wed Oct 24 15:31:07 2012 122.122.139.193:37929 TLS: Initial packet from [AF_INET]122.122.139.193:37929, sid=63cabcef 2f672a5a
Wed Oct 24 15:31:51 2012 122.122.139.193:38205 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Oct 24 15:31:51 2012 122.122.139.193:38205 TLS Error: TLS handshake failed
Wed Oct 24 15:31:51 2012 122.122.139.193:38205 SIGUSR1[soft,tls-error] received, client-instance restarting

使用 UDP 协议,在 TLS 握手阶段就直接挂了,然后会不断的尝试冲连,依然连接失败。换用 TCP 可以暂时避免此类问题。

3. UDP: bad checksum
公司出口机器的 log,大量的 bad checksum,经测试,应该是只要是海外的 DNS 就会出现下面类似的 log:

Oct 24 10:56:43 gateway kernel: [5538087.810633] UDP: bad checksum. From 8.8.4.4:53 to 122.122.139.193:50331 ulen 57
Oct 24 10:56:43 gateway kernel: [5538088.067360] UDP: bad checksum. From 8.8.4.4:53 to 122.122.139.193:36779 ulen 57
Oct 24 10:57:44 gateway kernel: [5538149.655353] UDP: bad checksum. From 8.8.4.4:53 to 122.122.139.193:36168 ulen 57
Oct 24 10:58:48 gateway kernel: [5538213.186756] UDP: bad checksum. From 8.8.4.4:53 to 122.122.139.193:58376 ulen 59

这个比 DNS 劫持、污染更牛逼。通过 ssh 远程解析 DNS 可以一定程度缓解此类问题。

另外,请分清劫持跟污染的区别。
劫持是指直接劫持了 DNS 服务器,控制其解析权,返回一个错误的信息。
污染(DNS cache poisoning)是指用户通过 53 UDP 端口对 NS 服务器发出域名解析的请求,方院士一旦发现与规则相匹配的请求,则伪装成 NS,直接给用户返回一个错误的 IP。这个的前提条件是 IDS 返回 UDP 包的速度比真正 NS 返回的速度快,用户只接受第一个返回的结果。

可以更换 DNS 来解决 DNS 劫持的问题,但是不能解决污染的问题。

总之,猫抓老鼠的过程,历史的规律告诉我们,老鼠总是比猫活的更长久更坚强。

ref:
http://openvpn.net/archive/openvpn-users/2007-07/msg00104.html

记录几个 DNS

前两个太出名了,基本处于半墙状态,丢包率在 50% 左右。接下来的两个大家也应该都知道,后面的四个分别为 tw 以及 hk 的。拿出来跟大家共享下。
vpn 全局之后,恢复,各项解析正常。

8.8.8.8
8.8.4.4

208.67.222.222
208.67.222.220

168.95.192.1
168.95.192.2
203.80.96.9
203.80.96.10

公司主站域名放在国外解析,昨天上午某些无耻的运营商,不排除 wfg 的可能,屏蔽了公司在国外的域名解析商的 dns 服务,使用国内 DNS 的用户出现大面积的访问中断。紧急搬回国内,使用那个很山寨的啥 pod 服务,到目前(10/16/2011 10:30)为止,大部分地区已经恢复。

在局域网内做(移动)互联网真是件悲剧的事!