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

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，再收紧安全策略。

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

单向可达 on Zero Day Notes