如何发现给定接口背后的NAT类型

我想发现一个给定的网络接口背后的NAT（FullCone，Restricted Cone，Port Restricted cone，Symmetric）的类型。

我已经测试了不同的工具（ http://freshmeat.net/projects/jstun/,http://code.google.com/p/boogu/ ），但他们报告了同一界面的不同结果。

我正在寻找Python（或其他语言，第二选择是Java，如果没有其他可用的）的确定答案。

NAT设备以许多不同类型的地址和端口映射方案实现。 STUN无法正常使用它们。

这是否足够明确？它只是一个维基百科的引用，但从这看起来你的请求在物理上是不可能的。

我是@ S.Lott的回答：不可能使用STUN（或任何其他协议）100％确定你所支持的NAT类型。

问题是（正如我最近所见），NAT有时可以作为地址相关（对称），有时作为端点独立（完全，受限制或端口受限锥）。

当您考虑它时，作为地址依赖意味着当您将数据包从NAT后面的客户端上的一个套接字发送到两个不同的服务器时，NAT将为每个服务器创建两个自定义公共地址：端口元组。在我的例子中，这些绑定似乎是完全随机的，但如果范围很小，有时候这些元组实际上是相等的！哪个混淆了测试。

我当时正在使用这个库，有时它告诉我NAT的行为是地址依赖的，有时它是Endpoint-Independent（两者之间的切换似乎也是完全随机的，有时它发生在我重新启动设备后，有时候在一段时间，…）。

这种情况发生在斯洛伐克电信公司的移动设备上，斯洛伐克电信公司主要由德国电信公司所有，所以我认为这个问题至少会在整个欧洲范围内出现。

我会说这里的规则是这样的：如果STUN测试告诉你，你在对称NAT后面而不是那种情况，但如果它告诉你，那么你就不能100％肯定。

最后一点，一个检查NAT关于TCP的行为的简单方法是在google中键入“我的IP地址是什么”，然后先打开（比如说）五页。如果页面与您的IP地址不一致，则NAT的行为是地址相关或地址和端口相关（对称）。但同样，如果他们确实对应，你就不能确定。

正如@ S.Lott所说，STUN是你的首选协议。

然后，STUN只是一个协议。这是我的建议：

1 STUN现在有两个版本：旧版本是RFC3489 – 这是一个轻量级协议，允许应用程序发现它们与公共Internet之间的NAT和防火墙的存在和类型（因此它主要用于检测NAT类型）; 并且新版本是RFC5389 – 这是处理NAT遍历的其他协议的工具。

2还有一个名为TURN RFC5766的 STUN中继扩展。 TURN允许主机控制中继的操作并使用中继与其对等体交换分组。 TURN与其他一些中继控制协议的不同之处在于它允许客户端使用单个中继地址与多个对等体通信。

工具：

注意：由于TURN是新版本STUN的扩展，因此TURN服务器还支持RFC5389的新STUN请求。