由于个人隐私泄露，此博客不再更新

OpenWrt Chaos Calmer 15.05正式发布

试用后发现版本号r46767，从此版本开始，opkg将进行sig验证，内核版本3.18.20，新增对464XLAT技术的支持，可实现网络地址映射转换，原生支持IPv6，无需手动安装luci-proto-ipv6插件。

VMware ESXi如何更换证书

/etc/vmware/ssl/rui.crt
/etc/vmware/ssl/rui.key
上述文件可以更换，但必须保证公钥和私钥配对。

通过hotplug.d/iface脚本实现DNS隐蔽信道的自动连接

hotplug.d/iface是在接口接驳状态发生变化时所执行的脚本，所执行的内容应该在执行有限次之后不再触发接口接驳状态的变化，绝不可以执行无限次之后仍然可触发接口接驳状态的变化，所以使用hotplug.d/iface实现DNS隐蔽信道的自动连接必须使用判断结构，避免DNS隐蔽信道连接建立之后由于触发了接口接驳状态的变化导致脚本重复执行，判断条件为DNS隐蔽信道是否已连接。
判断条件为$(ifconfig dns0 |grep "not")，条件为真表示未连接成功，条件为假表示已连接成功。由于DNS隐蔽信道程序带有自动检测网络通断的特性，长时间无法保持连接时会放弃连接断开dns0虚拟网卡，所以无需通过ping隐蔽信道服务器端的方式侦测连接状态。
参考脚本：
while [ "1" ]; do
dns=$(ifconfig dns0 |grep "not")
if [ "$dns" ]; then
sleep 60
else
iodine iodine.ipv6nxtgnwrt.homenet.org
fi
done
经测试DNS隐蔽信道使用上述参考脚本自动连接后最长1小时以上保持稳定状态，已基本可满足Internet隐蔽接入的稳定性需求。

iptables高级应用——防止异常的RST打断VPN连接

由于异常的RST进入了VPN服务器和VPN客户端，VPN连接可能因此中断。该异常的RST经常在受到网络审查的地区出现，通常紧跟在SYN之后极短的时间之内出现，如果无SYN发出则不会出现，说明该RST来自BRAS或者骨干网，并不是服务器所发送的。网络审查系统通常设计得很差，由于担心消耗过多的计算资源，无法实现RST紧跟着ACK之前到来，所以一般人很容易分析出该RST必然是假的。不过由于收到了ACK，我们知道VPN连接是有可能建立起来的，只是由于RST的干扰导致的中断。前面提到的Internet协议（TCP/IP）增强技术在Windows下难以实现，我们一般选择使用OpenWrt路由器实现。在防火墙自定义规则中，我们添加了如下规则：

iptables -t mangle -A PREROUTING -p tcp --tcp-flags RST RST -j DROP

经过测试，我们发现VPN客户端收不到RST数据包了，但是VPN仍然断了。仔细排查之后发现服务器竟然收到了RST，看来网络审查系统是双向发伪RST包的，后来我们又在服务器端也配置了同样的规则。双方都受到保护之后VPN连接很容易就建立了起来，在此过程中防火墙一直在报警说收到了RST包，数量非常多，比正常数据包都要多几倍，可见网络审查系统非常愚钝，发了这么多没用的RST数据包还在发，徒然浪费资源还不如去审查别人去。

拥有多个OpenWrt路由器的局域网如何配置DHCP

OpenWrt路由器上的DHCP服务器有2个选项，DynamicDHCP选项控制该路由器上的DHCP服务器是否向未知的客户端分配地址，Force选项控制该路由器上的DHCP服务器优先级。在一个局域网中，一般只允许一台DHCP服务器，但是多个DHCP服务器是可以和谐共存的。如果让多个DHCP服务器和谐共存，开启DynamicDHCP选项的路由器不能多于一台，开启之后未知的客户端可获取到它分配的动态地址，如果有开启DynamicDHCP，其他路由器必须都开启Force并关闭DynamicDHCP，它们只能向已知的客户端分配静态地址，开启DynamicDHCP的服务器必须关闭Force降低优先级。一般局域网同时对静态和动态地址都有需求，多DHCP服务器可满足这种需求，使用静态地址的客户端可以选择不同的路由。

iptables高级应用——动态TTL

