此目录下的文档都是用户自己编写的指南,并未经过eMule(电骡)开发人员的验证。不过对于大多数用户而言,这些文章仍然颇有裨益。你可以在论坛的此专用主题贴找到相关的提问与评论。
Hi,大家好
我与Kad的“通过防火墙”状态进行了不懈的斗争并最终胜利,现在就来分享一下我的心得。跟大多数伙计们碰到此问题的网络环境一样,我也是在一台位于NAT之后的Windows主机上运行eMule,平时分到私网IP。
感谢神圣的骡子,我是自己网站的管理员,因此有这个机会详细分析这个问题。故事的开始一如平常:我已经在WinXP中打开了eMule所需的端口,并且在路由器中已经设置了TCP和UDP端口的转发规则,但是Kad状态仍然是“通过防火墙”。更加搞笑的是,Kad状态曾经有一回蹦到了“打开”状态,之后又莫名其妙地变回“通过防火墙”,而我根本没碰任何设置。不过我在Ed2k网络中总是能获得HighID。
后来我发现:除了设置端口转发规则之外,只要将私网IP映射到某个专用的公网IP上,Kad状态就会立即显示为“打开”。于是我恢复到只配置了端口转发规则的状态,然后同时tcpdump内部接口和外部接口的数据包。结果我发现,通过NAT向外发送的UDP数据包,仍然使用eMule赋给的初始端口,也就是说所发送的报文无法响应远端节点的UDP请求。想象一下这时我有多惊讶吧。
从上面的情况来看,端口转发设置有时对相反方向无效,至少对于某些路由器来说是如此。因此可能需要对NAT进行额外配置,这样在eMule试图连接外部节点时能够保持UDP初始端口。对于Kad网络来说保持UDP端口不变非常关键,因为你的IP以及端口等信息会被其它节点传播到整个网络。
举例说明:
假定你的eMule主机在局域网内的地址是10.1.1.10,通过NAT映射到互联网的2.2.2.2地址。eMule使用的UDP端口初始设置为4672。
当eMule试图连接IP地址为3.3.3.3的Kad节点时,NAT将内网IP 10.1.1.10转译为2.2.2.2,将内网端口4672转译为外网端口(例如65000之类)。只要NAT还记录着这条转译规则,那么3.3.3.3这个节点就能够通过65000端口反向联系到你。但是,其它Kad节点有可能通过3.3.3.3获得你的信息,此时这些节点会认为你的UDP端口是65000,而不是4672。毫无疑问,这些节点都无法通过Kad连接到你的骡子,因为转译规则仅对3.3.3.3这个IP有效。
解决办法是让NAT在向外的Kad“会话”时保持初始端口不变(通常是4672),也就是针对向外的UDP报文创建NAT规则条目。
我在*BSD中用PF实现此要求。配置语句如下所示:
nat on $extif proto udp from 10.1.1.10 port 4672 -> $realip port 4672
nat on $extif from 10.1.1.0/24 to any -> $realip
rdr pass on $extif proto tcp from any to $realip port 4662 -> 10.1.1.10 port 4662
rdr pass on $extif proto udp from any to $realip port 4672 -> 10.1.1.10 port 4672
第1行确保eMule的Kad端口在外网仍然是4672,第2行进行普通的NAT转发,第3行和第4行分别设置向内的Ed2k连接数据包以及Kad数据包的端口转发规则。
当然,你需要根据实际使用的路由器/NAT设备查阅相关手册,按照手册进行适当的配置。
希望这篇文章能帮上忙。
《让Kad状态不再是“通过防火墙”!》,由Ejack翻译自eMule官方网站英文版帮助与支持《Firewalled On Kad No More!》并首发于eMuleFans.com。原文版权归属于eMule官方和原文作者。翻译内容版权归属于翻译者并遵守CC 3.0 BY-NC-SA协议。已编入eMule官网简体中文版帮助与支持《让Kad状态不再是“通过防火墙”!》。
6条评论隐藏
意义不大啊
又看了下,对于一般路由用户只是个思路来,不用死死纠结于端口映射总是没有效果
看来 真正关键的是在于畅通的网络,本地中转什么的都可以给人添上麻烦,以前的文章都有点误导人的感觉了。是不是即便是不是highid——不连服务器,只要连接通畅,其实根本就没有任何影响?
ipv6就没有nat的问题乐了,那时候任何p2p软件,似网服务器,将大放光彩,可惜支持ipv6的骡子没有。
说的没有具体步骤,,看不懂,对新人来说你这意思不大,不够详细
看得我晕头转向云里雾里
这都什么跟什么啊
我就是遇到了这个问题 都1年了还没解决 看完文章后还是不知道该如何解决 急死了 跪求高手来一篇详细的解决方法