Networking

今天发现一台国内的机器流量异常，检查发现这台机器上运行的 DNS 缓存服务被人用作了攻击的放大杠杆，这里简单记一下。

发现流量异常，首先当然是检查服务器上的 TCP 会话，发现了一些不太正常的东西，关闭之后流量减少，但仍然没有回到正常水平。

于是听包。这一听发现一大片：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

07:39:53.271744 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.271772 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.271784 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.271792 IP 158.XX.XX.238.53019 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.274225 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.274252 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.274262 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.274270 IP 92.XX.XX.148.31650 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)
07:39:53.291822 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291850 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291860 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291869 IP 158.XX.XX.238.13616 > XX.XX.XX.XX.53: 56854+ [1au] ANY? isc.org. (36)
07:39:53.291877 IP 92.XX.XX.148.56278 > XX.XX.XX.XX.53: 23600+ [1au] ANY? isc.org. (36)

近日， netmap 已经正式进入 -CURRENT (r227614)。目前联编带 netmap 的内核需要做下面的操作：

% cd /usr/src/sys
% patch -p0 < dev/netmap/head.diff

然后在内核联编配置中加入：

现时 InfiniBand 硬件已经相当廉价。有些 4x 的 InfiniBand 适配器已经可以在 $100 以内拿到。由于 InfiniBand 可以提供高带宽、低延迟的数据传输，而且点对点对联不需要交换机，因此可以以十分低廉的价格满足近实时同步，或分离存储服务这样的需求。

今年年初的时候， Isilon、我厂 和 Panasys 联合资助了 FreeBSD 上的 InfiniBand 协议栈的实现。这个实现基于 OpenFabrics Alliance 的 OFED，对基于 Mellanox 芯片的多种常见的 InfiniBand 卡都提供了支持。这些代码目前已合并至 FreeBSD 的开发主线，并将随 FreeBSD 9.0-RELEASE 发布。

鸡蛋不能放在同一个篮子里，特别是 DNS 服务器这样的鸡蛋……在没拿到AS之前，至少也应该做到跨ISP冗余才好。

今天 BAFUG 活动， Luigi Rizzo （十年前提出DEVICE_POLLING概念的那哥们） 带来了他在 FreeBSD 上新实作的 netmap。

简单来说 netmap 实际上是提供了一种让用户程序以一致的接口直接访问网卡（收发包且zero copy）的方法。Luigi Rizzo 的测试中，用以 1050MHz 的单核，在很普通的万兆网卡上就可以轻松达到 14.8 Mpps 了，每个包的开销大约是90个时钟周期。

之前一直没什么概念，今天看了微软的 KB 321169 的解释，大致如此：

• 客户端 (SMB Redirector) 如果启用了 security signature，则必须等待命令处理完成才会发出下一条SMB；
• 服务器端如果启用了延迟ACK，则可能需要过200ms (Windows 2000)才会给出ACK回应

不过感觉这个解释依然不是很有说服力—-文档上说，SMB服务器端是需要对 NT_TRANSACT_NOTIFY_CHANGE 给出回应的，那么这种情况下ACK不就回应回来了吗？或者说，只要收到了 ACK 就说明服务器端已经处理了这条 SMB？哪位帮忙理解一下？

2011年6月8日是 Internet Society 倡导的世界 IPv6 日，许多著名的互联网公司都将在这一天测试全面开放 IPv6 访问；中国地区的 IPv6 日网站可以在 这里 找到。

在很久很久以前就有人提出IPv4将要用完的事情，然而当时IPv4地址空间还很充裕，而且NAT还没有非常广泛地使用。于是这事说着说着就变成了一个狼来了的故事，不停地有人嚷嚷IPv4地址要用完了，而这个用完的日期则在600天、400天和300天附近的时候反复来回地拉锯了很久。

和狼来了那个故事稍微不太一样的是，喊狼来了的那些人，例如大的IPv6 ISP和运营商已经早早做好了准备，而那些把这故事当做狼来了而毫无警惕的人则只好手忙脚乱地应付了。

阿宅的一大恶趣味是喜欢仅仅因为"Because we can"而去做一些事情，我也是。我自己的网站的第一个DNS AAAA记录是2007年7月31日创建的，而FreeBSDChina.org于2007年8月4日也已经开始在IPv6上提供服务。由于当时条件所限，在当时我能够使用的唯一的测试手段是登录到一台位于北美的有双栈支持的测试服务器来进行测试。到了北美以后，因为这里的住户 IP 地址是很少发生变化的，我开始在家搭建 IPv6 路由，到后来在北美地区托管了一台服务器，基本上一直都是以双栈的方式接入Internet了。目前，我拥有两个/48的IPv6地址段和两个/64的IPv6地址段。

时间过得很快。今年年初的时候我看到了一个报道说 IPv4 地址大约还剩不到1年了，于是开始关注相关的报道。根据 Hurricane Electric 的估算，今天距离 IPv4 中央地址池的地址耗尽还有大约 47 天。中央地址池的耗尽对最终用户并不会产生立即而直接的影响（总有各种各样的办法来减少IP地址的占用，大企业或者ISP可以用NAT，双层甚至三层NAT等技术来减少实际使用的IP，等等），但是无论如何，我们之前所熟悉的那个互联网的日子已经所剩不多了。

这其实是一个很严肃的话题。

我在酒店或者提供免费wireless访问的地方一般都会拨VPN回家/公司，然后通过那里的路由访问Internet。这个习惯不能完全消除运营商进行的攻击，但能减少能够实施这种攻击的人的范围。

有时，会有需要接入远程的 IPv6 网络。例如，办公或网吧等环境可能不提供 IPv6 接入的条件，或者需要接入更高安全级别的网络等等。

使用 OpenVPN 提供 IPv6 服务需要的条件包括：