[AWS] 掃盲，AWS的網(wǎng)絡(luò)組件介紹

前言

用了一段時間的AWS，決定總結(jié)一下我已經(jīng)用到過的AWS中的網(wǎng)絡(luò)組件，算是個掃盲文，適用于網(wǎng)絡(luò)技術(shù)背景的同學(xué)。對于網(wǎng)絡(luò)小白，我只有一個建議——好好閱讀用戶手冊，反正你本來也不懂，你用的云說啥，就是啥好了。

公正的講，對于非網(wǎng)絡(luò)專業(yè)方向的IT管理員來說，AWS所抽象過的網(wǎng)絡(luò)組件，確實更容易理解，它隱藏了很多現(xiàn)實中網(wǎng)絡(luò)的細節(jié)，但反過來，當(dāng)一個深受Cisco荼毒的工程師開始用這些東西，就會覺得怎么用怎么不順手。

順帶一提，福廠的網(wǎng)絡(luò)組件，簡直是對AWS網(wǎng)絡(luò)組件的1:1映射，不愧是福廠，善于學(xué)習(xí)列強的先進經(jīng)驗(笑

AWS的網(wǎng)絡(luò)組件都有哪些東西？

·VPC

·Route Table

·Subnet

·IGW/VGW/TGW

·SG&Network ACL

·Avaibility Zone

·VPN/Direct connect

·Endpoint

·3rd Party Device(Virtual)

我知道的，大概就是上面這些東西，由于成本壓力和客觀上的超遠距離(從中國到美東的us-east-1)，我們沒有使用Direct connect，而選擇了AWS VPN，結(jié)果深受其害，在持續(xù)數(shù)周的"一小時"抖動后，我終于發(fā)現(xiàn)，原來AWS也是和我們這些網(wǎng)工一個路數(shù)，做個產(chǎn)品以“能用”就為標(biāo)準(通了就走！)

AWS:什么？Cisco的IOS-XE都已經(jīng)更新到了16.10了？關(guān)我什么事，我提供的配置參考仍然是12.4的版本，并且只有IKEv1的參考……

關(guān)于這個悲傷的故事，放到后面再說，下面逐一來介紹一下AWS的這些網(wǎng)絡(luò)組件。

VPC

Virtual Private Cloud，為每個用戶提供一個隔離的網(wǎng)絡(luò)環(huán)境，你很容易就能想到現(xiàn)實中的網(wǎng)絡(luò)概念——VRF。

VRF是在單臺設(shè)備上進行路由資源隔離，如果要在整個網(wǎng)絡(luò)中為用戶提供隔離的網(wǎng)絡(luò)環(huán)境，就勢必要用上各種各樣的封裝技術(shù)，也就是VPN們——MPLS/VPN，VXLAN/EVPN，甚至使用VRF&GRE隧道也可以。

我們無從得知AWS到底用了什么，當(dāng)然，這也不重要。在筆者看來，這些技術(shù)雖然各有優(yōu)劣，但僅就提供隔離網(wǎng)絡(luò)環(huán)境這一效果來說，沒什么太大差別——因為最終，網(wǎng)絡(luò)資源的隔離仍然是在單臺設(shè)備上完成的，所有這些技術(shù)，只是為了將分散在單臺設(shè)備上的，隔離的網(wǎng)絡(luò)資源，在公共的網(wǎng)絡(luò)上打通，封裝的本質(zhì)，只是為了讓遠端的設(shè)備能夠識別，數(shù)據(jù)包到底屬于哪個VRF而已。這些技術(shù)/方案的邏輯，你甚至可以用遠古時期的Frame-Relay來解釋。

p.s.當(dāng)年在培訓(xùn)機構(gòu)學(xué)習(xí)MPLS/VPN的時候，F(xiàn)rame-Relay就天天被拉出來鞭尸。

Route Table，路由表

這是我個人最討厭的一個組件，它割裂了我對于“路由表”的理解，產(chǎn)生了極大的不適感。我用一張圖來說明AWS的Route Table是個什么東西，這張圖是我在部署CSR1000v時畫的。

AWS Route Table Example

Private Subnet A和Private Subnet B被關(guān)聯(lián)在一個Route Table上，姑且就叫Private Route Table好了。

Public Subnet A關(guān)聯(lián)在另一個Route Table上，就叫Public Route Table好了。

CSR1是筆者部署的一臺EC2，當(dāng)然，是一臺啟動后就是CSR1000v虛擬路由器的EC2。它有兩個網(wǎng)卡，分別關(guān)聯(lián)到了Private Subnet A以及Public Subnet A上。

換言之，從這兩個網(wǎng)絡(luò)接口發(fā)出的流量，進入了不同的路由表，也就是Private Route Table和Public Route Table

那么請問，CSR1，關(guān)聯(lián)到Public Subnet那側(cè)的端口，是否能訪問到Private Subnet B中的主機呢？通常來說，應(yīng)該是不可以?？磮D說話你會覺得路由域是隔離的。

但是請記住，AWS只會給你提供一個隔離網(wǎng)絡(luò)，一個VPC即為一個隔離網(wǎng)絡(luò)，在一個VPC內(nèi)部，你只能依賴安全組進行進一步的隔離。

所以，CSR1關(guān)聯(lián)到Public Subnet A上的端口，也是可以訪問到內(nèi)部網(wǎng)絡(luò)去的，你必須依賴安全組進行訪問控制。

Route Table在VPC內(nèi)部不具備隔離網(wǎng)絡(luò)資源的作用，它最主要的作用是，分割訪問至VPC外部的路由

典型的訪問至VPC外部的路由，就是訪問Internet所需要的默認路由。

在上圖中，Public Route Table的默認路由指向了AWS的Internet Gateway(縮寫為IGW，即AWS設(shè)定的VPC中的Internet出口)，而Private Route Table的路由則指向了CSR1的網(wǎng)卡

換言之，關(guān)聯(lián)在Private Route Table中的Subnet，命中默認路由去往CSR1，經(jīng)過CSR1進行NAT轉(zhuǎn)換后訪問互聯(lián)網(wǎng)。

當(dāng)然，如果你有訪問其它外部資源的情況，比如VPN，比如TGW，也是一樣的。同一個VPC內(nèi)不同的路由表的主要區(qū)別在于去往VPC外部時的路由，A路由表和B路由表對于同一條路由，指向的下一跳可以不同，僅此而已。

P.S.TGW，用于將不同的VPC連起來的一個組件。在多VPC環(huán)境中，TGW還可以簡化VPN拓撲的復(fù)雜度。Transit Gateway，其實就是個提供網(wǎng)絡(luò)連通性的網(wǎng)絡(luò)服務(wù)節(jié)點。

那，它如何實現(xiàn)的？我們不妨大膽猜測一下——

實際上，如果你觀察AWS路由表這一事物，會發(fā)現(xiàn)里面從來就沒有關(guān)聯(lián)至特定子網(wǎng)的明細路由，只有一條VPC大段路由。VPC內(nèi)所有的路由表都是如此。

乍一看上去，“將子網(wǎng)關(guān)聯(lián)至路由表”這一行為非常像是我們在路由器的某個SVI接口下敲一條vrf forwarding XXX的命令，但若真是這樣，就無法解釋為什么關(guān)聯(lián)在不同路由表中的子網(wǎng)內(nèi)的主機可以互相通信了。所以，一個基本的事實是，VPC內(nèi)的所有子網(wǎng)一定是在一個路由域內(nèi)的，而路由表這一概念，其實是別的東西，從它的作用來看，或許稱呼為外聯(lián)路由表更合適。所以，我們也可以推斷出，子網(wǎng)的網(wǎng)關(guān)，并不在路由表上，所有子網(wǎng)的網(wǎng)關(guān)都在一個路由域內(nèi)，路由表，其實是這個路由域外部的一個東西。

于是我就畫了這樣一張圖——

可以肯定的一件事是，沒人會去吃飽了撐的天天重復(fù)造輪子，AWS實現(xiàn)的網(wǎng)絡(luò)組件的背后，一定也是我們熟悉的種種網(wǎng)絡(luò)技術(shù)，而最貼近的，應(yīng)該就是PBR了。

上面這張圖可以實現(xiàn)AWS的邏輯，即某個特定子網(wǎng)的流量被固定扔到一個路由表中去，當(dāng)然這個路由表有一條回到VPC網(wǎng)絡(luò)的大段路由。到這里，其實它就是一個可以執(zhí)行三層轉(zhuǎn)發(fā)的路由實例，只不過AWS起了個名字叫路由表，它到底是個什么我們不得而知，也不重要。

當(dāng)然啊，以上只是猜測，是從它的行為邏輯反推出來的結(jié)論。

Subnet

每個VPC在創(chuàng)建的時候會要求分配一個根網(wǎng)段，Subnet則是從根網(wǎng)段下派生出來的子網(wǎng)。VPC創(chuàng)建的時候會有一個主路由表，如果你不做顯式關(guān)聯(lián)，那么每個Subnet默認關(guān)聯(lián)到主路由表。

將Subnet關(guān)聯(lián)到特定的路由表即可影響該Subnet下所有主機訪問外部的路徑。在AWS中，典型的一個應(yīng)用場景是——

負載均衡器所在的Subnet，關(guān)聯(lián)到Public Route Table，其默認路由指向IGW，因為負載均衡器通常都需要固定的公網(wǎng)IP地址;

而對于后端服務(wù)器，可以關(guān)聯(lián)到Private Route Table，由于不需要對外暴露端口，Private Route Table可以將默認路由指向一個NAT網(wǎng)關(guān)，通過NAT網(wǎng)關(guān)訪問互聯(lián)網(wǎng)。

AWS提供了一款NAT網(wǎng)關(guān)，你也可以自己部署第三方虛擬機，比如大C記或者Fortinet的虛擬路由器/防火墻之類的……

IGW/VGW/TGW

AWS所抽象出來的三種網(wǎng)關(guān)類型。

IGW，Internet Gateway，訪問Internet的必經(jīng)之地。當(dāng)你為EC2分配公網(wǎng)IP地址的時候，這個地址總是存在于IGW上的，IGW做了EC2私網(wǎng)地址到公網(wǎng)地址的1對1轉(zhuǎn)換。

VGW，當(dāng)VPC需要通過VPN/Direct connect連接到本地數(shù)據(jù)中心/站點時，就需要VGW。VGW存在的合理性很容易分析，如果是我設(shè)計機房，接入?yún)^(qū)肯定被單獨安排在某個或者某幾個物理位置，所以從用戶所在的位置到達接入?yún)^(qū)一定是存在物理鏈路/物理網(wǎng)絡(luò)的，那么對應(yīng)的，在虛擬網(wǎng)絡(luò)里就需要一個VGW這樣的角色，用于完成底層的流量轉(zhuǎn)發(fā)。

