DHCP (Dynamic Host Configuration Protocol )協議的探討與分析

問題背景

最近在作業中遇到了連接外網的交換機在IPv6地址條件下從運營商自動獲取的DNS地址與本機手動輸入配置的IPv4地址下的DNS發生沖突的問題，這個問題在實際的生產網上會帶來業務的中斷和不穩定，在進入到生產環境中的本地終端發送給資料中心的網路流量會因為IPv4 和 IPv6 下的DNS沖突而導致無法正確的發送流量，

在終端中，默認的IPv6 的優先級會大于IPv4的優先級，這樣就會帶來沖突問題，解決的問題就是將連接外網的網路線從與連接內網的交換機中斷開即可以解決，下邊的圖片說明了該問題的發生的場景:

從上邊的圖看出，業務終端連接著“本地業務網核心交換機”來獲取和轉發網路流量到資料中心生產網路中的服務器，在正常的條件下，“本地業務網核心交換機”和“本地運營商交換機”是不能通過網路跳線連接在一起并配置到同一個Vlan中的，在本次問題中，因為“本地運營商交換機”和“本地業務網核心交換機”連接在了同一個Vlan，導致了業務終端的業務流量從資料中心生產網路來源的不穩定，而造成了業務不穩定，

在這個解決問題的程序中，有DHCP和ARP在實際網路環境下的運用場景和背景模糊不清的問題，故而撰寫這篇博客來復習和鞏固DHCP協議，

DHCP 概念

1. 什么是 DHCP 網路協議

網路是非常復雜且抽象的，網路中的硬體設備比如 路由器、交換機、集線器、網線、網卡、網橋共同組成了核心網路，在硬體設備上流通的網路流量，做到怎么去引導網路流量正確得流向到正確的網路設備上，需要TCP/IP 協議作為網路流量的核心協議，

但是如果一個網路管理員想要正確地讓TCP/IP協議正確運行，需要給網路中的主機和路由器配置一些關鍵資訊，比如說介面的IP地址，我們可以輕易地在電腦上輸入 ipconfig 命令去顯示當前網路設備的網路地址資訊，那么這個地址到底是怎么被分配到當前的設備上的？

對于一個網路設備(終端)的核心IP資訊主要有: IP地址、子網掩碼 和 DNS服務器地址，

而獲取網路設備的 TCP/IP資訊主要有這幾個方面：

• 手動配置 - 通過終端上的配置界面根據業務的要求進行手動配置，
• 動態獲取 - 例如 windows 上的手動配置選項上的動態獲取選項，
• 特定的演算法進行計算，

一般來說，對于服務器端的采用手動配置方式來適應業務的核心需求，對于客戶端比如連接網路拓撲上的個人終端那么采用動態獲取方式來獲取相關資訊，

原因有以下幾個方面:

• 客戶端與服務器端的互動會更加頻繁，并且客戶端可能會在網路中發生遷移，
• 服務器端的配置服務要求客戶端的網路一定必須是固定的，

在這個場景下，客戶端需要從服務器端動態地獲取服務器端的資訊并配置到本地中，這個時候 DHCP就派上了用場，在本文中，主機 == 客戶端，即任何需要從網路中獲取地址的設備( 不包括 網路中的路由器)，請區別開這個方面的概念，服務器 = 服務端，有時候并不一定是一個獨立的設備，而是一個應用程式(在大多數條件下)，希望能將這些方面的概念區別出來，

DHCP，從英文的含義來說，Dynamic Host Configuration Protocol，是用來動態地配置主機的相關狀態，從DHCP的發展來說，DHCP是繼承于BOOTP 協議 ( Bootstrap Protocol )，后者在設計協議的程序中僅僅提供了有限的主機資訊配置，并且主機的資訊一旦從遠程服務器端分配之后，就很難再被修改；DHCP的出現改變了這種局面，DHCP幾乎提供了所有的主機配追資訊，并且引入了租約的概念，使得主機資訊能夠動態地產生變化和進行更改，此外，作為可以動態地更改主機的配置的協議，

DHCP 是一個基于 Client/Server 模式的網路協議，

