谷歌云又出问题

谷歌是全球最大的云服务提供商之一，谷歌云在公有云的圈子内也算是巨头级别的存在。越是强大的公司就越不允许有任何的瑕疵，然而，近日众多美国用户发现连接至谷歌（包括谷歌云、YouTube及其他网站）的流量突然经过俄罗斯重新路由至中国境内。

这就意味着，在美国部分州的网民启动浏览器和软件、并连接到谷歌及其服务后，不是与属于这家硅谷巨头的服务器进行联系，而是与俄罗斯和中国的系统进行联系。美国境外的网民也可能受到了影响。

谷歌已证实，在星期一下午太平洋标准时13：12至14：35的一段时间，连接至谷歌云、API及网站的流量经过属于境外互联网服务提供商（ISP）的IP地址改道而行。在谷歌云上构建的网站和应用程序（比如Spotify、Nest和Snapchat）也有机构检测到总共180多个前缀受到了这次路由泄漏的影响，牵涉范围广泛的谷歌服务。分析表明，这次泄密的起因是尼日利亚提供商MainOne和中国电信之间的BGP对等互联（peering）关系。MainOne通过位于拉各斯的IXPN与谷歌有着对等互联关系，并有着通往谷歌的直接路由，但这些直接路由泄露到了中国电信。这些泄露的路由经中国电信传播，通过TransTelecom传输到NTT和其他中转ISP。

这次泄漏主要是由企业级中转提供商传播的，并没有对消费者ISP网络造成太大的影响。

其实，BGP劫持和路由配置泄漏事件时常发生。最突出的案例是马来西亚电信路由泄漏事件，但每天也有成千上万较小规模的路由泄漏事件发生。互联网路由的设计是基于可信方（互联网服务提供商）之间的交流：这使得解决不必要的路由泄漏成为很难实现的任务。

什么是BGP

边界网关协议（Border Gateway Protocol）是运行于 TCP 上的一种自治系统（AS）的路由协议。 BGP 是唯一一个用来处理像因特网大小的网络的协议，也是唯一能够妥善处理好不相关路由域间的多路连接的协议。BGP 系统的主要功能是和其他的 BGP 系统交换网络可达信息，实现自治系统间通信。

BGP 是一个外部网关协议，允许一个AS与另一个AS进行通信。BGP允许一个AS向其他AS通告其内部的网络的可达性信息，或者是通过该AS可达的其他网络的路由信息。同时，AS也能够从另一个AS中了解这些信息。与距离向量选路协议类似，BGP为每个目的网络提供的是下一跳（next-hop）结点的信息。

由于可能与多个的AS相连，在一个AS内部可能存在多个运行BGP的边界路由器。同一个自治系统(AS)中的两个或多个对等实体之间运行的BGP被称为IBGP（Internal/Interior BGP），归属不同的AS的对等实体之间运行的BGP称为EBGP。

整个互联网是由所有ISP（网络服务提供商）子网相互连接组成的，每个ISP可以看成是一个AS。ISP管理着自己所拥有的IP地址段，通过BGP协议告诉其他AS自己子网络里都包括了哪些IP地址段，自己的AS编号（AS Number）以及一些其他的信息。

BGP挟持概述

BGP协议里虽然有一些简单的安全认证的部分，但是对于两个已经成功建立BGP连接的AS来说，基本会无条件的相信对方AS所传来的信息，包括对方宣称所拥有的IP地址范围。

对于ISP分配给大公司客户的地址段，ISP往往会对BGP做一些有限的过滤。但是对于大型ISP来说，因为对方所拥有的IP地址段可能过于分散，所以一般是按最大范围设置BGP prefix 地址过滤。比如假设ISP A拥有地址段20.1.0.0/16和20.200.0.0/16，那么ISP B可能会设置过滤对方传来的20.0.0.0/8以外的路由。

当然这种情况比较极端，一般ISP分配到的IP地址段都是连续的，但是基本也都有可操作的空间，可以把数百到几万个不属于自己的IP合法加到自己的BGP信息里。

多数ISP甚至都没有把自己本身的IP段过滤掉，也就是说如果其他AS声称拥有该ISP自己的IP段，这个ISP的BGP路由也会相信。

当我们控制了ISP的BGP路由后，像平常一样发送路由信息。通过修改AS Path，让其他AS认为你到目标网络的距离最短，相邻的AS学习到新的路径之后会慢慢同步到网络中的其他AS。此时，同步了新路径的AS前往目标网段的数据都会发送到被控制的路由上。

目前有几个方法来检测劫持和路由泄露，但是这些方法一般难以落实或有许多不足。这些检测方法包括

