從谷歌宕機事件認識互聯網工作原理

大約在太平洋標準時間2012年11月5號下午6：24分/時間標準時間2012年11月6號凌晨2：24分，CloudFlare的員工發現谷歌的服務中斷了。我們使用谷歌的電子郵件等服務，所以，當它的服務不正常時，辦公室的人會很快發現。我在網絡技術小組工作，因此我立刻接上網絡查看是什么情況——是局部區域問題還是全球問題。問題排查我很快就意識到，所有谷歌的服務我們都不能連接上——甚至包括連接，谷歌的公共DNS服務器——于是，我從追查DNS開始。$dig+trace下面是我在探測G的域名服務器時得到的回復：.172800INNS.172800INNS.172800INNS.172800INNS.;;Received164bytesfrom0#53()in152ms;;connectiontimedout;noserverscouldbereached無法探測到任何服務器的結果證明確實有什么地方出了問題。尤其是，這意味著從我們的辦公室將連接不到任何的谷歌DNS服務器。我開始網絡層查找問題，看看是否是在這個通信層出了問題。PING0(0):56databytesRequesttimeoutforicmp_seq092bytesfrom1-1-15.edge2-eqx-sin.moratelindo.co.id(17):Timetoliveexceeded這里出現了奇怪的信息。通常，我們不應該在谷歌的路由信息中看到一個印度尼西亞的網絡服務提供商(Moratel)的名字。我立即進入一個CloudFlare的路由器中查看發生了什么事。與此同時，Twitter上世界其它地方的報告顯示了我們并不是唯一遇到問題的地方。互聯網路由為了理解是出了什么問題，你需要知道一些互聯網是如何工作的基礎知識。整個互聯網是由很多的網絡組成，這些網絡被稱為是“自治系統(AS)”。每個網絡都有一個唯一的數字來標志自己，被稱為AS號。CloudFlare的AS號是13335，谷歌的AS號是15169。各個網絡通過一種叫做邊緣網關協議(BGP)的技術互相連接。邊緣網關協議被稱為是互聯網的粘合劑——由它來聲明哪個IP地址屬于哪個網絡，由它來建立從某個自治網絡到另外一個自治網絡的路由。一個互聯網“路由”跟這個詞的表意完全一樣：由一個自治網絡里的IP地址到另外一個自治網絡里的另一個IP地址的路徑。邊緣網關協議是基于一個相互信任的體制。各個網絡基于信任的原則告訴其它網絡哪個IP地址屬于哪個網絡。當你發送一個數據包，或發送一個穿越網絡的請求，你的網絡服務提供商會聯系它的上游提供商或對等提供商，詢問它們從你的網絡服務提供商到網絡目的地，哪條路線最近。不幸的是，如果當一個網絡發出聲明說某個IP地址或某個網絡在它的內部，而事實不是這樣，如果它的上游網絡或對等網絡信任了它，那么，這個數據包最終將會迷路丟失。這里發生的就是這個問題。我查看了邊緣網關協議傳遞的谷歌IP的路由地址，路由指向了Moratel(23947)，一個印度尼西亞的網絡服務提供商。我們的辦公室在加利福尼亞，離谷歌的數據中心并不遠，數據包絕不應該經過印度尼西亞。很有可能是，Moratel聲明了一個錯誤的網絡路由。當時我看到的邊緣網關協議發來的路由是：tom@edge01.sfo01>showroute0inet.0:422168destinations，422168routes(422154active，0holddown，14hidden)+=ActiveRoute，-=LastActive，*=Both/24*[BGP/170]00:15:47，MED18，localpref100ASpath:443634912394715169I>toviage-1/0/9.0我查看了其它路由，比如谷歌的公共DNS，它同樣被劫持到了相同的(不正確的)路徑：tom@edge01.sfo01>showrouteinet.0:422196destinations，422196routes(422182active，0holddown，14hidden)+=ActiveRoute，-=LastActive，*=Both/24*[BGP/170]00:27:02，MED18，localpref100ASpath:443634912394715169I>toviage-1/0/9.0路由泄漏像這樣的問題在行業內被認為是起源于“路由泄漏”，不是正常的，而是“泄漏”出來的路由。這種事情并不是沒有先例。谷歌之前曾遭受過類似的宕機事件，當時推測是巴基斯坦為了禁止YouTube上的一個視頻，巴基斯坦國家ISP刪除了YouTube網站的路由信息。不幸的是，他們的這種做法被傳遞到了外部，巴基斯坦電信公司的上游提供商——電訊盈科(PCCW)信任了巴基斯坦電信公司的做法，把這種路由方式傳遞到了整個互聯網。這個事件導致了YouTube網站大約2個小時不能訪問。今天發生的事情屬于類似情況。在Moratel公司的某個人很可能是“胖手指”，輸錯了互聯網路由。而電訊盈科，Moratel公司的上游提供商，信任了Moratel公司傳遞給他們的路由。很快，這錯誤的路由就傳到了整個互聯網。在邊緣網關協議這種信任模式中，與其說這是惡意的行為，不如說這是誤操作或失誤。修復解決方案就是讓Moratel公司停止聲明錯誤的路由。作為一個網絡工程師，尤其是像CloudFlare這樣的大網絡公司里工作的工程師，很大一部分工作就是和其它世界各地的網絡工程師保持聯絡。當探明問題后，我聯系到了Moratel公司的一位同事，告訴他發生了什么事。他大概在太平洋標準時間下午6：50分/世界標準時間凌晨2