DHCP協議原理及抓包分析

DHCP作用:

DHCP 全稱Dynamic Host configuration protocol 動態主機配置協議。 可以爲客戶機自動分配IP地址、子網掩碼以及缺省網DNS服務器的IP地址等TCP/IP參數 簡單來說 就是DHCP服務器上有一個數據庫, 存放着IP地址、網關、DNS等參數。 客戶端請求使用時, 服務器則負責將相應的參數分配個客戶端,避免客戶端手動指定IP地址等。特別是在一些大規模的網絡中。客戶端數目較多,使用DHCP可以方便對這些機器進行管理,爲客戶機提供TCP/IP參數配置,如IP地址、網關地址和DNS服務器等,不僅效率高,而且不存在IP地址衝突的情況現在的無線路由器默認都帶有DHCP功能,也就是說一個無線路由器同時也是一個DHCP服務器。

 

DHCP工作過程

DHCP大致流程下圖所示

 

DHCP DISCOVER: 尋找服務器

當DHCP客戶端第一次登錄網絡的時候或者是開機的時候, 此設備本機上沒有任何IP設定,就會網絡廣播尋找DHCP服務器 由於客戶端此時還不知道自己屬於哪一個網路﹐所以封包的來源地址會爲0.0.0.0, 目的地址則爲255.255.255.255,然後再附上DHCP discover的信息﹐向網路進行廣播。 網絡上每一臺安裝了TCP/IP協議的主機都會接收到這種廣播信息,但只有DHCP服務器纔會做出響應。

DHCP OFFER分配IP地址

DHCP服務器監聽到客戶端發出的DHCP Discover廣播後 會針對這個客戶端的硬件地址 (MAC)與本身的設定數據來進行下列工作:

1 到服務器的登錄文件中尋找該用戶之前是否曾經用過某個 IP ,若有且該 IP 目前無人使用,則提供此 IP 給客戶機;

2若配置文件針對該 MAC 提供額外的固定 IP (static IP) 時,則提供該固定 IP 給客戶機;

3若不符合上述兩個條件, 則隨機取用目前沒有被使用的 IP 參數給客戶端,並記錄下來。迴應給客戶端一個DHCP OFFER封包由於客戶端在開始的時候還沒有IP址﹐所以在其DHCP Discover封包內會帶有其MAC地址信息﹐並且有一個XID編號來辨別該封包﹐DHCP服務器迴應的DHCP Offer封包則會根據這些資料傳遞給要求租約的客戶。根據服務器端的設定﹐DHCP Offer封包會包含一個租約期限的信息。但這裏僅僅是分配, 客戶端還沒有真正的使用

 

DHCP REQUEST 請求使用

如果客戶端收到網路上多臺DHCP服務器的迴應﹐只會挑選其中一個DHCP Offer(通常是最先抵達的那個)並且向網路發送一個DHCP Request廣播封包,告訴所有DHCP服務器它將指定接受哪一臺服務器提供的IP位址。之所以要以廣播方式回答,是爲了通知所有的DHCP服務器,他將選擇某臺DHCP服務器所提供的IP地址, 同時,客戶端還會發送一個ARP封包, 查詢上有沒有其他機器使用該IP地址, 如果發現該IP被佔用, 客戶端會發送一個DHCP Decline封包DHCP服務器 拒絕接受其DHCP Offer,並重開始發送DHCP Discover信息

 

DHCP ACK  IP地址分配確認

DHCP服務器收到DHCP客戶機回答的DHCP Request請求信息之後, 它便向DHCP客戶機發送一個包含它提供的IP地址和其他設置的DHCP Ack確認信息。以確認IP地址的正式生效。然後DHCP客戶機便將其TCP/IP協議與網卡綁定,另外,除DHCP客戶機選中的服務器外,其他的DHCP服務器都將收回曾提供的IP地址

 

重新登錄

當DHCP客戶機分配到IP每次DHCP客戶重新登錄登錄時, 不需要發送DHCP Discover信息了,而是直接發送包含前一次所分配的IP地址的DHCP Request請求信息。當DHCP服務器收到這一信息後, 會嘗試DHCP客戶機繼續使用原來的IP地址 並回答一個DHCP Ack確認信息。 如果IP地址無法繼續在分配給原來的DHCP客戶機使用時(比如IP地址以分配給其他DHCP客戶機)則DHCP服務器DHCP客戶機回答一個DHCP NAck否認信息 原來的DHCP客戶機收到此DHCP NAck否認信息後, 必須重新發送DHCP Discover信息來重新請求信的IP地址

 

更新租約

DHCP服務器向DHCP客戶機出租的IP地址一般都有一個租借期限, 期滿DHCP服務器便會收回出租的IP地址,如果DHCP客戶機要延長其IP租約, 則必須更新其IPDHCP客戶機啓動時和IP租約期限一半時, DHCP客戶機都會自動向DHCP服務器發送其IP租約的信息 DHCP客戶機除了在開機的時候發出DHCP Request請求在外, 在使用租期超過50%時刻處,DHCP 客戶機會以單播形式向DHCP Server發送DHCP Request報文來續租IP地址。如果DHCP 客戶機成功收到DHCP 服務器發送的DHCP ACK報文,則按相應時間延長IP地址租期;如果沒有收到DHCP 服務器發送的DHCP ACK報文,則DHCP 客戶機繼續使用這個IP地址。在使用租期超過87.5%時刻處,DHCP 客戶機會以廣播形式向DHCP Server發送DHCP Request報文來續租IP地址。如果DHCP 客戶機成功收到DHCP 服務器發送的DHCP ACK報文,則按相應時間延長IP地址租期;如果沒有收到DHCP 服務器發送的DHCP ACK報文,則DHCP 客戶機繼續使用這個IP地址,直到IP地址使用租期到期時,DHCP Client纔會向DHCP Server發送DHCP Release報文來釋放這個IP地址 客戶想提前退 可以隨時發送DHCP Release命令解約

 

