正文

上鏡像會被抓嗎（上鏡像會被抓嗎視頻）

發(fā)布時間：2023-03-14 02:10:22 稿源：創(chuàng)意嶺閱讀： 110 問大家

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于上鏡像會被抓嗎的問題，以下是小編對此問題的歸納整理，讓我們一起來看看吧。

ChatGPT國內(nèi)免費在線使用，一鍵生成原創(chuàng)文章、方案、文案、工作計劃、工作報告、論文、代碼、作文、做題和對話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準，寫出的就越詳細，有微信小程序端、在線網(wǎng)頁版、PC客戶端

官網(wǎng)：https://ai.de1919.com

本文目錄:

1、為什么交換機抓包要開啟鏡像端口
2、交換機中作為鏡像端口的話，只能抓取來往的包，不能對外進行通信是吧
3、本本帶的原裝win7是32位的，想升級到64位的，但是還想把硬盤上的那個正版的32位系統(tǒng)的安裝鏡像抓出來
4、添加遠程鏡像丟包

上鏡像會被抓嗎（上鏡像會被抓嗎視頻）

一、為什么交換機抓包要開啟鏡像端口

鏡像口，是整個交換機的數(shù)據(jù)量的鏡像，單一交換機口，是按 ACL 來訪問的。

ACL 的主要作用是過濾掉外面沒有授權(quán)的IP地址來訪問內(nèi)部的資源從而做到讓內(nèi)部主機或服務器更安全。簡而言之，ACL可以過濾網(wǎng)絡中的流量，是控制訪問的一種網(wǎng)絡技術(shù)手段。

因ACL 的存在，你抓的包就不完全了。失去了網(wǎng)絡監(jiān)控的意義。

而鏡像口正是為解決此問題而存在的。

二、交換機中作為鏡像端口的話，只能抓取來往的包，不能對外進行通信是吧

上鏡像會被抓嗎（上鏡像會被抓嗎視頻）

端口鏡像（port Mirroring）功能通過在交換機或路由器上，將一個或多個源端口的數(shù)據(jù)流量轉(zhuǎn)發(fā)到某一個指定端口來實現(xiàn)對網(wǎng)絡的監(jiān)聽，指定端口稱之為“鏡像端口”或“目的端口”，在不嚴重影響源端口正常吞吐流量的情況下，可以通過鏡像端口對網(wǎng)絡的流量進行監(jiān)控分析。在企業(yè)中用鏡像功能，可以很好地對企業(yè)內(nèi)部的網(wǎng)絡數(shù)據(jù)進行監(jiān)控管理，在網(wǎng)絡出故障的時候，可以快速地定位故障。

也是可以進行通信的。不過這個鏡像端口上肯定連接的是監(jiān)控主機或者設備，不會用于普通終端的連接吧。

三、本本帶的原裝win7是32位的，想升級到64位的，但是還想把硬盤上的那個正版的32位系統(tǒng)的安裝鏡像抓出來

用GHOST手動作個鏡像保留起來吧

四、添加遠程鏡像丟包

一天，有同事反映，他的內(nèi)網(wǎng)服務器192.168.193.254訪問北京總部的資源172.16.1.1無法正常訪問，ping測試發(fā)現(xiàn)丟包嚴重，有很多發(fā)包request沒有得到響應reply，懷疑丟在環(huán)境里，讓給排查一下。ping測試在服務器上用tcpdump看如下圖：

可以看到很多發(fā)出的request沒有回包，中間部分有回包。沒有回包的，他認為這些沒響應的ping請求包丟在公司路徑里了，導致總部沒有回包。

和他確定組網(wǎng)如下：

ros路由器通過vpn連接北京的資源172.16.1.1。

處理思路：

發(fā)包丟包常見原因：

一個計算機網(wǎng)絡模型不外乎，終端設備，節(jié)點設備，傳輸鏈路，目的設備?？赡苡邪l(fā)的不對，回的不對，或者路徑節(jié)點和通信鏈路的原因。

1、傳輸質(zhì)量不好，或者擁塞，經(jīng)過節(jié)點設備收到大量轉(zhuǎn)發(fā)的包，而超出轉(zhuǎn)發(fā)端口的最大速率，導致丟棄一部分包。

2、環(huán)境中存在節(jié)點ip沖突或者mac沖突，導致一部分發(fā)包發(fā)給錯誤mac，導致正常路徑?jīng)]有收到包。

