方院士近况(一)

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

xen 动态迁移

前提是两台机器共享存储设备,比如 NFS。
/etc/xen/xend-config.sxp 文件需要修改的指令,不解释,直接看上面的注释,注意,两台机器的配置需要一模一样:
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address ”)
(xend-relocation-hosts-allow ”)

重启:
# /etc/init.d/xend restart

修改 exports 文件:
/data/xen/web_1    192.168.1.0/24(rw,no_root_squash)

启动 nfs:
# /etc/init.d/portmap start
# /etc/init.d/nfs start

注意防火墙,开始迁移:
# xm migrate id 192.168.1.220 -l

ref:
http://www.virtuatopia.com/index.php/Migrating_Xen_domainU_Guests_Between_Host_Systems

通过 modprobe 彻底禁用 netfilter

要禁用 iptables 很简单,曲线救国,禁用掉模块就好了:
$ cat /etc/modprobe.d/blacklist-iptables.conf
alias ip_tables off

alias iptable off
alias iptable_nat off
alias iptable_filter off

alias nf_nat off
alias nf_conntrack_ipv4 off
alias nf_conntrack off
alias nf_defrag_ipv4 off

alias x_tables off

alias xt_limit off
alias xt_tcpudp off
alias xt_multiport off

alias ipt_REJECT off
alias ipt_LOG off

再启用上面的文件之前,记得先把 iptables 规则清空、rmmod 掉对应的模块。这也是另外一种防止 『dropping packet』 的方式。
netfilter 的模块在 /lib/modules/2.6.32-38-server/kernel/net/ipv4/netfilter/ 里面。
Continue reading

如何设置邮箱以及密码

下面这个是写给对安全有比较高要求的同学,如果你是个 shitizen,每天仅仅是用用百毒扣扣看看猫扑,完全可以忽略下面的文字。

这年头不光密码要做的足够的复杂,连邮箱都需要有一定级别的强度,不然遇到 #MircoSHIT 这种二货,只能等死了。

对于邮箱来说,比如一个叫王人人的同学,使用下面这些组成的邮箱去注册人人网是很容易被人『猜』出来的:
[email protected]
[email protected]
[email protected]
[email protected]

[email protected]

如果他恰巧用了上面的某些邮箱,然后又注册了 Skype,他的账户就裸奔了。
而像 『[email protected]』这类的及其变形则比较适合做注册之用,如果对安全特别高,可以 Google『Disposable Temporary E-Mail』,或者像中情局的那位大大跟她情人一样,共用一个邮箱草稿。

另外一点重要的是,务必一个网站一个邮箱,对应一套独特的密码。
对于密码的选择,最初是生成一套相对有规律的密码,然后做 sha1sum,不过依然不够强悍,还有很可能被 crack 掉,后来干脆直接随机生成,大小写、数字、特殊字符必须包含,这会涉及到管理问题,纯用脑子记明显是不可能,需要第三方的工具帮你来记忆,具体的操作,很多文档都说的很好,比如这几个(1, 2, 3),不再叙述。

很多人都是出了问题再事后补救,第一次可以,第二次再出现类似的问题就不好了。

r8169 网卡驱动

某台 11.10  3.0.0-12-generic 的机器网络异常,ifconfig 有大量的丢包,ssh 时不时 hung 住:
# ifconfig
eth0      Link encap:Ethernet  HWaddr 44:44:d6:b4:1e:7e
          inet addr:10.18.102.201  Bcast:10.18.102.255  Mask:255.255.255.0
          inet6 addr: fe80::5604:a6ff:feb4:1e7e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:21274 errors:0 dropped:21274 overruns:0 frame:21274
          TX packets:12028 errors:0 dropped:81 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:9653617 (9.6 MB)  TX bytes:2188437 (2.1 MB)
          Interrupt:46 Base address:0xc000

syslog 有大量的如下信息:
Oct 10 11:21:29 jaseywang kernel: [  905.012397] r8169 0000:04:00.0: eth0: link up
Oct 10 11:21:32 jaseywang kernel: [  908.289727] r8169 0000:04:00.0: eth0: link up
Oct 10 11:22:19 jaseywang kernel: [  954.627060] r8169 0000:04:00.0: eth0: link up
Oct 10 11:23:20 jaseywang kernel: [ 1015.182140] r8169 0000:04:00.0: eth0: link up
Oct 10 11:23:37 jaseywang kernel: [ 1033.004186] r8169 0000:04:00.0: eth0: link up
Oct 10 11:24:16 jaseywang kernel: [ 1071.335548] r8169 0000:04:00.0: eth0: link up
Oct 10 11:25:02 jaseywang kernel: [ 1117.070819] r8169 0000:04:00.0: eth0: link up
Oct 10 11:25:42 jaseywang kernel: [ 1156.881366] r8169 0000:04:00.0: eth0: link up
Oct 10 11:26:13 jaseywang kernel: [ 1188.351029] r8169 0000:04:00.0: eth0: link up
Oct 10 11:26:43 jaseywang kernel: [ 1217.619851] r8169 0000:04:00.0: eth0: link up
Oct 10 11:26:50 jaseywang kernel: [ 1225.107516] r8169 0000:04:00.0: eth0: link up
Oct 10 11:26:52 jaseywang kernel: [ 1227.069138] r8169 0000:04:00.0: eth0: link up
Oct 10 11:26:54 jaseywang kernel: [ 1228.735701] r8169 0000:04:00.0: eth0: link up
Oct 10 11:26:56 jaseywang kernel: [ 1231.040210] r8169 0000:04:00.0: eth0: link up
Oct 10 11:27:28 jaseywang kernel: [ 1262.864740] r8169 0000:04:00.0: eth0: link up
Oct 10 11:28:07 jaseywang kernel: [ 1302.013430] r8169 0000:04:00.0: eth0: link up

更换网线无果,想到可能是网卡驱动的问题,确实是 r8169 这个驱动惹得祸,10 年就有人发现此类问题了。 将其更换为 r8168。下载这个链接的驱动。

卸载当前的 r8169:
# rmmod r8169

解压安装:
# tar zjvf r8168-8.032.00.tar.bz2
# cd r8168-8.032.00/
# ./autorun.sh

完毕,检查确认:
# lsmod  | grep r8168
r8168                 244911  0

将 r8169 加入 blacklist:
$ cat /etc/modprobe.d/blacklist-r8169.conf:
blacklist r8169

基本是把这个的链接翻译了一遍。这篇文章也确认了在 Ubuntu 的 10.10, 11.04, 11.10 版本在使用 kernel 默认的驱动时上会出现此类的问题。