今天在Windows 7下實驗VMware的NAT網路模式時遇到了障礙，Guest-OS不僅無法訪問Internet，而且連Host-OS也ping不通。有時候彷彿能ping通Host-OS，但是卻返回大量的(DUP!)包，如下圖所示：

根據這個提示，在Google上搜索“ping DUP!”得到大量的結果，有的說禁用VMnet8網絡卡然後重啟即可解決，有的說可能是區域網上有IP衝突，有的說可能ping的是廣播地址，還有的說區域網有迴路等等，除了第一個禁用/啟用VMnet8具有可操作性之外，其他都是些莫名其妙的不知道具體如何解決的答案。但是，遺憾的是禁用/啟用VMnet8後問題依舊。 在Guest-OS上執行iptables -L

並未發現有設定防火牆規則，並且在Host-OS上已經禁用防火牆了，所以應該可以排除防火牆的原因。然後在vmware社群上看到了這篇帖子，有個人使用tcpdump來定位問題，實驗後仍然沒有發現什麼異常，無果而終。
在ping DUP!這個問題上花費了大約整整一天的時間，最終意識到ping DUP!可能並不是虛擬機器無法訪問網路的癥結所在，通過網路上給出的答案可以發現ping DUP!問題更多的原因可能是區域網內網路配置錯誤或者網絡卡異常導致的，而且出現這種現象的原因太多，很難入手。於是重新審視這個問題，把問題的所有現象一一列出來：

• Host-OS IP: 192.168.0.107
• Host-OS Gateway: 192.168.0.1
• Guest-OS IP: 192.168.220.128
• Guest-OS Gateway: 192.168.220.2
• Guest-OS ping自身192.168.220.128正常，ping閘道器192.168.220.2正常
• Guest-OS ping Host-OS 192.168.0.107返回大量DUP包
• Guest-OS ping Host-OS的閘道器 192.168.0.1返回大量DUP包
• Host-OS ping Guest-OS 192.168.220.128正常
• 開啟網路和共享中心，VMnet1和VMnet8屬於未識別的網路，而且公共網路不能修改

最後兩點現象很快就讓人感到異常，特別是未識別網路這條，如下圖所示：

於是Google關鍵字“VMnet8 未識別的網路”，根據第一條記錄的結果修改登錄檔中的*NdisDeviceType=1然後重啟VMnet8網絡卡，問題竟然就解決了！修改登錄檔參見下圖：

原來是Windows 7網路訪問的限制，也可以說是VMware的一個Bug，VMware在新建網絡卡時裝置型別*NdisDeviceType使用了預設值0,0意味著網絡卡是標準的真實網絡卡，VMware應該將其設定為NDIS_DEVICE_TYPE_ENDPOINT(1)才對，這樣Windows會知道這個網絡卡是個虛擬網絡卡並沒有和真實的外部網路連線，在“網路和共享中心”中忽略這些網絡卡，不會受網路共享設定的限制。

通過解決這個問題，再次意識到真的“不能在一顆樹上吊死”。解決問題往往有兩種方式：

• 第一種方式是：首先找出問題的一個異常現象，然後通過各種手段解決這個異常，最終會有兩種結果：一是異常解決並且問題解決，二是異常解決問題並未解決。如果是情況一，則問題解決，結束。如果是情況二，則排除了這個異常和問題的聯絡，這時需要尋找另一個異常現象，重複上述步驟繼續解決
• 第二種方式是：首先列出所有發現的異常現象，然後針對每個異常現象快速確定和問題有聯絡的可能性（譬如利用搜索引擎），然後針對每個可能性再繼續對問題進行分析

可以發現兩種解決問題的方式正如圖的兩種遍歷演算法：深度優先演算法和廣度優先演算法，方式一為深度優先，方式二為廣度優先。深度優先的缺點是可能會導致無止境的往下延伸，越往下延伸解決方案離最初的問題可能就越遠，直到排除所有可能性後才能解決最初的問題，在遇到奇葩的問題時，效率可能會非常低下。我們將每一次延伸稱之為問題的解決路徑，如果你的問題的解決路徑很短，譬如我們這裡的這個問題，根據現象“VMnet8 未識別網路”就可以直接解決問題，而根本不需要在ping DUP!問題上耗費無數的時間來研究。整個問題的解決示意圖如下：

可見，如果根本不能確定問題原因時，通過廣度遍歷的方式，加上問題之間的聯絡，可能會更好更快的解決問題。所以，在面臨問題時不要沉陷在自己的某一個想法中，可以從多個角度去看待問題。

參考