114DNS称其由于使用了“BGP线路”，ICMP echo-reply中的TTL值会不断发生变化。在普通的线路上，如果实现了动态TTL，如果观察者不清楚具体的细节，很容易就会认为使用了“BGP线路”。观察者一般只能观察到来自配置了动态TTL的路由器发出的ICMP echo-reply，所以只需在OUTPUT链上配置随机匹配的TTL变化目标。在OpenWrt上面，我们尝试了如下的配置：

iptables -t mangle -A POSTROUTING -p icmp --icmp-type echo-reply -m iprange ! --dst-range 192.168.0.0-192.168.255.255 -j TTL --ttl-inc 64

iptables -t mangle -A POSTROUTING -p icmp --icmp-type echo-reply -m iprange ! --dst-range 192.168.0.0-192.168.255.255 -m statistic --mode random --probability 0.5 -j TTL --ttl-inc 1

iptables -t mangle -A POSTROUTING -p icmp --icmp-type echo-reply -m iprange ! --dst-range 192.168.0.0-192.168.255.255 -m statistic --mode random --probability 0.5 -j TTL --ttl-dec 1

iptables -t mangle -A POSTROUTING -p icmp --icmp-type echo-reply -m iprange ! --dst-range 192.168.0.0-192.168.255.255 -m statistic --mode random --probability 0.5 -j TTL --ttl-inc 3

iptables -t mangle -A POSTROUTING -p icmp --icmp-type echo-reply -m iprange ! --dst-range 192.168.0.0-192.168.255.255 -m statistic --mode random --probability 0.5 -j TTL --ttl-dec 3

iptables -t mangle -A POSTROUTING -p icmp --icmp-type echo-reply -m iprange ! --dst-range 192.168.0.0-192.168.255.255 -m statistic --mode random --probability 0.5 -j TTL --ttl-inc 9

iptables -t mangle -A POSTROUTING -p icmp --icmp-type echo-reply -m iprange ! --dst-range 192.168.0.0-192.168.255.255 -m statistic --mode random --probability 0.5 -j TTL --ttl-dec 9

iptables -t mangle -A POSTROUTING -p icmp --icmp-type echo-reply -m iprange ! --dst-range 192.168.0.0-192.168.255.255 -m statistic --mode random --probability 0.5 -j TTL --ttl-inc 27

iptables -t mangle -A POSTROUTING -p icmp --icmp-type echo-reply -m iprange ! --dst-range 192.168.0.0-192.168.255.255 -m statistic --mode random --probability 0.5 -j TTL --ttl-dec 27

为什么如此配置，这需要仔细探讨。OpenWrt的使用环境通常包括外部计算机、内部计算机和路由器3种计算机，如果配置规则不精确，将破坏不需要受到影响的3方中的某2方之间的数据包。我们需要实现的是路由器应答外部计算机时发出的echo-reply中的TTL随机化，所以路由器应答内部计算机就不需要更改TTL，也就是排除内部计算机为目的地址的匹配。外部计算机ping不到内部计算机，内部计算机也不能应答外部计算机。最后外部计算机应答内部计算机这种情况由于dst-range中被排除所以也不受影响。其实还有一种情况就是通过管理界面登录路由器并在上面运行网络诊断的ping时路由器收到的应答也不需要修改TTL，如果不仔细斟酌可能会发现规则匹配，因为dst-range排除的范围不包括路由器的WAN接口地址，不过由于使用了POSTROUTING链，规则匹配也就排除了。

有一个非常经典的问题，在天平左右两个托盘均可放置砝码的情况下，如何设计砝码的重量，使砝码数量最少的情况下能够称出所有整数重量的物体，答案是1,3,9,27,81……所以这里的规则也使用这个数列里面的数字了，但是考虑到TTL=64初始值可能不够用，所以一开始还需要将TTL升高64确保够用。

应用上述规则之后我们进行了ping测试，并将大量测试结果中的TTL数据提取出来，升序排列之后直接转换为散点图。经过观察我们发现该散点图中的点大致在一条直线上，说明TTL随机化之后的数值均匀分布，达到了我们需要的动态TTL效果。当然，也可以调整规则使TTL以其他形式分布。

zh.wikipedia.org现已受到DNS污染而ipv6nxtgnwrt未受影响

2015年5月19日下午，中文维基百科在中国大陆开始无法访问访问，原因是“zh.wikipedia.org”遭到关键字阻断和DNS污染。由于我们在3个核心路由器上都配置了域名解析策略“/wikipedia.org/2001:470:20::2”等，此次DNS污染事件并未影响我们的私有网络DNS解析服务器对zh.wikipedia.org域名的正常解析。接下来我们还将继续对DNS污染情况进行监视，对可能受到破坏的域名添加无污染的DNS解析策略进行保护。

