回程路由 on Zero Day Notes

记一次机房搬迁网络割接后跨机房业务单向可达的排查

Sat, 27 Mar 2021 07:05:00 +0800

问题背景

公司把老园区 IDC（机房 A）里一批业务虚机与存储节点整建制迁到新园区机房 B，割接窗口定在周六凌晨 02:00–05:00。方案表面上很「干净」：业务网段整体搬迁、入口防火墙 DNAT/策略按新地址切换、跨机房链路从原有 MPLS 专线切换到新建的双上联 IPSec + 专线混合出口。搬迁前做过 ping/traceroute 抽样和少量应用冒烟，窗口内业务侧汇报「新机房对外正常、监控基本绿」。

真正的问题在周一早高峰才爆出来——一部分跨机房调用表现为「半通」：机房 A 的应用访问机房 B 新地址能建连，反过来 B 访问 A、或 B 回调 A 的回调地址却超时；运维在 B 机跳板机能 ssh 到 A，A 的同事却感觉「B 回不来」。很多人第一反应是防火墙、安全组或应用端口，结果越查越像「路由和回程没在同一张图上」。

故障现象

方向性矛盾
- A→B：HTTP/HTTPS、数据库、消息队列客户端侧大都能建立 TCP，偶发超时。
- B→A：同端口大量 connect timeout；部分会话能 SYN 出去，却收不到 SYN-ACK。
工具表象分裂
- 在 B 上 ping A 的网关通，ping A 的业务 VIP 有时通有时不通。
- traceroute 在两个方向上路径长度不一致：A→B 走新建专线，B→A 却绕到旧出口或公网边界设备。
业务侧症状
- 双向回调型接口（支付回调、工单状态推送、AD 同步）失败率飙升。
- 单向拉取型任务（A 定时拉 B 报表）看似正常，掩盖了回程问题。
- 监控对「本机存活」全绿，因为探针都是本机房内部路径，跨机房回程不在探针路径上。
变更后漂移
- 割接记录写着「静态路由已切换」，但两台核心三层、边界防火墙、业务侧策略路由（PBR）的生效快照并不一致；部分设备仍保留「迁出前」的下一跳。

排查过程

1. 先定方向，不要一上来改防火墙

先在故障对上做最小对照实验，把「通/不通」钉死为方向问题，而不是端口问题：

# 在 A 业务机
curl -v --connect-timeout 3 http://B_VIP:8080/health
tcptraceroute B_VIP 8080

# 在 B 业务机
curl -v --connect-timeout 3 http://A_VIP:8080/health
tcptraceroute A_VIP 8080

结果非常整齐：A→B 三次握手完成；B→A 停在第一次 SYN 之后，抓包在 A 网卡上根本看不到这个 SYN。说明问题不在应用监听，而在 B→A 的包在中间被送丢/送错路径。

2. 对称抓包，暴露非对称路径

在 A/B 业务机、A/B 机房出口防火墙、跨机房专线两端同时抓同一五元组：

`1`	`src=B_APP dst=A_VIP sport=随机 dport=8080`

时间线对齐后发现：

B 业务机发出 SYN，下一跳走对；
B 出口防火墙会话表有 created；
专线 B 侧有出包，A 侧专线口没有对应入包；
同时在 A 的旧上联/备用出口上，出现了目的为 A_VIP 的怪异入向流量（且被 antispoof/严格 uRPF 或安全策略丢掉）。

也就是说：B 以为自己走新专线去 A，但实际回程/对向某段仍把流量 steers 到旧路径，形成经典的非对称路由（asymmetric routing）；中间任一设备做了状态检测或反向路径校验，就会表现为「单向可达」。

3. 对照三张表：转发表、策略路由、NAT

把割接 checklist 里「已经改完」的对象重新导出对账，而不是只看变更单勾选：

检查项	A 核心	B 核心	A 边界 FW	B 边界 FW
业务网段路由下一跳	仍指向旧互联	新专线	DNAT 已切	正常
回程明细路由	缺失 B 新网段细路由	有	有	有
策略路由（PBR）	旧 match 未删	新 policy 生效	—	源网段 match 半生效
会话残留	无	有旧 SPI/旧隧道	长连接未清	已清

