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

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

我查看了StunRFC（RFC5389），它没有指定如何确定NAT类型。它确实提到了它的早期版本（RFC3489）确实提供了确定NAT类型的机制。但也提到

此外。经典的STUN的NAT类型分类算法被发现存在缺陷，因为许多NAT没有完全符合那里定义的类型。

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

---

提前感谢。

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

RFC 5389-基本STUN协议。STUN绑定请求和绑定响应的基本协议与RFC 3489基本相同。协议头会被一个魔法cookie更新，该cookie占据了一些事务id字段。一些眩晕属性被重新定义。添加了一些新的地址（特别是-XOR\U映射的\U地址）。对如何执行stunauth进行了一些更改。NAT行为和分类讨论转移到RFC 5780

RFC 5780-“使用STUN发现Nat行为”。NAT类型发现的基本变化是区分NAT端口映射行为和NAT过滤行为。而RFC 3489则试图将NAT分类为几个桶中的一个（“锥形”、“端口受限”、“对称”）——这太笼统了，无法描述NAT

RFC 5769-仅概述了几种不同的STUN消息类型的十六进制转储的外观

出于好奇，我想知道你的应用程序是否在NAT后面运行是有用的。但是知道NAT的行为会如何影响您的代码路径呢

---

GitHub上托管的无耻插件使用。

感谢您的回答。我正在研究nat遍历，因此了解nat类型会有所帮助，尽管它不会改变代码流。我认为这是一件令人兴奋的事情。顺便说一句，鉴于RFC 5389对RFC 3489机制没有很好的意见，新的RFC 5780的nat类型确定有多准确。你试过了吗？如果是的话，有什么观察结果吗？我必须回去检查我的笔记，但是大多数表现良好的NAT在映射行为方面是“端点独立的”，在过滤方面是“地址+端口依赖的”。如果你有一个这样的NAT，这就意味着你可以通过UDP通过穿孔可靠地进行P2P。如果NAT对于映射来说不是“端点独立的”（在旧的RFC中称为“对称的”），那么遍历就变得更加困难。“港口预测”有时有效。我很想和你谈谈你的项目和/或我们是否可以合作。请随时在gmail.com上与我联系。