如何发现给定接口后面的 NAT 类型
我想发现给定网络接口后面的 NAT 类型（FullCone、Restricted Cone、Port Restricted Cone、Symmetric）。
我测试了不同的工具（http://freshmeat.net/projects/jstun/，http://code.google.com/p/boogu/），但他们报告了不同的结果相同的界面。
我正在寻找Python（或其他语言，第二选择是Java，如果没有其他可用的语言）的明确答案。
I would like to discover the type of the NAT (FullCone, Restricted Cone, Port Restricted cone, Symmetric) a given network interface is behind.
I've tested different tools (http://freshmeat.net/projects/jstun/, http://code.google.com/p/boogu/) but they report different results for the same interface.
I'm looking for a definitive answer in Python (or other languages, 2nd choice being Java, if nothing else is available).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我赞同 @S.Lott 的答案：不可能使用 STUN（或任何其他协议）来 100% 确定您背后的 NAT 类型。
问题是（正如我最近目睹的那样）NAT 有时可能充当 地址 -依赖（对称），有时作为端点独立 （全锥、受限锥或端口受限锥）。
仔细想想，地址相关意味着当您从 NAT 后面的客户端上的一个套接字将数据包发送到两个不同的服务器时，NAT 将为每个服务器创建两个自定义公共地址：端口元组。 就我而言，这些绑定似乎完全随机，但如果范围很小，有时这些元组实际上是相等的！ 这使测试变得混乱。
我当时正在使用 这个库，有时它告诉我 NAT 的行为是地址相关的，有时它告诉我 NAT 的行为是地址相关的它是端点独立的（两者之间的切换似乎也是完全随机的，有时是在我重新启动设备后发生的，有时是在一段时间后发生的，...）。
我在 Slovak Telekom 的移动设备上发生了这种情况，该公司主要由 Slovak Telekom 所有="http://en.wikipedia.org/wiki/Deutsche_Telekom" rel="nofollow noreferrer">德国电信 所以我认为这个问题至少会在整个欧洲范围内出现。
我想说的是，这里的规则是这样的：如果 STUN 测试告诉您您位于对称 NAT 后面，那么情况就是如此，但如果它告诉您其他情况，那么您就不能 100% 确定。
最后一点，检查 NAT 相对于 TCP 的行为的一种简单方法是在 google 中输入“我的 IP 地址是什么”，然后打开前（比如）五个页面。 如果页面与您的 IP 地址不一致一致，则 NAT 的行为是地址相关或地址和端口相关（对称）。 但同样，如果它们确实对应，你也无法确定。
I second the answer from @S.Lott: It is not possible to use STUN (or any other protocol) to determine with 100% certainty what type of NAT you're behind.
The problem is (as I witnessed recently) that the NAT may sometimes act as Address-Dependent (Symmetric) and sometimes as Endpoint-Independent (Full, Restricted or Port Restricted cone).
When you think about it, being Address-Dependent means that when you send packets from one socket on a client behind the NAT to two distinct servers, then the NAT will create two custom public address:port tuples for each of the servers. In my case, these bindings seemed completely random, but if the range is small, it sometimes happened that these tuples were actually equal! Which confused the test.
I was using this library at the time and sometimes it told me the NAT's behavior was Address-Dependent and other times it was Endpoint-Independent (the switch between the two also seemed completely random, sometimes it happened after I restarted the device, sometimes after a time period,...).
This happened to me on a mobile device with Slovak Telekom, a company mostly owned by Deutsche Telekom so I think the problem will be at least Europe-wide.
I would say that the rule here is this: If STUN test tells you that you're behind a Symmetric NAT than that is the case, but if it tells you otherwise, then you can not be 100% sure.
One last note, an easy way to check your NAT's behavior with respect to TCP is to type "what is my IP address" into google and then open first (say) five pages. If the pages are not consistent about your IP address, your NAT's behavior is Address-Dependent or Address-and-Port-Dependent (Symmetric). But again, if they do correspond, you just can't be sure.
http://en.wikipedia.org/wiki/STUN
这足够确定吗？ 这只是维基百科的引用，但从这里看来你的请求在物理上是不可能的。
http://en.wikipedia.org/wiki/STUN
Is that definitive enough? It's only a wikipedia quote, but from this it looks like your request is physically impossible.
正如@S.Lott 所说，STUN 是您的首选协议。
然后，STUN 只是一个协议。这是我的建议：
1 STUN 现在有两个版本：旧版本是 RFC3489 - 这是一个轻量级协议，允许应用程序发现它们与公共互联网之间的 NAT 和防火墙的存在和类型（因此它主要且仅用于检测 NAT 类型） ; 新版本是 RFC5389 - 这是其他协议处理 NAT 穿越的工具。
2 另外还有一个名为 TURN 的 STUN 中继扩展 RFC5766 。 TURN 允许主机控制中继的操作并使用中继与其对等方交换数据包。 TURN 与其他一些中继控制协议的不同之处在于，它允许客户端使用单个中继地址与多个对等点进行通信。
工具：
STUN 客户端（RFC3489）：pystun 通过 python
TURN 服务器 (RFC5766) : turnserver 由 c
注意：
由于TURN是新版本STUN的扩展，因此TURN服务器也支持RFC5389新的STUN请求。
As @S.Lott 's say, STUN is your first choice protocol .
And then, STUN is just a protocol.Here is my advice:
1 STUN now has two version : the old version is RFC3489 - this is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet (so it's mainly and only for detecting NAT type ); and the new version is RFC5389 - this is a tool for other protocols in dealing with NAT traversal .
2 Also there is a relay extension to STUN named TURN RFC5766. TURN allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.
The tools:
STUN client (RFC3489) : pystun By python
TURN server (RFC5766) : turnserver By c
Note:
Because TURN is the extension of new version STUN, the TURN server also support new STUN request by RFC5389 .