我在防火墙后面的服务器上运行TURN服务器（http://tools.ietf.org/html/rfc5766）。该计算机具有公共IP地址，其中传入和传出的网络数据包将发送到服务器的专用IP地址或从服务器的专用IP地址发送。基本上，服务器无法将套接字绑定到公共IP地址，只能绑定私有IP地址。运行ifconfig会显示网络设备具有专用IP地址。
当我运行TURN服务器时，我必须绑定到私有IP地址（因为服务器不认为它连接到公共Internet）。对分配创建的所有响应都会将私有IP地址发回XOR-RELAYED-ADDRESS。客户端收到XOR-RELAYED-ADDRESS并将数据发送到服务器的私有IP地址，这显然会失败。
我正在考虑两种方案来克服这个问题：
我觉得第一种方法打破了TURN RFC ...即使我无法对TURN服务器将XOR-RELAYED-ADDRESS的IP作为TURN服务器的公共IP之外的其他内容发回的情况进行成像， RFC表示XOR-RELAYED-ADDRESS是客户端应该向其发送数据的。
我觉得第二种方法打破了RFC less ......如果这有意义的话。此外，这种方法不会强迫客户做任何特殊的事情，而第一种方法需要所有客户都遵守上述规定。
您如何看待这个？有没有人经历过这个，和/或对哪个方法打破更少的RFC，或者哪个方法甚至违反了RFC？
答案 0 :(得分：3)
我在Amazon EC2上运行my STUN server code的问题几乎相同。击晕服务器返回给客户端的原始地址和备用地址是NAT的IP地址。
我想过的一些解决方案：
假设客户端已预先配置为知道备用IP地址（如果他们确实想要执行其他NAT类型检测测试）。这对于STUN来说并不是一个糟糕的假设。毕竟，他们应该知道昏迷服务的主要IP地址。
修改服务器代码，使其从命令行或配置文件传递映射的IP地址。这相当于您上面描述的第二种方法。我可以让服务器在启动时通过Web请求自行发现它自己的外部IP地址（或测试另一个昏迷服务器）。
您的第一个提案 - 客户知道IP映射 - 假设您没有尝试与您自己以外的其他客户端互操作，那就完全没问题了。但是如果你认为你需要使用别人的客户端堆栈，那么这个选项变得不那么令人满意了。您可以采用混合方法 - 为客户理解的TURN Allocate响应创建一个新的自定义属性，“忽略中继IP，只是假设端口正确”。这没关系，但不是很好。
你的第二个建议更符合我上面的＃2。还有另外一件事要考虑。如果您的客户也在与TURN服务器相同的防火墙后面会发生什么？你想要内部地址还是外部地址？然后，如果您的客户端都在同一防火墙后面，他们可能不需要TURN进行通信。另一个问题只是将正确的IP地址传递给服务器的管理开销。
我喜欢你的第二个提案。
您可以考虑向BEHAVE IETF email discussion group发帖提问。他们是起草STUN和TURN规范的公开委员会。我认为他们应该意识到在NAT后面运行的云中的服务器正变得越来越普遍。他们可能会有一些建议。我非常希望与您联合创作这封电子邮件。或至少阅读他们的回应。