问题现象
分支与总部都用 192.168.1.0/24 时，站点到站点 VPN 建好后会出现一种典型现象：隧道显示已建立、对端能 ping 通，但访问「对端」的 192.168.1.x 地址总是走到本地设备。原因是路由表无法同时表达两个相同的网段，本地接口的直连路由比隧道路由更具体，流量根本不出隧道。
三种解法与成本排序
方案 A 改一端网段：最干净，但要同步改 DHCP 作用域、静态 IP、防火墙地址对象、监控与文档，成本集中且一次性。方案 B 在 VPN 网关上做目标 NAT：把对端网段映射成一个不冲突的本地网段（如把对端 192.168.1.0/24 映射为 10.99.1.0/24），配置量小但会破坏端到端可见性。方案 C 双重 NAT：源地址与目标地址都转换，排障最复杂，只适合临时过渡。
从源头避免
规划期用 10.x 分层编码几乎可以完全避免这类问题：每个站点一个 /16，站点内再按 /24 划分，任何两个站点都不会撞段。对已经上线且无法整体改造的网络，至少要把「谁用了哪些段」盘清楚并纳入文档，新建站点时先查表，避免继续复制默认的 192.168.1.0/24。
基本信息
| 故障表现 | VPN 通、ping 对端设备通，但访问同段地址走本地 |
|---|---|
| 根本原因 | 两端内网网段重叠，路由无法区分目的地 |
| 方案 A | 改一端网段（最干净，需同步 DHCP 与静态配置） |
| 方案 B | VPN 网关做目标 NAT 映射 |
| 方案 C | 双重 NAT（源加目标），过渡期使用 |
典型使用场景
- 两家公司合并后互联，双方都用 192.168.1.0/24
- 家庭办公连公司内网，家用路由器默认段与公司段相同
- 分公司沿用总部模板建网，导致全公司都是同一个 /24
- 云上 VPC 与本地数据中心网段重叠，专线打通后访问异常
- 并购或临时项目组接入，来不及统一编址
冲突判定方法
冲突判定方法
ip route get 192.168.1.1
# 若结果显示经由本地接口而非隧道接口 → 命中了本地直连路由
tracert 192.168.1.1 # Windows：观察是否只有一跳
ping -c 2 192.168.1.1 # 通，但通的可能是本地设备
# 结论：VPN 通不代表对端可达，重叠网段下必须靠改址或 NAT 解决三种方案对比
| 方案 | 改动量 | 副作用 | 适用 |
|---|---|---|---|
| A 改网段 | 大（需同步 DHCP、静态配置、策略） | 几乎无，长期最清晰 | 新建或可停机的场景 |
| B 目标 NAT | 中（改网关策略） | 失去端到端可见性，日志地址不一致 | 不便改址的既有网络 |
| C 双重 NAT | 中偏小 | 排障复杂，部分应用协议不能穿透 | 临时过渡或少量主机 |
做目标 NAT 时要同时处理双向映射：只改一个方向的地址，另一方向回包会被丢弃或走到本地设备，表现为「能发出请求但收不到响应」。映射关系、参与网段与例外地址都应写进文档。
改网段是高风险动作：DHCP 作用域、静态 IP、防火墙地址对象、NAT 规则、监控与 DNS 记录任一处漏改都会造成长时间不可用。变更前先做完整清单，分阶段实施并保留回退方案。