关键发现有三条：

A 侧核心对「B 新业务网段」缺少更优的明细路由，最长匹配落到一条更宽的默认/汇总，下一跳仍是割接前的旧互联地址。
B 侧有一条基于源地址的策略路由：迁移过来的新网段访问「总部/机房 A」应走新专线，但 match ACL 只写了部分子网，漏写了当晚临时扩容的 /26。
边界防火墙上，A→B 的新建连正常；B→A 因路径绕行，包以「非预期入接口」到达 A，被 strict RPF / 接口防欺骗 静默丢弃——所以 A 业务机 tcpdump 空白，特别像「没人来连」。

4. 控制面确认：不是 OSPF 抖动，是静态/PBR 漂移

show ip ospf neighbor / 邻居状态稳定，没有 Flap；问题集中在割接时手工切的静态与 PBR。再查变更窗口的操作记录，发现执行顺序是：

先切业务 DNS / VIP；
再切防火墙 DNAT；
最后才改路由，且 A/B 两侧不是同一人、同一时间点提交；
回退演练只验证了 A→B 主路径，没有强制做 B→A 与回调路径验收。

于是出现了「业务对外看起来活着，跨机房回程悄悄裂开」的窗口。

5. 业务层二次验证

挑三类代表流量复测：

纯正向：A 批处理拉 B API → 基本成功；
纯反向：B 同步任务写 A → 失败；
回调：B 处理完主动 POST A 回调 URL → 失败。

与网络层结论完全同构，排除「个别应用 bug」干扰。

解决方案

止血（分钟级）

在 A 核心补齐 B 新网段明细静态路由，下一跳强制指向新专线对端，metric 优于汇总默认。
修正 B 侧 PBR 的 match ACL，把漏网的 /26 与临时测试网段一次性纳入，确保源网段回总部/ A 时统一走新专线。
边界防火墙：
- 临时将相关接口 RPF 从 strict 调整为 loose（或对专线口加例外），避免好路径未完全收敛时误杀；
- clear session 清掉绕行产生的半开/错向会话。
业务侧：对回调类任务短暂切到「A 主动拉取」降级模式，减少用户可见失败。

按此操作约 10 分钟后，B→A 三次握手恢复，回调成功率回到基线。

根治（当天窗口收口）

路由即代码：把 A/B 核心静态、PBR、防火墙路线用同一份 inventory（网段、下一跳、接口、优先级）生成，禁止两侧各改各的。
割接验收改为「双向五元组矩阵」，至少覆盖：
- A→B 业务端口；
- B→A 业务端口；
- 回调 URL；
- 管理面（跳板机、监控、备份）；
- 大包（ping -M do -s 1400）防止隐式 MTU 问题夹带进来。
严格 RPF 只在收敛完成后加回；窗口内对新建互联口使用可观测的 drop 计数告警，而不是静默丢。
旧互联地址、旧汇总路由设置明确 撤线时间与只读标记，防止「先留着保底」变成长期黑洞入口。
在流量分析/NetFlow 上对「非预期入接口访问本机房 VIP」做基线告警，作为非对称路径的持续探针。

根因分析

根因不是单一命令写错，而是三类问题叠加：

路径规划只画了去程：搬迁方案重点写「业务怎么进新机房」，回程与回调被默认成「对称自愈」，在静态+PBR 环境里不成立。
两侧变更不同步：路由、NAT、DNS、策略路由分属不同执行人，缺少同一时刻的配置快照对账，出现「半切」状态。
验收探针路径不覆盖故障路径：本机房健康检查与 A→B 主路径全绿，恰好照不到 B→A 与错误入接口丢包。再叠加 strict RPF，故障表现从「绕路」升级成「单向黑洞」。

技术本质是：跨机房割接中的控制面（静态/PBR）与数据面期望路径不一致，形成非对称路由；状态防火墙/RPF 把不对称放大成业务单向可达。