TGW，當(dāng)你有多個VPC，且多個VPC需要互訪，切多個VPC還需要和本地互訪的時候，TGW就派上用場了。Transit Gateway，顧名思義，中轉(zhuǎn)用的網(wǎng)絡(luò)節(jié)點，在這種情況下，VPN可以直接安排在TGW上。不過筆者曾經(jīng)碰到過TGW上無法排障的流量黑洞問題，很是頭痛。AWS的網(wǎng)絡(luò)組件多半都存在這個問題，抽象后易于使用，但缺少排障和運維工具，一旦點子背，就只能怪自己運氣不好。

SG&Network ACL

這兩個都是訪問控制，差別在于，SG有會話特性，也就是支持自反，對于一個被放行的會話，不會去阻擋反向連接;Network ACL看上去就是工作在普通三層設(shè)備上的ACL，沒有自反。沒有自反的ACL基本等于廢物，所以在我們的實踐中，Network ACL的入站和出站都是允許0.0.0.0/0，安全控制完全依賴SG進行。

SG，即Security Group，安全組。

有一種說法是SG實際上是iptables，但是看起來，AWS并沒有控制用戶虛擬機的權(quán)限，所以如果SG是iptables，那應(yīng)該也是宿主機上的iptables。

在網(wǎng)絡(luò)防火墻的部署中，我們很少會基于特定主機去部署防火墻，即便是邏輯上的虛擬墻(例如ASA的Security Context或者Fortinet的VDOM)，也是對應(yīng)邏輯上的子網(wǎng)，將一個或者一些子網(wǎng)放到一個邏輯上的區(qū)域中，以區(qū)域為單位配置訪問策略。

