[圖解]ARP協議(一)
一、ARP概述
如果要在TCP/IP協議棧中選擇一個"最不安全的協議",那麽我會毫不猶豫把票投給ARP協議。我們經常聽到的這些術語,包括"網絡掃描"、"內網滲透"、"中間人攔截"、"局域網流控"、"流量欺騙",基本都跟ARP脫不了幹系。大量的安全工具,例如大名鼎鼎的Cain、功能完備的Ettercap、操作傻瓜式的P2P終結者,底層都要基於ARP實現。
聽上去這麽"逆天"的協議,其實技術原理又簡單的難以置信,例如ARP整個完整交互過程僅需要兩個包,一問一答即可搞定!但是ARP協議也有它令初學者迷惑的地方,例如由它本身延伸出來的"代理ARP"、"免費ARP"、"翻轉ARP"、"逆向ARP",而這些不同種類的ARP,又應用於不同的場景。好吧,在深入到技術原理之前,作為初學者,我們先記住下面三句話:
①ARP(Address Resolution Protocol)即地址解析協議, 用於實現從 IP 地址到 MAC 地址的映射,即詢問目標IP對應的MAC地址。
②在網絡通信中,主機和主機通信的數據包需要依據OSI模型從上到下進行數據封裝,當數據封裝完整後,再向外發出。所以在局域網的通信中,不僅需要源目IP地址的封裝,也需要源目MAC的封裝。
③一般情況下,上層應用程序更多關心IP地址而不關心MAC地址,所以需要通過ARP協議來獲知目的主機的MAC地址,完成數據封裝。
接下來,我們通過圖解的方式來深入了解ARP協議是如何工作的。
二、ARP原理之請求應答
同一個局域網裏面,當PC1需要跟PC2進行通信時,此時PC1是如何處理的?
根據OSI數據封裝順序,發送方會自頂向下(從應用層到物理層)封裝數據,然後發送出去,這裏以PC1 ping PC2的過程舉例==>
PC1封裝數據並且對外發送數據時,上圖中出現了"failed",即數據封裝失敗了,為什麽?
我們給PC1指令-"ping ip2",這就告知了目的IP,此時PC1便有了通信需要的源目IP地址,但是PC1仍然沒有通信需要的目的MAC地址。這就好比我們要寄一個快遞,如果在快遞單上僅僅寫了收件人的姓名(IP),卻沒有寫收件人的地址(MAC),那麽這個快遞就沒法寄出,因為信息不完整。
那麽,現在PC1已經有了PC2的IP地址信息,如何獲取到PC2的MAC地址呢?此時,ARP協議就派上用場了。我們接著上面這張圖,繼續==>
通過第三和第四步驟,我們看到PC1和PC2進行了一次ARP請求和回復過程,通過這個交互工程,PC1便具備了PC2的MAC地址信息。
接下來PC1會怎麽做呢?在真正進行通信之前,PC1還會將PC2的MAC信息放入本地的【ARP緩存表】,表裏面放置了IP和MAC地址的映射信息,例如 IP2<->MAC2。接下來,PC1再次進行數據封裝,正式進入PING通信,如下==>
小結:經過上面6個步驟的處理,PC1終於把數據包發送出去了,之後便可以進行正常的通信了。看到了吧,ARP的功能和實現過程是如此的簡單:它在發送方需要目標MAC地址的時及時出手,通過"一問一答"的方式獲取到特定IP對應的MAC地址,然後存儲到本地【ARP緩存表】,後續需要的話,就到這裏查找。
既然是"緩存"表,意味著它有時效性,並且如果電腦或者通信設備重啟的話,這張表就會清空;也就是說,如果下次需要通信,又需要進行ARP請求。在我們的windows/macos系統下,可以通過命令行"arp -a"查看具體信息=>
三、ARP原理之廣播請求單播回應
上面的圖解過程看上去簡單又純粹,好像我們就已經把這個協議的精髓全部get到,但其實,我們只是剛揭開了它的面紗,接下來我們才真正進入正題。例如,上面的圖解過程中,整個局域網(LAN)只有PC1和PC2兩個主機,所以這個一問一答過程非常的順暢。
而實際網絡中,這個LAN可能有幾十上百的主機,那麽請問,PC1如何將這個【ARP請求包】順利的交給PC2,而PC2又如何順利的把【ARP回應包】返回給PC1? 我們看下面的圖:
為了營造出"幾十上百"的效果,這裏多添加了2個主機進來 ( ω ),並且增加了有線和無線的環境。那麽,在多主機環境下,PC1現在發出的ARP請求包,怎麽交到PC2手裏?
這時,ARP協議就需要采用以太網的"廣播"功能:將請求包以廣播的形式發送,交換機或WiFi設備(無線路由器)收到廣播包時,會將此數據發給同一局域網的其他所有主機。
那麽,什麽是廣播?對於初學者而言,我們只需要知道,大部分的廣播包,它們有一個共同特征:二層封裝時目的MAC是全f(ffff.ffff.ffff)或三層封裝時目的IP是全1(255.255.255.255)。可以這樣更方便的記住:目的地址最大的,就是廣播。
註明:廣播根據所在層次可分為二層廣播和三層廣播,根據發生範圍可分為本地廣播和定向廣播,小夥伴們有興趣可以自己再去拓展下。
接下來我們來看下這個ARP廣播請求包接下來是如何工作的?
根據上圖我們看到,PC1發送的請求廣播包同時被其他主機收到,然後PC3和PC4收到之後(發現不是問自己)則丟棄。而PC2收到之後,根據請求包裏面的信息(有自己的IP地址),判斷是給自己的,所以不會做丟棄動作,而是返回ARP回應包。
ARP請求是通過廣播方式來實現的,那麽,PC2返回ARP回應包,是否也需要通過廣播來實現呢?答案是否定的。大部分網絡協議在設計的時候,都需要保持極度克制,不需要的交互就砍掉,能合並的信息就合並,能不用廣播就用單播,以此讓帶寬變得更多讓網絡變得更快。
那麽,ARP回應包是如何處理的?這裏需要特別關註ARP請求包的內容,在上面的圖解裏面,ARP請求包的完整信息是:我的IP地址是IP1,MAC地址是MAC1,請問誰是PC2,你的IP2對應的MAC地址是多少?
簡單來說,ARP請求首先有"自我介紹",然後才是詢問。這樣的話,PC2在收到請求之後,就可以將PC1的IP和MAC映射信息存儲在本地的【ARP緩存表】,既然知道PC1在哪裏,就可以返回ARP單播回應包。
這張圖我們需要得到兩個信息:①被詢問者PC2先生成了ARP映射信息,然後才是詢問者PC1;②PC3和PC4等其他主機,無法收到這個ARP回應包,因為是單播形式。
小結:ARP協議通過"一問一答"實現交互,但是"問"和"答"都有講究,"問"是通過廣播形式實現,"答"是通過單播形式。
四、ARP數據包解讀
為了讓大家更好的理解ARP協議以及廣播和單播的概念,我們來看一下用Wireshark抓取到的真實網絡中的ARP過程,通過數據包的方式來呈現,地址信息如下,部分MAC信息隱去。(建議初學者用GNS3配合Wireshark來抓取協議包進行分析,相比真實網絡更加幹凈,方便分析)
主機1 <---> 主機2
主機1: IP1 10.1.20.64 MAC1:00:08:ca:xx:xx:xx
主機2: IP2 10.1.20.109 MAC2:44:6d:57:xx:xx:xx
【ARP請求包】
【ARP回應包】
【ARP協議字段解讀】
Hardware type :硬件類型,標識鏈路層協議
Protocol type: 協議類型,標識網絡層協議
Hardware size :硬件地址大小,標識MAC地址長度,這裏是6個字節(48bti)
Protocol size: 協議地址大小,標識IP地址長度,這裏是4個字節(32bit)
Opcode: 操作代碼,標識ARP數據包類型,1表示請求,2表示回應
Sender MAC address :發送者MAC
Sender IP address :發送者IP
Target MAC address :目標MAC,此處全0表示在請求
Target IP address: 目標IP
五、ARP到底是鏈路層還是網絡層?
這個問題的難度堪比另外一個世界級難題:世界上最好的編程語言是什麽?
其實早在20世紀時,W.Richard Stevens在《TCP/IP詳解卷一》裏面就提到了這個難題。這裏給出我個人的協議分層思路,給大家作為參考=>
協議到底所屬哪一層,可以從應用/功能來考慮,也可以從層次/包封裝來考慮。
以ARP協議為例,它的功能最終是獲取到MAC信息,服務於鏈路層,從這點考慮,ARP是鏈路層協議;但是從層次來看,ARP基於Ethernet協議,IP協議基於Ethernet協議,它們在Ethernet協議裏面有獨立的Type類型,前者是0x0806,後者是0x0800,既然ARP和IP協議"平起平坐",那麽IP是網絡層,ARP難道就不是網絡層?
小結:基於功能來考慮,ARP是鏈路層協議;基於分層/包封裝來考慮,ARP是網絡層協議。(此方法對於ICMP協議同樣管用)
推薦課程:《TCP/IP協議棧精講》
本文出自 “陳鑫傑講網絡與安全” 博客,請務必保留此出處http://chenxinjie.blog.51cto.com/7749507/1959191
[圖解]ARP協議(一)