关于GFW审查eD2k协议的相关内容汇总

不知道大家有没发现,近这一两年来eMule连接eD2k服务器非常困难?
没错,那是因为eD2k协议遭到的GFW的干扰和封锁!

昨天的文章 https://plus.google.com/100358287882745531104/posts/graVczcZeN7 已经介绍过GFW拦截具备迷惑协议的连接,目的就是要审查eMule与其连接的eD2k服务器之间的通讯。
经 +Ryan Wu 提醒测试了下,发现一个令人遗憾的事实: GFW已经具备对eMule搜索关键词的审查了……

以下是测试报告:


图 中1所示,客户端向服务器端 filex-lport/1887端口 发送搜索文件的请求,图中3所示是传送的内容:e3:0a:00:00:00:16:01:06:00:e6:b5:8b:e8:af:95 ,其中 e6:b5:8b:e8:af:95 是“测试”的UTF-8的十六进制编码,显然“测试”是敏感词之一;
留意图中3所示,20ms后马上收到3个RST包: SEQ1+1460=SEQ2+2920=SEQ3 ,确认是GFW发送的伪造数据包,而这3个数据包是从 filex-lport/1887端口 发送过来的, 可以确定是GFW针对上述文件搜索查询而进行的重置 。
也就是说,eMule客户端使用迷惑协议连接至境外服务器时会立即被GFW重置连接,迫使客户端使用普通连接重新连接境外服务器;而此时若客户端向境外服务器发送文件搜索查询,GFW会审查搜索的关键词,若发现存在敏感词则马上将连接重置,从而使客户端无法得到搜索结果。
所以eMule里文件搜索最后一根救命稻草就是Kad网络了……

以下是部分对应时间轴的日志:
01:15: 正连接到 UsenetNL.biz No1 (91.225.136.126:1887 – 支持迷惑协议) …
01:16: 连接到[Server],发送登陆请求
01:16: [Server]可能到达最大客户连接数了(被GFW连接重置迷惑协议握手)
01:16: 正在连接到[Server]…
01:16: 连接到[Server],发送登陆请求
01:18: 连接建立于:[Server](客户端与服务器建立普通连接)
01:18: received an IP: ……, NAFC-Adapter will be checked
01:18: 新的客户ID为 ……
01:24: 失去与[Server]的连接(搜索敏感词,GFW重置客户端与服务器的连接)

原文:http://fqok.org/?p=3176

发表评论