概述： 2026年6月16日，印度政府为打击医学入学考试泄题，下令全国封禁Telegram一周。印度运营商Rcom（AS18101）奉命用BGP劫持的方式在境内黑洞Telegram流量，结果路由外泄，半个地球的Telegram用户跟着断联。Telegram以更精确路由反击，Rcom干脆连反击路由一并劫持——这场持续数小时的攻防，把互联网路由安全的老底翻了个底朝天。本文基于Kentik官方博客与APNIC/LACNIC在APRICOT 2026公布的案例研究，复盘事件全貌，讲清BGP为什么骗得动、RPKI这道闸门拦住了什么、没拦住什么，以及一份可以带走的运维整改清单。
先交代背景。2026年6月16日，印度政府依据《IT法》第69A条下令全国封禁Telegram，期限到6月22日。起因是印度国家测试机构（NTA）的报告：即将重考的NEET医学本科入学考试出现有组织的泄题舞弊，Telegram上活跃着名为"PAPER LEAKED NEET"、"Private Mafia"的频道，公然向考生和家长兜售所谓“真题”。政府还顺手要求Telegram在6月30日前关闭消息编辑功能，理由是该功能被用来事后伪造泄题证据。
Telegram CEO帕维尔·杜罗夫（Pavel Durov）随即公开抗议，称这一周长禁令是对超过1.5亿印度用户的“连坐惩罚”。但他抛出的另一个指控才是本文主角：他公开点名印度电信运营商Reliance，称其正在用一种叫"BGP劫持"的流氓手段，破坏印度境外（包括阿联酋）数百万用户对Telegram的访问。
注意，被点名的是Rcom（AS18101），前身Reliance Communications，不是如日中天的Jio——这两家虽都姓“安巴尼”，但分属两兄弟的不同商业集团，别搞混。
Kentik在其官方博客（When Local Blocks Go Global）的路由监测数据里还原了全过程：2026年6月16日07:17 UTC，AS18101开始在BGP里宣告多个属于Telegram的IP段（例如正常情况下只由Telegram AS62041宣告的91.108.4.0/22），意图把去往这些地址的流量吸过来直接丢弃，也就是业界俗称的“黑洞”。这是各国执行封网令的常见技术动作，本不该有任何国际影响。
问题在于：这些劫持路由漏出了印度国界。
给不熟悉承载网的读者补个底。BGP（边界网关协议）是互联网自治系统（AS）之间的导航协议。每个AS向邻居宣告“我拥有某某IP前缀，把发往它的流量交给我”，宣告沿着邻居一路扩散，全网就形成了一张路由表。这套体系1989年设计时有一个致命假设：所有参与者都说真话。
没有任何内建机制验证“你真的有权宣告这个前缀”。一台路由器收到一条前缀宣告，它只能检查“格式对不对、路径里有没有环”，至于宣告者是不是这个地址段的真正主人，协议本身不知道。所以只要一个AS发起一条伪造宣告，且它的上游不过滤，这条假路由就会像谣言一样传遍全球。
劫持的杀伤力取决于“骗到多少人”。BGP选路规则里，更长的前缀（更精确的路由）优先级更高，因此一次典型的攻防是：受害者宣告更精确的路由夺回流量，攻击者再宣告更更精确的路由……循环下去，直到有人在配置层面认输。
这个脆弱性不是新话题。Kentik的文章把这次事件归入一个特殊类别："intentional, but also accidental"（有意为之，却又意外外泄）——政府下令封网，运营商用BGP实现封禁，本意只在本国生效，结果配置失当，劫持路由冲出国门。这个剧本的祖师爷是2008年巴基斯坦电信劫持YouTube：为执行国内封禁而宣告YouTube的/24路由，忘了做出口过滤，结果全球用户两小时刷不开YouTube。
Kentik的监测数据把6月16日这一天切成了几幕：
| 时间（UTC，2026-06-16） | 事件 |
|---|---|
| 07:17 | AS18101开始宣告Telegram地址段（如91.108.4.0/22），意图黑洞流量 |
| 随后数小时 | 劫持路由外泄至国际路由表，多个国家的Telegram用户连接失败 |
| 当日上午 | Telegram开始宣告更精确路由反击，夺回地址空间 |
| 16:14 | AS18101连这些更精确路由一并劫持，流量再度被吸往印度并丢弃 |
| 当日稍晚 | 劫持路由被撤回，事件平息 |
| 06-22 | 封禁令到期，印度境内恢复访问 |
有两个细节值得运维同学咂摸。
细节一：Telegram的反击是教科书式的。 发现自己前缀被劫后，Telegram立刻宣告更精确路由——这是BGP选路规则下的标准自救。但对方的回应是跟踪劫持：你在16:14前夺回，我16:14连你的/24甚至更长前缀一起劫。这说明对方不是配置手滑，而是有人在实时盯路由表。Kentik的原话更直白：AS18101连更精确路由也劫，"intentionality pretty clear"——故意得不能再故意了。
细节二：为什么破坏面没有失控？ Kentik全球路由监测源里只有1.6%看到了这条劫持路由。原因在于Telegram在所有前缀上都部署了ROA（路由起源授权），绝大多数国际运营商执行RPKI ROV校验、拒收“Invalid”路由，假路由在半路就被扔了。Kentik还点了名：Rcom唯一的上游AS15412，以及印度的AS9498、AS4755（Bharti Airtel系），如果这几家拒绝RPKI-invalid路由，这次事故会被完整封锁在印度境内。
技术上的肇事点大概率是封禁配置本身。标准做法是把黑洞路由打上NO_EXPORT团体属性（配合公认的黑洞社区65535:65281），让劫持路由“只传本国、不出邻居”。这次外泄说明这一步没做——这是配置纪律问题，属合理推断，Kentik原文只说“AS18101大概率不想外泄，但它确实泄了”。
用一张图看整个传播链条：
flowchart TD
A["印度封网令生效<br/>6月16日至22日"] --> B["Rcom AS18101<br/>宣告Telegram前缀"]
B --> C["意图黑洞流量<br/>仅限印度境内"]
B --> D["配置失当<br/>路由经上游外泄"]
D --> E["已部署ROA的网络<br/>拒收Invalid路由"]
D --> F["未过滤的网络<br/>接受了假路由"]
E --> G["全球仅1.6%<br/>监测源中招"]
F --> H["多国用户<br/>Telegram失联"]
B --> I["Telegram反击<br/>宣告更精确路由"]
I --> J["16:14对方跟进<br/>连更精确一并劫持"]
如果说印度案是“政府行为+配置事故”的混合体，那另一起案例展示了纯黑产打法——它更能说明为什么RPKI不是终点。
2026年3月底，在APRICOT 2026/APNIC 61大会的路由安全SIG上，APNIC与LACNIC联合公布了一个案例研究，LACNIC首席技术策略师Carlos Martinez-Cagnazzo随后在APNIC官方博客撰文（RPKI vs social engineering）。事件发生在2025年7月，三次短促劫持：
| 时间（UTC-3，2025年7月） | 时长 |
|---|---|
| 09日19:47 | 约20分钟 |
| 10日20:34 | 约15分钟 |
| 12日10:13 | 约5分钟 |
事情的发现颇具戏剧性：一个用户报告邮件发不出去——服务器显示发送成功，对方却永远收不到。排查发现，LACNIC的一部分地址段正被毫无授权的网络宣告。攻击者刻意伪造起源ASN，让假路由不落入“Invalid”状态，从而绕过ROV校验的雷达。
往上游追查，真相更冷：攻击者用伪造的公司文件和一个与真实机构高度相似的仿冒域名，冒充印尼一家小ISP（其ASN由APJII/IDNIC注册管理），成功说服一家跨国上游供应商开通了BGP转接。拿到会话后，他从这个被劫持的ASN背后，用多个伪造起源ASN发起短促宣告——打几分钟就撤，随机时间，随机目标，像在试探水面。这家小ISP本身也是受害者，事后APNIC方面还在会上专门向其致歉。调查显示该ASN在AFRINIC、ARIN、LACNIC、APNIC各区都有类似前科，是惯犯踩点。
这个案例的教训写得很清楚（原文）：攻击者没有攻破RPKI，他攻破的是上游开通流程。 跨国供应商在给陌生客户开BGP会话前，没有核实公司身份、没有验证域名归属，一份伪造的LOA（授权书）就放行了。同时，受害方ROA里过宽的MaxLength设置，让大量更具体前缀也能通过校验，放大了事故规模。LACNIC、APNIC、APJII/IDNIC三家注册机构的跨国协同最终确认了欺诈、锁定了被利用的上游，供应商随后切断BGP会话。
flowchart TD
A["攻击者<br/>伪造文件与仿冒域名"] --> B["冒充印尼小ISP<br/>申请BGP转接"]
B --> C["跨国上游供应商<br/>身份核验放水"]
C --> D["BGP会话开通"]
D --> E["短促宣告伪造起源<br/>20分钟15分钟5分钟"]
E --> F["部分网络放行<br/>流量被劫"]
E --> G["跨RIR协同排查<br/>确认欺诈切会话"]
把两次事故放在一起看，RPKI ROV的表现值得单独讲。
ROV的原理不复杂：地址资源持有者在RIR签署ROA，声明“某某前缀只能由某某AS宣告”。全世界的运营商在收到BGP路由时查这条声明—— origins 对不上就判Invalid，拒收。IETF把这套策略固化在RFC 9582（2024年发布，取代RFC 6811），路径侧的补强ASPA则由RFC 9584定义，用于验证“这条AS路径上的上游关系是真的”。
Kentik的文章给了我们一条难得的对照时间线，同样是“政府封网导致路由外泄”，RPKI部署前后的结果天差地别：
| 年份 | 国家 | 封禁对象 | 外泄后果 | 路由保护状态 |
|---|---|---|---|---|
| 2008 | 巴基斯坦 | YouTube | 全球断看约两小时 | 无 |
| 2021 | 缅甸 | 区域性中断，事后Twitter补齐ROA | 无 | |
| 2022 | 俄罗斯 | 外泄被ROA挡住，影响极小 | 是 | |
| 2023 | 伊拉克 | Telegram | 影响极小 | 疑似路由过滤生效 |
| 2024 | 巴西 | X | 外泄几乎无人察觉 | 是 |
| 2026 | 印度 | Telegram | 多国用户中断，1.6%监测源中招 | 部分（多数国际骨干过滤，仍有漏网） |
三句话总结这张表：
第一，ROA确实把“外泄”从全球事故降级成了区域噪音。 2021年缅甸事件后Twitter火速部署ROA，一年后俄罗斯几乎复制粘贴的同款事件就没打出水花。Kentik引述Twitter时任CISO的话说得妙：“搞安全的很多意义，就在于让你的系统别三天两头坏一次。”
第二，ROV的效果取决于“别人”过不过滤，不由你自己决定。 印度案里Telegram的ROA一个不少，但因为不是所有路径都拒收Invalid，仍有1.6%的监测点被污染。路由安全是公地悲剧，每一个不过滤的AS都是别人事故的放大器。
第三，ROV防不住两件事：更精确的合法起源劫持，和绕开ROV的社工。 印度案里对方劫的是更精确路由，MaxLength内照样“Valid”；七月案里攻击者干脆伪造起源ASN避开Invalid状态，再从伪造的上游关系把流量带走。这正是ASPA（防伪造上游）和上游开通身份核验要补的两块板。
综合两份权威分析，给维护IP承载网/互联网出口的同学整理一份可落地的清单：
1. 源头：ROA纪律。 给自有全部前缀签ROA是及格线；重点是MaxLength设置——按实际需要的最长前缀填，别图省事拉满。过宽的MaxLength等于给劫持者留了“更精确路由合法化”的后门。ROA要随地址规划定期复审，段回收了ROA也要回收。
2. 边界：出口过滤与黑洞规范。 任何基于BGP的封禁动作，必须配NO_EXPORT/NO_ADVERTISE等策略限定传播范围；黑洞路由用标准社区属性并在AS边界终止。这条写进割接模板和封禁SOP，别靠工程师现场发挥。
3. 入口：拒收Invalid。 在所有对等和上游会话上开启ROV并拒收Invalid，包括 transit 和 IXP 方向。你的过滤不只是保护自己，也决定着别人的劫持会不会经你扩散——印度案里那几个“如果当时过滤”的AS就是镜子。
4. 商务：上游开通即安全边界。 给客户开BGP会话前核验RIR/IRR记录、回拨注册联系人电话、警惕仿冒域名（注册时间新、与真实机构形似）、慎信LOA。ASPA具备支持后尽快部署，从路径上杜绝“伪造上游”。
5. 监测：别等用户报警。 接入RIPE NCC RIS、Cloudflare Radar、RouteViews一类的路由监测源，对自有前缀的异常起源设告警。七月案里“邮件发得出去但对方收不到”这种幽灵故障，靠的正是监测平台揪出伪起源。跨RIR/跨运营商的协同处置通道平时要建好，事件时的响应速度全靠它。
标准允许多种实现方式，具体校验策略与设备配置形态以各厂家官方文档为准；但上面五条里，前三条是纯策略问题，不依赖任何新设备。
复盘完这两起事件，最值得记住的不是任何一条命令，而是一个认知：互联网的导航系统至今仍建立在“互信”之上，所有安全机制都是在给这个1989年的假设打补丁。
印度案告诉我们，一个国家的一次封网行政令，技术上如何可能变成半个地球的通信事故——哪怕全球大部分骨干网都已经学会了拒收假路由。七月案则告诉我们，密码学补丁再严密，攻击者永远会找链条上最“人”的那一环：一份伪造文件、一个形似域名、一个没有回拨确认的开通流程。
对运营商来说，BGP劫持的攻防没有终局，只有水位。ROV普及率在涨，攻击就转向更精确路由和社工；ASPA开始铺开，攻击就转向开通流程。运维团队能做的，是把自己的每一块板补齐：前缀签ROA、MaxLength收紧、出口配过滤、入口拒Invalid、开通做核验、监测设告警。这六件事没有一件是新技术，但2008年巴基斯坦干的那件蠢事，2026年还在原样重演——说明行业缺的从来不是知识，是把知识焊进SOP的那道工序。
下次看到“某国封网”的新闻，不妨多想一层：那几条本该死在国界内的路由，现在到哪了？
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。