2012年11月20日星期二

(In 2012-11-20)关于近日IPv6隧道被阻断连接

近日看到一篇文章声称防火长城已经具备审查IPv6协议的能力

文章还附上了WireShark的抓包结果:



可见上图,访问了一个大概含有关键词的域名,然后马上被发了RST包RESET了连接,非常典型的HTTP协议URL关键词连接重置;而下图则是查询DNS服务器 twitter.com 的结果,却被防火长城抢先返回了虚假的结果 1.1.1.1 和 255.255.255.255 随后正确的结果抵达,也是很典型的域名服务器缓存投毒污染。

  这确实让人感觉悲哀……但看清楚,发送的 Destination 和接收的 Source 虽然确实是Google的IPv6服务器地址,但是发送的 Source 和接收的 Destination 却是2001开头的IPv6地址,也就是IPv4转换地址,可见博主是使用的IPv4的隧道访问位于境外的IPv6隧道服务器,再由位于境外的IPv6隧道服务器访问Google的IPv6服务器。因为隧道对于用户来说是透明的,所以这里除了转换地址基本看不到位于境外的IPv6隧道服务器的痕迹。

  通过IPv6隧道,位于境内的博主与位于境外的IPv6隧道服务器基于IPv4协议进行通讯,也就是将IPv6的报文封装在IPv4协议的数据包里。而因为分片的问题,同时IPSec对于IPv6现在已经不是必须项目,而且也需要双方同时支持IPSec才能实现,所以在没有IPSec的保护下,位于境内的博主与位于境外的IPv6隧道服务器之间的通讯被一览无遗,只要稍加研究IPv6隧道通讯包的结构,结合IPv4时代积累的丰富会话劫持的经验,实现对IPv6隧道的审查对防火长城来说,完全不是一件难事。

  所以,这其实也不是很让人惊讶的事情。

2 条评论:

  1. 2001开头的IPv6地址确实为转换地址无误
    但是事实上原博主使用的IPv6隧道服务器并非在境外
    2001:da8开头是CERNET2的isatap隧道
    http://bgp.he.net/net/2001:0da8::/32
    也就是说该隧道服务器是校长管的

    回复删除
  2. 接楼上
    刚刚测试了自己在用的境外隧道
    未见RST和DNS污染
    http://goo.gl/n6JtO

    回复删除