iGFW

(In 2012-11-20)关于近日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隧道的审查对防火长城来说，完全不是一件难事。

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

来源：http://chengr28.blogspot.co.uk/2012/11/in-2012-11-20ipv6.html

=========

喜迎 GFW for IPv6 献礼十八大

昨天晚上有同学反映，即使连了VPN也无法访问YouTube。晚上自习回来后，自己测了一下，发现在连接VPN的情况下，DNS查询是通过VPN 的，也就是能查询到正确的IP地址，但是有的时候会查询到IPv6的地址，通过IPv6的流量是不通过VPN的，问题就出在这里。

用curl http://www.youtube.com/命令访问YouTube网站，然后看抓包的结果。

从抓包结果可以看出，访问YouTube网站的TCP连接遭到了reset。

此外，IPv6的DNS查询目前也遭到了污染。

在不连接VPN的情况下用dig @2001:470:20::2 twitter.com进行DNS查询，然后看抓包的结果。

从抓包的结果可以看出，两个错误的查询结果(分别是1.1.1.1和255.255.255.255)抢在正确的查询结果之前返回，很明显是遭到了DNS污染。

显而易见，目前国内IPv6网络已经遭到了TCP reset和DNS污染，而这两种正是GFW目前在国内IPv4网络中常用的封锁手段，意味着GFW for IPv6已经开始部署。

献礼十八大？呵呵。

来源：http://ichon.me/2012/11/08/gfw-for-ipv6.html