4

我想发现给定网络接口后面的 NAT 类型(FullCone、Restricted Cone、Port Restricted cone、Symmetric)。

我测试了不同的工具(http://freshmeat.net/projects/jstun/http://code.google.com/p/boogu/),但它们针对同一界面报告了不同的结果。

我正在寻找 Python (或其他语言,第二选择是 Java,如果没有其他可用的话)的明确答案。

4

3 回答 3

5

我支持@S.Lott 的回答:不可能使用 STUN(或任何其他协议)来 100% 确定您所使用的 NAT 类型。

问题是(正如我最近所看到的)NAT 有时可能充当地址相关(对称),有时充当端点独立(完整、受限或端口受限锥形)。

当您考虑它时,地址依赖意味着当您从 NAT 后面的客户端上的一个套接字发送数据包到两个不同的服务器时,NAT 将为每个服务器创建两个自定义的公共地址:端口元组。在我的例子中,这些绑定看起来是完全随机的,但如果范围很小,有时这些元组实际上是相等的!这使测试感到困惑。

我当时正在使用这个库,有时它告诉我 NAT 的行为与地址相关,有时它与端点无关(两者之间的切换似乎也完全随机,有时在我重新启动设备后发生,有时在一个时间段,...)。

这发生在我使用Slovak Telekom的移动设备上,这家公司主要由Deutsche Telekom所有,所以我认为问题至少会出现在整个欧洲。

我想说这里的规则是这样的:如果 STUN 测试告诉你你在对称 NAT 后面,那么情况就是这样,但如果它告诉你不是这样,那么你就不能 100% 确定。

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

于 2013-08-09T03:23:17.553 回答
3

http://en.wikipedia.org/wiki/STUN

NAT 设备在许多不同类型的地址和端口映射方案中实现。STUN 不适用于所有这些。

这足够确定吗?这只是维基百科的引用,但从这里看来,您的请求在物理上是不可能的。

于 2008-12-15T21:25:30.890 回答
0

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

然后,STUN 只是一个协议。这是我的建议:

1 STUN现在有两个版本:旧版本是RFC3489 - 这是一个轻量级协议,允许应用程序发现它们与公共 Internet 之间的 NAT 和防火墙的存在和类型(因此它主要且仅用于检测 NAT 类型);新版本是RFC5389——这是其他协议处理NAT穿越的工具。

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

工具:

  • STUN 服务器 (RFC3489) : stund By c++
  • STUN 客户端 (RFC3489) : pystun By python

  • TURN 服务器 (RFC5766) : turnserver By c

  • TURN 客户端 (RFC5766) : turn-client由 c 和 python

注意:由于 TURN 是新版本 STUN 的扩展,TURN 服务器也支持 RFC5389 的新 STUN 请求。

于 2012-03-12T06:30:48.953 回答