关于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