原文地址：https://blog.cloudflare.com/how-a-nigerian-isp-knocked-google-offline/
原文标题：How a Nigerian ISP Accidentally Knocked Google Offline
原文作者：Tom Paseka
原文写于：2018/11/16 GMT+8 上午1:22:35
译者：驱蚊器喵#ΦωΦ
翻译水平有限，有不通顺的语句，请见谅。
上周一的晚上 - 2018年11月12日 - 谷歌和一些其他的网络服务中断(outage)了74分钟。这不是第一次发生这种情况; 尽管可能存在员工在工作时搞鬼的假设，但这样的事件只能说明，数据包从互联网上的一个点到另一个点的传输有多么脆弱。
我们的日志显示，在星期一，UTC 时间的 21:12，MainOne，一个尼日利亚互联网服务提供商，意外的错误配置了他们的部分网络导致了“路由泄露(route leak)”。这导致了 Google 和其他的许多网络通过不寻常的网络路径进行路由。像这样的事件实际上经常发生，但在这种情况下，谷歌用户产生的流量非常大，以至于他们压倒了中间网络 - 导致许多服务（但主要是谷歌）无法访问。
您可能会惊讶地发现，世界某个地方的 ISP 出现错误可能会导致 Google 和其他服务离线。这篇博客文章解释了这种情况是如何发生的，以及互联网社区正在做些什么来试图解决这种脆弱性。
路由泄漏(Route Leak)是什么, 以及它是如何发生的?
当流量被路由到常规和最佳路由路径之外时，这称为“路由泄漏(route leak)”。我们需要讲解一些更多的背景知识来解释它们如何发生的。
Internet 上的每个网络和网络提供商都有自己的自治系统（Autonomous System,AS）号码。此编号是唯一的，表示该组织管理的 Internet 部分。需要提及一下，谷歌的主要 AS 号码是 15169。这是谷歌在互联网的部分，谷歌的流量应该从最快的路由路径结束。
关于 Google/AS15169 路由如何传播到第1层 (Tier-1) 网络的典型视图
如上图所示，Google与大多数的第1层网络（最大的网络链接大型互联网）直接相连。当一切正常运行时，谷歌的AS路径，路由数据包从网络到网络内流转，最终到达目的地，实际上非常简单。例如，在上图中，如果您是 Cogent 的客户，当您试图访问 Google 时，您将看到的AS路径为“174 6453 15169”。这一串数字就像一系列路标(waypoints)：从 AS 174（Cogent）开始，转到 Tata（AS 6453），然后到 Google（AS 15169）。因此，Cogent 的客户通过 Tata，一个庞大的一级提供商来到谷歌。
在事故的发生期间，MainOne 错误配置了他们的路由为 AS 路径所示的：“20485 4809 37282 15169”。由于这种错误配置，MainOne 对等(peered)（即直接连接）的任何网络都可能通过这条错误路径泄露路由。例如，上面段落中的 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，因此没有对 CN2 给他们的路由路径进行任何验证。
这表明构成 Internet 的底层涉及到了多少信任连接。这是一个由很多网络组成的巨大网络（即互联网！），通过不同实体（国家和公司）之间的合作来工作。
这就是尼日利亚的路由错误然后通过中国然后通过俄罗斯传播的方式。考虑到所涉及的流量，网络不堪重负，谷歌无法访问。
值得明确指出的是：谷歌的流量在前往尼日利亚之前途径俄罗斯和中国，然后才到达正确的目的地，这使得某些人认为错误配置是罪魁祸首(nefarious)的。而我们不这么认为。相反，此事件反映了一个重大错误，就是错误的配置没有被适当的网络过滤捕获。在许多网络中存在过多的信任和不充分的验证：这是一个系统性问题，使互联网容易受到错误的影响，更容易受到攻击。
如何减少这样的路由泄漏(Route Leaks)
除 Cloudflare 的内部系统以外，BGPMon.net和 ThousandEyes 也检测到了这一事件。BGPMon 有几种检测异常的方法; 在这种情况下，他们能够发现到达谷歌的路径中的提供商是不正常的。
Cloudflare 的系统立即检测到这一点，并采取了自动修复(auto-remediation)措施。
(hexo 中添加 tweet，使用了 https://github.com/tea3/hexo-tag-twitter 这个项目的生成器, 但是你可能需要科学上网上方的推文才能正确显示)
有关 Cloudflare 自动修复系统的更多信息：https://blog.cloudflare.com/the-internet-is-hostile-building-a-more-resilient-network/
展望未来
Cloudflare 致力于与其他组织合作，以推动更安全和更稳定的路由。我们最近写了有关 RPKI 以及我们将如何开始执行“严格”RPKI验证(“Strict” RPKI validation)的文章，并将继续努力实现安全的互联网路由。我们希望所有提供公共服务的网络提供商都能确保对客户进行适当的过滤，停止劫持(hijacks)和路由泄漏，并像 BCP-38 一样实施最佳的方案。