一次“一刀切”VPN 封禁引发的渠道回调全挂事故

事故复盘：一次“一刀切”VPN 封禁引发的渠道回调全挂事故

1. 事故背景

为了提升内部系统安全性，公司近期对后台管理系统进行了安全加固。起因是一个后台业务系统被非法访问了，导致了资金损失（x USD）。老板对此高度重视，要求所有后台系统必须立即物理隔离，强制接入 VPN，禁止公网直接访问。

由于时间紧迫，技术团队在接到指令后，迅速对包含“教育后台”在内的多个管理系统实施了全量 VPN 切换。

2. 故障现象

切换 VPN 两天后，业务端开始出现异常反馈：

• 客服反映： 客服反映在支付成功后，个人中心的订单状态长时间显示“未支付”。
• 监控缺失： 负责同步业务动态的企微机器人，连续两天没有推送过“订单付款成功”的通知。

3. 原因分析

经过紧急排查，发现问题根源在于网络策略的“一刀切”导致了公网回调链路断裂。

我们的教育后台系统不仅承载了管理员操作的 UI 界面，同时还作为异步回调的接收端，部署了微信、支付宝、连连支付等渠道的 Callback 接口。

1. 链路闭环失败： 用户支付成功后，支付渠道（微信/支付宝等）服务器会从公网发起一个 POST 请求到我们的后台接口，通知支付结果。
2. 防火墙拦截： 实施 VPN 强制访问后，后台系统只允许来自 VPN 内网 IP 的流量。支付渠道服务器拥有的是公网 IP，且不可能接入我们的企业 VPN。
3. 结果： 所有的支付回调请求全部被防火墙拦截。虽然用户钱付了，渠道也结算了，但我们系统因为收不到通知，始终认为订单处于“待支付”状态。

4. 暴露出的问题

• 依赖链路梳理不清晰： 在执行网络变更前，未能识别出后台系统同时具备“内网管理”与“公网接收”的双重属性。
• 安全与业务的权衡失调： 面对老板的压力，盲目追求绝对安全，忽略了资金核心链路的可用性。
• 监控存在盲区： 系统只监控了前端下单的成功率，却缺少对“预期回调到达率”的监控，导致问题延迟两天通过人工反馈才发现。

5. 整改与架构优化

针对此次事故，我们不仅修复了网络配置，还对系统架构进行了彻底拆分和标准化治理：

5.1 动静分离与架构拆分

我们将原有的耦合系统拆分为两个独立逻辑区域（仅整理，但并未做调整）：

• 后台管理端（Internal）： 仅限管理员使用，通过 VPN 严格管控。
• 渠道网关端（Public）： 专门用于接收公网回调。该模块独立部署公网 IP，但仅开放特定的 Callback 接口。

5.2 安全策略升级

对于必须暴露在公网的回调接口，不再依赖 IP 封禁，而是采用更细粒度的防护手段：

• 严格验签： 强制校验渠道商的数字签名，确保请求来源合法。
• 接口限流： 针对回调接口设置频率限制，防止恶意刷接口或 DDoS 攻击。
• 白名单机制： 收集微信、支付宝等官方公布的服务器 IP 段，配置防火墙白名单，只允许这些范围内的 IP 访问。

5.3 兜底机制：T+1 对账

为了防止类似的网络抖动或策略变更再次影响资金业务，我们强化了 T+1 自动对账系统。即使回调因意外再次中断，系统也会在次日凌晨自动拉取渠道账单进行比对，补全漏掉的订单状态，确保资金与业务状态最终一致。

6. 总结教训

这次事故给了我们一个深刻的警示：任何涉及底层网络、权限、部署方式的变更，都必须进行全链路的流量复盘。

我们需要明确界定系统的内外网边界：

• 纯内部系统： 坚决走 VPN，关门作业。
• 对公/对 C 端系统： 保持公网开放，但必须建立起以“验签+限流+白名单”为核心的动态安全防线。

安全不应该是业务的阻碍，而是在理清调用关系后的精准防护。