我试图使用下面的iptables命令将传入的连接路由到另一台计算机上的teampeak服务器
iptables -t nat -A PREROUTING -p udp -s 0/0 -d LOCALIP --dport 9987 -j DNAT --to DESTINATIONIP
iptables -t nat -A POSTROUTING -o eth0 -d DESTINATIONIP -j SNAT --to-source LOCALIP
可以,但是每个加入的用户现在都有我的路由服务器的IP。
如果客户端到达路由服务器上的端口,是否可以通过某种方式直接将客户端直接推到新IP?
可以,但是每个加入的用户现在都有我的路由服务器的IP。
当服务器相距较远时,这很难避免。之所以会发生这种情况,是因为您在第2行中具有SNAT规则,并且如果最终服务器位于完全不同的网络上,则也需要该SNAT规则,以强制所有“答复”流量也通过路由服务器返回。
如果删除了SNAT规则,则将保留客户端的IP地址-但这会带来更大的问题,因为TeamSpeak服务器将直接向客户端发送响应,从而完全绕开“路由”服务器。这将使客户端感到困惑,因为它们将请求发送到地址X,并且不希望收到地址Y的响应。
一个更好的方式来做到这将是隧道的原始数据包内另一个IP数据包(使用GRE或WireGuard或OpenVPN的)。然后,您的路由服务器将通过隧道转发所有内容,并且可以轻松地将TeamSpeak服务器配置为通过隧道进行响应,而无需进行SNAT任何操作。
如果客户端到达路由服务器上的端口,是否可以通过某种方式直接将客户端直接推到新IP?
如果直接为客户端配置IP地址,则否。没有通用的IP功能。如果客户想谈谈1.2.3.4,它会跟1.2.3.4 -你不能强迫它发送数据包到5.6.7.8来代替。
这种重定向只能作为应用程序级协议功能来实现。例如,HTTP具有重定向。因此,如果TeamSpeak本身在其协议中内置了重定向,则可以使用该重定向。如果没有,那就没有。(我猜这就是“ TSDNS”的意思吗?)
但是,如果您的客户端通过域名进行连接,则可以为该域名创建“ SRV记录”,然后将TS3客户端指向其他位置。
SRV仍然依赖于应用程序级别的支持(大多数程序不了解它),但至少已正式证明TS3实际上使用SRV记录提供了支持。
概要:
您说您有一个域名。在您的情况下,最好的解决方案是使用TS3可以识别的DNS SRV记录,这基本上是它们的全部目的。这样,客户端将直接转到指定的TS3服务器,而根本无需联系您的“路由”服务器。
如果无法创建SRV记录,则在两台服务器之间建立基本隧道;删除SNAT规则;更改DNAT规则以使用TS服务器的“隧道” IP而不是其公共IP;并在TS服务器上设置“策略路由”,以便它知道通过同一隧道进行响应。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句