不基于主機來做的原因也很簡單——沒必要。當(dāng)整個網(wǎng)絡(luò)都是由特定幾個管理員來管理時，用戶根本就不需要關(guān)心ACL做在哪里，用戶只需要在意通或者不通，能不能通這樣的問題就好了。

AWS將IP抽象掉了，一些普通用戶搞不好連自己的EC2的私有IP是啥都不知道。某個主機需要通公網(wǎng)就直接給個公網(wǎng)IP。并且如果沒有專業(yè)的網(wǎng)絡(luò)工程師來規(guī)劃網(wǎng)絡(luò)，很多用戶搞不好就是一個Subnet用到死，甭管啥應(yīng)用都在這一個子網(wǎng)里，于是對于AWS而言，在照顧網(wǎng)絡(luò)小白用戶的前提下，SG就必須能基于特定主機來實現(xiàn)。

這基本上就斃掉了所有的網(wǎng)絡(luò)防火墻方案。宿主機上的iptables看起來最合適。但是宿主機的iptables過于分散，AWS還需要將它們抽象在一起，這些工作都被AWS隱藏掉了，用戶看到的，只是SG，以及將SG關(guān)聯(lián)到具體的虛擬機上去。

這也就解釋了，為什么SG總是入站控源，出站控目標(biāo)……因為SG在整個網(wǎng)絡(luò)的末端，而網(wǎng)絡(luò)防火墻，工作在網(wǎng)絡(luò)的轉(zhuǎn)發(fā)路徑上。

