RPKI 安全价值

客户看到的是网站打不开、云服务失联或 API 请求失败，不会区分背后是哪条 BGP 路由出了问题。RPKI 帮助网络识别未经授权的路由起源，减少一类本可避免的连接故障，让服务更可靠地到达客户。

先保护客户到达服务的路径

即使服务器运行正常，错误的路由起源也可能把流量引向别处。对运营商和主机服务商来说，路由保护直接关系到客户能否使用已经购买的服务。

地址资源持有者通过 ROA 声明允许的起源 ASN。接收网络再用经过验证的数据核对前缀、ASN 和长度，按配置拒绝 Invalid 路由，减少起源授权冲突对客户流量的影响。

发布 ROA 与执行 ROV，各自带来什么？

发布 ROA，让其他网络有依据识别您的路由；执行 ROV，让自己的网络能够验证收到的路由。两者互相配合，但不会因为开启其中一项，就自动完成另一项。

用文档示例说明：203.0.113.0/24 授权给 AS64496。如果另一个 ASN 发布相同前缀，且覆盖它的验证数据中没有匹配授权，该路由就是 Invalid。是否拒绝，由接收方配置的策略决定。

RPKI 入门指南解释了三种验证状态。技术定义可查阅RFC6811（英文）。

NotFound 表示没有经过验证的授权覆盖该前缀。它与 Invalid 不同，按普通路由策略处理。

把技术投入落到客户体验上

RPKI 如何帮助日常交付

业务任务	做好哪项工作	客户得到什么
启用新地址	先发布正确的起源授权，再发布路由。	执行验证的网络能够识别新路由。
切换上游或 ASN	提前核对实际起源与 ROA。	减少迁移中的意外访问中断。
接收外部路由	识别 Invalid，执行经过验证的拒绝策略。	降低错误起源影响业务访问的机会。
处理连接故障	同时比较起源、前缀长度与授权数据。	让运维团队更快找到可修复的问题。

衡量效果时，关注客户可达性、新前缀上线速度和授权问题处理时间。路由显示 Valid，是一项有用的技术结果；客户服务能否正常使用，还要实际检查。

让不同保护措施各司其职

ROV 检查路由起源。路由泄漏可能保留正确起源，伪造路径也可能带上获授权的 ASN。因此，前缀过滤、出口策略和路径监控需要一起工作。

应用层也有自己的保护：TLS 保护连接，DNSSEC 验证签名的 DNS 数据。把路由、域名和应用连接衔接起来，才能覆盖客户使用服务的完整过程。更多场景见RPKI 与具体网络威胁。

上线保护时，也守住正常客户流量

添加汇总前缀的 ROA 前，先覆盖客户子网及其实际 ASN。迁移起源前，先确认新授权已经在验证器中可见。这样能减少正常路由因授权没有跟上而变成 Invalid。

先观察结果，修复正常业务中的不匹配，再从小范围启用过滤。配置独立缓存，并测试数据过期后的行为。具体步骤见RPKI 部署指南。

看客户真正经过的网络

ROA 覆盖率反映有没有授权数据，ROV 部署反映网络是否使用这些数据做路由决策。两种比例不能互相替代，也不能代表所有客户路径。

向上游了解三种验证状态的处理方式，从外部观察自己的前缀，并检查备用链路和流量清洗路径。这些结果，比没有日期的全球普及率更能帮助下一次业务上线。

路由安全与地址连续性，一起准备

正确授权帮助路由正常工作，证书层级背后的上游关系仍需可靠支撑。多部署几台验证器能提高本地可靠性，却不能代替服务商对地址连续性的责任。

用 Unlimited IPv4 和 LARUS Continuity，与 LARUS 直接规划下一步扩容，让团队专注客户和业务。阅读卢恒对连续性的说明（英文）。

网络团队常问的问题

RPKI 能证明地址所有权吗？

RPKI 提供资源证书和签名的路由授权。Valid 表示路由符合验证后的起源数据，并不是所有权证明。技术授权与持续使用地址的服务关系，需要分别看清楚。

RPKI 能拦截所有劫持吗？

在授权数据和过滤策略都到位的地方，ROV 可以拒绝未经授权的起源。涉及完整路径的攻击还需要其他保护，所以路径监控与故障处理同样重要。

团队现在可以先做什么？

整理客户使用的前缀和 ASN，核对 ROA，并在调整路由接收策略前观察验证结果。先找到差异，部署就有了明确的起点。