必须用MASQUERADE而非SNAT，因其自动适配DHCP/PPPoE等动态公网IP，避免IP变更导致NAT失效；同时须开启并持久化IP转发、限定源地址段、保存iptables规则、放行FORWARD链，否则流量不通或真实IP暴露。
直接结论：用 iptables -t nat -A POSTROUTING -o -j MASQUERADE 即可实现隐藏内网真实 IP 的动态 NAT，但必须配合开启 IP 转发、限制源地址、防止规则丢失这三步，否则流量不通或暴露风险仍在。
为什么必须用 MASQUERADE 而不是 SNAT
当服务器外网接口使用 DHCP 或 PPPoE（如家庭宽带、云厂商弹性公网 IP 绑定变动）时，公网 IP 不固定。SNAT --to-source 需要写死 IP，一旦 IP 变更，NAT 规则立即失效；而 MASQUERADE 会自动读取出口接口当前生效的 IP 地址，无需人工干预。它本质是 SNAT 的动态封装版，底层仍依赖连接跟踪（nf_conntrack），所以也要求内核模块已加载。
常见错误现象：ping 内网客户端能通网关，但无法访问外网；tcpdump 抓包发现出向数据包源 IP 仍是私有地址——大概率是没开转发或规则未命中。
- 确认外网接口名（别错写成
eth0实际是ens3或enp37s0f1）：运行ip -br a - 务必加
-s限定源地址段，避免把本机其他流量也伪装（例如管理口流量）：iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o ens3 -j MASQUERADE - 不要省略
-t nat，漏掉就写进 filter 表，完全无效
IP 转发不是“开了就行”，得持久且生效
echo 1 > /proc/sys/net/ipv4/ip_forward 是临时开关，重启即丢。真正起效需两步落地：
- 写入
/etc/sysctl.conf：追加net.ipv4.ip_forward = 1，然后执行sysctl -p - 验证是否生效：
sysctl net.ipv4.ip_forward输出应为net.ipv4.ip_forward = 1，不是0 - 某些发行版（如 CentOS 8+/RHEL 8+）默认用
nftables替代iptables，此时即使开了转发，iptables规则也可能被绕过——需确认iptables-legacy模式启用：update-alternatives --config iptables
规则不保存 = 白配，不同系统持久化方式完全不同
CentOS 7+ 和 Ubuntu 20.04+ 默认不自带规则持久化机制，重启后 iptables -t nat -L 看得到规则，但实际不生效。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- Ubuntu/Debian：安装
iptables-persistent，保存命令是iptables-save > /etc/iptables/rules.v4（注意路径和文件名，错一个字符都不加载） - CentOS 7+/RHEL 7+：需先
yum install iptables-services，再执行service iptables save（会存到/etc/sysconfig/iptables），并systemctl enable iptables - 切勿手动往
/etc/rc.local写iptables-restore—— systemd 下该文件默认不执行，且时机晚于网络初始化，易导致规则加载失败
容易被忽略的 FORWARD 链放行问题
POSTROUTING 规则只管地址转换，不管“让不让过”。若 FILTER 表的 FORWARD 链默认是 DROP（多数安全加固模板如此），内网流量会在到达 nat 表前就被拦住。
必须显式放行两类包：
- 已建立/关联连接的返回流量：
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT - 内网发起的新连接：
iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT（注意顺序，这条必须在 ESTABLISHED 规则之后） - 别漏掉
-A是追加，如果已有REJECT规则在前面，新规则加在末尾也没用——用iptables -L FORWARD --line-numbers查位置，必要时用-I插入
隐蔽性真正的薄弱点不在 NAT 本身，而在 FORWARD 链配置疏漏、IP 转发未持久、或 MASQUERADE 未限定源段导致本机管理流量也被伪装——这些细节一错，内网拓扑或真实 IP 就可能从 DNS 查询、HTTP 头、甚至 TLS SNI 泄露出去。
