近期筆者在單位服務器虛擬化(VMware vSphere)集群中新建了一臺虛擬主機用作Web服務器部署Web應用。虛擬主機建好后,服務器操作系統(CentOS 7)順利安裝完成,虛擬機能正常訪問網絡。奇怪的是,遠程VPN登錄服務器網絡,無法訪問上述創建的VMware虛擬主機,而且也無法Ping通故障虛擬主機。但遠程VPN進入服務器網絡,通過VMware vSphere管理主機,能Ping通上述故障虛擬主機,故障虛擬主機也能Ping通VMware vSphere管理主機。
服務器虛擬化采用VMware vSphere6.0虛擬化軟件將三臺物理服務器進行集群,三臺物理主機的互聯網絡部分和存儲網絡部分獨立分開,每臺物理服務器通過獨立網絡接口與存儲交換機相連,然后存儲交換機再與網絡存儲相聯接。
同時,每臺物理服務器通過另外一個獨立網絡接口與匯聚交換機相聯接,再通過防火墻接入互聯網。有專門的一臺物理主機用作VMware vSphere管理主機和網絡存儲管理主機。具體結構如圖1所示。
部署Web應用的工程師需要通過SSH遠程登錄到新建的虛擬主機進行遠程部署,反映無法通過SSH進行遠程連接。SSH服務已經安裝并成功啟動,并且在VMware vSphere管理主機進行過SSH遠程連接測試,能進行連接,用管理員賬號也可以成功登錄,一切正常。初步可以排除故障虛擬主機的配置問題。如果SSH服務和網絡配置有問題,上述測試應該能夠發現問題的。
1.聯系遠程部署Web應用工程師進行聯合調試。要求進行Ping測試,對方反饋無法Ping通虛擬主機(虛擬主機網絡允許Ping)。初步排除SSH服務引起的故障,問題很可能出在網絡連接上。
2.遠程登錄VMware vSphere管理主機,Ping故障的虛擬主機。奇怪的現象出現了,筆者居然可以Ping通。遠程部署Web應用工程師是通過VPN連接到服務器網絡的,筆者也是通過VPN連接進來的。難道是VPN登錄賬號配置的問題?

圖1 網絡拓撲結構
3.登錄防火墻,檢查VPN配置,筆者所用VPN賬號與部署工程師所用的VPN賬號配置權限完全相同。為了進一步驗證,用部署工程師所用的VPN賬號遠程登錄到服務器網絡,通過VMware vSphere管理主機Ping故障的虛擬主機,居然可以Ping通,說明故障跟VPN賬號配置無關。
4.再次詢問部署工程師是如何進行操作的。部署工程師反饋是通過VPN遠程連接后,直接在本地遠程連接SSH和Ping包測試的,無法通過SSH登錄,也無法Ping通。部署工程師和筆者的測試不同在于:一個是VPN連接后,在本地直接訪問虛擬主機,而筆者是VPN連接后,遠程登錄到VMware vSphere管理主機,通過VMware vSphere管理主機訪問虛擬主機。VPN登錄連接成功后,本地主機和VMware vSphere管理主機是一樣的,都在同一個服務器組成的局域網內,不應該無法Ping通。
5.模擬部署工程師的操作進行測試。首先通過VPN登錄服務器網絡,在本地直接Ping故障虛擬主機,的確無法Ping通。難道是VMware vSphere網絡配置的問題?嘗試通過服務器局域網中的另外一臺實體服務器Ping故障虛擬主機,也是可以Ping通的。VMware vSphere網絡配置的問題也被排除了。
至此,故障已經相當明確了,服務器局域網本地訪問是沒有任何問題,問題就聚焦在VPN登錄進來的主機。懷疑問題應該出在了出口防火墻的VPN配置上。
6.VPN是在內網中架設一臺VPN服務器。用戶連上互聯網后,通過互聯網連接VPN服務器,然后通過VPN服務器進入內網,可讓用戶通過外網訪問到內網資源。VPN連接成功,就相當于內部局域網中的一臺主機。
筆者單位的VPN服務器集成在了防火墻設備中。登錄網絡防火墻,仔細分析VPN配置,發現VPN登錄進來的用戶賬號被分配到了172.17.70.X網段。問題進一步明晰,是172.17.70.X的網段的主機無法Ping通172.17.50.X網段的故障虛擬主機。是否172.17.70.X的網段的主機也無法Ping通172.17.50.X網段的其他主機?如果同樣也無法Ping通,則問題可能出在三層轉發。結合圖1,可以判定是網絡防火墻的問題。如果可以正常Ping通,說明僅無法Ping通故障虛擬主機,則問題很可能出在網關配置。
7.VPN遠程登錄連接,在本地直接Ping172.17.50.X網段的另一臺服務器172.17.50.6,一切正常。由此可以推斷,故障是由網關配置造成的。

圖2 故障虛擬主機網絡配置
由于VPN遠程登錄后,可以Ping通172.17.50.X網段的其他主機,說明防火墻的VPN關于網絡地址分配的配置沒有問題。問題出在故障虛擬主機的網絡配置。遠程登錄到VMware vSphere管理主機,查看故障虛擬主機的網絡配置(如圖2)。故障虛擬主機的網關被錯設置成了172.17.50.253,正確的網關應該是172.17.50.254。修改網關,設置完成重新啟動,故障消失。
本次VMware虛擬主機網絡不通故障的順利解決,給我們提供了以下四點啟發。
1.Ping命令是網絡管理員的得力助手,在日常的網絡維護和故障排除中有著不可替代的作用。在使用Ping命令前,請確保被Ping主機、網絡設備(如:防火墻、路由器、三層交換機等設備)、Ping主機允許Ping包通過,否則根本無法確認網絡是否連通。
2.網絡是一個互聯互通的系統,需要放在一個系統里綜合考慮。開始筆者是排除故障虛擬主機的配置問題,最后問題又聚焦回故障主機的網絡配置,最終通過重新修改網關配置解決問題。
3.主機在同一個網段內互相訪問,無需通過網關進行轉發,網關配置出錯,將不會影響同一個網段內的主機互相訪問。主機跨網段訪問時,網關就顯得至關重要了。如果網關配置出錯,主機將數據包發往錯誤的地址,從而造成網絡不通。
4.網絡管理工作不能過于隨意,得遵循一定的規范。之所以出現上述錯誤配置,是由于筆者單位內部局域網中有部分三層交換機被網絡工程師配置成相應網段的253地址作為網關。按照常理網關配置一般不是網段的1地址就是254地址,一般網段的開始或者結尾地址是分配給網關使用,即172.17.50.1或者172.17.50.254。如果嚴格遵循這種分配規范,怎么也不會將網關錯誤配置成172.17.50.253。