以编程方式确定路由器 NAT 类型
我需要以编程方式确定程序中的路由器 NAT 类型。我确实查看了一些与 STUN 相关的答案和 UPnP 相关信息。但没有得到任何明确的答案。
我查看了 STUN RFC (rfc 5389)，它没有指定如何确定 NAT 类型。它确实提到它的先前版本（RFC 3489）确实提供了确定 NAT 类型的机制。但还提到
此外。经典的 STUN NAT 类型分类算法被发现是错误的，因为许多 NAT 并不完全适合其中定义的类型。
鉴于上述情况，您能否建议我如何继续确定我的软件中的路由器 NAT 类型。此外，既然 RFC 3489 已经过时，还有其他方法吗？
提前致谢。
I need to programmatically determine the Router NAT type in my program. I did look at some of the STUN related answers and UPnP related information on SO. But did not get any definitive answers.
I looked at STUN RFC (rfc 5389) and it does not specify how to determine the NAT type. It does mention that it's previous version (RFC 3489) did provide the mechanism to determine NAT type. But also mentions that
Furthermore. classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there.
Given above, could you please advice on how I should go ahead with determination of router NAT type in my software. Further, now that RFC 3489 is obsoleted is there any other means?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
RFC 3489 分为三个不同的 RFC：
RFC 5389 - 基本 STUN 协议。 STUN 绑定请求和绑定响应的基本协议与 RFC 3489 基本相同。协议标头通过占据一些事务 id 字段的 magic cookie 进行更新。一些 STUN 属性被重新定义。添加了一些新的（特别是 - XOR_MAPPED_ADDRESS）。 STUN 身份验证的完成方式进行了一些更改。 NAT 行为和分类讨论移至 RFC 5780。
RFC 5780 -“使用 STUN 发现 Nat 行为”。 NAT 类型发现的基本更改是将 NAT 端口映射行为与 NAT 过滤行为分开。而 RFC 3489 会尝试将 NAT 分类为几个类别（“锥体”、“端口限制”、“对称”）之一 - 这对于描述 NAT 来说太通用了。
RFC 5769 - 只是概述了几种不同 STUN 消息类型的十六进制转储的样子。
出于好奇，我认为了解您的应用程序是否在 NAT 之后运行是很有用的。但是了解 NAT 的行为会如何影响您的代码路径呢？
无耻插件 - 使用托管在 GitHub 上的我的 STUN 服务器代码。
RFC 3489 was split into three different RFCs:
RFC 5389 - basic STUN protocol. Basic protocol of STUN binding request and binding response are largely the same as RFC 3489. The protocol header gets updated with a magic cookie occupying some of the transaction id field. Some STUN attributes get redefined. A few new ones added (specifically - XOR_MAPPED_ADDRESS). Some changes to how STUN auth is done. NAT behavior and classification discussion moved to RFC 5780.
RFC 5780 - "Nat Behavior discovery using STUN". The basic change to NAT type discovery was to distinguish NAT port mapping behavior separate from NAT filtering behavior. Whereas RFC 3489 would try to classify a NAT into one of several buckets ("cone", "port restricted", "symmetric") - which was just too generic to describe a NAT.
RFC 5769 - Just outlines what the hex dump of a few different STUN message types would look like.
Out of curiosity, I suppose knowing if your app is running behind a NAT is useful. But how would knowing the NAT's behavior influence your code path?
Shameless plug - Use my STUN Server code that is hosted on GitHub.