案例背景
1、業(yè)務訪問流程
納稅人通過互聯(lián)網(wǎng)登陸網(wǎng)上申報服務器，提交相關納稅信息；
網(wǎng)上申報服務器將這些納稅信息轉發(fā)給前置機的同時，將相關信息寫入征管服務器數(shù)據(jù)庫；
網(wǎng)上申報服務器與前置機的數(shù)據(jù)交互出現(xiàn)問題，那么網(wǎng)上申報服務器會將征管服務器數(shù)據(jù)庫相關的信息鎖死。
2、故障現(xiàn)象
網(wǎng)上申報業(yè)務系統(tǒng)運行時，每天總有一部分納稅人的申報表單數(shù)據(jù)無法正常上傳，通過征管服務器的業(yè)務軟件可發(fā)現(xiàn)這些用戶的申報數(shù)據(jù)處于鎖狀態(tài)；
在沒有網(wǎng)閘的情況下，網(wǎng)上申報服務器與前置機直接通訊，則故障現(xiàn)象消失，網(wǎng)上納稅全部正常。
3、網(wǎng)上申報服務器的地址是192.168.1.1，經(jīng)過網(wǎng)閘后轉換為X.X.16.73，前置機的IP地址為X.X.16.56，征管服務器的IP地址為X.X.16.200。網(wǎng)絡拓撲圖如下：
案例分析
結合故障現(xiàn)象與業(yè)務流程，我們可以清晰的發(fā)現(xiàn)，問題應該出現(xiàn)在網(wǎng)上申報服務器經(jīng)過網(wǎng)閘的地址轉換后與前置機交互的過程中。網(wǎng)閘是最為可疑的故障關鍵點，遂在網(wǎng)閘前后部署網(wǎng)絡分析系統(tǒng)（在此環(huán)境下，可直接在申報服務器上和前置機上分別安裝網(wǎng)絡分析系統(tǒng)），對網(wǎng)上申報業(yè)務數(shù)據(jù)交互過程分別進行抓包。
通過科來網(wǎng)絡分析系統(tǒng)捕獲前置機交互的數(shù)據(jù)包，一段時間后，我們在“TCP會話” 視圖中，發(fā)現(xiàn)某些TCP會話持續(xù)時間比一般TCP會話長很多（這是跟正常情況下的業(yè)務會話持續(xù)時間對比發(fā)現(xiàn)，屬于對比分析法應用方式的一種）。打開其中一個TCP會話，查看其詳細的數(shù)據(jù)包視圖，以了解其具體交互過程。
網(wǎng)閘地址73首先發(fā)送reset報文，后網(wǎng)閘地址向前置機發(fā)送（重傳）報文，前置機直接發(fā)送reset報文重置連接。這個過程，導致該TCP會話持續(xù)時間很長。我們還發(fā)現(xiàn)這些TCP會話中，存在大量的TCP重置報文，且第一個發(fā)送reset報文的是網(wǎng)閘的IP地址。
網(wǎng)閘為什么會突然給前置機發(fā)送reset報文呢？我們查看這個reset報文的詳細解碼視圖，發(fā)現(xiàn)這個數(shù)據(jù)報文的源MAC地址并非網(wǎng)閘的MAC，真實的網(wǎng)閘MAC地址是00:40:63:EF:43:DF，而這個數(shù)據(jù)報文的源MAC地址卻是00:21:5E:82:AF:86，難道是網(wǎng)內(nèi)存在某些設備針對該業(yè)務數(shù)據(jù)進行會話劫持攻擊？通過進一步的分析，在這個reset報文之前，是前置機發(fā)送給網(wǎng)閘地址的確認報文，這個報文封裝的目的MAC地址就是00:21:5E:82:AF:86。
前置機為什么會在數(shù)據(jù)交互的過程中，突然出現(xiàn)這種狀況呢？一般而言，主機是根據(jù)其ARP表項來封裝要發(fā)送的數(shù)據(jù)報文的目的MAC地址，那么，這里前置機發(fā)往網(wǎng)閘數(shù)據(jù)報文的目的MAC地址出現(xiàn)改變是否是因為前置機的ARP表項內(nèi)容變化了呢？我們在前置機的DOS窗口下，使用arp –a命令查看異常時的ARP表項內(nèi)容，發(fā)現(xiàn)網(wǎng)閘IP對應的MAC地址的確變成了00:21:5E:82:AF:86。
Internet Address Physical Address Type
X.X.16.73 00-21-5E-82-AF-86 dynamic
能夠導致ARP表項更新的只可能是ARP報文，是前置機收到ARP欺騙報文導致了ARP表項的更新嗎？由于前面都是針對TCP層面的數(shù)據(jù)交互來分析的，看不到ARP報文，因此我們決定在科來網(wǎng)絡分析系統(tǒng)的“數(shù)據(jù)包”視圖查看交互過程的所有數(shù)據(jù)報文。我們發(fā)現(xiàn)在網(wǎng)閘向前置機發(fā)送連接請求之后，前置機立即向網(wǎng)絡中發(fā)送ARP請求，請求網(wǎng)閘IP對應的MAC；在網(wǎng)閘響應了前置機的ARP請求之后，前置機開始與網(wǎng)閘進行TCP三次握手交互；這是，來自MAC地址為00-21-5E-82-AF-86的ARP響應到達了前置機，前置機更新其ARP表項，以后，前置機在收到來自網(wǎng)閘的數(shù)據(jù)報文之后，都向00-21-5E-82-AF-86地址發(fā)送確認報文。
為了便于大家理解，我們將這個交互過程中，網(wǎng)閘、前置機以及未知設備的數(shù)據(jù)交互情況和狀態(tài)變化做一個圖示，如下：
通過上面的圖示，我們可以清楚的看到，導致該業(yè)務故障的原因是網(wǎng)絡內(nèi)有一臺設備使用了和網(wǎng)閘一樣的IP地址。
另外，我們分析前置機的狀態(tài)，可以知道，前置機之所以會在交互的過程中向網(wǎng)絡內(nèi)發(fā)送目的IP為網(wǎng)閘的ARP請求報文，是因為前置機ARP表中網(wǎng)閘IP的ARP表項老化。在前置機ARP表中網(wǎng)閘IP的ARP表項未老化之前，網(wǎng)閘與前置機交互數(shù)據(jù)時是正常的，而網(wǎng)閘與前置機的業(yè)務數(shù)據(jù)交互間隔時間是隨機的（這決定于網(wǎng)上納稅用戶登錄網(wǎng)上申報服務器提交納稅信息的時間），這就可以解釋為什么是部分網(wǎng)上申報業(yè)務表單出現(xiàn)異常。
網(wǎng)絡內(nèi)有2臺設備使用了同一個IP地址，應該很容易被發(fā)現(xiàn)，為什么一直沒有被發(fā)現(xiàn)呢？其實，這是因為網(wǎng)閘的這個IP只有網(wǎng)上申報業(yè)務使用，而那個未知的網(wǎng)絡設備設置的這個IP，很可能僅僅是用來管理的，這個設備長期在線，又很少有人管理（至少信息中心的人都不知道該設備的存在），因此不會主動向網(wǎng)絡中發(fā)送ARP報文，不會影響到網(wǎng)絡內(nèi)其他主機和應用的正常運行。但是，它會響應其他主機對它IP地址的ARP請求。我們可以通過交換機的MAC地址表找到這個設備所在的位置。
分析結論及解決方法
此次業(yè)務故障的原因完全跟網(wǎng)閘無關，是由于內(nèi)網(wǎng)一臺MAC地址為00:21:5E:82:AF:86的設備和網(wǎng)閘映射的地址沖突導致的。
問題原因定位之后，我們至少可以通過以下三種方式解決該故障：
1、由于是ARP表更新導致的，我們可以手動綁定網(wǎng)閘的ARP，或者修改注冊表，將前置機的ARP表老化時間調(diào)大。
2、找出使用了網(wǎng)閘映射IP的設備，修改該設備的IP地址；修改網(wǎng)上申報服務器通過網(wǎng)閘后映射的IP地址。
3、還可以讓該業(yè)務系統(tǒng)在應用層面設置一個檢測模塊，當發(fā)現(xiàn)有表單提交異常時，等待一段時間，重新向前置機提交表單。
總結：在剛接觸到這個故障時，以為是網(wǎng)閘的原因導致的故障，但是通過數(shù)據(jù)包分析后我們發(fā)現(xiàn)是由于網(wǎng)絡中有IP地址沖突導致的故障，所以在接觸到故障時，不要主觀臆測故障原因，而是要通過分析的手段找到根本的原因，以便提高故障解決的效率。
