????????DHCP（Dynamic Host Configuration Protocol/動態(tài)主機配置協(xié)議）是到目前為止筆者接觸到的比較復雜的協(xié)議，在傳輸過程中，DHCP有8種報文類型來實現(xiàn)不同的過程，而當客戶端成功獲取地址之后也會有多種狀態(tài)的變化。因此筆者打算先從dhcp的報文入手，理清楚一臺終端設備從無到有取得IP地址的過程。
????????為何要使用DHCP呢？首先，終端設備接入互聯(lián)網(wǎng)一定是需要IP地址的，就像普通的電腦，而最初分配IP地址的方式就是手動輸入IP地址，如有10臺設備A/B/C/D…I/G那么就找出10個IP地址如192.168.0.2/3/4/5…11。只需要一對一的設定好每臺設備的IP不沖突，設置好網(wǎng)關、掩碼、dns等就可以正常上網(wǎng)了。筆者第一章架設linux服務器和第二章接入專網(wǎng)的時候都是用的這種方式。但隨著接入量的增加，地址分配、更改會變得非常繁瑣，有時候一個內網(wǎng)環(huán)境下用戶接入量少則幾千多則幾萬，這要是一個一個手動設置IP地址，工作量根本無法統(tǒng)計。
????????其實對于網(wǎng)管而言，哪臺電腦是什么IP地址似乎并不是很重要，大多數(shù)人配置IP地址的目的也僅僅是為了上網(wǎng)。那么是否存在一種方式可以使得接入終端在連入互聯(lián)網(wǎng)后可以自動獲取一個IP地址，而網(wǎng)管可以看到一張IP對應電腦的關系表來進行維護呢?
????????方案上肯定是可行的，這就涉及到了IP地址的動態(tài)分配，即DHCP。如下所示是客戶端一次完整的DHCP請求、續(xù)約的過程。其中涉及三次數(shù)據(jù)交互，分別為兩次請求（Discover-Offer、Request-ACK）一次續(xù)約（Request-ACK）?；谶@三次交互客戶端就順利獲取并延續(xù)使用IP地址來訪問互聯(lián)網(wǎng)。
????????筆者來仔細看一下這幾個請求過程：
????????DHCP Discover：客戶端在剛接入網(wǎng)絡時，本身是沒有IP地址的，這時候，客戶端需要在網(wǎng)絡內發(fā)起一次discover的請求，這時候源地址是0.0.0.0，目的地址為255.255.255.255，來詢問網(wǎng)絡中哪臺設備是dhcp server。Discover報文只是在客戶端所在的子網(wǎng)內進行廣播。
????????DHCP Offer：dhcp server收到客戶端的discover報文后，為了響應客戶端而回復一個offer報文。服務器會匹配客戶端所在的子網(wǎng)信息后會送給客戶端IP地址。并在地址池中暫時保留該地址。
????????DHCP Request：對于實際使用的網(wǎng)絡，沒有網(wǎng)絡協(xié)議可以規(guī)定網(wǎng)絡中只能有一臺dhcp server。當客戶端收到多個dhcp offer的時候會根據(jù)先到先得的原則從中選取最先獲得的報文。之后客戶端會再次廣播一個名為request的報文告知所有響應的dhcp server。
????????DHCP ACK：dhcp server收到request報文，保留客戶端ip-mac地址。
????????DHCP Request（Renew/ACK）：當客戶端到了最大租期的一半時，會向dhcp server發(fā)送一個request報文來申請續(xù)約，dhcp server給出回復(ACK)。
????????DHCP報文的8種類型:
????????經(jīng)過上述步驟，客戶端與服務器已經(jīng)建立了連接并進行租期的續(xù)約。除了上述discover、offer、request、ack四種基礎的報文類型，還有以下四種：
????????DHCP NAK：當DHCP收到客戶端的request報文之后，沒有發(fā)現(xiàn)相應的租約記錄或某些原因（如地址池用盡）無法分配IP地址，則返回客戶端NAK報文。
????????DHCP Release：當客戶端不使用所分配的IP地址時，會發(fā)送release報文告知dhcp server。
????????DHCP Decline：當客戶端收到dhcp的地址信息后，發(fā)現(xiàn)由于某些原因地址不可用（如地址沖突）會發(fā)送decline報文告知dhcp server。
????????DHCP Inform：當客戶端希望獲取dhcp server詳細信息時會發(fā)送inform報文至服務器。
????????附：四種常見dhcp報文：https://ro.wikipedia.org/wiki/DHCP
????????DHCP協(xié)議：https://tools.ietf.org/html/rfc2131
????????熟悉了客戶端自動獲取IP地址的過程，下一步筆者就開始搭建一臺DHCP服務器了。老樣子，先把上一章的TFTP服務停掉：/bin/systemctl stop xinetd.service
????????查看一下狀態(tài)確認關閉：/bin/systemctl status xinetd.service
????????查看yum已經(jīng)安裝的dhcp軟件：yum list installed | grep dhcp
????????查看yum源關于dhcp的安裝軟件：yum list | grep dhcp
????????yum安裝DHCP：yum install dhcp.x86_64
????????安裝好之后，和之前TFTP一樣，筆者先對其進行初始化設置：
????????cd /etc/dhcp/
????????cat dhcpd.conf
????????筆者看到第四行似乎有個example的配置文件，果斷進去看了看語句的格式。熟悉之后筆者開始對dhcp的策略配置： cat /usr/share/doc/dhcp-4.2.5/dhcpd.conf.example
????????先介紹一下筆者的網(wǎng)絡情況，筆者之前配的馬賽克地址（一直以來稱作192.168.101.2）是筆者園區(qū)網(wǎng)絡的地址，這段地址在筆者的數(shù)據(jù)中心，一般是固定地址供服務器使用。其余的一些地址則是由現(xiàn)網(wǎng)中的DHCP server分配，園區(qū)網(wǎng)絡中除了客戶端獲取地址之外，基于ap-ac架構的無線接入點也需要獲取地址，并同時需要下發(fā)option選項。而筆者園區(qū)網(wǎng)絡比較復雜，現(xiàn)網(wǎng)業(yè)務不能中斷，因此筆者考慮找兩段沒有用過的地址，在專網(wǎng)（10.150.101.0/24）中進行測試。首先筆者在10.150.101.0/24網(wǎng)段中測試一下同網(wǎng)段前半部分地址分發(fā)，并為某臺設備綁定地址；其次筆者新建一段地址10.150.100.0/24通過dhcp relay的方式為option 60字符為Aruba的設備下發(fā)ac地址。
????????明確了測試目標，筆者進行dhcpd.conf的配置：
????????vi dhcpd.conf
????????首先進行全局設置：
????????ddns-update-style none;
????????調整ddns的方式為none，DDNS為域名解析提供了一種動態(tài)關聯(lián)的機制，其目的是為了實現(xiàn)客戶端地址變動時，dns解析可以跟隨主機的IP地址變動。由于客戶端完全可以通過mac-ip的綁定不使其地址變動，所以該功能在網(wǎng)絡中應用意義不大，就直接設置為none了。
????????http://www.zytrax.com/books/dns/ch9/dhcp.html
????????ignore client-updates;
????????同上，客戶端更新，直接關閉。
????????default-lease-time 3600;
????????該字段是標識dhcp租約的時間，筆者在全局模式下設置為1小時=3600秒。
????????max-lease-time 86400;
????????最大租約時間，如果某地址池設置的租約時間大于該閾值，則生效。設置為1天。
????????option domain-name "hbai.com";
????????option domain-name-servers 10.150.101.249;
????????設置dns服務器為本機地址，使得dhcp server可以同時下發(fā)dns供服務器域名解析。
????????class "aruba" {
???????????????match if substring (option vendor-class-identifier, 0, 7) = "ArubaAP";
????????}
????????定義一個class規(guī)則，匹配字符“ArubaAP”。
????????option serverip code 43 = string;
????????option serverip31:31:2e:31:31:31:2e:31:2e:31:31:31;
????????設置option 43下發(fā)的ac地址為11.111.1.111以ascii來表示。
????????全局模式下配置差不多就這些，下面就是定義一些地址池，新建兩段地址用做測試。整個文件的配置如下：
????????配置中，筆者新建了同網(wǎng)段的一個地址池10.150.101.10-10.150.101.100，對匹配到字符為Aruba的設備下發(fā)地址，同時，筆者有臺mac后四位為137d的設備，對其綁定地址10.150.101.55。
? ? ? ? 同時，筆者新建了一段10.150.100.0的網(wǎng)段，進行地址分配。
????????配置參數(shù)完成后參考之前的策略，開放防火墻udp67端口。
????????firewall-cmd --list-all
????????firewall-cmd --zone=public --del-port=67/udp–permanent
????????firewall-cmd –reload
????????cd /etc/firewalld/zones/
????????cat public.xml
????????開啟dhcp服務：systemctl start dhcpd
????????開啟dns服務：systemctl start named
????????對于一臺客戶機而言，取到地址是一件非常簡單的事情，只要在操作系統(tǒng)上設置為自動獲取地址，等待地址獲取就可以了。由于故障排查的要求，筆者需要對整個dhcp地址獲取、續(xù)租、釋放等過程都需要有深刻的理解，因此筆者在內網(wǎng)的一臺跳板機抓包分析dhcp的獲取過程和option字段。
????????在同網(wǎng)段的某臺內網(wǎng)windows設備上開啟wireshark，選擇網(wǎng)卡后在搜索欄中篩選關于dhcp的報文：bootp
????????(wireshark官網(wǎng)地址：https://www.wireshark.org/#download)
????????很幸運，筆者的專網(wǎng)比較干凈（無大量設備自動獲取地址），因此抓到了一個完整的dhcp四次交互過程：
????????如上圖所示，是筆者一臺mac末尾為137d的設備進行dhcp獲取地址的過程。在這臺設備接入網(wǎng)絡后，即開始發(fā)送DHCP Discover報文，當筆者的dhcp服務器在67端口監(jiān)聽到該報文后就會恢復客戶端DHCP Offer報文，由于筆者在配置文件中將其mac綁定了地址10.150.101.55，因此服務器將該地址返回給客戶端，再經(jīng)過request和ack兩個階段后客戶端成功獲取地址。
????????首先筆者查看discover報文，在該報文中首先看option 55的請求參數(shù)列表，客戶端會向服務器請求如下option參數(shù)。
????????在報文中并沒有看到客戶端請求option 43的信息，筆者的客戶端在發(fā)起dhcp請求時，除了獲取到想要的IP地址之外，還請求了包括子網(wǎng)掩碼、廣播地址、網(wǎng)關、dns、主機名、NTP、MTU的信息。
????????查看一下discover報文中的option 60，是F5Nerworks。該字段標識了客戶端的廠商信息。
????????當客戶端發(fā)起一次請求之后，dhcp服務器就會對其進行響應，這個報文就是DHCP offer報文。
????????查看報文中的option 53、option 54信息，看到報文類型為offer，dhcp服務器地址為筆者服務器的地址。
????????查看報文中option 51，看到筆者在服務器端設置的默認lease time為1H。
????????查看報文中option 1、option 3，看到筆者設置的掩碼和網(wǎng)關。
????????查看該報文中的option 15、option 6，看到筆者下發(fā)的dns server ip為10.150.101.249，dns下發(fā)成功。
????????后面兩個交互的報文是客戶端和服務器確認地址獲取成功，option信息基本相同，就不再細看了。
????????最后再看一下dhcp的租約信息。Linux的租約目錄在/var/lib/dhcpd/下，進入該目錄cat dhcpd.leases文件就可以看到地址和租約了~
????????該文件記錄了某時間點IP地址和客戶端MAC地址的對應關系，一旦需要溯源，就可以以這個文件為準了。筆者測試時間測試跨度比較長，其間地址綁定等操作陸陸續(xù)續(xù)測試了多次，這個租約是某周末前后筆者截取的一段log，其中137d的地址綁定已經(jīng)被筆者釋放了，這個測試階段測試了已經(jīng)獲取地址設備的續(xù)約，使用了兩臺設備分別下發(fā)了地址池第一個和最后一個地址。
????????還有一些遺憾，由于出差筆者沒法找到合適的設備測試option 60字段是否下發(fā)成功，文中關于option 60的一些配置是查看相關的文檔資料配置的，這個在文件“cat /usr/share/doc/dhcp-4.2.5/dhcpd.conf.example”中就有配置的例子，但要抓到option 43的報文還需要進行下一步的驗證。
????????附上一個客戶端dhcp狀態(tài)圖，度娘上直接搜的?？梢愿奖愕睦斫饪蛻舳嗽诓煌瑺顟B(tài)間的轉換，有興趣的朋友可以根據(jù)不同的狀態(tài)抓取相應的報文仔細分析。到此為止客戶端獲取地址并續(xù)約的過程已經(jīng)實現(xiàn)。
????????CSDN一篇對DHCP option解讀：http://blog.csdn.net/nosodeep/article/details/45971677
