2

我在防火墙后面的服务器上运行 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 的破坏更少……如果这有意义的话。此外，这种方法不会强制客户端做任何特殊的事情，而第一种方法需要所有客户端都遵守上述规定。

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

4

1 回答 1

4

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

我考虑过的一些解决方案：

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

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

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

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

我喜欢你的第二个建议。

You could consider posting a question to the BEHAVE IETF email discussion group. They are the open committee that drafted the STUN and TURN specs. I think they should be aware that servers in the cloud running behind NATs are becoming increasingly common. They may have some advice. I would be keenly interested in joint authoring this email with you. Or at least reading their response.

于 2012-07-22T07:30:15.630 回答