2011-08-20 67 views
1

我有3個應用程序:MasterServer,Server和Client。Nat punch,MasterServer/Server/Client。客戶端無法通過已知的公共IP和端口與服務器通信

的MasterServer上運行:70.105.155.5:15555(端口轉發的UPnP)

我創建了一個服務器,讓MasterServer知道我的存在。 MasterServer保留我的公共IP和端口。 MS獲取的端口由我的路由器隨機分配(可以說:70.105.155.5:16666)。服務器每10秒保持發送一次MasterServer消息以保持相同的端口打開。

我打開客戶端,在其上向服務器請求MasterServer以獲取公共IP和端口。 MasterServer返回:70.105.155.5:16666。我知道100%確定服務器的公共端口16666仍然打開,因爲我可以在我的日誌中檢查該端口。

但從Client => Server發送的所有消息都不會收到。同時服務器仍然通過16666從MasterServer獲得消息。

所以這真的令人費解。我忘記了什麼嗎?我對NAT的理解有缺陷嗎?

感謝您的幫助!

回答

2

這裏有很多問題,它也取決於路由器的安全配置,通常用戶無法控制。一般的藉口是,這是一個安全防範措施,但真正的防火牆和NAT是兩個不同的問題。無論如何,大多數家庭用戶都被卡住了。他們通常可以選擇顯式映射端口,如果路由器支持,UPnP也可以幫助您。

但是回到NAT之前,如果你的服務器和客戶端坐在同一個NAT之後,你可能會遇到問題,這似乎是你上面引用的地址的情況。大多數NAT僅重寫來自公共接口的傳入數據包 - 因此,物理到達私有接口的數據包(即使它們發往公用IP)也不會被轉發。要在野外支持這種配置,您需要設備將其私有地址通告給MasterServer,並檢測他們何時想與同一NAT後面的其他設備通話,如果是,請使用私有地址而不是通過NAT。這在許多方面都存在缺陷,特別是嵌套的NAT,但我認爲這是你能做的最好的。

除此之外,在所有設備都位於不同NAT後面的情況下,一些路由器只允許轉發端口上的傳入流量(如果它們來自最初將傳出流量發送到的端口)(導致端口首先開放)。有些還要求它來自遠程設備上的相同源端口。

解決方法是讓MasterServer做更多的工作。要點是,它應該告訴兩個同伴相互發送一個數據包;這些可能會或可能不會通過,但只是通過服務器的NAT將數據包發送到客戶端的公共IP地址可能足以讓服務器的NAT正確地轉發來自客戶端的較晚數據包。反之亦然。

實際上它更加複雜,因爲服務器的NAT可能會在與客戶端交談時與使用MasterServer交談時使用不同的端口。因此,雖然這可能會打開一個端口供客戶端與服務器通話,但它可能不是客戶端期望使用的端口。如果NAT的行爲如此,那麼你需要看看它的端口編號選擇是如何可預測的。有些只是逐個增加(但要記住同一個NAT後面可能有其他設備,導致該數字一次跳躍超過一個步驟)。對於這些客戶端,客戶端需要發送一系列服務器端口垃圾郵件來試圖找出哪一個端口被打開。 MasterServer再次處於協調這一狀態的最佳位置。

其他在端口分配上看起來完全是隨機的,並且這些可以做的事情不多。但是,如果兩端都在這些隨機NAT之後,那麼這只是終端。只要一端更容易被打開,隨機結束就不重要了。

還要注意,有些NAT爲目標上的每個端口使用不同的出站端口 - 即使端口未被隨機分配,這也會使預測困難得多。再次,只要連接的一端是靈活的,你可以容忍這些NAT,但是在對等的環境下,它們最終將成爲一場噩夢,因爲它們無法互相交流。

+1

關於對稱NAT穿越的參考 - 這是關於預測笨拙的NAT上端口分配的內容:http://tools.ietf.org/id/draft-takeda-symmetric-nat-traversal-00.txt –

+0

非常感謝喬治。我猜像COD這樣的遊戲並沒有這些問題,因爲服務器總是託管在專用的鑽井平臺上,而這些平臺都有適當的網絡設置來處理它。 你知道STUN解決方案是否可靠嗎? –

+1

這取決於COD是否發送點對點流量或始終通過服務器路由它。我相信,STUN只是一種服務,它允許通用公共託管服務器告訴連接對等體他們的公共IP /端口對當他們談論STUN服務器時。所以它只適用於簡單的NAT,它可以爲相同的私有地址/端口對重複使用相同的公共端口,而不管目的地是什麼。 –

相關問題