以编程方式确定路由器 NAT 类型答案

【问题标题】：Programmatically determine the Router NAT type以编程方式确定路由器 NAT 类型
【发布时间】：2012-01-26 00:40:18
【问题描述】：

我需要在我的程序中以编程方式确定路由器 NAT 类型。我确实查看了一些与 STUN 相关的答案和关于 SO 的 UPnP 相关信息。但没有得到任何明确的答案。

我查看了 STUN RFC (rfc 5389)，它没有指定如何确定 NAT 类型。它确实提到它的先前版本（RFC 3489）确实提供了确定 NAT 类型的机制。但也提到了

此外。经典的 STUN 的 NAT 类型分类算法被发现有问题，因为许多 NAT 并不能完全适合那里定义的类型。

鉴于上述情况，您能否建议我应该如何继续在我的软件中确定路由器 NAT 类型。此外，既然 RFC 3489 已经过时，还有其他方法吗？

提前致谢。

【问题讨论】：

标签： nat nat-traversal stun

【解决方案1】：

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

RFC 5389 - 基本 STUN 协议。 STUN 绑定请求和绑定响应的基本协议与 RFC 3489 基本相同。协议标头会使用一个魔术 cookie 更新，该 cookie 占据了一些事务 id 字段。一些 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 上的 my STUN Server code。

【讨论】：

感谢您的回答。我正在研究 nat 遍历，因此了解 nat 类型会有所帮助，尽管它不会改变代码流。我认为这是一件令人兴奋的事情。
顺便说一句，鉴于 RFC 5389 对 RFC 3489 机制没有很好的意见，使用较新的 RFC 5780 确定 nat 类型的准确性如何。你有没有试过，如果有，有什么观察吗？
我必须回去检查我的笔记，但大多数表现良好的 NAT 在其映射行为方面是“端点独立的”，而在过滤方面是“地址+端口相关的”。如果您拥有这些 NAT 之一，这仅意味着您可以通过带有打孔的 UDP 可靠地进行 P2P。如果该 NAT 不是“独立于端点”的映射（在旧 RFC 中也称为“对称”），则遍历变得更加困难。 “端口预测”有时会起作用。我很想和你聊聊你的项目和/或我们是否可以合作。请随时在 gmail dot com 上与我离线 jselbie 跟进。