最近一直在使用gfw6,感觉不错。

试着做如下黑箱分析:

  1. 阻断ipv6反向代理地址的工作方式:阻断地址通过计算获得:RFC 6147中指出,dns64反向代理服务器返回的ip由服务器决定,“一般情况下,返回一个带ipv6固定前缀的地址”;现在看来大部分dns64服务器都是按照“一般情况”,GFW6只要将所有ipv6请求目标地址和源地址某两个块(一般为最后两个块)倒推成ipv4地址,即可选择性地发送RST包。如此土豪的方式,果然是一坨曙光计算机撑腰的大项目啊(笑)。
  2. 阻断固定ipv6地址的工作方式:和以前ipv4的时候是一样的,RST攻击。
  3. 开始污染DNS64解析感觉这个没啥作用
  4. 有两点值得注意:对反向代理,似乎只对请求方发送RST包;https连接没有被RST。

实验(与上文对应):

  1. 选定任意一个DNS64地址,用nslookup得到返回值,增加hosts条目;本例测试X望の声(墙外)和度娘(墙内)。wireshark抓包结果发现,X望の声的第一个返回包被reset,导致连接失败;度娘连接正常。

解决方案:

  1. 如果能找到一个“非典型”DNS64服务器,那GFW6的TCP阻断就痿了。假设某个DNS64服务器的算法为,最后两个地址块为 FFFF:FFFF-ipv4转换地址,那么GFW6无法确定阻断地址,要阻断,只能把block list中的地址一一询问该DNS64服务器;如果算法变一下,比如之前的计算结果再和一个常数异或一下,或者再每两天(正好和本地DNS cache的TTL重合)换一个常数,那么GFW6将会非常苦逼。RFC6147似乎没有明确指出“optional parameter”的含义,从5.2节来看,似乎奇葩的算法也是可以的。
  2. 西厢代理v6?括弧笑
  3. 这个好办,反正被墙的网站只是少数,nslookup一个没被墙的DNS64地址,按算法写到hosts里就好了嘛
  4. 可能是一个突破口,关注中。DNS64时X望の声有时竟然是可以上去的。

有用的资料: