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

Question

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

当我运行 TURN 服务器时，我必须绑定(bind)到私有(private) IP 地址(因为服务器认为它没有连接到公共(public) Internet)。所有对分配创建的响应都会发回带有私有(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？

Answer 1

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

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

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

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

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

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

我喜欢你的第二个建议。

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