在互联网路由安全领域，BGP（边界网关协议）长期面临前缀劫持、路径伪造和路由泄漏等威胁。Cloudflare 推出的 isbgpsafeyet.com 项目通过聚合 RPKI（资源公钥基础设施）与 ASPA（自主系统提供商授权）两类关键安全数据，为全球运营商建立了一套可公开验证的安全状态评分体系。该网站不仅提供实时查询接口，还维护了一个众包性质的大型 AS 安全状态数据库本文将剖析其技术实现细节，包括数据来源聚合方式、状态判定逻辑以及工程部署参数。

项目定位与技术愿景

isbgpsafeyet.com 由 Cloudflare 于近年发起，核心目标是通过推动 RPKI 的大规模部署来提升 BGP 整体安全性。与传统的路由安全监控仪表盘不同，该项目采用了「测试即服务」的思路普通用户只需访问网站即可检测当前 ISP 是否启用了 RPKI 无效前缀过滤，而网络运营商则可以查阅同行业者的安全状态，形成正向激励。

从架构角度看，项目数据分为两层：第一层是静态的 AS 状态列表，存储在 GitHub 仓库的 data/ 目录中，采用半结构化格式记录每个 AS 的 RPKI 部署情况；第二层是实时测试模块，通过 DNS 解析特定前缀并比对返回的路由宣告行为来验证过滤策略有效性。这种「静态库 + 动态探测」的混合模式既保证了数据的可维护性，又提供了现场验证能力。

数据模型与状态字段定义

网站前端展示的每条 AS 记录包含四个核心字段：AS 编号、运营商名称、网络类型（Transit / ISP / Cloud）以及两维安全状态指标。状态的表示方式为组合字符串，例如「signed + filtering safe」表示该 AS 既完成了 RPKI 签名（ROA 发布），又启用了对无效前缀的过滤「partially signed + filtering safe」则表示仅完成部分签名或仅对部分前缀实施了过滤。

状态的第一维度称为 Signing Status（签名状态），分为三种取值：signed 表示该 AS 已将自身的 IP 前缀发布为 ROA 对象，允许下游运营商验证其路由起源有效性；partially signed 表示仅有部分前缀完成签名，通常出现在大型运营商逐步迁移的过程中；unsigned 表示完全未部署 RPKI 起源验证。

第二维度称为 Filtering Status（过滤状态），同样分为 safe、partially safe 和 unsafe 三档。safe 表示该 AS 明确对来自邻居的 RPKI 无效路由进行了丢弃处理；partially safe 表示仅对特定流量或部分邻居执行了过滤；unsafe 则表示未实施任何 RPKI 过滤。这意味着即使某 AS 自身完成了 RPKI 签名，如果它不拒绝来自上游的无效路由，仍然可能被恶意前缀欺骗。

RPKI 与 ASPA 数据的聚合流程

虽然网站前端展示的是「签名 + 过滤」的二元组合，但其背后的数据聚合涉及多个技术层次。RPKI 数据来源相对标准化，全球有五大托管发布点（Trust Anchors）—— 包括 RIPE NCC、ARIN、APNIC、LACNIC 和 AFRINIC，它们各自维护一套 ROA 存储库。isbgpsafeyet.com 的数据采集脚本定期从这些 RPKI 存储库获取最新的 ROA 快照，解析其中的 AS 编号与前缀映射关系，进而判断每个 AS 是否完成了签名。

ASPA 数据的获取则更为复杂。ASPA（Autonomous System Provider Authorization）是 RPKI 的扩展规范，允许一个 AS 声明其合法的上游提供商列表即授权哪些 AS 可以作为自己的 provider。通过验证 BGP 路径中各 AS 是否出现在对应的 ASPA 授权列表中，可以检测出路径劫持和路由泄漏。ASPA 对象的发布目前仍在推广阶段，全球部署率远低于传统 ROA。isbgpsafeyet.com 在数据聚合时将 ASPA 信息作为补充字段，用以识别哪些 AS 同时支持起源验证与路径验证。

在具体实现上，项目维护了一个定时任务（通过 GitHub Actions 自动化执行），从 RIPE NCC 的 RPKI 仓库和 Cloudflare 自身的 bgpdata 采集点拉取最新数据。采集脚本会对原始数据做归一化处理，包括 AS 编号标准化（前缀去除、转换为整数格式）、运营商名称去重、以及状态推断。例如，如果一个 AS 在 RPKI 系统中存在有效 ROA 且其上游运营商均为 RPKI 签名单中的成员，则该项目会将其标记为「signed」。

状态评分算法的工程实现

将多源数据融合为统一的状态标签，需要一套明确的判定规则。项目采用加权评分与阈值决策相结合的算法，大致逻辑如下。

对于 Signing Status，脚本首先查询该 AS 是否在 RPKI 信任锚的 ROA 集合中出现过。如果出现且对应的前缀覆盖率达到 100%（即所有已宣告前缀均在 ROA 中有匹配），则标记为 signed；如果覆盖率介于 1% 与 100% 之间，标记为 partially signed；如果无任何 ROA 匹配，则标记为 unsigned。覆盖率阈值可通过配置文件调整，默认值设定为 80% 作为「显著部署」的门槛。

