nat网关配置需区分snat与dnat、合理规划pat端口、保障conntrack状态同步，并警惕绕过nat的安全盲区。

配置NAT网关不是“填个公网IP就完事”的操作，它直接决定内网能否出得去、外网能否连得进、数据是否被篡改或劫持。真正出问题时，往往表现为：内网用户突然无法上网、外部服务访问超时、端口映射失效、日志里反复出现“no route to host”或“connection refused”，甚至更隐蔽的——流量被静默丢弃或重定向。这些问题背后，多数源于对NAT工作层级、地址复用逻辑和安全边界的误判。

地址转换方向搞反：出站NAT与入站DNAT混为一谈

NAT不是单向开关，而是分场景的双向翻译机制：

• 出站NAT（SNAT/PAT）：内网私有地址→防火墙/网关公网出口地址，用于内网访问外网。必须配缺省路由指向网关，且策略需明确放行trust→untrust方向的流量。
• 入站DNAT：外部公网地址+端口→内网服务器私有地址+端口，用于发布内部服务。必须在安全策略中显式允许untrust→trust方向的对应端口，否则即使DNAT规则生效，包也会被策略丢弃。
• 常见错误：只配了DNAT规则，却忘了开安全策略；或把SNAT规则误写成目的地址转换，导致回程路由断裂。

端口复用冲突：PAT表耗尽或端口被意外占用

当大量内网终端共用一个公网IP做SNAT时，防火墙靠“IP+源端口”唯一标识会话。一旦端口分配枯竭或冲突，新连接就会失败：

• 默认PAT端口范围通常是1024–65535（约6.4万个），但部分设备（如早期华为USG）默认仅启用32768–65535，实际可用仅3.2万；高并发场景下极易打满。
• 某些应用（如SIP、FTP主动模式）会主动绑定高位端口，若与PAT池重叠，可能造成会话映射失败或音频中断。
• 建议：检查并扩大PAT端口范围（如配置nat port-range 1024 65535），对关键业务服务器禁用PAT，改用一对一静态NAT。

状态跟踪失效：NAT与连接跟踪（conntrack）不同步

NAT依赖连接状态表维持双向流匹配。一旦状态表异常，就会出现“能发不能收”或“回程包被当成非法新建连接丢弃”：

• 防火墙重启、配置热加载、或遭遇SYN Flood攻击时，conntrack表可能溢出或条目老化异常。
• Docker宿主机上，iptables的NAT规则与内核conntrack模块存在竞态：容器频繁启停易导致NAT规则残留，新连接命中旧映射，回程包走错路径。
• 排查方法：Linux下执行conntrack -L | grep "dst=公网IP"查看活跃NAT会话；华为防火墙可用display firewall session table verbose确认源/目的地址及NAT后地址是否一致。

绕过NAT的安全盲区：内网直连、DNS劫持与透明代理陷阱

NAT本身不提供安全防护，反而可能掩盖真实威胁面：

• 内网终端若手动配置了指向公网DNS（如8.8.8.8）或设置了静态路由，可能绕过网关NAT和安全策略，形成“策略旁路”。
• ARP欺骗+DNS响应注入（如Ettercap场景）可在NAT前劫持域名解析，使用户访问伪造站点——此时NAT照常工作，但流量早已被污染。
• 某些企业级网关开启“透明代理”后未同步更新证书信任链，导致HTTPS连接被中间人解密失败，浏览器报SSL_ERROR_BAD_CERT_DOMAIN，表面像NAT故障，实为TLS层拦截异常。

不复杂但容易忽略