DHCP報文解析

報文格式



OP: 若是客戶送給服務端的封包 設置1 反方向

Htype: 硬件類型, ethernet1

Hlen: 硬件長度, ethernet6

Hops: 若數據包需要經過router發送 沒站1若在一網內爲0

Transaction ID 事物ID是個隨機數,用於客戶端和服務器之間匹配請求和相應信息

Seconeds: 由用戶指定的時間,開始地址獲取和更新進行後的時間

Flags: 從0-15bits 最高位1表示server將以廣播方式傳遞封包給client, 0 表示表示server將以方式傳遞封包給client,其餘尚未使用

Ciaddr 用戶IP地址

Siaddr: 用於bootsrtap過程中IP地址(服務器IP地址)

Chaddr:  client的硬件地址

Sname:  可選server的名稱 0x00結尾

File: 啓動文件名

Options: 廠商標識, 可選的蠶食字段

 

抓包分析

DHCP discover階段

 

DHCP offer階段

 

DHCP request階段

 

DHCP ack階段

 

總結

階段

MAC

目標MAC

IP

目標IP

Discover

PC機的MAC

FF

0.0.0.0

255.255.255.255

Offer

Dhcp服務器或者中繼器路由的MAC

Dhcp客戶機的MAC

Dhcp服務器或者中繼路由器的IP地址

準備分配的IP地址

Request

PC機的MAC

FF

0.0.0.0

255.255.255.255

Ack

Dhcp服務器或者中繼器路由的MAC

Dhcp客戶機的MAC

Dhcp服務器或者中繼路由器的IP地址

準備分配的IP地址

 

3.DHCPTransaction  ID是由客戶機產生一個隨機數獲得,不同MAC地址產生的Transaction ID不同,Transaction  ID是區分不同DHCP請求的標識

 

 

ARP 協定

  這裏我們要介紹的是 Address Resolution Protocol (ARP)ARP TCP/IP 設計者利用乙太網的廣播性質﹐設計出來的位址解釋協定。它的主要特性和優點是它的位址對應關係是動態的﹐它以查詢的方式來獲得 IP 位址和實體位址的對應。它的工作原理非常簡單﹕

1. 首先﹐每一臺主機都會在 ARP 快取緩衝區 (ARP Cache)中建立一個 ARP 表格﹐用來記錄 IP 位址和實體位址的對應關係。這個 Table 的每一筆資料會根據自身的存活時間遞減而最終消失﹐以確保資料的真實性。

2. 當發送主機有一個封包要傳送給目的主機的時候﹐並且獲得目的主機的 IP 位址﹔那發送主機會先檢查自己的 ARP 表格中有沒有該 IP 位址的實體位址對應。如果有﹐就直接使用此位址來傳送框包﹔如果沒有﹐則向網路發出一個 ARP Request 廣播封包﹐查詢目的主機的實體位址。這個封包會包含發送端的 IP 位址和實體位址資料。

3. 這時﹐網路上所有的主機都會收到這個廣播封包﹐會檢查封包的 IP 欄位是否和自己的 IP 位址一致。如果不是則忽略﹔如果是則會先將發送端的實體位址和 IP 資料更新到自己的 ARP 表格去﹐如果已經有該 IP 的對應﹐則用新資料覆蓋原來的﹔然後再回應一個 ARP Reply 封包給對方﹐告知發送主機關於自己的實體位址﹔

4. 當發送端接到 ARP Reply 之後﹐也會更新自己的 ARP 表格﹔然後就可以用此紀錄進行傳送了。

5. 如果發送端沒有得到 ARP Reply ﹐則宣告查詢失敗。

ARP 的查詢過程可參考下圖﹕


ARP 的查詢過程

  前面說的 ARP 表格﹐只有在 TCP/IP 協定被載入核心之後纔會建立﹐如果 TCP/IP 協定被卸載或關閉機器﹐那麼表格就會被清空﹔到下次協定載入或開機的時候再重新建立﹐而同時會向網路發出一個 ARP 廣播﹐告訴其它機器它的目前位址是什麼﹐以便所有機器都能保持最正確的資料。

  然而﹐ARP cache 的大小是有所限制的﹐如果超過了界限﹐那麼越長時間沒被使用過渡資料就必須清理掉﹐以騰出空間來儲存更新的資料。所以﹐當機器收到 ARP equest 封包時﹐如果查詢對象不是自己﹐則不會根據發送端位址資料來更新自己的 ARP 表格﹐而是完全忽略該封包。同時﹐每筆存在 cache 中的資料﹐都不是永久保存的﹕每筆資料再更新的時候﹐都會被賦予一個存活倒數計時值﹐如果在倒數時間到達的時候﹐該資料就會被清掉。然而﹐如果該資料在倒數時間到達之前被使用過﹐則計時值會被重新賦予。

  當然了﹐ARP 尚有一套機制來處理當 ARP 表格資料不符合實際位址資料的狀況(例如﹐在當前連線尚未結束前﹐收到目的端的位址資料更新訊息)﹔或是目的主機太忙碌而未能回答 ARP 請求等狀況。

 

 

 

 

 

 

 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章