故事的開始是這樣的，遇到有人說他們想要去了解AWS的VPC的技術(shù)細(xì)節(jié)，然后說要在AWS的公有云上創(chuàng)建幾個(gè)實(shí)例，希望通過抓包來分析AWS的VPC的實(shí)現(xiàn)細(xì)節(jié)。當(dāng)時(shí)我就忍不住跳出來說，如果AWS的VPC可以提供這么的功能的話，他們的實(shí)現(xiàn)細(xì)節(jié)豈不早被人學(xué)會了。畢竟，VPC是基于overlay的網(wǎng)絡(luò)，在三層的物理網(wǎng)絡(luò)上實(shí)現(xiàn)一個(gè)大二層的專用網(wǎng)絡(luò)，如果能看到物理三層的東西的話，豈不是太不安全了。

但是，后來的發(fā)展的確說明我可能想的太多，因?yàn)锳WS的確從2015年開始就提供了VPC Flow Log[1]這樣的服務(wù)。當(dāng)然，大家也不要想太多，這個(gè)功能的目的主要是提供給大規(guī)模上云的用戶來做自家的VPC內(nèi)的網(wǎng)絡(luò)故障排除的。如果AWS真的說可以讓你抓到ENA上的網(wǎng)絡(luò)包，建議你三思。

VPC的故事和其他人一樣都是從OVS+VXLAN開始的，如下圖。

AWS的服務(wù)提供如下的幾種類型：

Accepted and rejected Traffic

No data and skipped records

Security group and network ACL rules

IPv6 traffic

TCP flag sequence

Traffic through a NAT gateway

Traffic through a transit gateway

需要注意的事，AWS說提供的是VPC Flow的信息，也就可以認(rèn)為這個(gè)信息只能是一跳的內(nèi)容，和傳統(tǒng)的wireshark的TCP session還是不同的。

關(guān)于AWS的VPC log的格式以及使用場景，AWS一如既往地提供了詳細(xì)文檔，就不贅述了。其中有意思的點(diǎn)如下：

當(dāng)創(chuàng)建一個(gè)客戶可定制的flow log時(shí)候的選項(xiàng)包含：

${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status} ${instance-id} ${subnet-id} ${vpc-id} ${pkt-srcaddr} ${pkt-dstaddr} ${tcp-flags} ${type}

其中，version 2和3 的區(qū)別：2是AWS default設(shè)置，并保存在S3上。3是客戶定制的。

其中的兩項(xiàng)需要多說一下：

pkt-srcaddr 和pkt-dstaddr. 當(dāng)ena有多個(gè)IP地址，或者和NAT網(wǎng)關(guān)連接的時(shí)候，使用缺省的log的格式，其中的IP信息其實(shí)是不正確的，這個(gè)使用這個(gè)字段來提供正確的信息。

看了老大的服務(wù)，老二Azure肯定也要了解一下。[2] Azure畢竟是software公司出身，相對AWS的簡單的CSV格式，提供了基于JSON的輸出，而且比較合理地做了進(jìn)一步的整合，提供了flowtuples的方式可以把一個(gè)TCPsession多個(gè)flow 保留在一起。因?yàn)榘藘蓚€(gè)方向的，因此package_send有了兩個(gè)方向的內(nèi)容。

正因?yàn)樽隽?a href="http://www.1cnz.cn/article/zt/" target="_blank">聚合，因此不需要AWS那個(gè)相對比較別扭的pkt_srcaddr和pkt_destaddr. 和AWS相比，沒有包含帳號信息，感覺是對于一個(gè)具體的VPC的subnetwork的flow信息。AWS 的格式則是包含了一個(gè)帳號內(nèi)的一個(gè)VPC網(wǎng)絡(luò)的子網(wǎng)內(nèi)的一個(gè)EC2實(shí)例上的一個(gè)ENA網(wǎng)卡的包信息。

對于另一個(gè)巨頭Google來講，簡直把這個(gè)log玩出了花[3]。因?yàn)間oogle號稱可以實(shí)現(xiàn)跨數(shù)據(jù)中心的遷移，因?yàn)樵贔low log中包含了太多的信息。特別貼心的是有個(gè)五元組的結(jié)構(gòu)，估計(jì)查詢上肯定極為舒適。

不僅包含了實(shí)例的信息，源和目的的都有：

InstanceDetails 字段格式

同時(shí)還包含了地理信息，對，你沒看錯：

GeographicDetails 字段格式

當(dāng)然Google的內(nèi)部的cluster和pod的信息也不隱藏了。

只能說Google把一個(gè)VPC日志能夠包含的，VPC可能涉及的，可以透露的信息都提供了。

而且，大家都知道Google喜歡RTT，他同樣提供一個(gè)

這個(gè)，可以算是很多網(wǎng)管都感興趣的信息吧。

回到國內(nèi)的公有云，目前能夠拿到詳細(xì)信息的有aliyun[4]和華為云。

濃濃的AWS風(fēng)格，這個(gè)也沒錯，畢竟云業(yè)務(wù)要做到簡單，可靠，耐操。畢竟云用戶中不懂JSON和遞歸結(jié)構(gòu)的才是優(yōu)質(zhì)客戶。

華為云：

沒有使用AWS和aliyun那種直接，扁平的方式，而是和Google一樣加了一個(gè)project的概念來提供VPC中的subnetwork的信息。

最后，看到公有云上面玩的這么花，其實(shí)硬件廠家是拒絕的。network switch肯定也可以做，但是如果能做到Google這樣的per cluster和pod，估計(jì)在現(xiàn)有架構(gòu)上就難了。因此就有了INT

這下子，一個(gè)協(xié)議橫跨軟硬件，功能估計(jì)是復(fù)雜了很多，但是接受程度如何呢？

原文標(biāo)題：AWS、Azure、Google，VPC哪家強(qiáng)？

文章出處：【微信公眾號：ssdfans】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

責(zé)任編輯：haq