1、不断地分检查析Routeviews和AS path。然而，这些数据的监控是非常复杂的，所以几乎没有什么用处；

2、测量的IP数据包的TTL字段。但是，攻击者也可以伪造TTL。

3、检测往返延时（RTT）。

谷歌云不是第一次犯错

无独有偶，在2016年4月份，由于两个bug的产生，致使谷歌云全线下线，长达18分钟的无云时间使得谷歌云变成了乌云。曾经确保 Google 的网站永不掉线Google 的工程副总裁对此进行“7×24”的全天候个人道歉。

这件事的原因也是：谷歌的工程师要对谷歌的网络配置进行瘦身，谷歌计算引擎中的部分IP模块长期未使用，工程师选择了对其删除并让谷歌的自动化系统在谷歌的网络系统里完成剩余的传输工作。但是一个IP模块从其配置文件中被删除时，用于网络配置管理的其他配置文件并没有完成相应的传输转移，于是乎这个模块传输失败了。

当传输失败时，谷歌通常会选择还原故障部分到之前的位置，然后添加新的模块重新传输。但是这次，前所未有的软件bug被触发了。这次传输失败后，并没有将故障部分还原到原来的位置，而是将GCE所有的IP模块进行了重新配置。而这次配置的用的就是用于更新的不完整的IP模块。

这一系列的bug已经导致了谷歌云出现了长达18分钟的中断。18分钟的乌云也许可以很快驱走，但是18分钟的无云却是无法抹平的用户心理阴影。

总之，做网络工程师这一行，有时候，就是细节决定成败！万一真的有一天你闯下大祸，你跑不跑路？欢迎在底下留言你差点要跑路的经历吧！

跑路经历一

上午银行营业时间一不小心蹬掉了机房总开关，导致整个银行断电

跑路经历二

第一次远程升级BRAS。一时没注意把自己也踢下去了，Enter 键刚按下去，自己就掉了。当时马上反应过来，心想完了。就像自己要死了的感觉。

跑路经历三

有一次我在240多台瘦机的机房里巡视，这是虚拟化项目， 突然发现虚拟化的服务器很响，越来越响， 我看了看不是风扇的声音， 我当时吓了我一跳，然后我有点紧张，菊花一紧，然后不知所措的把服务器的ups 电源断电了，然后服务器，就立刻停止了，当我做完这件事情之

后，我才反应过来，我摊上大事了， 我真的摊上大事了，当时脑海一片空白。。。。。

跑路经历四

我把思科3750 电源插头碰到导致接触不良烧了然后两排机柜的服务器都不能用了，后来被机房禁止进入半年。。。

跑路经历五

第一次独立去客户现场，帮客户做限速，客户要求交换机上做，死活不成功，后来去到核心设备上设置，把出口设置成8K，哗啦的一下子全公司几百台主机全部断网，爽爆了。

跑路经历六

悲剧的是远程的时候把网络配错了，远程桌面的时候把网卡禁用，telnet/ssh 的时候， 把自己忘了，来一个deny ip any any ，连自己都拒绝掉了。

跑路经历七

运行了10几年的思科设备，被我不小心断电了结果再也进不去彻底死掉了

跑路经历八

一开始去某IDC机房蹭网，只需要一个工作证就能带俩人进去了，后来听说有一屌丝关自己机柜电源时，把整个idc机房电源都关了，然后被电信机房列为永久黑名单，不得入电信机房。从此以后再去蹭网，就得拿身份证才行了。

跑路经历九

当年在波士顿办公室上班，机房APC UPS电源模块坏掉一个，响个不停，打电话给APC 报修， APC快递了个模块让我自己换，好吧，那就自己换，拿着电话听着印度英语口音的客服指导，开始搬动电源切换开关，切换主备电源模块，那个脑残设计的切换开关啊，我下手不给力，竟然没扳倒底，开关自己弹了回去。但这时候电源已经瞬间断开了一下。整个机房断电。设备全部重启。更要命的是，那运行了N 年的2621 路由器没起来。 console 发现不知道怎么进了rommon， boot后发现还是不能上网，一堆老美跑进来问什么情况，傻眼了。

跑路经历十

刚工作的时候，学会了怎么给路由器升级，当时接触了一台锐捷的RSR2024路由器，突发奇想把cisco的2811路由器灌到RSR2024上，然后删掉了原有的OS，结果 ....

跑路经历十一

广东移动核心数据中心机房，配置ip的时候，华为设备，掩码本来是30 的，少打了一个0，结果重分布进了核心网络，导致所有客户流量全部跑到我这台测试机了，什么淘宝、 新浪、网易都打电话投诉了···