iptables做端口转发

操作前说明 #

在 Linux 环境中执行系统级命令前，建议先确认发行版版本、当前用户权限和目标路径。涉及网络、磁盘、包管理、iptables 或系统服务的操作，最好先在测试环境验证，再放到生产服务器上执行。

原始操作记录 #

最常用的转发，从 192.168.1.21:59388 转发到 192.168.1.20:5938

pro='tcp'
NAT_Host='192.168.1.21'
NAT_Port=5938
Dst_Host='192.168.1.20'
Dst_Port=5938
iptables -t nat -A PREROUTING -m $pro -p $pro --dport $NAT_Port -j DNAT --to-destination $Dst_Host:$Dst_Port
iptables -t nat -A POSTROUTING -m $pro -p $pro --dport $Dst_Port -d $Dst_Host -j SNAT --to-source $NAT_Host
iptables -A FORWARD -d $Dst_Host -j ACCEPT

不常用的转发，192.168.1.21 所有端口全部转发到 192.168.1.20

NAT_Host='192.168.1.21'
Dst_Host='192.168.1.20'
iptables -t nat -A PREROUTING -p tcp -d $NAT_Host -j DNAT --to $Dst_Host
iptables -t nat -A POSTROUTING -p tcp -d $Dst_Host -j SNAT --to $NAT_Host
iptables -A FORWARD -d $Dst_Host -j ACCEPT

最特别的转发，从 10.0.0.30:59388 转发到 127.0.0.1:5938

sysctl -w net.ipv4.conf.eth1.route_localnet=1
iptables -t nat -A PREROUTING -p tcp -d 10.0.0.30.179 --dport 5938 -j DNAT --to 127.0.0.1:59388
iptables -t nat -A POSTROUTING -d 127.0.0.1 -p tcp --dport 59388 -j SNAT --to-source 10.0.0.30.179

注意：第一条命令的 eth1 为 10.0.0.30 所在网卡。

注意注意注意：这是不安全的做法，因为这样的流量是不正常的。

但是，偶尔有用，具体场景就是通过 SSH 做远程转发，Server 端默认只监听 127.0.0.1，然后就可以用这种转发通过 Server 端访问 Client 端了

关键理解 #

这类笔记最重要的不是把命令背下来，而是弄清楚它解决的是什么问题、依赖什么环境、执行后会改变什么。以后再次遇到类似情况时，可以先根据标题判断问题方向，再对照原始命令确认是否适合当前系统版本。

如果命令中包含具体路径、网卡名、磁盘名、进程名、IP 地址、端口号、用户名称或软件版本，实际执行时都要替换成自己环境中的真实值。不要直接照抄示例里的占位内容。

验证方法 #

执行完成后不要只看命令是否返回成功，还应结合服务状态、配置文件内容、日志输出和实际访问结果一起判断。常用检查命令包括 systemctl status、journalctl -xe、ip addr、ip route、cat、grep 等。

如果验证结果和预期不一致，建议先不要继续叠加更多修改，而是回到第一步检查环境差异。很多问题并不是命令本身错误，而是当前系统版本、软件版本、路径名称或权限条件与原记录不一致。

注意事项 #

如果是在远程服务器上操作，尤其是网络、SSH、DNS、防火墙相关配置，必须提前准备控制台、VNC、快照或备份，避免因为配置错误导致无法重新连接。

对于旧文章中的命令，还要考虑软件版本变化。浏览器 flags、Linux 发行版默认配置、Python 包版本、Windows 系统设置都会随着时间调整。再次使用时，最好把这篇记录当成排查思路，而不是绝对固定的唯一答案。

小结 #

这篇记录可以作为一个快速索引：先看标题确认问题类型，再看原始命令找到核心操作，最后结合验证方法确认是否真正生效。这样既保留了早期备忘的简洁性，也能减少以后重复排查的时间。