4、劫持检测原理：基于控制平面检测、基于数据平面检测、基于RPKI的检测

说实话，BGP劫持这事儿，最让人头疼的不是它有多复杂，而是你往往后知后觉。等用户投诉说“网站打不开”或者“流量去哪儿了”，可能已经过去好几个小时了。所以，怎么尽早发现劫持，就成了我们运维的必修课。

我个人习惯把检测方法分成三类：控制平面、数据平面，还有RPKI。这三者各有侧重，也各有短板。咱们一个一个聊。

4.1 基于控制平面的检测

控制平面检测，说白了就是盯着路由表看。你想想看，BGP的本质就是交换路由信息。如果有人在控制平面上搞鬼，那路由表里一定会留下痕迹。

核心思路： 对比你收到的路由更新，跟“预期”的路由是否一致。

我在项目中遇到过最典型的场景：某天我们的监控系统突然报警，说一条重要的/24前缀，AS Path里多了一个不认识的AS号。我第一反应就是——有人在搞事情。

常用的检测手段有这些：

• 前缀劫持检测： 检查某个前缀是否被多个AS同时宣告。正常情况下，一个前缀应该只属于一个AS（或者其客户）。如果出现两个不同的AS都在宣告同一个前缀，那大概率是劫持。
• AS Path异常检测： 对比历史数据，看AS Path的长度、AS号序列是否突然变化。比如，一个原本只有3跳的路由，突然变成了10跳，或者出现了你从未见过的AS号，这就要警惕了。
• MOAS（Multiple Origin AS）检测： 这是最直接的。如果一个前缀在路由表中出现了多个不同的Origin AS，那几乎可以断定是劫持。

嗯，这里要注意一点：控制平面检测只能告诉你“可能有问题”，但不能100%确认。因为有些合法的多归属场景，也会导致MOAS。所以，我们通常需要结合数据平面的检测来交叉验证。

4.2 基于数据平面的检测

数据平面检测，就是看流量到底去了哪里。控制平面说“路由是好的”，但数据平面可能已经“跑偏”了。你想想看，劫持的最终目的，不就是为了截获流量吗？

核心思路： 从多个观测点，主动探测目标前缀的连通性和路径。

我记得有一次，控制平面显示一切正常，但用户反馈延迟特别高。我用了几个分布在全球的探测节点，traceroute了一下目标IP，结果发现流量绕了一个大圈，最后到了一个完全不对的AS。这就是典型的数据平面劫持。

常用的方法：

• 主动探测： 使用traceroute、ping等工具，从不同地理位置探测目标前缀。对比探测结果，看路径是否一致。如果某个节点的路径明显异常，那就有问题。
• 被动监听： 在关键节点部署流量分析设备，实时监控流量的去向。比如，你发现原本应该发往某数据中心的流量，突然全部转向了另一个IP，那基本可以断定是劫持。
• BGP Stream等实时数据源： 利用公开的BGP数据（如RouteViews、RIPE RIS），结合数据平面探测，可以更全面地判断劫持范围。

数据平面检测的优点是“眼见为实”，但缺点也很明显——它需要你有分布式的探测能力，而且只能发现“正在发生”的劫持，对历史劫持无能为力。

4.3 基于RPKI的检测

RPKI（Resource Public Key Infrastructure）是近年来最受关注的解决方案。它从根源上解决了“谁有权宣告某个前缀”的问题。

核心思路： 通过密码学验证，确保只有合法的AS才能宣告对应的前缀。

RPKI的工作原理其实不复杂：

1. IP地址分配机构（如APNIC、RIPE）会签发一个数字证书，证明某个AS有权宣告某个前缀。
2. 这个证书会生成一个ROA（Route Origin Authorization）对象，里面包含了前缀、AS号、最大前缀长度等信息。
3. 当路由器收到BGP更新时，可以查询RPKI数据库，验证这个路由的Origin AS是否与ROA匹配。

如果匹配，就是Valid；如果不匹配，就是Invalid；如果查不到ROA，就是NotFound。

我曾经在一个项目中，帮客户部署了RPKI。部署之前，他们每个月都会遇到几次劫持告警。部署之后，虽然不能完全杜绝，但至少那些“粗放型”的劫持（比如随便宣告一个不属于自己的前缀）直接被挡在了门外。

下面这张图，展示了RPKI在BGP路由验证中的位置：

三种检测方法各有优劣，我整理了一个表格，方便你对比：

检测方法	检测对象	优点	缺点
控制平面	路由表、AS Path	实时性强，数据易获取	依赖历史基线，误报率高
数据平面	实际流量路径	结果准确，能确认劫持	需要分布式探测，成本高
RPKI	Origin AS 合法性	密码学验证，不可抵赖	部署复杂，无法防路径劫持

好了，关于劫持检测的原理，咱们就聊到这儿。记住，检测只是第一步，发现劫持之后怎么快速响应，那才是真正的考验。