方院士近况(一)

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