走到哪里，把IPv6带到哪里，让人们享受IPv6接入服务

由于学校信息中心所拥有的全球可路由IPv4地址数量有限，无法实现每个NIC一个地址的分配方式，所以拥有大量计算机的实验室几乎都在使用NAT技术实现Internet接入，但是由于设备老旧封闭不支持IPv6，所以校园网络中原生支持的IPv6协议无法跨过WAN到LAN的屏障，使LAN中的计算机无法接入IPv6。解决方法有很多，例如在NAT路由器上配置IPv6桥接、使用支持桥接的OpenWrt路由器旁路连接WAN到LAN，不过这些方法都难以在管理员不配合的情况下使用。我们经过实验发现，SoftEther VPN Bridge提供的站点到站点VPN接入服务功能可以实现我们的私有网络与所在LAN之间的桥接，可以实现走到哪里，把IPv6带到哪里的梦想，让所在LAN中的其他设备通过我们的私有网络接入IPv6网络。

IPv6安全性：局域网旁观者攻击

经过实验我们发现了一个IPv6的安全性问题：Windows缺省情况下启用IPv6协议，大部分局域网只使用了一个IPv4路由，但是很少有人手动关闭IPv6协议。这种情况下，局域网中的任何黑客都有可能通过架设DHCPv6的方式让一个主机通过优先级较高的IPv6协议连接到他所架设的DNS服务器和网关上，从而对局域网中的出入站数据包实施窃听、截断、中间人攻击。这一点引起了我们的注意，我们关闭了私有网络中所有Windows计算机上的自动获取IPv6功能，改用手动分配IPv6，确保了服务器的安全。

研究论文：隐蔽信道的相关研究

本研究针对网络中典型的ICMP隐蔽信道、DNS隐蔽信道、Tor隐蔽信道进行了基本原理的分析、搭建与配置、传输特性的测试、适用场合的探讨、检测技术的提出，带领读者学习信息安全领域最前沿的研究技术与理论知识，实现隐蔽信道的最佳实践。

实战硬盘SMART清零

Windows Update更新逻辑分析

补丁星期二又要来了，我们忙着给每台服务器打补丁的同时，对更新逻辑进行了一些分析。首先我们将这些补丁分为了几大类，可选补丁、更新程序、安全更新程序、NetFX补丁，我们就尝试着按照一定的顺序进行分类安装，安装完成之后再次检查更新，看看哪些更新被刚刚安装完的补丁替换了，就可以知道按照什么顺序安装补丁最合理。
安装可选补丁之后，更新程序和安全更新程序的某些补丁被替换。安装更新程序之后可选补丁没有被替换，而安全更新程序被替换。安装安全更新程序和NetFX补丁之后没有任何补丁被替换。综合上面的结果我们可以知道可选补丁可以替换的其他补丁，所以一定要先安装可选补丁，这样就可以让被替换的补丁免于二次安装。接下来安装更新程序，最后安装安全更新程序和NetFX补丁。经过大量尝试，我们弄明白了更新逻辑，这对我们制作集成了补丁的WindowsImageBackup很有帮助。
从此之后我们一直对补丁管理过程非常感兴趣，每个月都会在补丁星期二到来时将按照正确的逻辑收集到的补丁安装顺序和列表整理好，将补丁下载并集成到Windows中，让全新安装的Windows自带所需的补丁，确保所运行系统的完美与安全。

Azure试用体验

Hurricane Electric的Tunnel Server也会Down掉

瞧，今天就有一台Tunnel Server Down掉了，不过世界级的运营商就是好，敢于承认错误才是好运营商，如果中国联通今天上午的骨干网故障能在第一时间告知大家而不是经过大家的批评才被迫承认该故障的存在该多好。

对Google的域名解析策略已变更

经过研究我们发现使用2001:470:20::2解析所得的2607:f8b0::/32比直接使用默认IPv4的DNS解析所得的2404:6800::/32距离2001:470:d::/48更近，时延更低且数据包丢失率更低。我们已经将Google域名的解析策略变更，使我们私有网络到达Google的时间从300ms降低到150ms，将提高我们的服务质量。

ST3500418AS强刷固件的后果

