**概述：** 2026年6月16日，印度政府为打击医学入学考试泄题，下令全国封禁Telegram一周。印度运营商Rcom（AS18101）奉命用BGP劫持的方式在境内黑洞Telegram流量，结果路由外泄，半个地球的Telegram用户跟着断联。Telegram以更精确路由反击，Rcom干脆连反击路由一并劫持——这场持续数小时的攻防，把互联网路由安全的老底翻了个底朝天。本文基于Kentik官方博客与APNIC/LACNIC在APRICOT 2026公布的案例研究，复盘事件全貌，讲清BGP为什么骗得动、RPKI这道闸门拦住了什么、没拦住什么，以及一份可以带走的运维整改清单。 ## 目录 - 一、7点17分，印度的封网令“越境”了 - 二、BGP三分钟：互联网导航为什么骗得动 - 三、封网令如何捅破国界：一场数小时的攻防 - 四、第二案：伪造文件骗来的BGP会话 - 五、RPKI这道闸：1.6%背后的分水岭 - 六、运维整改清单：五道防线缺一不可 - 七、结语：互联网的信任模型没有补丁日 ## 一、7点17分，印度的封网令“越境”了 先交代背景。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](https://www.kentik.com/blog/when-local-blocks-go-global-the-india-telegram-bgp-incident/)）的路由监测数据里还原了全过程：2026年6月16日07:17 UTC，AS18101开始在BGP里宣告多个属于Telegram的IP段（例如正常情况下只由Telegram AS62041宣告的91.108.4.0/22），意图把去往这些地址的流量吸过来直接丢弃，也就是业界俗称的“黑洞”。这是各国执行封网令的常见技术动作，本不该有任何国际影响。 问题在于：这些劫持路由漏出了印度国界。 ## 二、BGP三分钟：互联网导航为什么骗得动 给不熟悉承载网的读者补个底。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大概率不想外泄，但它确实泄了”。 用一张图看整个传播链条： ```mermaid flowchart TD A["印度封网令生效
6月16日至22日"] --> B["Rcom AS18101
宣告Telegram前缀"] B --> C["意图黑洞流量
仅限印度境内"] B --> D["配置失当
路由经上游外泄"] D --> E["已部署ROA的网络
拒收Invalid路由"] D --> F["未过滤的网络
接受了假路由"] E --> G["全球仅1.6%
监测源中招"] F --> H["多国用户
Telegram失联"] B --> I["Telegram反击
宣告更精确路由"] I --> J["16:14对方跟进
连更精确一并劫持"] ``` ## 四、第二案：伪造文件骗来的BGP会话 如果说印度案是“政府行为+配置事故”的混合体，那另一起案例展示了纯黑产打法——它更能说明为什么RPKI不是终点。 2026年3月底，在APRICOT 2026/APNIC 61大会的路由安全SIG上，APNIC与LACNIC联合公布了一个案例研究，LACNIC首席技术策略师Carlos Martinez-Cagnazzo随后在APNIC官方博客撰文（[RPKI vs social engineering](https://blog.apnic.net/2026/03/31/rpki-vs-social-engineering-a-case-study-in-route-hijacking/)）。事件发生在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会话。 ```mermaid flowchart TD A["攻击者
伪造文件与仿冒域名"] --> B["冒充印尼小ISP
申请BGP转接"] B --> C["跨国上游供应商
身份核验放水"] C --> D["BGP会话开通"] D --> E["短促宣告伪造起源
20分钟15分钟5分钟"] E --> F["部分网络放行
流量被劫"] E --> G["跨RIR协同排查
确认欺诈切会话"] ``` ## 五、RPKI这道闸：1.6%背后的分水岭 把两次事故放在一起看，RPKI ROV的表现值得单独讲。 ROV的原理不复杂：地址资源持有者在RIR签署ROA，声明“某某前缀只能由某某AS宣告”。全世界的运营商在收到BGP路由时查这条声明—— origins 对不上就判Invalid，拒收。IETF把这套策略固化在[RFC 9582](https://datatracker.ietf.org/doc/rfc9582/)（2024年发布，取代RFC 6811），路径侧的补强ASPA则由[RFC 9584](https://datatracker.ietf.org/doc/rfc9584/)定义，用于验证“这条AS路径上的上游关系是真的”。 Kentik的文章给了我们一条难得的对照时间线，同样是“政府封网导致路由外泄”，RPKI部署前后的结果天差地别： | 年份 | 国家 | 封禁对象 | 外泄后果 | 路由保护状态 | | --- | --- | --- | --- | --- | | 2008 | 巴基斯坦 | YouTube | 全球断看约两小时 | 无 | | 2021 | 缅甸 | Twitter | 区域性中断，事后Twitter补齐ROA | 无 | | 2022 | 俄罗斯 | Twitter | 外泄被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的那道工序。 下次看到“某国封网”的新闻，不妨多想一层：那几条本该死在国界内的路由，现在到哪了？ ## 参考来源 1. [When Local Blocks Go Global: The India-Telegram BGP Incident — Kentik官方博客](https://www.kentik.com/blog/when-local-blocks-go-global-the-india-telegram-bgp-incident/) — 印度Telegram劫持事件的完整路由数据还原，含1.6%监测源数据、AS15412上游分析与历年封网外泄案例对比 2. [RPKI vs social engineering: A case study in route hijacking — APNIC官方博客](https://blog.apnic.net/2026/03/31/rpki-vs-social-engineering-a-case-study-in-route-hijacking/) — LACNIC首席技术策略师撰写的2025年7月社工劫持案例研究，APRICOT 2026/APNIC 61路由安全SIG同款议题 3. [Telegram prefixes hijack by Rcom AS18101 — Anurag Bhatia博客](https://anuragbhatia.com/post/2026/06/telegram-prefix-hijack-by-rcom/) — 印度独立网络工程师的第一时间技术分析，含杜罗夫公开指控原文背景 4. [RFC 9582: BGP Origin AS Validation Policies — IETF](https://datatracker.ietf.org/doc/rfc9582/) — ROV策略的现行标准（取代RFC 6811） 5. [RFC 9584: BGP AS_PATH Verification Based on ASPA — IETF](https://datatracker.ietf.org/doc/rfc9584/) — 防伪造上游关系的ASPA标准 --- > 本文由「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 等场景全覆盖。