這幾天操作GNS3和VMWare的實驗環境，總是會出現一些神奇的未知的錯誤。而這些錯誤經過排錯後仍然無法解決，後來重新配置環境等一系列嘗試後能夠達到理想的狀態。這裏就來簡單說一下這些非常規情況下的解決方法。
先來說常規思路，一個網絡不通暢，則需要考慮的點有以下：
1.連線與接口是否匹配
2.每個端口的IP地址、子網掩碼、網關是否正確
3.路由器是否配置時鐘頻率和靜態/動態路由
4.鏈路測試
*5.特殊情況
*6.NAT特殊性
指導思想：逐層排錯，鏈路測試。
1.連線與接口是否匹配
這是最基礎的，廣域網用串口線；局域網用直連線。可以通過GNS3中的文本顯示來更清楚的掌握每個端口的ID。廣域網是路由器之間的網絡，局域網是接交換機的網絡。
圖中的按鈕能顯示端口等一些細節的名稱。
2.檢查端口的IP、子網掩碼、網關。特別要考慮NAT模式的特殊性。
這一般是最容易忽略的點，尤其是網關，考慮到VMWare中NAT模式的特性，默認使用NAT服務的網關，而這個網關如果與實驗中設定的網關不同，仍然會走默認路線，而又因爲虛擬機與物理機連接，可以通過NAT的網關走物理機並訪問另一臺虛擬機，而不是使用我們搭配的網絡環境。
如上圖，80網段的網關設置的是80.5，但是我的NAT模式網關是80.10。那麼我發現了一個神奇的問題：10網段ping VMnet8下的虛擬機，不通；但是VMnet8下的虛擬機可以ping通VMnet1下的虛擬機。這就非常奇怪，因爲數據包有來有回才能通，既然雙向可達，爲何會出現這種情況呢？
我使用tracert命令發現了問題。
我發現VMnet8網卡直接使用默認的NAT端口出去並轉發到了目的地，因爲NAT端口可以到達物理機，而物理機又與衆多虛擬機直連。所以這種情況下，我修改了網關，指定爲80.5的網關。
然後再跟蹤VMnet1.
得到了理想的結果，而且也因此VMnet1 能夠ping通 VMnet8。至於爲什麼，我們來抓包看結果，抓VMnet1和GNS3交換機的連線。
我們可以看到，當VMnet8 PING VMnet1時，VMnet1抓到的包是這樣的，數據包來自於10.1，而10.1是物理機直連虛擬機的網卡！！（爲了簡化以後VMnet簡稱V）
V1收到來自物理機發來的數據包，這個數據包是由V8先發到物理機而發到虛擬機的，也就說根本沒有走規定的網絡。
然後我們來看一下 V1 PING V8
這次爲了確定數據流向，我在4條鏈路上抓包。發現最後一條路有reply數據包，而其他鏈路沒有reply。
我們發現，數據包單向可到達V8，但是V8的數據包卻在返回時丟失了，甚至還沒有到達第一個路由，是因爲V8默認網關80.10，而回傳的數據包因爲是響應數據包，爲了在網絡中傳輸，數據鏈路層協議裏附加了MAC地址信息，而返回的數據包走了網關80.10，在那個網關下的接口沒有對應的目標MAC地址，所以數據包丟包了。
所以，這就解釋了爲什麼V8可以ping通V1虛擬機，而V1卻ping不同V1虛擬機。V8的數據包到達V1後，V1返回數據包會按照我們搭建好的網絡順利到達V8。
說到底，這都是網關的問題，而NAT模式是最容易出問題的網關。
3.路由器是否配置時鐘頻率和靜態/動態路由。
這個反而好理解了，用show ip route命令就可以看到靜態路由和動態路由，只要確認有沒有和下一跳路徑對不對即可。而時鐘頻率比較容易忽略，一定要配置時鐘頻率，時鐘頻率在DCE端口配置，且數值有一定要求，不能隨便配置。
4.鏈路測試
所謂鏈路測試，也就是檢測全網暢通與否，檢測網絡暢通方法之一是一條路徑上所有節點間連線都進行抓包，然後根據鏈路上是否有去有回來判斷數據包網絡連通性。也可以一條路徑一條路徑進行ping測試，然後確認一下哪條路徑不對勁，對端口進行上面的一些檢查。
5.特殊情況：上面的情況檢查完後，理應沒有問題的情況下，此時就屬於不是理論上錯誤的特殊情況了，這種特殊情況出現的原因不確定因此不好解決。通常都是以嘗試的方式來糾錯，包括斷開連線重連、重啓應用程序、重啓電腦、重新配置一個完全相同的環境等。
還有，每次開機運行久了，偶爾會出現物理機上VMnet網卡失效的情況，比如WIN+R來訪問網上鄰居，發現連不通，此時禁用並重新啓用網卡就會解決。
還有Cloud 加新網卡並接入路由器時報錯，這種情況是因爲GNS3在安裝時會綁定電腦上的網卡，卸載重裝GNS3即可解決。
總而言之，出現很多理論上沒有錯而測試結果就是不對的情況，可以考慮重新配置環境。往往比i想象的要有效。
6.NAT 特殊性
仍然是這個例子。我們畫成拓撲圖方便理解
我們來詳細分析一下，爲什麼在默認網關指向80.10時（NAT服務）會出現PC2ping通PC而PCping不通PC2。
首先，我們先看正常情況下，網關指向80.5（配置的網關）
這時很好理解，就是按照我們配置的走，也是最簡單的路徑。而我們知道，NAT模式下的虛擬機非手動指定，會走默認網關（80.10）。
此時卻出現了神奇現象：PC2pingPC通而PCpingPC2不通。
我們通過抓包發現：
數據的來源不是80.129而是80.1，也就說NAT對其進行了地址轉換，那麼在這種情況下，就會出現問題了。
下面的情況：
PC2pingPC
1.PC2的數據包到達NAT路由，做地址轉換，準備上因特網；此時地址已經變更爲與物理網卡的地址1.113；然後發現可以通過直連網卡80.1來發送數據包，此時做第二次地址轉換，地址變爲80.1；然後PC收到數據包。此時PC2收到數據包後再返回數據包，此時，對這個數據包而言，1.113是內網，10.1是外網，他們通過地址轉換得來；80.10是1.113的內網，也就說是內網中的內網。但是因爲NAT服務的存在，所以原路返回是可能的。
PC ping PC2
2.PC的數據包根據規定路線到達PC2，PC2返回數據包，走NAT（默認網關）。NAT會轉換兩次地址，一次轉化爲物理網卡，再一次轉換爲虛擬網卡VMnet8，每次轉換都對PC而言是內網。當PC2收到反饋的數據包後，就會發現一個問題，我ping的是192.168.80.129，爲什麼從80.1返回一個數據包，我並沒有對你進行請求，這是一個風險數據包就丟包了。這樣就會導致PC ping PC2不通。
綜上所述，對於虛擬機環境的排錯。NAT服務下的計算機會出現很多需要額外注意的點，如果想要避免這些問題，那麼實驗過程中儘可能使用兩個僅主機模式的虛擬機而不使用NAT模式的虛擬機。但是，這種排錯的思想理念，通過抓包分析數據包的流向，都是非常重要的學習過程，而且，每當搞明白一個問題，對一個服務或系統的理解都會更進一步。