2010年5月31日星期一

让32位的Ubuntu使用4G内存

只需安装linux的PAE内核,32位的Ubuntu就能支持大内存了。

Ubuntu的软件源里就有Linux PAE内核,直接在线安装就行了。
sudo apt-get install linux-generic-pae linux-headers-generic-pae linux-image-generic-pae
启动时从pae内核启动,这样4G或更大的内存就能充分利用了。

2010年5月18日星期二

Google网页快照可以使用https访问了

把网页快照的地址http://webcache.googleusercontent.com改为https://webcache.googleusercontent.com,Google的网页快照就不会被墙了。

2010年5月15日星期六

对于gfw的dns投毒的一点小探讨

dns查询用的是udp协议,对这种无连接的协议gfw想用reset包来阻断连接是不可能的。对此gfw采用的是dns投毒,就是返回一个虚假的dns查询,对于udp协议来说只会采纳最先到达的数据包内容而把后面到达的包丢弃。如果查询不到正确结果,则是gfw发出的假包先到达,正确的查询结果被丢弃了而已。


如果墙外的dns的反应够快呢?这回被丢弃的则是gfw伪造的数据包了。为此我做了一个小小的测试。 测试的域名是www.youtube.com,dns是google公共dns 8.8.8.8 和 8.8.4.4。

在我这里ping 8.8.8.8 的延迟平均是142ms,ping 8.8.4.4 的延迟平均是 266ms 。在8.8.8.8查询dns会得到正确的查询结果;在8.8.4.4查询得到的是gfw伪造的结果。打开wireshark抓包分析一下,过滤一下抓包的结果,只显示dns查询。其实用8.8.4.4查询也能收到正确结果的数据包,只是gfw伪造的结果先到而已;如果换用8.8.8.8查询,查询的结果是正确的,但是也收到了gfw发出伪造结果,只是这次被抛弃的是gfw伪造的结果而已。

知道了这些,我们可以利用gfw对dns投毒反应时间有延迟来选择反应比gfw快的海外dns服务器来解析域名,这样可以在很大程度上解决dns投毒的问题。根据上面的测试结果,我们可以肯定在我所处的环境如果海外dns服务器的反应时间低于140ms则不会受到gfw的dns投毒影响。

在我所处的网络环境下。根据抓包分析,8.8.8.8的dns查询结果一般会在140ms左右后到达,8.8.4.4的dns查询结果会在250ms左右后到达,而gfw的伪造结果会在160ms-240ms之间到达。如果把dns设置为8.8.8.8,利用时间差,可以很大程度上避免gfw的dns投毒。顺便说一句,对于OpenDNS之类的号称没有dns劫持的服务器,如果查询速度不够快,在天朝所处的网络环境下也是无法发挥作用的。

Google将在下周开始提供HTTPS搜索以保护隐私

cnBeta消息:

下周,Google I/O就将开始,Mayer和Eric Schmidt将共同为人们展示Google的加密搜索特性。Google在2008年起于GMail中首次引入HTTPS,用来保护电子邮件访问的安全性,今年1月,Google发生安全问题后,GMail开始全面默认使用HTTPS加密。
现在,HTTPS将会被部署到Google.com的整个域,以确保加密的搜索过程中不会出现数据泄漏,之后,您在机场访问Google进行搜索,将不会 有数据被截取的担忧。
HTTPS是对网络安全的中坚力量之一,该协议也被俗称为安全套接字层(SSL),这种技术可以保障网络在传送敏感数据例如金融、医疗信息时不被拦截和盗取。不过由于网上欺诈和黑客行为越来越猖獗,大多数没电子邮件和其它基于网络的敏感服务没有SSL的保护,因此造成了 相当多的失窃和被监视问题。

2010年5月4日星期二

gfw对google搜索结果的审查力度似乎放宽了

用google.com.hk搜索当今圣上的名字,google会被连接重置。刷新一下,你会发现居然出搜索结果了,我随后又试了几个其他关键词都有这种现象,但不是所有关键词都有这种现象,有些还是会被连接重置1分钟左右。但是随后测试维基百科就没那么幸运了,直接被连接重置,刷新多次还是这样。

看来gfw对google的审查力度放松了,也许这是一个好兆头,也许只是gfw在当前时期做出的临时性的调整。不管怎么说,这确实比以前有进步。