Filtering Status 的判定则依赖主动测试与社区反馈两条路径。主动测试模块会选取一组已知处于 RPKI 无效状态的测试前缀（例如由项目预先构造的未授权前缀），向目标 AS 的边界路由器发送探测流量并观察是否被丢弃。由于直接测量过滤行为需要控制 BGP 路由器，实践中更多依赖社区贡献的过滤策略报告。项目在 GitHub 上开放了 data 目录的 Pull Request 权限，运营商或第三方可以提交 AS 的过滤状态更新，经维护者审核后合并。

最终的「Safe / Partially Safe / Unsafe」综合评级由二维状态的笛卡尔积映射得到。具体规则如下：只有当 Signing Status 为 signed 且 Filtering Status 为 safe 时，综合评级才为 safe；当任一维度为 partially 时降级为 partially safe；只要存在 unsafe 维度或两个维度均为 partially，则整体标记为 unsafe。这套映射规则被硬编码在 src/status.js 或类似的判定模块中，保持了逻辑的透明性与可审计性。

前端展示与交互设计

网站的视觉层采用纯静态页面构建技术栈为 HTML、CSS 和原生 JavaScript，通过 Webpack 打包后部署到 Cloudflare Workers（Workers Sites 模式）。这种架构的优势是全球边缘节点低延迟响应，且运维成本几乎为零。页面加载时，JavaScript 脚本从同源路径读取预先构建好的 JSON 数据集（即 data/asn.json 或类似文件），在客户端完成排序、搜索和过滤渲染。

交互功能包括：按网络类型筛选（Transit / ISP / Cloud）、按安全状态筛选（Safe / Partially Safe / Unsafe）、以及基于 AS 编号或运营商名称的关键词搜索。搜索结果采用虚拟列表渲染以应对数千条记录的性能压力。对于普通用户，最常用的功能是「测试我的 ISP」按钮点击后会引导用户访问特定的前缀测试页面或展示当前出口 IP 对应的 AS 安全状态。

值得注意的技术细节是网站的 CDN 加速策略。由于数据更新频率不高（通常为每日或每周），项目将静态资源设置为长期缓存（Cache-Control: max-age=86400），而数据文件本身则在每次 CI/CD 构建时重新生成。这种「数据即代码」的思路使得版本管理、审计回滚变得异常简便，任何历史状态都可以通过 Git 提交记录追溯。

数据维护与社区治理

项目采用完全开放的社区治理模式。所有 AS 安全状态数据存储在 GitHub 仓库的 data/ 目录下，文件格式为逐行文本或 JSON 数组。任何人都可以提交 Pull Request 来更新某运营商的状态，但需要提供可验证的证据链，例如 RPKI 验证器的输出截图、BGP 路由表的过滤日志或运营商官方公告。

维护者团队会对提交进行人工审核，重点检查数据的时效性与证据的充分性。对于争议较大的条目（例如运营商声称已部署但第三方检测结果不一致），项目会保留双方的标注并在页面上以红旗图标提示「数据待验证」。这种透明的众包机制在保证数据质量的同时，也避免了单一数据源可能带来的偏见。

项目的 CI/CD 流程由 GitHub Actions 驱动每日定时任务包括：从 RPKI 存储库同步最新 ROA 数据、运行测试用例验证数据格式有效性、触发 Webpack 构建、以及推送到 Cloudflare Workers 边缘节点。整个流水线耗时约三至五分种，确保数据延迟保持在可接受范围内。

工程参数与可部署配置

如果需要自建类似的 BGP 安全状态聚合服务，以下关键参数可作为参考。RPKI 数据同步推荐使用 RIPE NCC 提供的 rpki-cli 工具或 Cloudflare 的 bgp-aggregation 开源库，同步间隔建议设置为六至十二小时以平衡实时性与资源消耗。ASPA 验证规则遵循 IETF draft-ietf-sidrops-aspa-verification 规范，当前草案版本为 24。过滤状态检测可通过 BGP 采集平台（如 bgpstream）构造「毒化路由」并观察上游 AS 是否将其过滤。

状态评分阈值的推荐配置为：ROA 前缀覆盖率高于 80% 视为 signed；过滤策略中对 RPKI 无效路由的丢弃率高于 95% 视为 safe；综合评级采用前述笛卡尔积映射。前端静态资源推荐使用 Cloudflare Workers 部署，缓存策略设置为 Cache-Control: public, max-age=3600, s-maxage=86400，既保证热点数据快速响应，又为数据更新留出缓冲。

总结

isbgpsafeyet.com 通过将 RPKI 起源验证与 ASPA 路径授权数据融合为统一的「Safe / Partially Safe / Unsafe」评分体系，为互联网路由安全提供了可观测、可审计的公开接口。其技术实现兼顾了数据采集的自动化与状态判定的透明性，工程部署充分利用了 Cloudflare 边缘计算的低延迟优势。对于网络运营商而言，该项目既是安全现状的对照表，也是推动 RPKI 部署的催化剂。

参考资料