预防措施

搬迁网络设计强制输出三张图：去程、回程、管理面；任何网段变更必须三图同时改。
变更单增加「双向连通矩阵」必填项，未测双向不得宣布窗口成功。
PBR/静态路由变更走生成式配置，ACL 网段从 CMDB 自动展开，避免手写漏网段。
窗口内保留可快速回退的对称路径，但回退条目要有 TTL 和自动失效，禁止无限期双路径并存。
监控补齐路径级探测：从 A/B 双侧合成「对向 VIP + 关键端口」拨测，而不是只做本机 process up。
RPF/防欺骗策略与割接 runbook 绑定：割接中 loose、收敛后 strict，并确认 drop 计数进告警。
演练要包含「回调失败」场景：只测浏览器打开首页，测不出这类半通故障。

总结

这次机房搬迁表面上「业务在新机房活了」，实质上卡在回程路由与策略路由未同步，再被严格反向路径校验打成单向黑洞。排障关键不是先改应用，而是：

用双向 curl/tcptraceroute 把问题钉成方向性；
多点对称抓包证明非对称路径；
对账静态路由、PBR match、NAT 与 RPF；
先补明细回程与 ACL，再收紧安全策略。

对有搬迁/割接任务的团队，最大教训就一句话：能通一半往往比全断更危险——因为它能通过错误的验收。 把回程写进设计、把双向写进验收、把生成式配置写进变更，下一次割接才不会在周一早高峰才暴露「半张网」。

记一次跨机房链路变更验收Checklist的落地：连通矩阵、回程路由与MTU三道关

Tue, 15 Dec 2020 07:00:00 +0800

问题背景

机房搬迁、专线扩容、防火墙替换、VPN 重协商这类跨机房链路变更，现场最常见的验收口径是「两边能 ping 通、核心业务打开页面」。看起来很快，晚上却往往出事：A 到 B 正常、B 到 A 超时；小包没事、大文件/数据库同步卡死；白天流量小看不出来，晚高峰回程路径一拥塞就全面抖。

结合近年处置过的非对称路由、PMTUD 黑洞、OSPF 配置漂移、专线抖动等案例，我们把零散经验收成一份跨机房链路变更验收 Checklist，并在一次生产窗口强制落地。目标不是再写一篇事后复盘，而是让值班在变更当晚按清单逐项打勾，把「半通 / 大包不通 / 路径漂移」挡在业务发现之前。

故障现象

变更窗口结束后，监控与值守群一度显示「正常」：

ICMP 通：核心交换机、关键服务器双向 ping 延迟稳定，丢包为 0。
页面通：运维从办公网打开对端工单/监控，HTTPS 能打开。
告警静默：链路 up、BGP/OSPF 邻居 Established、专线 SD-WAN 面板全绿。

约 40 分钟后问题陆续冒头：

单向业务失败：A 机房调用 B 机房内部 API 正常，反向回调/Webhook 超时；部分日志同步只见 half-open。
大包业务卡死：跨机房备份、镜像同步、数据库物理复制进度条长时间不动；ping 小包仍正常。
路径不一致：traceroute 去程走新专线，回程仍钻旧 VPN 或策略路由旁路；NAT/状态防火墙开始出现「只见半连接」。
晚高峰放大：业务量上来后抖动与重传激增，一线又会把锅甩给「应用层超时配置」。

若只以「能 ping」结单，这类故障会伪装成应用问题，排查成本成倍上升。

排查过程

1. 停掉「能 ping 就收工」的习惯

窗口负责人没有直接关单，而是拉出验收清单，按业务矩阵 → 双向路径 → 大包/MTU → 协议与冗余 → 回退点五段复核。同时保留变更前配置快照、路由表导出与流量基线，避免「修着修着不知道改过什么」。

2. 第一道关：连通矩阵（比单点 ping 重要）

列出跨机房真实流量，而不是只测运维跳板机：

