“怎么沒網(wǎng)?Ping一下就好了!”您的Ping命令真的用對(duì)了嗎?
在對(duì)以太網(wǎng)網(wǎng)絡(luò)上的通信問題進(jìn)行故障排除時(shí),Ping命令是最廣泛使用的診斷工具之一。這種受歡迎程度是因?yàn)槊總€(gè)人都知道如何使用命令,執(zhí)行起來非常簡單。
在對(duì)通信問題進(jìn)行故障排除時(shí),我們?cè)跓o法正常工作時(shí)聽到的最常見的一句話是“但我可以ping通”,就好像這一點(diǎn)應(yīng)該作為確切的證據(jù),證明一切都按預(yù)期工作,通信服務(wù)器選擇不通信。
本文介紹了一些關(guān)于Ping命令的常見誤解,特別是如何有效地使用它,什么時(shí)候它可能不是任務(wù)的最佳工具,以及Ping的更好的替代方案(提供實(shí)際上可操作的數(shù)據(jù))。
什么是Ping命令?
在命令提示符下鍵入ping 1.1.1.1會(huì)發(fā)生什么?
Ping旨在告訴用戶主機(jī)是否可以在IP網(wǎng)絡(luò)上訪問,并通過發(fā)送ICMP(Internet控制消息協(xié)議)回應(yīng)請(qǐng)求來執(zhí)行此操作,遠(yuǎn)程主機(jī)(我們正在ping的IP地址)將在收到時(shí)回顯。
雖然這無疑是有用的,但Ping命令在它告訴我們的內(nèi)容中也非常有限,因?yàn)镮CMP位于IP協(xié)議之上(畢竟它是Internet控制消息協(xié)議)并且不需要像TCP或UDP這樣的傳輸協(xié)議。
為什么這很重要?
在Internet協(xié)議描述主機(jī)之間的通信的地方,傳輸協(xié)議(如TCP或UDP)描述了在這些主機(jī)上運(yùn)行的進(jìn)程之間的通信。如果沒有傳輸層,Ping命令將永遠(yuǎn)無法向我們提供有關(guān)遠(yuǎn)程主機(jī)的信息:
- 正在監(jiān)聽連接
- 有一個(gè)開放的接口
- 將接受我們流程的連接
- 甚至是我們想要與之溝通的合適主機(jī)
Ping命令只會(huì)告訴我們主機(jī)響應(yīng)指定IP地址的echo請(qǐng)求。
因此,Ping命令的缺點(diǎn)可以概括為命令根本沒有給我們足夠的信息來巧妙地得出控制器或網(wǎng)絡(luò)節(jié)點(diǎn)不通信的原因。那么,Ping命令的哪些替代方案在這種情況下值得考慮?
什么是Tracert命令?
Tracert命令在很大程度上起到與Ping命令相同的作用,并且只應(yīng)用于確定在指定的IP地址處是否存在響應(yīng)的內(nèi)容,僅此而已。
如果您正在ping同一子網(wǎng)上的設(shè)備,則Tracert和Ping將執(zhí)行完全相同的操作。當(dāng)ping不在同一子網(wǎng)或網(wǎng)絡(luò)上的主機(jī)時(shí),會(huì)發(fā)現(xiàn)Tracert的強(qiáng)大功能,因?yàn)樗粌H會(huì)顯示終端設(shè)備是否響應(yīng),還會(huì)顯示到達(dá)該遠(yuǎn)程主機(jī)的路由路徑。
如果Tracert在路徑中的任何特定點(diǎn)發(fā)生故障,則很容易識(shí)別通信中斷的特定位置。
Tracert通過發(fā)送與ping相同的ICMP Echo請(qǐng)求來完成此操作,但它使用“Time To Live”字段來控制消息可以跳轉(zhuǎn)的距離。第一個(gè)數(shù)據(jù)包以TTL為1發(fā)送,路徑中的第一個(gè)跳轉(zhuǎn)將減少為0,并以“Time to live exceeded in transit/運(yùn)行中的超時(shí)時(shí)間”響應(yīng),這有助于我們的機(jī)器現(xiàn)在知道第一個(gè)跳轉(zhuǎn)的IP地址路由路徑。
然后以TTL為2發(fā)送第二個(gè)回應(yīng)請(qǐng)求,以便消息可以在超時(shí)之前到達(dá)路徑中的第二跳。然后是3的TTL,4的TTL,依此類推,直到我們得到Echo響應(yīng),并且我們知道'ping'數(shù)據(jù)包已經(jīng)到達(dá)我們?cè)噲D到達(dá)的目標(biāo)節(jié)點(diǎn)。
就像ping一樣,Tracert結(jié)果告訴我們?cè)谶h(yuǎn)程主機(jī)上是否有運(yùn)行的應(yīng)用程序/固件/通信模塊能夠與我們通信 - 只是遠(yuǎn)程主機(jī)支持IP并且可以訪問。
因此,我們現(xiàn)在已經(jīng)確定,在許多情況下,Ping和Tracert命令在解決通信問題的有效性方面基本相同。我們還能嘗試什么?
什么是Portqry實(shí)用程序?
如果Ping命令沒有給我們?nèi)魏慰刹僮鞯臄?shù)據(jù),并且Tracert命令沒有給我們?nèi)魏慰刹僮鞯臄?shù)據(jù), 我們?nèi)绾蔚玫揭恍┪覀兛梢杂脕泶_定設(shè)備是否正在監(jiān)聽連接以及通信問題可能是什么是?這個(gè)問題將我們帶到PortQryUI--一個(gè)可從Microsoft下載的實(shí)用工具。
雖然它沒有預(yù)先安裝Windows,但PortQryUI是一個(gè)非常輕量級(jí)的實(shí)用程序,不僅可用于識(shí)別主機(jī)是否可訪問,還可用于確定在該主機(jī)上運(yùn)行的進(jìn)程是否可訪問和/或是否愿意接受連接。
知道1.1.1.1是DNS服務(wù)器,正如我們之前建立的那樣,讓我們??針對(duì)DNS端口53運(yùn)行Portqry。
我們可以看到,首先,Portqry嘗試在使用TCP和UDP查詢端口之前將IP地址解析為DNS主機(jī)名(在此處成功完成 - “one.one.one.one”),并且因?yàn)閷?shí)用程序知道53是DNS端口,它也向端口發(fā)送DNS查詢。
Portqry有三種可能的結(jié)果:
- 正在監(jiān)聽 - 該實(shí)用程序得到了端口的積極回應(yīng)
- 不監(jiān)聽 - 該實(shí)用程序收到了端口的回復(fù),告訴我們要離開
- 已過濾 - 該實(shí)用程序未收到來自端口的任何響應(yīng),無論是正面還是負(fù)面
現(xiàn)在讓我們?cè)趯?shí)驗(yàn)室中使用本地Modbus PLC進(jìn)行嘗試,我們知道這可以通過端口502(默認(rèn)的Modbus端口)看到連接請(qǐng)求。
這次我掃描一系列端口502-503,仍然要求檢查TCP和UDP。
結(jié)果并不令人驚訝; 主機(jī)名稱解析失敗,因?yàn)樗皇且粋€(gè)PLC(雖然它沒有超出PLC分配DNS名稱的可能性的范圍,大多數(shù)不是),并且查詢結(jié)果確實(shí)顯示有一個(gè)進(jìn)程在端口502上偵聽傳入的TCP連接。
現(xiàn)在,顯然,我們實(shí)驗(yàn)室中的Modbus PLC沒有任何通信問題。但是,您現(xiàn)在可以想象,當(dāng)Portqry實(shí)用程序以“Not Listening”或“Filtered”響應(yīng)端口和傳輸時(shí),對(duì)于無響應(yīng)的設(shè)備有多么有用,我們希望在正常通信情況下能夠得到肯定的響應(yīng)。
但是,如果我們從Portqry得到積極響應(yīng)但仍然沒有成功通信,我們還能做些什么呢?
什么是Netstat?
雖然Netstat命令不提供遠(yuǎn)程設(shè)備接受連接的能力的信息,或者遠(yuǎn)程主機(jī)是否可以在網(wǎng)絡(luò)上訪問,但在查看本地計(jì)算機(jī)上的套接字狀態(tài)時(shí),它是非常寶貴的資源。
運(yùn)行簡單的netstat枚舉本地套接字信息,顯示本地和遠(yuǎn)程地址,套接字狀態(tài)以及與該主題關(guān)聯(lián)的進(jìn)程ID(在想要跟蹤哪個(gè)應(yīng)用程序正在使用端口時(shí)特別有用)。在對(duì)PLC的連接問題進(jìn)行故障排除時(shí),套接字狀態(tài)將是最有用的列,因?yàn)樗梢陨钊肓私獍l(fā)生問題的連接順序。過濾后(使用FIND)可以輕松過濾任何關(guān)鍵字的Netstat列表; 包括IP地址和端口:
在解釋Socket狀態(tài)時(shí),至少在一般情況下 - 理解TCP狀態(tài)圖以查看錯(cuò)誤發(fā)生在連接序列中的哪個(gè)位置。毫無疑問,這是有用的,只是觸及netstat能夠表達(dá)的表面,建議運(yùn)行netstat /?查看所有可用選項(xiàng)。
什么是Wireshark?
如果所有其他方法都失敗了,并且上面的工具顯示一切都應(yīng)該工作,那么Wireshark就是我們的首選診斷工具。Wireshark將捕獲網(wǎng)卡上的所有流量,并將向我們顯示目標(biāo)設(shè)備與我們的計(jì)算機(jī)之間究竟發(fā)生了什么。
因此,雖然Ping命令肯定有其作為一個(gè)非?;镜墓收吓懦ぞ撸粦?yīng)該被誤認(rèn)為是一個(gè)完成所有工作的工具。