Avaibility Zone

可用區(qū)這個概念，實際上是真實物理網(wǎng)絡(luò)在虛擬世界的一個映射。虛擬的東西最終還是要落到哪些物理的服務(wù)器，交換機上去的，沒有哪個技術(shù)可以支撐一個虛擬化跑遍全世界的網(wǎng)絡(luò)，于是就會有Region，會有可用區(qū)。每個可用區(qū)的設(shè)計規(guī)模，可能只有AWS自己清楚，用戶不知道，但用戶可以選。

把不同的Subnet放到不同的可用區(qū)，一定是可以提高可靠性的，我個人在規(guī)劃CSR1000v的部署的時候，CSR1和CSR2所關(guān)聯(lián)的Subnet就在兩個不同的可用區(qū)……這一定程度上加劇了部署時的復(fù)雜性。

VPN/Direct connect

Direct connect……名字叫的賊好聽，不就專線么。VPN，就是隧道模式的IPSec VPN，AWS貼心的為你提供了很多廠家的配置參考，雖然都比較老。

筆者公司面臨的需求是跨國的混合云，Direct connect用腳趾想都知道會貴到難以承受，所以選擇了VPN的方案。

我習(xí)慣性的配置了IKEv2的VPN，也確實UP了，也能轉(zhuǎn)發(fā)流量，但是總有幾條隧道每隔一個小時就斷一次，斷的莫名其妙。一個小時太過規(guī)律，所以懷疑是生存時間到期，但通常來說，IPSec會在生存時間到期前就去re-key，不應(yīng)該出現(xiàn)規(guī)律性的中斷問題。

