先路由后 NAT 是什么
主流防火墙与路由设备的转发顺序是先查路由确定出接口与下一跳，再按策略执行目的 NAT 与源 NAT，最后发出报文。理解这个顺序能解释一大类「NAT 配了但地址没变」的现象：目的地址在路由表里不可达，或者命中了指向错误接口的路由，NAT 环节根本不会执行到。把路由作为排查的第一步，可以避免在 NAT 配置上反复无效尝试。
基本信息
| 典型顺序 | 路由查找 → 目的 NAT → 源 NAT → 转发出接口 |
|---|---|
| 关键推论 | 路由不可达时 NAT 不执行，报文本就被丢弃 |
| 验证手段 | 会话表查询 + 出入接口抓包对比转换前后 |
| 差异说明 | 厂商实现细节不同，个别设备的 NAT 判定时机有差别 |
| 影响范围 | 多默认路由、策略路由共存时表现更复杂 |
典型使用场景
- 上网异常排查：内网能 ping 通网关但访问不了外网，判断是路由还是 NAT 问题
- 新增发布映射：验证目的 NAT 是否生效，需要先确认目的地址路由可达
- 多出口选路：确认流量实际从哪个接口出去，再判断源 NAT 用的是哪个地址池
- 策略路由与 NAT 叠加场景：策略牵引改变了出接口，源 NAT 随接口变化而改变
- 返回流量不对称问题：确认出向与回向路径是否经过同一台设备
- 地址池规划核对：确认会话表中记录的转换后地址与规划一致
验证步骤
验证步骤
# 1. 查路由表确认目的地址可达，且下一跳与出接口符合预期
# 2. 建立一条测试连接（如 curl 或 telnet 到目标端口）
# 3. 查会话表，读出原始地址与转换后地址
# 4. 在出接口抓包，确认实际发出的源地址与端口
# 5. 核对返回报文是否回到同一台设备与同一会话
# 6. 记录结论：是路由问题、NAT 问题，还是回程路径问题现象与结论对照
| 现象 | 更可能的环节 | 下一步验证 |
|---|---|---|
| 连接超时且会话表无记录 | 路由不可达或策略未放行 | 查路由表与策略命中计数 |
| 会话表有记录但源地址未转换 | 源 NAT 条件未命中 | 核对源 NAT 的匹配条件与应用位置 |
| 会话表正确但出口抓包无包 | 出接口或链路问题 | 查接口状态与下一跳可达性 |
| 有出无回 | 回程路径或上游未放行 | 在入接口抓包确认返回报文 |
多默认路由或策略路由场景下，同一目的地址可能因源地址不同而从不同出口转发，源 NAT 转换后的地址也随之不同，排查时要带上源地址一起看。
会话表是这类问题最直接的证据：一条会话同时记录原始与转换后的地址端口，比逐条核对配置快得多。