源区域	目标区域	代表流量	协议/端口	期望
A 应用区	B 数据库区	业务读写	TCP 业务端口	双向可建连
B 应用区	A API 网关	回调/Webhook	TCP 443/业务口	反向同样要通
A 备份网	B 对象存储/NAS	备份复制	TCP/NFS/专用口	持续大流量稳定
监控区	两端主机	探针/exporter	ICMP+TCP	对称可达
办公运维	两端堡垒/带外	运维通道	SSH/RDP/HTTPS	变更中不中断

执行要求：

每个格子用源侧真实网段主机测，不拿 NAT 后的跳板机冒充应用源
同时测 TCP 端口（nc/Test-NetConnection/curl），不只靠 ICMP
关键 conntrack/会话表，确认是 ESTABLISHED，而不是反复 SYN 重试
任一方「半通」即判验收失败，禁止用「业务侧可绕行」抵赖

本窗口第一轮就扫出 2 条反向路径缺失：B→A 的回调地址仍指向旧 VIP，A 侧安全策略只放行了新专线网段的入向，出向回包被旧策略路由送进黑洞。

3. 第二道关：回程路由与对称性

「去程通、回程不通」是跨机房变更的高频杀手。清单强制做：

双向 traceroute / 路由查表
在源、目的各取 2 个真实主机，对打并记录路径哈希（下一跳序列）。去程与回程若不一致，标记为「非对称」，进入高风险清单。
策略路由 / PBR / 默认路由优先级
核对静态路由、SD-WAN 选路、防火墙 policy-based route 是否与新链路同步；禁止只改一边的下一跳。
状态防火墙与 RPF
对启用 strict uRPF / 会话严格绑定入接口的设备，非对称几乎必然丢回程。能改 loose 的评估影响；不能改的必须把去程回程收敛到同一逻辑路径。
NAT 边界
跨机房若存在源 NAT/目的 NAT，验收时确认两端看到的五元组一致，避免「A 以为连的是 10.x，B 回的是公网映射地址」。

本窗口发现：新专线只在 A 侧注入了更优 metric，B 侧回程仍偏好旧 IPsec。白天流量小时偶发成功（部分流碰巧对称），高峰则大面积超时——典型「验收假绿」。

4. 第三道关：MTU / MSS / 大包

小包通、大文件卡，优先怀疑隧道封装与 PMTUD：

测路径 MTU
ping -M do -s <size>（Linux）或等价大包 DF 探测，从 1500 递减找到两端实际可用 MTU；隧道场景常见有效载荷掉到 1400 附近。
禁止只靠「不分片就缩小包」糊弄
业务 TCP 若 MSS 未钳制，仍会发接近 1500 的包，中间丢 ICMP「需要分片」时即 PMTUD 黑洞。
验收项必须含大包业务
至少跑一轮：iperf/smb 大文件、数据库逻辑同步、对象存储 multipart；持续 3–5 分钟看重传与吞吐是否达到基线 80% 以上。
设备侧检查
隧道口 MTU、TCP MSS adjust、是否错误丢弃 ICMP Type3 Code4、是否对 DF 包粗暴 drop。

本窗口第三关直接复现：ICMP 64 字节完美，1420+ DF 包在防火墙被静默丢弃；备份任务卡在初始化后的大块传输。放通必要 ICMP 差错并在网关做 MSS 钳制后恢复。

5. 协议邻居、冗余与回退演练

在三道关都绿后，补协议与运维动作：

路由协议：邻居稳定时长、LSA/前缀数量对比变更前、是否出现 flap damping
冗余：主断备切、备断主回切各测一次，观察收敛时间与是否双主/黑洞
DNS/VIP/证书：跨机房域名解析与证书 SAN 是否指向新入口
回退点：保留旧链路 admin-down 而非物理拆线，直到观察期结束；回退步骤写成 5 分钟内可执行的命令序
观察期：至少覆盖一个业务高峰 + 一次备份窗，监控丢包、时延、会话失败率、专用链路带宽

6. 清单落地时的分工与门禁

