【翻译】为什么今天谷歌无法访问以及互联网工作原理

原文地址：[url]http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about[/url]

[b]为什么今天谷歌无法访问以及互联网工作原理[/b]

今天，部分谷歌服务出现故障长达27分钟。问题原因比较复杂，涉及到互联网隐蔽的角落。我是CloudFlare的网络工程师，在帮助谷歌回复服务中发挥了一些作用。下面我就讲讲都发生了什么。

太平洋时间下午6:24 / 通用协调时间 02:24（太平洋时间2012.11.5 / 通用协调时 2012.11.6） ，CloudFlare员工宣布谷歌服务无法访问。我们使用谷歌的邮件应用，所以当我们无法访问服务时，很快发现这个问题。我是网络工程组的，所以马上开始检查是本地问题，还是谷歌服务问题。

[b]解决问题过程[/b]
我迅速意识到已经无法访问谷歌所有的服务，甚至谷歌的公共DNS服务器8.8.8.8，所以我开始检查DNS问题。

$ dig +trace google.com

下面是我访问google.com域名服务器的返回结果：

google.com.                172800        IN        NS        ns2.google.com.
google.com.                172800        IN        NS        ns1.google.com.
google.com.                172800        IN        NS        ns3.google.com.
google.com.                172800        IN        NS        ns4.google.com.
;; Received 164 bytes from 192.12.94.30#53(e.gtld-servers.net) in 152 ms

;; connection timed out; no servers could be reached

事实是所有服务器都无法访问，肯定有地方出问题了。也就是说，从我们公司的网络无法连接到谷歌的任何DNS服务器。

我开始查看网络层，看看是不是这里的问题。

PING 216.239.32.10 (216.239.32.10): 56 data bytes
Request timeout for icmp_seq 0
92 bytes from 1-1-15.edge2-eqx-sin.moratelindo.co.id (202.43.176.217): Time to live exceeded

这很奇怪。正常情况下，我们不应该在到谷歌的路径上看到马来西亚网络服务供应商（Moratel）。我到CloudFlare的路由器上检查到底出了什么事。同时，Twitter上世界各地的问题报告说明不只是我一个人遇到了问题。

[b]网络路由[/b]
为了找到问题原因你需要先了解一些网络的工作原理。互联网是网络的集合，这些网络被称为自治系统（AS）。每个网络有一个唯一的号码标识它，被称为AS码。CloudFlare的AS码是13335，谷歌的是15169。网络由Border Gateway Protocol（BGP）互联。BGP是互联网胶水——负责管理哪个IP属于哪个网络以及建立一个AS到另外一个AS的路由。互联网路由就像它听起来的那样：一个AS的IP地址到另外一个AS的IP地址之间的路径。

BGP是一个高可靠的系统。每个网络都相信对方说的IP，以及它们背后的网络。当你通过网络发送一个数据包或者一个请求时，你的ISP连接到它的上层提供者找到一条到目的网络的最短路径。

不幸的是，如果一个网络把一个不属于它的IP或者网络声明为它自己的，并且它的上层服务信任它，那么路由就会出现错误。这里出现的就是这个错误。

我检查了谷歌IP地址的BGP路由。路由经过Moratel（23947），一个马来西亚ISP。我查看的是从加利福尼亚出发的路由，谷歌的数据中心离我们办公室不远，所以数据包不应该经过马来西亚。最可能的原因就是Moratel声明了一个不属于它的网络。
BGP路由如下：

tom@edge01.sfo01> show route 216.239.34.10                          

inet.0: 422168 destinations, 422168 routes (422154 active, 0 holddown, 14 hidden)
+ = Active Route, - = Last Active, * = Both

216.239.34.0/24    *[BGP/170] 00:15:47, MED 18, localpref 100
                      AS path: 4436 3491 23947 15169 I
                    > to 69.22.153.1 via ge-1/0/9.0

查看其它路由，例如谷歌公共DNS，也是同样的错误路径：

tom@edge01.sfo01> show route 8.8.8.8 

inet.0: 422196 destinations, 422196 routes (422182 active, 0 holddown, 14 hidden)
+ = Active Route, - = Last Active, * = Both

8.8.8.0/24         *[BGP/170] 00:27:02, MED 18, localpref 100
                      AS path: 4436 3491 23947 15169 I
                    > to 69.22.153.1 via ge-1/0/9.0

[b]路由泄露[/b]
这种情况业界叫做“路由泄露”，路由在正常路径泄露了。这不是没有发生过。谷歌原来也经历过类似的事情，巴基斯坦宣布审查YouTube上的视频内容，巴基斯坦国家ISP不再对服务IP提供路由。不幸的是，他们把空路由泄露了出去。巴基斯坦电信的上层服务商PCCW信任巴基斯坦电信发送的内容，然后路由就在网络上传播开了。结果是，YouTube两个小时无法访问。

今天的情况类似。Moratel的某个人修改了互联网路由。它的上层服务商PCCW信任Moratel发送的路由信息。然后，错误的路由信息迅速蔓延。这不太可能是蓄意的，但却是BGP信任模型可能由错误配置导致失败的证据。

[b]解决方案[/b]
解决方案就是让Moratel停止声明错误的路由。作为一个网络工程师，尤其是像CloudFlare这样的大网络，与世界各地其他网络工程师都有联系。当我指出这个问题时，我联系了Moratel的同事，让他们知道发生了什么。他在太平洋时间下午6:50 / 通用协调时间2:50修复了该问题。三分钟后，路由恢复正常，谷歌服务也恢复正常。

通过查看节点地图，我估计3-5%的网民受到了影响。影响最严重的是香港，在那里PCCW是主要提供商。如果你在那段时间无法访问谷歌服务，现在你知道为什么了。

[b]构建更好的互联网[/b]
这些都是互联网是一个基于信任系统的遗留问题。今天的事件表明，即使你像谷歌一样强大，你无法控制的因素也会影响用户访问你的网站。所以，组建一个网络工程师团队监控路由和管理连接是非常重要的。CloudFlare每天保证我们的客户得到最优的路由。我们检测我们网络上所有网站以保证获得尽可能快的传输服务。

[b]更新：[/b]太平洋时间 11月6日 11:00 星期二
Moratel说是异常的硬件故障导致的。这不是故意的。在检测硬件故障的同时，Moratel立即关闭了与谷歌连接的BGP节点。