惠普的台式机上拆下来的HP35固件强刷CC49，刷完之后SMART表大量报错，温度显示不正常，不过可以正常使用，不影响数据完整性和性能。所以大家以后千万不要随便强刷固件，以免引起更严重的后果，如果硬盘不能使用将很难修复。

ipv6nxtgnwrt私有AS最新的IPv6地址块/64前缀已变更

感谢大家长期以来的支持，我们经过几年来的网络理论与技术实践，发现了使用/48地址块存在的一些问题，经过慎重考虑与详细比较，我们决定迁移到/64地址块。经过申请我们获得了3个/64地址块，并将它们命名为OpenWrt地址块：2001:470:d:600::/64、DreamBox地址块：2001:470:d:1280::/64、PandoraBox地址块：2001:470:d:1296::/64，分别对应着3个私有6in4隧道接入路由器：openwrt.ipv6nxtgnwrt.homenet.org[2001:470:d:600::1]、dreambox.ipv6nxtgnwrt.homenet.org[2001:470:d:1280::1]、pandorabox.ipv6nxtgnwrt.homenet.org[2001:470:d:1296::1]。这3个/64地址块在LAN中是互通的，通过私有网络接入的服务器都将同时获得3个/64地址块中相应的SLAAC地址，同时我们也会在配置域名DNS记录的时候考虑将3个地址同时配置为AAAA记录，访问者在访问的时候将会随机选择一个地址，不仅起到了负载均衡的作用，还可以防止某一路由器的故障对访问造成的影响。

面对DNS污染，如何解救Google Public DNS

8.8.8.8和8.8.4.4受到了严重的DNS污染，现在已经几乎无法正确地解析域名了。但是经过长期测试我们发现2001:4860:4860::8888和2001:4860:4860::8844尚未受到DNS污染，我们决定在私有网络中建立两个虚拟的DNS服务器，转发IPv6的域名解析请求和应答，并且通过配置路由表将目的地址为8.8.8.8和8.8.4.4的路由指向虚拟的DNS服务器，让这两个虚拟的DNS服务器使用无污染的IPv6代替8.8.8.8和8.8.4.4转发域名解析请求和应答。

在这里，由于虚拟服务器上的DNS转发器同时支持IPv6和IPv4的特性，使不支持IPv6的DNS客户端也可以享受没有被污染的DNS解析服务而无需配置IPv6协议。这种网络运行方式类似于192.88.99.1（6to4任播中继），提供相同的服务而IP地址相同，那么客户端可以任选一条最近的路由接受其所提供的服务。任播又被称为Multi-Origin Routes，某个IP可能同时属于多个AS，在这里我们把8.8.8.8和8.8.4.4放置到自己的私有AS中，并设置了到达它们的路由。

经过实际测试，我们发现8.8.8.8和8.8.4.4的域名解析不再受到DNS污染，而且由于运行方式类似于任播技术，用户使用过程中并不关心这个8.8.8.8和8.8.4.4到底是在Google还是在私有网络中，因为其所提供的服务和真正的8.8.8.8和8.8.4.4是完全相同的DNS域名解析服务。

Synology DiskStation的CA证书和私钥的替换

Synology DiskStation Manager的Web管理界面只提供了服务器证书和私钥以及中间证书的替换选项，而如果想替换CA证书和私钥，将DSM变成一个证书颁发机构来使用，那么就必须通过SSH或Telnet连接到DiskStation，将其中的证书和私钥替换掉。我们经过查找可以发现CA证书和私钥被存储在了如下位置：

./usr/syno/etc/ssl/ssl.crt/ca.crt

./usr/syno/etc/ssl/ssl.crt/server.crt

./usr/syno/etc/ssl/ssl.intercrt/server-ca.crt

./usr/syno/etc/ssl/ssl.key/ca.key

./usr/syno/etc/ssl/ssl.key/server.key

替换它们需要使用rm先将它们删除掉，再使用wget从某个位置下载到相应位置。最后我们还发现了默认的UNIX权限会导致DiskStation工作不正常，需要手动chmod 400进行权限设定，经过设定之后CA证书成功被替换，DiskStation工作恢复正常，并且Web管理界面中显示服务器证书和CA证书匹配，将服务器证书识别为自签署证书。

经过创建证书测试，我们发现所创建的证书签名者不再是Synology的默认证书了，这样我们就无需再在计算机上将不安全的Synology默认证书安装到可信的根证书颁发机构目录了。