關於虛擬機器的通訊原理

前段時間，與一哥兒們討論這個問題的時候，讓人挺糾結的。自己抽空分析了一下，下面是學習筆記：

 

本機環境：
Windows XP SP3
（IP:192.168.1.100 後續用真實機代替本環境）

虛擬環境：
VPC2007
（Windows Server 2003   IP:192.168.1.200 後續用虛擬機器代替本環境）

抓包軟體：

OmniPeek V5.4

 

（注意：虛擬機器與本機要在同一個網段，不然會ping不通，另外在端要先運行arp -d
命令清空ARP緩衝.... ^_^）

 

     記得我以前在無憂網客聯盟論壇裡面
學習CCNA/NP時，看過一些關於乙太網路的基礎知識。畢竟在乙太網路中傳輸資料必須要靠唯一的MAC地址來識別最終的目標電腦。簡單的來講，在LAN中，如果一台電腦要與另一台電腦通訊傳送資料包，那麼必須先要檢查自身ARP緩衝中該IP地址的MAC地址，如果MAC不存在，就會在廣播網裡面發送一個ARP請求，再根據ARP資料包找到該電腦的MAC地址，待MAC地址匹配確認，才開始最終的傳輸。

 

     （當初就怎麼沒想過LAN資料包是如何到達虛擬機器的？ 囧......）

 

1、設定OmniPeek：

這裡選擇IP協議：

 

2、清空本機ARP緩衝：

再開啟cmd（從本機ping虛擬機器）

，待清空後點擊start開始捕獲，如：

 

3、分析資料包

     既然能ping通，當然首先是捕獲一下原生ICMP協議資料包，看看有沒有產生真正的資料包。於是用OmniPeek抓包分析一下，果然產生了“真實”的ARP、ICMP共計4條資料包：

     （這裡“真實”一詞之所以打個引號，是因為......留個疑問，後面再做解釋吧！）

 

     先開啟ARP請求的資料包，因為之前運行了arp -d

命令清空了ARP緩衝表，所以才會產生出ARP請求的資料包：

 

     再看看ARP回顯的資料包，此時目標地址與源地址都已經得到：

 

     再看ping程式產生的ICMP資料包，先是請求（這裡ICMP Type
表示請求或回顯的標誌）：

 

     再看ping程式回顯時資料包：

 

     這些資料包，總體看來似無任何“異常”，從ARP到ICMP一路都順暢與規矩，仍然發現不了什麼問題。

 

     帶著疑問始終不解，於是請教了網路群裡面老兵，他告訴我VPC/VM虛擬機器裡面一般會有一個獨立的服務或驅動在類比一塊虛擬網卡。於是在微軟官方某大牛的部落格
中找到了這樣答案，大致意思是這樣的：

 

1、採用NDIS過濾驅動，基於VPC或是Virtual Server的虛擬網卡都是類比了一個虛擬適配器裝置，該虛擬網卡的MAC地址都是以00-03-FF開頭；

2、每個一個虛擬機器都會建立一個預設的虛擬網路介面卡（最多隻能虛擬建立四個）；

3、在安裝完VPC之後，會在系統中多個服務或驅動:Virtual Machine Network
Services，這個服務很強大，它負責資料在虛擬網卡和物理網卡中傳遞。

 

     依靠Virtual Machine Network
Services，物理網卡會處於一種XXO的狀態，它不光會接收投遞到其真實MAC地址的資料，同時還會接收投遞到虛擬網卡MAC地址的資料，經過此一步資料匯總，然後再依據各個MAC地址，資料投遞到相應MAC的網卡之上，不管資料是投遞到虛擬機器還是真實本機，反之亦然。

 

     於是用巨盾的進程工具，果然找到了這樣一個驅動：

     於是終於搞清楚了，為什麼能ping通虛擬機器了，有點小小的“雞動”了！！！

 

     關於VM的話，相信也是類似的“原理”吧，它帶有特殊的進程、特殊的服務或許特殊的驅動，做些“特殊”的事....有興趣的朋友不妨你自己試試！

 

     （由於鄙人的老本本硬碟空間很“寶貴”，我就不試了。自己一直沒用VM，即便“能省就省”吧.....）