在本地數(shù)據(jù)中心的路由器上開Debug查了很久，看到一些疑似癥狀，譬如re-key timeout之類的日志，但無論是改配置的方式，甚至兩條隧道Down掉一條，都不能解決問題。搞笑的是，當(dāng)我嘗試把隧道按照AWS的配置參考改成IKEv1的配置時，故障就消失了……

著重說一下AWS的VPN，拓撲結(jié)構(gòu)是下面這樣的——

簡單來說，AWS的一個VPN實例包含兩個隧道，AWS一端，兩條隧道源自不同的Router，實現(xiàn)了可靠性，至于客戶端，對不起，我們只接受一個Customer Gateway，你可靠不可靠關(guān)我屁事……

如果你一定要實現(xiàn)客戶端，也就是你本地數(shù)據(jù)中心/站點的可靠性，你的拓撲就得長這樣……

換言之，要維護四條IPSec隧道。還行，不算多，VPC多了以后可能就上天了。(我已經(jīng)上天了……)

當(dāng)然，VPC多了以后，可以引入TGW來避免重復(fù)造VPN，拓撲大概這樣子——

對于每個VPN實例，AWS會運行BGP來保證可靠性，兩個VPN隧道完全對等，路由選擇是取決于哪邊的路由先收到……在你本地的BGP中，如果隧道1的路由先收到，則隧道1的路由優(yōu)選，如果隧道1掛了，隧道2的路由優(yōu)選，隧道1恢復(fù)后變?yōu)閭浞荨?/span>

如果你有兩個VPN實例，你就要控選路了，而且只能在本端控。我實測AWS的BGP至少還是認識AS-PATH這個屬性的，可以通過設(shè)置AS-PATH來控制路由。AWS一端的BGP沒有給你留操作界面。

對于跨國場景，底層的Internet質(zhì)量總是不穩(wěn)定，延時丟包率都比較感人，所以AWS的部分Region支持加速，加速的邏輯其實也很粗暴——當(dāng)你開啟加速的時候，AWS在其網(wǎng)絡(luò)邊緣的節(jié)點給你開了個NAT或者反向代理之類的東西，反正能讓你的IPSec流量順利通過該節(jié)點轉(zhuǎn)發(fā)至真正的VPN點。所以即便是AWS，也無法解決真實的距離問題，也只能通過就近接入，然后把包袱扔給自家骨干網(wǎng)來優(yōu)化訪問……

Endpoint

AWS上有一些SaaS服務(wù)，比如S3，它不是工作在用戶的VPC中的。當(dāng)用戶需要通過VPC去訪問這些SaaS服務(wù)的時候，AWS給用戶開了一個Endpoint，在VPC中，將訪問這些服務(wù)的路由指向Endpoint，這些路由多半都是公網(wǎng)路由。

不同用戶的VPC的IP地址一定存在重疊，所以可以很容易的想到，Endpoint還會執(zhí)行SNAT。所以，就是一個通往SaaS服務(wù)的路由+NAT點。

3rd Party Device

AWS生態(tài)非常牛逼的地方就在這，它支持豐富的第三方擴展。但實際上，3rd Device的集成，是個很美好的大餅，而真正部署起來的時候，并沒有那么好用。究其根源是，AWS對3rd Device的處理一視同仁——EC2，所以，無論你是買了ASA還是CSR1000v還是Fortigate，本質(zhì)上都是買了個EC2，你需要遵循EC2中的種種規(guī)則和限制。

舉幾個例子，比如，AWS的路由表中的下一跳并不是填寫ip地址的，由于3rd Device實際上是EC2，所以當(dāng)你要通過路由引流至這些設(shè)備時，你就必須寫路由指向這些設(shè)備的網(wǎng)卡。

那如果要高可用呢？Cisco的思路是，讓CSR1000v去調(diào)用AWS的API，修改路由表中路由的下一跳，以便指向另外一臺設(shè)備的網(wǎng)卡。啥？HSRP？不好意思不支持。