角色	职责
变更执行	按变更单改配置，输出前后 diff
网络值班	跑连通矩阵与 traceroute，填写路径记录
业务代表	对关键交易/同步链路做真实拨测
安全/防火墙	确认策略与会话、ICMP 差错、NAT
变更经理	三道关全部勾选后才允许「初步完成」

门禁规则：任一关未通过 → 不得关闭变更单；可暂时业务放行但必须保持旧链路可秒级回退，并升级为 P1 跟踪。

解决方案

当晚按 Checklist 闭环处理，而不是继续和业务「对现象」：

补齐反向路由与策略：B 侧注入指向新专线的回程明细；回调 VIP 与安全策略源站网段对齐；清理指向已下线地址的残余静态路由。
收敛非对称：短期用策略路由强制关键子网对走同一逻辑隧道；中期把 SD-WAN/动态路由 metric 两端对称发布，取消「只在一端宣告更优」。
修复 MTU 路径：放行路径上 ICMP fragmentation needed；隧道口设置合理 MTU；边界做 tcp adjust-mss；用大包业务回归确认吞吐回基线。
固化验收产出物：每次跨机房变更强制附件三份——连通矩阵结果表、双向 traceroute 文本、大包测试截图/日志；缺一不结单。
观察 48 小时：覆盖一次晚高峰与一次跨机房备份窗，无半通与吞吐塌陷后，再 admin-down 旧链路进入拆除排期。

根因分析

表层是「路由/策略/MTU 各改了一点却没形成闭环」，深层是验收标准错误：

用连通性代替业务性：ping 通 ≠ 业务双向可用，更不等于大包与长连接可用。
用单点代替矩阵：只测运维主机与个别 VIP，漏掉回调、备份、监控等反向与旁路流量。
去程思维：变更单习惯写「怎么把包送过去」，很少写「包怎么原路回来」以及防火墙会话是否对称。
忽视封装开销：专线/IPsec/GRE/VXLAN 叠加后有效 MTU 下降，PMTUD 若被安全策略误伤，故障只在大包时出现，白天小流量验收永远绿。
缺少强制门禁：清单若只是「参考」，窗口压力下仍会被跳过；必须与结单流程绑定。

预防措施

A. 变更前（T-1）

导出两端路由表、策略路由、NAT、隧道 MTU/MSS、邻居状态
画清本次流量矩阵（至少含业务、回调、备份、运维、监控）
明确主路径/回退路径与可接受中断窗口
预置大包测试账号与 iperf/文件源，不靠临时找业务要包

B. 变更中（执行）

配置 diff 双人复核，禁止口播改生产
每完成一段切换就跑矩阵对应格子，不做「全部改完再测」
旧链路保持可回退，直到三道关通过

C. 变更后（验收三道关，缺一不可）

关 1 连通矩阵：双向 TCP/业务端口全绿，无半开连接
关 2 回程对称：双向 traceroute 路径符合设计，无意外旁路
关 3 MTU/大包：DF 大包与真实大流量业务达标
冗余切换与回切演练完成
观察期与监控基线对比通过

D. 制度化

把本 Checklist 嵌入变更管理系统：跨机房/跨专线类别强制模板
季度抽检历史变更附件，缺矩阵/缺 traceroute 记流程缺陷
与「机房搬迁割接」「PMTUD/黑洞」「路由震荡」类事故单做关联培训，新人上岗先跑一遍模拟矩阵

总结

跨机房链路变更最怕的不是完全不通，而是半通、大包不通、高峰才爆。把验收从「ping 一下」升级为 连通矩阵 + 回程对称 + MTU/大包 三道关，并用结单门禁卡住，是成本最低、收益最稳的防坑手段。

本篇作为网络侧方法论/Checklist，和既有的机房搬迁非对称路由、IPSec 大包/PMTUD、OSPF flap 等排查文互补：那些文章回答「出了什么事」，本清单回答「怎样在当晚就证明没出事」。建议团队直接复制表格进变更单模板，按现场拓扑改端口与代表主机，不必等下一次半夜回填再补课。

延伸阅读

IPSec 隧道与 MTU