DHCP 是基于UDP/IP協議進行傳輸，服務器端使用埠 67, DHCP客戶端使用埠號 68，

2. DHCP 協議內容

DHCP主要分為兩個部分: 網路IP地址的管理 和 配置資訊的傳遞

• 網路IP地址的管理： 地址管理處理 IP 地址的動態分配， 并且為每一個主機 (Host) 提供地址的租約
• 配置資訊傳遞: 從服務器端向主機端傳遞報文 和 狀態機的配置，

3.DHCP 地址管理

地址池 與 地址租約

如果用戶在客戶端中申請配置一個 動態網路地址配置，那么 DHCP客戶端(Host) 會向 DHCP服務器 發送一個 IP地址請求， 這個時候在遠程的 DHCP服務器 就會維護一個 IP地址池，并且從這個地址池來取出一個IP回應給 DHCP客戶端， 在地址分配的程序中，DHCP服務器也會指定回應給 DHCP客戶端的IP地址的租約期，在租約期中，這個地址可以被客戶端使用，租約期到之后這個IP地址被 DHCP服務器自動識訓，客戶端可以在租約期內請求延長租約，

DHCP 報文內容

DHCP的組成從網上有很多解釋，下圖來自網路:

• Op： 報文型別，分為 兩大類： Request（1） 和 Reply（2）
• HW Type： 硬體型別，一般是以太網：1
• HW Len： 硬體地址長度，單位位元組，對應以太網：6（mac地址長度為6位元組48bit）
• Transaction ID：事務ID，亂數，有客戶端生成，服務器Reply時，會把Request中的Transaction拷貝到Reply報文中，
• Secs： 距離第一次發射IP請求或Renew請求過去的秒數
• Flags：標志位，目前僅第一個bit有使用，置1 標明廣播
• Client IP Address：當前客戶端的IP地址，如果當前客戶端沒有IP地址，則置0
• Your IP Address： 服務器想客戶端提供IP地址時，會把IP地址填入本欄位
• （Next）Server IP Address：客戶端引導時需要的另一個服務器的IP地址
• Gateway （Relay） IP Address： 網關（中繼）IP地址，有DHCP 中繼器在轉發DHCP報文的時候填入
• Server Name： Server名字，有64bytes，一般不使用，填充為0
• Boot File name： boot file的路徑，128bytes， 一般不使用，填充為0
• Option： 選項，不定長度， DHCP報文中比較重要的欄位

DHCP Option 內容

之前介紹過，因為DHCP是從Bootp 協議繼承和拓展過來的，因此很多不能在Bootp實作的內容都放到了Option 來實作，通俗來說，DHCP協議其實就是攜帶許多Option的Bootp，

報文中的Option遵循以下的形式:

• 如果Option沒有值，則只有標志位之類的內容，則以一個位元組表示
• 如果Opiton有值，即Opiton是以下name-value對，則Opiton需要多個位元組表示，其中第一個位元組表示 option的名字，第二位元組表示value的長度，第三個位元組開始表示value，

常見的Option型別情參照下圖:

4.DHCP 作業原理

主機加入到一個新的網路中

DHCP 將一臺從未分配過的主機加入到網路需要經歷四個階段: 1. 發現階段，2.提供階段，3.請求階段，4.確認階段，

發現階段

新的Client加入網路時，會使用0.0.0.0作為源地址，發送discover廣播報文，查詢網路上有哪些DHCP Server，以及這些DHCP Server 能Offer哪些IP地址，這個廣播幀的MAC地址為新的Client的MAC地址，型別欄位為 0x0800，載荷資料為一個廣播 IP 報文，該報文的目的IP地址 為有限的廣播地址: 255.255.255.255， 協議欄位值為 0x11, 載荷資料是一個 UDP報文，訊息為 DHCPDISCOVER，

在該階段中，與客戶端所在二層網路中的所有設備都會接收到這個廣播幀，并將這個廣播幀洪泛出去，在其他設備接收到這個資料幀的時候會將相關的載荷按照網路分層逐層上傳，在設備的傳輸層UDP模塊在接收網路層上傳的資料包之后會決議資料包的埠號， 對于一個DHCP服務器來說，67 作為獨特的埠號，會被打開，而對于其他的設備來說這個埠不被打開，那么這個資料包就被丟棄，

