用 iptable 做这样的转发能实现么

[yingtl]

三台机器 Client_1 VPS_1 VPS_2
VPS_1 设置到达它的 PORT_A 数据 转发到 VPS_2:PORT_B， 但是不修改 src
VPS_2:PORT_B 收到数据后 看到的数据包的 src 是 Client_1

这种做法在公网上能实现么

谢谢

[trepwq]

client-1 会丢弃 vps2 的 tcp 数据包的吧

[yingtl]

@trepwq 用 UDP， 端口统统打开

[mt7620]

prerouting 做 DNAT 试试

[mt7620]

VPS1 上开来一个
iptables -t nat -A PREROUTING -p tcp --dport 12306 -j DNAT --to-destination 222.222.222.222:12315

[oott123]

听说很多机房防火墙会丢掉 src 不对的包。

[dorothyREN]

这。。。随便写个转发就行了吧

[ThirdFlame]

这不就是 目的地址转换么？

[yingtl]

@mt7620 我这里试验的是还要加一条 SNAT 不然数据到达不了， 如同 @oott123 所讲， 某个环节过滤掉了

[ivyliner]

如果 VPS_2 可以直接访问 Client 的话, 可以直接添加路由表就好了.

[ShadowStar]

和 TCP/UDP 无关，和什么机房的防火墙也无关。
对于 Client 来说，发送的五元组信息是 Client_1:Rand_Port -> VPS_1:Port_A，接收到的五元组信息是 VPS_2:Port_B -> Client_1:Rand_Port，socket 根本对不上。

[LGA1150]

@oott123 正解
@ShadowStar 其实 Client 端也可以 DNAT

[yingtl]

@ShadowStar UDP 监听的话就不用在乎这个了

[Austing]

@ShadowStar
@yingtl
和发送回复对不对的上以及 UDP 无关.
了解一下 BCP 38/RFC 2827.
如果 VPS_A 直接 DNAT 到 VPS_B 不不改变 SRC, 那么理论上就是伪造发送源进行 IP 欺骗, 99% 的 VPS 都不可能没开启 uRPF 和 ACL 来防止伪造的.
并且很多不是自有 transit 的服务商在其上游就已经被开启了 uRPF, 你可以直接在 VPS_A 尝试用 client 或其他任意 IP 直接向 B/其他服务器发包看一下, 然后接受 server tcpdump 抓包一下, 我相信对面是根本收不到的.

[Austing]

如果你想做到不改变发送源, 那你可以在 VPS_A 和 VPS_B 之间另外建立一条隧道来实现.
纯公网基本不太可能, 如果你不缺钱, 那你可以找没有开 uRPF 的机房或者自己买条 transit 做 bgp 吧 :)

[ShadowStar]

@yingtl 胡扯，你以为 UDP 就不需要 IP 了？

[ShadowStar]

@Austing 你说的这些都是外围的安全防护措施，当然可以有各种的方式。
我说的是最基础的 TCP/IP 通信基础，在什么防护措施都没有的情况下，本身就无法双向通信。

[Austing]

@ShadowStar 双向无法通信的前提是, 只是在客户端不进行任何操作的前提下, 当然无法通信, 你大可客户端 hook 再进行一次包修改.
没有任何问题, 而且使用情况也很多, 各大云的 LB 几乎全是如此.

[yingtl]

@Austing #13 早先的时候是用用户态程序做的转发, 包前面再加了个地址. 现在换成了 IPIP 隧道

[yingtl]

@Austing #12 题外话, 伪造源的话, 如果伪造的是相同机房的可以发出去么, 这些 VPS 商家的构架有防止这种情况么

[Austing]

@yingtl 一般来讲是不行的, 因为一般 VPS 服务商是在宿主机就过滤, 现在 VPS 商家常用的 solusvm openstack 之类的默认防止欺骗什么的都是最基本的- -
如果它是租用的其他服务商的服务器, 那么他的上游服务商很可能也会有过滤.
所以很多时候可能会有很多层的...
不过你可以自己试试啊, 随便用 hping 什么的发包然后抓包看看, 能收到就是能发呗.
但是你要是同机房同网络的话, IPIP 隧道正常应该也没多少性能衰减吧.