eMule Fans 電騾愛好者

此目錄下的文檔都是用戶自己編寫的指南，並未經過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狀態不再是「通過防火牆」！》。