## 几个选项对比
把到达某端口的流量转给另一台机器，三种常用做法各有性格。iptables 的 DNAT 在内核网络层改写目标地址，性能最好，不增加用户态进程，但规则复杂、排障门槛高，且要连带考虑回程的源地址伪装。rinetd 是专职的单配置文件转发守护进程，一行一条转发规则，简单到极致，性能对一般业务够用。ssh 隧道靠加密连接承载转发，零配置开箱即用，天然跨公网，但依赖 ssh 连接的存活，稳定性最弱。
iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp \ --dport 8080 -j DNAT --to-destination 192.168.10.20:80 iptables -t nat -A POSTROUTING -d 192.168.10.20 -p tcp \ --dport 80 -j MASQUERADE
# rinetd 配置 203.0.113.10 8080 192.168.10.20 80
ssh -L 0.0.0.0:8080:192.168.10.20:80 user@跳板机 -N
## 各自适用面
iptables 适合长期、稳定、高性能的转发场景，规则随防火墙体系统一管理，配合持久化机制开机生效。rinetd 适合没有防火墙体系包袱、只想快速加一条映射的场景，例如临时把内网服务暴露给测试方。ssh 隧道适合个人临时访问与排障，加密通道跨公网最省事，但生产长期依赖它是事故隐患。
## 选择建议
判断标准两条：转发要活多久，流量走不走公网。长期转发用 iptables 纳入防火墙规则统一维护；短期测试用 rinetd 随建随拆；个人排障用 ssh 隧道。顺云云服务器之间尽量直接内网互通，转发只作为过渡手段，需要对外暴露服务时优先评估端口是否该直接监听公网并配好防火墙规则。
iptables 方案的持久化要点单独强调：nat 表规则与过滤器规则都要纳入统一的保存恢复机制，只保存了过滤规则而漏掉 nat 表，重启后转发失效而防火墙还在，排查方向会被带偏。规则的注释字段写清每条转发的用途与创建时间，一年后的维护者会感谢这个习惯。
另外两条路线的运维细节：rinetd 的转发不改变来源地址，后端日志里看到的都是转发机地址，需要真实来源就换 DNAT 方案或配合协议层传递；ssh 隧道长期使用要配自动重连与监控，断了没人知道是常态事故。转发架构变更时同步更新安全文档与拓扑图，隐蔽的转发链路是安全的盲区。