TURN 服务器在防火墙后面 - 如何处理 XOR-RELAYED-ADDRESS

Question

我正在防火墙后面的服务器上运行 TURN 服务器 (http://tools.ietf.org/html/rfc5766)。机器有一个公共 IP 地址，传入和传出的网络数据包从服务器的专用 IP 地址发送到/从该地址发送。基本上，服务器不能将套接字绑定到公共 IP 地址，只能绑定私有 IP 地址。运行 ifconfig 显示网络设备具有私有 IP 地址。

当我运行 TURN 服务器时，我必须绑定到私有 IP 地址（因为服务器不认为它连接到公共 Internet）。对分配创建的所有响应都会发回带有私有 IP 地址的 XOR-RELAYED-ADDRESS。客户端收到 XOR-RELAYED-ADDRESS 并将数据发送到服务器的私有 IP 地址，这显然失败了。

我正在考虑两种选择来克服这个问题：

• 让我的客户端代码忽略 XOR-RELAYED-ADDRESS 的 IP 地址，只使用 XOR-RELAYED-ADDRESS 的端口。客户端会将所有中继消息发送到 TURN 服务器的公共 IP（因为客户端已经事先知道该值）和 XOR-RELAYED-ADDRESS 端口。
• 更改我的服务器以了解其公共 IP（即使它无法将套接字绑定到它），并始终在 XOR-RELAYED-ADDRESS 响应中发回公共 IP。

我觉得第一种方法破坏了 TURN RFC...即使我无法想象 TURN 服务器会将 XOR-RELAYED-ADDRESS 的 IP 作为 TURN 服务器的公共 IP 以外的其他东西发送回的情况， RFC 说 XOR-RELAYED-ADDRESS 是客户端应该发送数据的地方。

我觉得第二种方法破坏了 RFC less...如果这有意义的话。此外，这种方法不会强制客户端做任何特殊的事情，而第一种方法需要所有客户端都遵守上述规定。

您对此有何看法？有没有人经历过这种情况，和/或对哪种方法破坏 RFC 更少，或者任何一种方法是否违反了 RFC 有任何意见？

Answer 1

我在 Amazon EC2 上运行 my STUN server code 时遇到了几乎完全相同的问题。 stun 服务器返回给客户端的源地址和备用地址是经过 NAT 处理的 IP 地址。

我想到的一些解决方案：

1. 假设客户端已预先配置为知道备用 IP 地址，如果他们确实想要进行额外的 NAT 类型检测测试。对于 STUN，这不是一个糟糕的假设。毕竟，他们应该知道 stun 服务的主 IP 地址。

2. 修改服务器代码以从命令行或配置文件传递它的映射 IP 地址。这相当于你上面描述的第二种方法。我可以让服务器在启动时通过 Web 请求（或测试另一个 stun 服务器）自行发现它自己的外部 IP 地址，以使其自动完成。

假设您不尝试与除您自己以外的其他客户端进行互操作，那么您的第一个建议 - 客户端知道 IP 映射 - 非常好。但是，如果您认为您需要使用其他人的客户端堆栈，那么这个选项就变得不那么可取了。您可以采用混合方法 - 为 TURN Allocate 响应发明一个新的自定义属性，您的客户端理解为“忽略中继 IP，只假设端口是正确的”。这还可以，但不是很好。

你的第二个建议更符合我上面的#2。还有一件事要考虑。如果您的客户端也位于与您的 TURN 服务器相同的防火墙后面，会发生什么情况？你要内部地址还是外部地址？再说一次，如果你的两个客户端都在同一个防火墙后面，他们可能不需要 TURN 来通信。另一个问题只是将正确的 IP 地址传递给服务器的管理开销。

我喜欢你的第二个建议。

您可以考虑将问题发布到BEHAVE IETF email discussion group。他们是起草 STUN 和 TURN 规范的开放委员会。我认为他们应该意识到，在 NAT 后面运行的云服务器正变得越来越普遍。他们可能有一些建议。我非常有兴趣与您共同撰写这封电子邮件。或者至少阅读他们的回复。