我正在防火墙后面的服务器上运行 TURN 服务器 (http://tools.ietf.org/html/rfc5766)。该计算机具有公共(public) IP 地址，传入和传出的网络数据包发送到服务器的私有(private) IP 地址或从服务器的私有(private) IP 地址发送。基本上，服务器不能将套接字绑定(bind)到公共(public) IP 地址，只能绑定(bind)到私有(private) IP 地址。运行 ifconfig 显示网络设备具有私有(private) IP 地址。
当我运行 TURN 服务器时，我必须绑定(bind)到私有(private) IP 地址(因为服务器认为它没有连接到公共(public)互联网)。对分配创建的所有响应都会发送回带有私有(private) IP 地址的 XOR-RELAYED-ADDRESS。客户端收到 XOR-RELAYED-ADDRESS 并将数据发送到服务器的私有(private) IP 地址，这显然失败了。
我正在考虑两种选择来克服这个问题:
- 让我的客户端代码忽略 XOR-RELAYED-ADDRESS 的 IP 地址并仅使用 XOR-RELAYED-ADDRESS 的端口。客户端会将所有中继消息发送到 TURN 服务器的公共(public) IP(因为客户端事先已经知道该值)和 XOR-RELAYED-ADDRESS 端口。
- 更改我的服务器以了解其公共(public) IP(即使它无法将套接字绑定(bind)到它)，并始终在 XOR-RELAYED-ADDRESS 响应中发回公共(public) IP。
我觉得第一种方法破坏了 TURN RFC...尽管我无法想象 TURN 服务器将 XOR-RELAYED-ADDRESS 的 IP 作为 TURN 服务器的公共(public) IP 以外的其他内容发回的情况， RFC 表示 XOR-RELAYED-ADDRESS 是客户端应将数据发送到的地址。
我觉得第二种方法对 RFC 的破坏更少...如果这有意义的话。此外，该方法不会强制客户端做任何特殊的事情，而第一种方法需要所有客户端都遵守上述内容。
你对此有何看法？有没有人经历过这种情况，和/或对哪种方法破坏 RFC 更少有任何意见，或者是否有任何一种方法违反了 RFC？
最佳答案
我运行 my STUN server code 时遇到几乎完全相同的问题在亚马逊 EC2 上。 stun 服务器返回给客户端的原始地址和备用地址是经过 NAT 处理的 IP 地址。
我考虑过的一些解决方案:
如果客户端确实想要执行额外的 NAT 类型检测测试，则假设客户端已预先配置为知道备用 IP 地址。对于 STUN 来说，这是一个不错的假设。毕竟，他们应该知道 stun 服务的主 IP 地址。
修改服务器代码以从命令行或配置文件传递映射的 IP 地址。这相当于上面描述的第二种方法。我可以让服务器在启动时通过网络请求自行发现它自己的外部 IP 地址(或测试另一个 stun 服务器)，以实现自动发现。
假设您没有尝试与除您自己的客户端以外的其他客户端进行互操作，那么您的第一个建议 - 客户端了解 IP 映射 - 就完全没问题。但是，如果您认为需要使用其他人的客户端堆栈，那么此选项就不太理想了。您可以采用混合方法 - 为 TURN 分配响应发明一个新的自定义属性，您的客户端将其理解为“忽略中继 IP，仅假设端口是正确的”。这还可以，但不是很好。
你的第二个建议更符合我上面的#2。还有一件事需要考虑。如果您的客户端也与您的 TURN 服务器位于同一防火墙后面，会发生什么情况？您想要内部地址还是外部地址？话又说回来，如果您的两个客户端位于同一防火墙后面，他们可能不需要 TURN 进行通信。另一个问题只是将正确的 IP 地址传递到服务器的管理开销。
我喜欢你的第二个建议。
您可以考虑将问题发布到 BEHAVE IETF email discussion group 。他们是起草 STUN 和 TURN 规范的开放委员会。我认为他们应该意识到，在 NAT 后面运行的云服务器正变得越来越普遍。他们可能会提供一些建议。我非常有兴趣与您共同撰写这封电子邮件。或者至少阅读他们的回复。
关于networking - 防火墙后面的 TURN 服务器 - 如何处理 XOR-RELAYED-ADDRESS，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11527654/