ARP協議的探測原理_ARP原理

ARP（Address Resolution Protool)協議是地址解析協議的縮寫。 以太網中， 一個主機要和另

臺主機進行通信， 必須要知道目標主機的MAC地址， 而網絡傳輸的數據幀里面就包含目的主機

MAC地址。 這個目的MAC地址由ARP協議獲得， 地址解析的過程就是主機在發送幀前， 將目

IP地址作為參數， 獲取目標MAC地址的過程。 主機首先檢查ARP映射表， 看是否有與目的IPx

應的MAC地址。 如果檢查到了匹配的MAC地址， 則將該地址封裝到數據幀中并送到輸出隊列等

待發送。 如果沒有找到匹配的MAC地址， 則發送一個含有目的節點IP地址的廣播包來詢問該Ⅱ

對應的MAC地址。 目標節點收到該廣播包后會給源節點發送ARP應答， 告訴源節點它的MAC地

址。 源節點收到ARP應答后， 會更新它的ARP映射緩存。

在Windows中， 可以利用SendARPAPI函數獲知某IP地址（函數的輸入）對應主機的MAC地

址， 若該IP是死點， 則該函數返回錯誤值， 也就能判斷某IP是否為死點。 在調用SemdARP前， 必須

調用FlushlpNetTableAPl函數清除主機的ARP緩存。 ARP協議有一個特點：ARP數據包不能跨越

路由器。 而在CIN中， 眾多的子網是由路由器或具有路由功能的高端交換機分隔開的， 因此， 只能

在同一個子網（稱為網段）使用ARP協議探測其他IP。 為了解決該問題， 我們利用認證成功的認

證Agent作為我們的探測代理。 原理如下控制中心負責探測與其同一網段的其他IP， 對于其他的

我的手機 2017/9/14 9:48:05

各個網段， 控制中心搜尋相應認證成功的認證Aent作為探測代理， 由后者負責探測與之同一網段

的其他IP信息， 探測完畢后轉發給控制中心。 在此過程中， 控制中心負責搜尋探測代理， 發送探測

任務及參數， 接收探測結果并顯示在人機界面中， 若探測某主機未受監控， 則采取相關措施懲罰該

用戶。

我們前面提到， 在探測到某IP是活動節點后， 由控制中心（實際上是自檢測保護服務的

Scanner)或探測代理（稱為Spy）發送加密信息給該節點， 在CINSS中， 加密密鑰就是用戶登錄密碼

相關的hash值， 只被用戶、該節點認證成功的認證Agent、控制中心所擁有。 在認證Agent 接收到該

加密信息后， 利用加密密鑰響應。 這和我們前面論述的認證Agent六種認證狀態聯系起來， 在未認

證成功前， 認證Agent不可能真正擁有加密密鑰， 即使在自動認證過程中所試用的加密密鑰也是未

被驗證的。 因此， 未認證成功的認證Agent不可能正確地響應， 這滿足網絡通信的安全性要求。 正

是基于這種考慮， 我們要求未認證成功的認證Agent阻塞所有的數據包， 包括ARP包， 使其“看起

來”是一個死點。 但這又產生一個新問題， 因為ARP包被阻塞， 認證Agent無法進行認證。 我們在

前面定義的控制代碼負責暫時放行正在認證狀態時的認證數據包， 一旦認證結束， 重新阻塞所有

的數據包。 在正在認證的過程中， 若該IP被探測， 此時認證Agent尚未認證結束， 這樣就會導致其

被誤認為非控節點。 因此， 通過兩次SendARP的使用可以解決該問題， CINSS固定地設置認證持續

時間為5秒， 這在高寬帶的CIN中已經是非常久的時間， 設置兩次認證間隔時間必須大于60秒， 設

置Scanner與Spy等待響應的時間為10秒。 若在第一次SemdARP時探測某IP是活動節點， 其間該

節點的認證Agent認證成功， 則能正確響應， 若認證失敗， 則節點的ARP包被阻塞， 第二次SendARP

必然失敗， 這樣該節點不會被認為是非控節點。 現在只剩下最后一個問題：在探測到非控節點后，

如何對其進行懲罰， 我們利用ARP欺騙方法實現之。