以編程方式確定路由器NAT類型

我需要以編程方式確定我的程序中的路由器NAT類型。我確實看過一些關於SO的STUN相關答案和UPnP相關信息。但沒有得到任何明確的答案。以編程方式確定路由器NAT類型

我查看了STUN RFC（rfc 5389），它沒有指定如何確定NAT類型。它確實提到它的前一版本（RFC 3489）提供了確定NAT類型的機制。但也提到

此外。經典的STUN分類NAT類型的算法被發現是錯誤的，因爲許多NAT並不適合那裏定義的類型。

鑑於上述情況，您能否就如何在我的軟件中確定路由器NAT類型提出建議。此外，現在RFC 3489已經過時了，還有其他方法嗎？

在此先感謝。

2011-12-22 sthustfo

RFC 3489被分成三個不同的RFC：

RFC 5389 - 基本的STUN協議。 STUN綁定請求和綁定響應的基本協議基本上與RFC 3489相同。協議頭被一個佔用一些事務id字段的魔術cookie更新。一些STUN屬性被重新定義。添加了一些新的（特別是 - XOR_MAPPED_ADDRESS）。對於如何完成STUN認證的一些更改。 NAT行爲和分類討論轉移到RFC 5780.

RFC 5780 - 「Nat行爲發現使用STUN」。 NAT類型發現的基本變化是區分與NAT過濾行爲分開的NAT端口映射行爲。而RFC 3489會嘗試將NAT分類到幾個桶之一（「cone」，「port restricted」，「symmetric」） - 這太籠統了，無法描述NAT。

RFC 5769 - 只是概述了幾種不同STUN消息類型的十六進制轉儲的外觀。

出於好奇，我想知道你的應用是否在NAT後面運行是有用的。但是如何知道NAT的行爲會影響你的代碼路徑？

無恥插件 - 使用my STUN Server code託管在GitHub上。

來源

2011-12-22 11:38:43 selbie

感謝您的回答。我正在研究nat遍歷，因此瞭解nat類型雖然不會改變代碼流，但它有幫助。我認爲這是令人興奮的工作。 – sthustfo 2011-12-22 11:54:24

順便說一句，考慮到RFC 5389對RFC 3489機制沒有很好的意見，使用新的RFC 5780確定nat類型的準確性有多高。你有沒有嘗試過，如果是的話，有任何意見？ – sthustfo 2011-12-22 11:57:09

我必須回去查看我的筆記，但大多數行爲良好的NAT在其映射行爲方面都是「端點獨立的」，而在過濾方面則是「地址+端口依賴」。如果你有這些NAT之一，這意味着你可以可靠地通過UDP進行P2P打孔。如果該NAT不是「端點獨立」的映射（在舊RFC中稱爲「對稱」），則更難以遍歷。「港口預測」有時會起作用。我很樂意與您討論您的項目和/或我們是否可以合作。隨時與我離線jselbie在Gmail點com。 – selbie 2011-12-22 20:32:09

以編程方式確定路由器NAT類型

回答

相關問題