在華為的數通教材中，給出的例子是路由器上運行了 DHCP服務器 ， 但是鏈路中可能有多個設備也運行了DHCP服務器，這個時候所有收到該請求包的服務器都會給請求客戶端回復一個資料包來證明自己已經接收到了請求資訊，

對于DHCP的傳輸模式 - UDP協議，是一種面向無連接的、不需要可靠傳輸的通信方式，因此 DHCP 需要依賴自己的一種可靠的傳輸傳輸方式，其中包括：什么情況下需要重復發送已經發送過的請求，重復請求的間隔時間是多少，最大重復次數是多少等等...

提供階段

DHCP Server接收到DHCP Discover報文后，回應Offer報文，提供IP地址（可能包含DNS等其他資訊）給Client，這個階段中，不涉及客戶端是否接受服務端給出的 IP 地址，只是服務器端給客戶端的一個回應， 每個接收到 DHCPDISCOVER 訊息的服務器，都從自己維護的 IP 地址池分配出一個有效的且未被使用的 IP地址，并通過 DHCPOFFER 訊息將這個IP地址分配發送給客戶端，

對于一個 DHCPOFFER 訊息來講，訊息被封裝在客戶端預留埠號為68，源埠號67的一個UDP報文中，該UDP報文又是被上層封裝到一個被廣播的IP報文中， 這個IP報文的目的地址是一個有限廣播地址：255.255.255.255，源地址為DHCP服務器端所對應的單播地址，其中協議欄位為0x11，該IP報文又被上層封裝到了一個廣播幀中，這個廣播幀的源MAC地址為 DHCP Server 所對應的單播MAC地址，型別欄位的值為 0x0800，

在傳輸的程序中，與請求客戶端所在同一個二層網路中的所有設備都會接收到這個請求資料包，只有開啟了 DHCP Client 服務的客戶端才會接收到這個資料包的載荷資料（DHCPOFFER），并上傳至應用層上的 DHCP Client 中，

但是在同一個二層網路中可能存在著其他同樣打開 DHCP Client 服務的客戶端，終端如何區分是不是自己發出的DHCPDISCOVER請求呢？其實可會斷在發送 DHCPDISCOVER 請求的時候就已經創建了一個用于區別請求且獨一無二的交易號(Transaction ID) ，這個交易號會在服務端向客戶端發送DHCPOFFER回執的時候

3.Client 根據收到的Offer報文，選擇一個DHCP Server，并選擇它提供的IP地址，然后廣播Request報文，向DHCP Server請求該IP地址，同時向本地網路（尤其是其他DHCP Server）公告自己已經選擇了某個DHCP Server的某個IP地址，

4.DHCP Server 回應ACK報文，將IP地址分配給client端 （特殊情況：DHCP Server在發送Offer報文和接收到Request的短暫時間內把IP分配給了其他主機），

5.DHCP Client 收到ACK報文后，會針對獲得的IP地址發送ARP Request，進行IP地址沖突檢測，

6.如果IP地址已經被其他主機使用，則Client放棄該IP地址，向Server發送DHCP DECLINE報文告訴Server該地址不能使用，然后一段時間后（一般10s）再此嘗試獲取該IP地址

7.如果Client仍然無法使用該IP地址，則發送DHCP RELEASE報文，放棄該地址，

主機已經有IP地址，只想更新租約

1.此時可以跳過DHCP Discover報文和DHCP Offer報文，

2.Client發送攜帶當前IP地址的Request報文，

3.如果Server同意Client續約，則發送DHCP ACK報文，如果拒絕續約，則發送DHCPNAK報文，

下邊有一個圖來具體的說明 DHCP 的作業原理以及建立相關網路聯系的流程和原理:

【未完待續.... 下一部分將加上華為模擬設備上的】

標籤：其他

上一篇：虛電路網路和資料報網路

下一篇：利用Metasploit 打入ThinkPHP內網...