路由泄露的泄露本质，是原理一个自治系统（AS）把自己从邻居学来的路由，又转发给了另一个邻居，泄露而这条路径本身并不在对方的原理预期之内。听起来绕，泄露但拆开看就一句话：BGP不验证路径真伪，原理只信任你告诉它的泄露东西。

先看一个真实场景。原理2021年4月，泄露某家小型ISP的原理运维在做路由策略调整时，一条prefix-list写错了掩码长度。泄露原本只允许自己客户网段通过的原理规则，突然放行了所有/24路由。泄露结果呢？原理它从上游Tier 1那里学到的谷歌、脸书、泄露Akamai的路由，被它一股脑儿宣告给了另一个上游。短短几分钟，全球大量流量开始往这个只有几十台设备的AS涌。等NOC发现时，洛杉矶和法兰克福的交换中心已经堵成停车场。

这就是典型的“路由泄露”（route leak），和“路由劫持”（hijack）有区别。劫持是冒充别人起源，泄露是路径属性被改坏了，但起源还是对的。问题在于，BGP选路只看AS_PATH长度、LOCAL_PREF、MED这些属性。一旦泄露出去的那条路径比你原来的短，或者LOCAL_PREF更高，流量就拐弯了。

为什么BGP这么容易中招？因为它设计于1989年，那个年代互联网还是一片互信的小圈子。RFC 4271里压根没提“验证”两个字。AS_PATH里的每个AS号，理论上应该是你亲自加进去的，但没人强制检查。一个AS可以随意在宣告前塞入伪造的AS号，也可以把学来的路由不加修改地传给第三方。后者就是泄露的温床。

具体到操作层面，泄露通常发生在三种配置失误里。第一种：对等体策略写反了。比如你和一个客户peer，本该只给他发你自己的路由和客户路由，结果你写成了“发给所有peer”。第二种：社区属性没过滤干净。上游给你打的no-export或no-advertise社区，你在往外发的时候忘了strip掉。第三种：路由反射器（RR）的cluster-id冲突，导致反射路由在客户AS之间乱窜。第三种最隐蔽，因为RR本身不修改AS_PATH，泄露出去的路由看起来完全合法。

我见过一次更离谱的。某园区网运维为了做流量工程，在边界路由器上写了一条route-map，把从ISP-A学来的默认路由重分发进了OSPF，然后OSPF又重分发回BGP，传给了ISP-B。ISP-B一看，你居然给我发默认路由？立刻把你当成上游。结果这个园区网瞬间成了半个省的中转站，出口带宽跑满，用户连内网都卡。事后查配置，route-map里只有一个permit，没有deny，等于放行一切。

防泄露的手段其实不复杂，但需要纪律。前缀列表、AS_PATH过滤器、最大前缀数限制，这三样是基本功。RPKI能解决起源验证，但对路径泄露基本没用——因为泄露的路由起源是对的。真正有用的是BGPsec，可惜部署率到今天还不到1%。所以现实里，大部分网络还是靠“手动挡”：在边界上写死只发客户路由，对等体之间用社区打标签，RR上配好cluster-id和originator-id检查。

说到底，路由泄露不是协议漏洞，是配置漏洞。BGP把信任完全交给了运维人员，而人总会犯错。一个掩码写错、一个社区忘删、一个route-map少写deny，就能让半个互联网绕路。你问我怎么防？先把你边界路由器的出方向策略打印出来，逐条读一遍。我打赌，至少有一条permit any。

(责任编辑：知识)