静态路由效率高。

DNAT SNAT 端口转发肯定不如路由。

其实你不需要iptables DNAT，A做静态路由，把C网段的路由指向B，B做源地址路由（策略路由）把A来的请求指向C。这是三层转发（路由），能访问C的任何端口、任何协议，而且性能好。如果用iptables 做DNAT端口转发就是四层的，只能每个端口+协议的组合单独配置，性能也打折扣。

回程最简单是B开 masquerade，C看到的是B发来的请求回给B，B的masquerade机制回给A，iptables的masquerade本质是SNAT四层转发。

如果能在C上配静态路由就更好了，直接把A的网段指向B，B知道C在哪儿，不需要四层转发了，B什么都不用做回程就通了。

【 在 hyoga 的大作中提到: 】
: A机需要从B机跳转到C机，在B上做了一条DNAT，把从A访问B的特定端口转发到C。
: 那么回程的两种方式：
: 1）在C上添加静态路由，所有访问A IP的走B路由；
: ...................
--
FROM 123.126.43.*

按理说不应该出现源、目的地址不匹配的情况，所以你的环境还是没描述清楚，你ABC之间具体是什么情况？

正常来说，A->B和B->C应该有各有一条类似隧道的链路，AB都有私网地址，隧道当然可以建在公网上。

这样的话，路由或四层转发都可以，而且可以一个方向路由、另一个方向四层转发，只要不出现你说的那种源、目的错乱就可以了。

如果A和B都只有公网地址，没任何形式的隧道，那就没办法用路由的方式，必须做4层的转发，A发给B，B把A->B的包换成B->C发出去，回程再换一遍，AB之间所有包全程都在公网上跑。

但是这种情况下不会涉及C该不该设静态路由去A啊，因为C不会收到A发来的包(源、目的都被B替换了），不可能回给A，只会回包给B啊。

【 在 freyoneby 的大作中提到: 】
: 关键别人进来的时候做了DNAT，只做路由，A收到的包是C的源地址，A发出去的包又是B的地址，socket能建立起来？只有方案1可行吧
--
FROM 123.126.43.*

路由性能最好，包原封在跑，内核的路由模块性能很高。
四层转发次之，要改源、目的地址，要conntrak，但还是在内核里处理。
五花八门儿的代理性能差，可靠性也差，要进出 user space。

如果是互联网企业，这样的需求，能用路由解决肯定不会走四层转发，走四层转发也不用iptables（本质是netfilter，落后生产力了）。代理就不用说了。

个人用途其实怎么实现都无所谓，达成目的就好。

顺便吐糟一下，网上总有些小白认为各种代理好，最著名的就是ss之类的，其实都是些厨余垃圾（没法算工业垃圾）。

【 在 Loveni 的大作中提到: 】
: google下tcpproxy或者rinetd。
: 简单不简单看需求看场景，这个世界基本逻辑就是垃圾被淘汰，存在即合理。
:
--
FROM 111.201.129.*

用nginx的地方是必须拆包到7层才能解决问题

楼主的问题3层就能解决，最多用到4层

你这是无知搅*棍

【 在 Loveni 的大作中提到: 】
: 不要拽概念，proxy不在7层在哪？nginx最常用的不是反代是啥？
: 都吹互联网高性能网络，还不学学阿里最近RP的RDMA的落地应用？不懂就去搜搜
:
: ...................
--
FROM 111.201.129.*