再比如，兩個CSR1000v之間起了個IBGP，結(jié)果發(fā)現(xiàn)流量在兩個路由器之間的轉(zhuǎn)發(fā)是有黑洞的……原因也很容易想到，因為這倆路由器壓根就不是直連，它們中間還過了一個"路由表"，這個"路由表"可不會跟著你的CSR1000v去收斂路由，解決方案也很傻X——我在兩個CSR1000v的內(nèi)部接口之間起了個GRE隧道……(捂臉

至于各家稀奇古怪的高可用技術(shù)就更不談了，現(xiàn)實世界中，網(wǎng)絡(luò)設(shè)備商的高可用幾乎做到了用戶無感知，做不到的都不好意思拿出來賣，但到了云上，你需要仔細研究，小心規(guī)劃，做好文檔，不然說不定哪天就不通了……這背后的原因還是因為3rd Device本質(zhì)是EC2。

我見過的高可用騷操作包括——修改網(wǎng)卡關(guān)聯(lián)的(飄網(wǎng)卡!)，修改路由表的，如果支持HAVIP這樣的功能就使用HAVIP的，真的很佩服設(shè)備商們的想象力。

但，最根本的問題是，設(shè)備商在云上的虛擬機真的賺錢嗎？

還是以CSR1000v為例，部署復(fù)雜，暗坑較多不說，AWS直接購買的價格也很驚人，雖然有一年購買的50%OFF，但是，不能選性能也是個討厭的事情。譬如筆者可能只需要50Mbps的性能，但隨便一個EC2都能達到更高的性能，而直接購買的License又只有Max Performance一種，于是總的成本就會很高。

另一種購買方式是BYOL，即自帶license，AWS上只有一個虛擬機，成本低非常多，但是又多了一步線下采購License的流程。

無論是從購買還是使用上，設(shè)備商和AWS的割裂都很嚴重，并沒有人真的很重視這塊市場，甚至恐怕真的在AWS上應(yīng)用CSR1000v的人也很少。不賺錢的生意就是無源之水，賣虛擬機不是做慈善，既然是無源之水，設(shè)備商為AWS上的虛擬機所能提供的支持，軟件穩(wěn)定性，可靠性，兼容性，都是要打上一個大大的問號的。

筆者就曾碰到過t2.medium級別的虛擬機盡管配置看上去能滿足我的需求，但實際上，卻出現(xiàn)了IPSec不解包導(dǎo)致DMVPN永遠卡在NHRP上的問題(本地DC的NHRP包發(fā)出去了，但CSR不解IPSec，致使NHRP協(xié)商不成功)

關(guān)于云的一些思考

在和云上的這些妖魔鬼怪打交道的日子里，我也在思考，云到底帶來了什么。在我看來，云似乎仍然只是一個服務(wù)中小型IT需求的東西，對于大型的IT需求，對于已有完整的內(nèi)部分工和流程的公司而言，云的諸多限制，反而會增加很多隱性成本，而這些成本，是很難被量化和計算的。

有一些問題可以靠云解決，比如在一個距離較遠的地方建立一個虛擬的數(shù)據(jù)中心，VPC的開通總是比租機房快的多。

但也有很多問題不是靠云可以解決的，譬如物理距離所帶來的延時和丟包，網(wǎng)絡(luò)的不穩(wěn)定……光就能跑那么快，海底光纜就那么幾根，如果你的應(yīng)用從沒有考慮過弱網(wǎng)對抗，那么在這種條件下，勢必就會很難受。

說起來，很多Global Design的PPT，總是每個大洲畫個Region，卻從來不提Region之間要怎么建，似乎總是默認Region之間有個骨干網(wǎng)。真是的，拿空氣給你造骨干網(wǎng)么。

還是那句話，云不是萬能藥，上云要謹慎，做混合云要謹慎。小公司可以完全依賴云，TOP大公司可以自己造個云，最難受的永遠是中間這一層的大部分公司，他們的IT基礎(chǔ)設(shè)施，永遠在預(yù)算和需求之間來回搖擺，嗯，這么說起來，中產(chǎn)階級的生活狀態(tài)，差不多也是這樣(笑