NAT 不生效的固定排查顺序
内网出不去或外网进不来时，按固定顺序排查能少走弯路：先看接口角色与转换条目挂载的接口是否正确，再看源选择规则是否命中，接着看是否产生会话，最后核对回程路由与上层服务。前三步判断问题是否出在 NAT 本身，后两步判断流量已经转换但路径或服务有问题。前后两段的排查方向完全不同，先分清在哪一段是关键。
基本信息
| 适用平台 | 三厂设备通用排查流程 |
|---|---|
| 第一步 | 接口角色与命令挂载位置是否正确 |
| 第二步 | 源选择规则是否命中，看规则计数 |
| 第三步 | 会话表是否有表项产生 |
| 第四步 | 回程路由与服务器侧放行是否到位 |
典型使用场景
- 内网主机能 ping 网关但上不了网
- 外网访问内网服务不通，需要区分是映射问题还是服务问题
- 变更完成后业务未按预期恢复，需要快速定位是否 NAT 相关
- 间歇性不通的排查：需要多次采样会话与计数
- 厂商设备替换后的验收检查
华为 VRP
华为 VRP
display nat outbound # 条目是否挂在正确的接口上
display acl 2000 # 规则命中计数是否增长
display nat session all # 是否产生转换会话
display ip routing-table 8.8.8.8 # 是否有出网路由思科 IOS
思科 IOS
show ip nat statistics # 看接口角色与命中未命中计数
show access-lists 1 # 源选择规则计数
show ip nat translations # 会话表
show ip route 8.8.8.8 # 回程与出网路由H3C Comware
H3C Comware
display nat outbound
display acl 2000
display nat session all
display ip routing-table 8.8.8.8现象与定位对照
| 现象 | 优先检查 | 说明 |
|---|---|---|
| 规则计数不增长 | 源选择 ACL 覆盖范围 | 流量未命中规则，问题在规则而不是设备 |
| 计数增长但无会话 | 命令挂载位置与接口角色 | 流量进入设备但未进入转换流程 |
| 有会话但业务不通 | 回程路由与服务器放行 | 转换正常，问题在下游 |
| 间歇性不通 | 会话老化、链路抖动与负载分担 | 需要多次采样，单次快照看不出问题 |
| 只有部分主机受影响 | 源选择范围与终端分布 | ACL 与地址规划不匹配是常见原因 |
排查纪律
- 改配置前先采集现状：规则、计数、会话、路由四项快照都要留，回退与对比才有依据
- 一次只改一处并立即验证：多点同时修改会让因果关系无法判断
- 用测试流量触发：没有流量经过时看不到会话，测试时从真实客户端发起
- 把公网侧测试与内网侧测试分开做：两侧结果不同能快速判断问题方向
- 记录排查过程中每一步的现象，交接与复盘时价值极高
常见疑问
- 为什么改了配置没变化：可能改的不是生效的那一份，核对运行的配置与引用关系
- 清不清会话表：非必要不清，清空会中断在线业务
- 怎么判断是设备问题还是运营商问题：在设备上向公网地址做连通性测试，区分故障边界
- 为什么同一网段两台主机表现不同：检查终端自身网关、地址与主机防火墙
思科的统计输出会直接列出已标记为内外网的接口，是排查第一步最快的依据；华为与 H3C 则通过查看转换条目确认挂在哪个接口上，思路一致。
把这份顺序固化成巡检脚本的检查项：规则计数、会话数量、接口状态三项定期采集，异常时能立刻看出是哪一环先出的问题。