iptables端口映射必须完成四步：开启ip_forward、配置PREROUTING DNAT、放行FORWARD链、添加POSTROUTING MASQUERADE/SNAT，缺一不可。
iptables端口映射必须配齐四步，漏一步就连接失败
Linux端口映射不是加一条iptables -t nat -A PREROUTING就能完事。它本质是数据包在内核网络栈中的一次完整旅程：进得来、改得了、转得过去、回得回来。缺任何一环，客户端看到的都是Connection refused或彻底无响应——连超时都不报。
这四步是硬性依赖：
- 开启
/proc/sys/net/ipv4/ip_forward（值必须为1），否则内核直接丢弃非本机目的地址的数据包 -
iptables -t nat -A PREROUTING做DNAT，把外部请求的目标IP和端口重写成内网服务地址 -
iptables -A FORWARD显式放行，否则默认策略为DROP时包在转发链就被拦下 -
iptables -t nat -A POSTROUTING加MASQUERADE或SNAT，确保内网服务返回时源IP是网关自身，不然客户端收不到响应
PREROUTING DNAT规则写错的三个典型表现
很多人以为--to-destination填对了IP和端口就OK，但实际运行时仍不通。常见问题集中在入口匹配、目标可达性和协议一致性上：
- 没指定入口接口（如
-i ens33），当机器有多网卡时，规则可能被误匹配到内网流量，导致本该转发的包被忽略 -
--dport写成内网服务端口（比如--dport 80），而客户端实际访问的是8080；正确写法是--dport 8080对应外网入口端口 -
--to-destination后的IP不可达，比如目标主机不在同一子网且没配静态路由，或防火墙本身无法ping通该IP - 用
REDIRECT代替DNAT：前者只适用于本机进程发包（如本地代理），跨主机转发必须用DNAT
FORWARD链放行不等于“允许所有转发”
单纯执行iptables -A FORWARD -j ACCEPT看似简单，但在生产环境极不安全，也容易掩盖真实问题。真正有效的放行要绑定方向和状态：
- 最简但可用：
iptables -A FORWARD -p tcp -d 192.168.1.100 --dport 80 -j ACCEPT（仅放行去往目标服务的流量） - 更推荐显式约束：
iptables -A FORWARD -i ens33 -o ens34 -p tcp -d 192.168.1.100 --dport 80 -j ACCEPT（限定入接口和出接口） - 必须加状态跟踪：
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT，否则TCP三次握手都完成不了——SYN能过去，SYN-ACK被DROP - 检查规则顺序：
iptables -L FORWARD -n --line-numbers，确认ACCEPT规则没被前面的REJECT或DROP拦截
firewalld转发必须手动开启masquerade
用firewall-cmd --add-forward-port看起来一行搞定，但实际生效有两个隐藏前提，漏一个就静默失败：
- 必须执行
firewall-cmd --add-masquerade --permanent，否则内网服务返回包的源IP仍是私有地址（如192.168.1.100），外网客户端无法路由回来 - 必须确认当前active zone（如
public），且该zone的target不能是default或REJECT；可用firewall-cmd --get-active-zones验证 - 所有
--permanent操作后必须firewall-cmd --reload，仅--permanent不reload不会生效 - 示例完整命令：
firewall-cmd --permanent --add-forward-port=port=2222:proto=tcp:toaddr=192.168.2.5:toport=22→firewall-cmd --add-masquerade --permanent→firewall-cmd --reload
云主机或Docker宿主机重启后ip_forward常被重置，每次上线前务必cat /proc/sys/net/ipv4/ip_forward确认为1——这是整个链路最底层却最容易被忽略的开关。
