從谷歌宕機(jī)事件認(rèn)識(shí)互聯(lián)網(wǎng)工作原理

從谷歌宕機(jī)事件認(rèn)識(shí)互聯(lián)網(wǎng)工作原理

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