谷歌和其他一些服务中断了74分钟。这不是第一次发生这种情况 ; 尽管可能存在假设坏演员在工作的诱惑,但这样的事件只能证明数据包如何从互联网上的一个点传到另一个点有多少脆弱性。

我们的日志显示,星期一21:12 UTC,一名尼日利亚互联网服务提供商MainOne意外错误配置了部分网络导致“路由泄露”。这导致Google和许多其他网络通过不寻常的网络路径进行路由。像这样的事件实际上经常发生,但在这种情况下,谷歌用户产生的流量非常大,以至于他们压倒了中间网络 - 导致许多服务(但主要是谷歌)无法访问。

您可能会惊讶地发现,世界某个地方的ISP出现错误可能导致Google和其他服务脱机。这篇博客文章解释了如何发生这种情况以及互联网社区正在做些什么来试图解决这种脆弱性。

什么是路线泄漏,以及如何发生?
当流量路由到常规和最佳路由路径之外时,这称为“路由泄漏”。解释它们如何发生需要更多的背景。

Internet上的每个网络和网络提供商都有自己的自治系统(AS)号码。此编号是唯一的,表示该组织控制的Internet部分。值得注意的是,以下解释谷歌的主要AS号码是15169.这是谷歌的互联网角落,谷歌流量应该以最快的速度结束。

尼日利亚互联网服务提供商如何意外地击败谷歌离线-IDC帮帮忙

关于Google / AS15169路由如何传播到第1层网络的典型视图。
如上所述,Google直接连接到大多数第1层网络(最大的网络链接大型互联网)。当一切正常运行时,谷歌的AS路径,路由数据包从网络到网络到达目的地,实际上非常简单。例如,在上图中,如果您是Cogent的客户并且您试图访问Google,那么您将看到的AS路径为“174 6453 15169”。这一串数字就像一系列航路点:从AS 174(Cogent)开始,转到Tata(AS 6453),然后转到Google(AS 15169)。因此,Cogent的订户通过Tata,一个巨大的一级提供商来到谷歌。

在事件发生期间,MainOne错误配置了他们的路由,如AS路径所示:“20485 4809 37282 15169”。由于这种错误配置,MainOne对等(即直接连接)的任何网络都可能通过这条错误路径泄露其路由。例如,上面段落中的Cogent客户(AS 174)不会像他们应该的那样通过Tata(AS 6453)。相反,他们首先通过TransTelecom(俄罗斯运营商,AS 20485),然后到中国电信CN2(跨境中国运营商,AS 4809),然后到MainOne(尼日利亚互联网配置错误配置,AS 37282),以及直到那时他们才最终被交给谷歌(AS 15169)。换句话说,伦敦的用户可以将他们的流量从俄罗斯流向中国到尼日利亚 - 然后才进入谷歌。

但是......为什么影响那么多人呢?
造成这种情况的根本原因是MainOne错误配置了它们的路由。如前所述,像这样的事件实际上经常发生。这种错误配置的影响应该仅限于MainOne及其客户。

然而,相对孤立并将其转变为更广泛的内容是因为CN2--中国电信的优质跨境运营商 - 并没有过滤MainOne提供给他们的路由。换句话说,MainOne告诉CN2它有权传递谷歌的IP地址。大多数网络验证这一点,如果不正确,请将其过滤掉。CN2没有 - 它只是信任MainOne。因此,MainOne的错误配置传播到一个更大的网络。更复杂的是,俄罗斯网络TransTelecom很可能表现得与CN2类似,因为CN2对MainOne表现得很好 - 他们信任而没有对CN2给他们的路由路径进行任何验证。

这表明构成Internet的底层连接涉及多少信任。它是一个网络网络(互联网!),通过不同实体(国家和公司)之间的合作来运作。

这就是尼日利亚的路由错误然后通过中国然后通过俄罗斯传播的方式。考虑到所涉及的流量,网络不堪重负,谷歌无法访问。

值得明确指出的是:谷歌的流量在前往尼日利亚之前通过俄罗斯和中国,然后才到达正确的目的地,这使得某些人认为错误配置是邪恶的。我们不相信这种情况。相反,此事件反映了一个错误,该错误未被适当的网络过滤捕获。在许多网络中存在过多的信任和不充分的验证:这是一个系统性问题,使互联网更容易受到错误的影响。

如何减轻像这样的路径泄漏
随着Cloudflare的内部系统,BGPMon.net和ThousandEyes发现了这一事件。BGPMon有几种检测异常的方法; 在这种情况下,他们能够发现到达谷歌的路径中的提供商是不规则的。

Cloudflare的系统立即检测到这一点,并采取了自动补救措施。