3、和第二種情況類似，有的設備有多個網(wǎng)卡，配置有不同的ip地址，當接在同一交換機下，會出現(xiàn)響應目的ip是另一個網(wǎng)卡ip的arp請求的情況，導致ping的request發(fā)給另一個mac地址，而這個網(wǎng)卡不是自己所屬ip，可能不回ping的reply消息，造成源設備打印time out。

4、自身或者經(jīng)過節(jié)點設備路由配置錯誤，導致發(fā)給另一個節(jié)點ip而這個節(jié)點沒有轉(zhuǎn)發(fā)功能，ping的request被終止在設備里，而導致丟包。

ping丟包，可以由上逐個節(jié)點跟蹤抓包，和源設備抓包比對，利用ping的發(fā)出request的序號來判斷丟了那些包？第3種很少見，我們就判斷是否屬于上面124三種情況中的一種，丟在那個范圍節(jié)點了。

看組網(wǎng)，自己pc去ping172.16.1.1，看到很少有丟包，如下圖：

排除原因1的可能性，判斷一下是否是2,4的原因？

很奇怪，為啥他的ping丟包這么厲害，決定從上到下ros到核心交換機逐級抓包，看看丟在哪一級了？

在出口ros上抓包，看到ping的包序號不連續(xù)，上來的ping的request消息均收到了目的方回復的reply消息，判斷是很多ping的request消息沒有發(fā)到ros導致，沒有丟在ros路由器側(cè)。服務器側(cè)看到發(fā)出的ping的seq連續(xù)，而ros出口看到只有很少一部分，序號也不連續(xù)。

如上圖：

但同事的抓包文件里顯示發(fā)出ping的序號是連續(xù)的

決定鏡像抓一下機柜匯聚交換機到核心交換機間的包看看，發(fā)出來的是否有問題？

發(fā)現(xiàn)序號不連續(xù)，過來的ping的request均收到回包。判斷測試交換機發(fā)出的ping消息的request消息已經(jīng)丟了好多。排除原因2，查看服務器的配置，看是否是原因4？

覺得交換機丟包的可能性不大，到服務器上192.168.192.254上去看看？

看ip配置

執(zhí)行route -n查看路由表的情況？

看到如上圖中有兩個0.0.0.0的路由表項，配置有兩個默認路由，而且metric等級一樣！

決定執(zhí)行tcpdump -i any -nne icmp 看看發(fā)出的mac地址，另起一個putty進行ping看看。

發(fā)現(xiàn)有一部分ping request發(fā)向了另一mac地址，這些request都沒有返回ping的reply消息。

發(fā)現(xiàn)發(fā)給fa:16:3e:1c:fd:81的ping的request消息都沒有收到reply消息。

而發(fā)給c8:50:e9:67:fa:0c卻收到的reply消息，檢查一下這兩個mac對應的ip地址。

檢查這兩個mac地址：

由mac地址表對應關(guān)系看出，雙路由導致發(fā)給192.168.193.116的mac地址的包沒有收到響應reply消息。

同事反饋，116那條路由是過去測試虛擬機臨時加的，不能上外網(wǎng)，現(xiàn)在不使用。所以刪掉路由route del -net 0.0.0.0/0 gw 192.168.193.116后，ping的抓包后正常。

如上圖：ping的request和回包reply里目的和源mac地址互換，都正常有回包。

知識點：

1，ros路由器可以指定mangle里tzsp端口進行抓包。

2，ping消息含序號，用來確定是那一包。

3，Tcpdump命令查看mac地址用-enn，但當使用-i any時，因為沒有指定端口無法獲取收發(fā)雙方的mac地址。

4，交換機一般不會引起丟包。

5，這種丟包問題，要么發(fā)的時候，有一部分發(fā)錯地方，要么傳輸中丟了，要么目的ip沒收到，目的網(wǎng)關(guān)轉(zhuǎn)發(fā)的時候，有一部分發(fā)給了另一個mac地址，要么是收的沒問題沒有丟包，但會響應發(fā)給了錯誤的地方。總之，源設備長ping嗎，在源和目的兩邊都抓包，對比ping的request消息里攜帶的序號，和沒有收到reply包的序號，確定丟在那個環(huán)節(jié)。檢查對應的環(huán)節(jié)就行了

以上就是關(guān)于上鏡像會被抓嗎相關(guān)問題的回答。希望能幫到你，如有更多相關(guān)問題，您也可以聯(lián)系我們的客服進行咨詢，客服也會為您講解更多精彩的知識和內(nèi)容。