本發(fā)明涉及網絡技術領域,具體涉及一種單物理網卡多VLAN的DHCP服務器實現方法。
背景技術:
當前,隨著硬件的不斷升級,很多公司會逐漸使用Linux服務來對整個公司提供DHCP服務,在現有技術下,Linux的存在一些開源的DHCP服務,不過這些服務要對多個VLAN提供IP分配服務,一般需要多個物理網卡,且配置一般比較復雜。
另外,在講究信息安全的今天,很多時候DHCP不僅僅是提供IP這么一個簡單的功能,可能還會涉及到DCHP dicover、offer等數據包數據的處理,從而根據策略來決定如何分配,因此如果僅僅是借助Linux上的第三方DHCP服務是無法滿足這個需求的。
技術實現要素:
為了解決上述問題,本發(fā)明提供了一種單物理網卡多VLAN的DHCP服務器實現方法。本發(fā)明提供的一種單物理網卡多VLAN的DHCP服務器實現方法,是虛擬VLAN網卡技術和JAVA程序的結合,具有良好的擴展和編程能力,具有良好的適應性,同時能夠有效降低成本,提高效率,以更好的適應時代和市場的要求。
本發(fā)明采用的技術方案如下:
一種單物理網卡多VLAN的DHCP服務器實現方法,包括步驟S1,虛擬VLAN網卡的配置,所述步驟S1包括如下步驟:
S11,基于物理網卡針對每個VLAN新建一個虛擬VLAN網卡;
S12,給每個虛擬VLAN網卡配置所述網段的IP,并加載802.1q模塊。
上述的一種單物理網卡多VLAN的DHCP服務器實現方法,其中,所述步驟S1還包括:
S101,判斷所述物理網卡的網卡驅動是否支持802.1q協(xié)議;如果是,至步驟S102;
S102,判斷所述物理網卡所在的服務器內核是否能加載802.1q模塊,如果是,至步驟S11。
上述的一種單物理網卡多VLAN的DHCP服務器實現方法,其中,還包括步驟S2,對每個虛擬VLAN網卡進行DHCP報文的監(jiān)聽。
上述的一種單物理網卡多VLAN的DHCP服務器實現方法,其中,還包括步驟S3,核心報文解析,所述步驟S3包括如下步驟:
S31,判斷接收到的報文是否屬于DHCP報文,如果是,至步驟S32,如果否,則結束;
S32,解析接收到的報文對應的報文種類。
上述的一種單物理網卡多VLAN的DHCP服務器實現方法,其中,還包括步驟S4,根據接收到的報文種類,做對應DHCP數據包封裝和發(fā)送:當接收到DHCP請求報文,計算出對應分配的IP并發(fā)送報文;當接收到DHCP需求報文,確認對應的IP并發(fā)送報文;當接收到DHCP通知報文,確認報文參數信息并發(fā)送報文;當接收到DHCP釋放報文,進行租賃周期的釋放。
本發(fā)明過程具體分為虛擬VLAN網卡的配置、網卡監(jiān)聽報文、核心報文解析和IP分配算法邏輯、DHCP數據包封裝和發(fā)送。只需要單物理網卡即可實現對多個VLAN提供DHCP服務。
附圖說明
為了更清楚地說明本發(fā)明實施例或現有技術中的技術方案,下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹,顯而易見地,下面描述中的附圖僅僅是本發(fā)明的一些實施例,對于本領域普通技術人員來講,在不付出創(chuàng)造性勞動性的前提下,還可以根據這些附圖獲得其他的附圖。
圖1是本發(fā)明一種單物理網卡多VLAN的DHCP服務器實現方法的流程圖;
圖2是本發(fā)明一種單物理網卡多VLAN的DHCP服務器實現方法一實施例中PC機的DHCP請求過程;
圖3是本發(fā)明一種單物理網卡多VLAN的DHCP服務器實現方法的流程圖。
具體實施方式
下面將結合本發(fā)明實施例中的附圖,對本發(fā)明實施例中的技術方案進行清楚、完整地描述,顯然,所描述的實施例僅僅是本發(fā)明一部分實施例,而不是全部的實施例。基于本發(fā)明中的實施例,本領域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例,都屬于本發(fā)明保護的范圍。
實施例
如圖1所示,一種單物理網卡多VLAN的DHCP服務器實現方法,包括如下步驟:
S1,虛擬VLAN網卡的配置:
S101,判斷所述物理網卡的網卡驅動是否支持802.1q協(xié)議;如果是,至步驟S102;
S102,判斷所述物理網卡所在的服務器內核是否能加載802.1q模塊,如果是,至步驟S11。
S11,基于物理網卡針對每個VLAN新建一個虛擬VLAN網卡;使用vconfig命令,使最后一個參數和交換機對應的VLAN號相同;
S12,給每個虛擬VLAN網卡配置所述網段的IP,并加載802.1q模塊。每個虛擬VLAN網卡都要分配IP,那么把該虛擬VLAN網卡和要分配的IP組即ip范圍一一對應。
S2,對每個虛擬VLAN網卡進行DHCP報文的監(jiān)聽。
S3,核心報文解析:
S31,判斷接收到的報文是否屬于DHCP報文,如果是,至步驟S32,如果否,則結束;
S32,解析接收到的報文對應的報文種類。
S4,根據接收到的報文種類,做對應DHCP數據包封裝和發(fā)送:當接收到DHCP請求報文,計算出對應分配的IP并發(fā)送報文;當接收到DHCP需求報文,確認對應的IP并發(fā)送報文;當接收到DHCP通知報文,確認報文參數信息并發(fā)送報文;當接收到DHCP釋放報文,進行租賃周期的釋放。
如圖2所示,在一具體實施例中,當PC機發(fā)起DHCP請求時,具體請求過程如下:
(1)PC主機啟動,DHCP處于INTITIAL狀態(tài)為了獲取IP地址,DHCP客戶機初始化TCP/IP,通過UDP端口67向網絡中發(fā)送一個DHCP discover廣播包,請求租用IP地址。該廣播包中的源IP地址為0.0.0.0,目標IP地址為255.255.255.255;包中還包含客戶機的MAC地址和計算機名,本地所有的DHCP server會收到這個報文,數據包中的目標端口設為BOOTP67端口。這時PC主機會處于SELECT狀態(tài)。
(2)處于SELECT狀態(tài)的PC主機會接受DHCP server發(fā)來的DHCP offer報文,每個報文中會包含為客戶機配置的信息以及server為客戶機提供的租用IP,一般主機會收到零個或者多個offer報文,一般PC主機會響應第一個offer報文,并與server協(xié)商相關事宜,為此主機會發(fā)送一個DHCP request報文,并進入REQUEST狀態(tài)。
(3)DHCP server會給PC主機一個ack的確認信息,這時一個DHCP獲取過程結束。主機進入BOUND穩(wěn)定狀態(tài)。
(4)假如PC主機不需要IP地址或者需要換個IP,這時PC主機會發(fā)送一個DHCP release報文向DHCP server,這時PC主機重新處于初始狀態(tài)。
(5)一般服務器給PC主機的IP地址都有租期,時間長短不等,而DHCP主機會有3個計時器,當擇期過半50%,這時PC主機會發(fā)送一個DHCP request報文要求續(xù)租進入RENEW狀態(tài),DHCP server會響應這個報文發(fā)送ack確認信息,這時DHCP會重新進入BOUND狀態(tài)。
(6)假如DHCP server沒有響應主機的請求,等租期到了87.5%這時主機會重新發(fā)送DHCP request報文要求續(xù)租,主機進入REBIND狀態(tài),假如這時候DHCP server的IP地址不夠用,會發(fā)送一個nack信息,這時主機會重新進入初始狀態(tài)再次按照(1)到(4)步驟重新申請IP。假如收到ack信息確認續(xù)租成功,說明這個IP我們還可以繼續(xù)使用。沒有響應,PC主機只有等到IP租期耗盡,重新進入初始狀態(tài)重新獲取。
如圖3所示,本發(fā)明設計在一具體實施例中的DHCP服務流程具體如下:
1、Linux服務器和交換機的trunk口相連,確保能讓所有VLAN的報文發(fā)送到服務器。
2、服務器上按照每個VLAN id,在某個物理網卡上建立對應的虛擬VLAN網卡,并配置一個IP,同時確保服務器內核加載了802.1q模塊。該VLAN id為交換機上的對應的一個VLAN號,具有唯一性。
3、運行JAVA編寫的DHCP服務器監(jiān)聽在每個虛擬VLAN網卡,利用libpcap打開每個虛擬VLAN網卡的句柄,能隨時抓取報文。
4、按照上文說的PC機請求DHCP的流程,首先PC機會發(fā)出discover報文,報文廣播到交換機,交換機會將此轉發(fā)到服務器,由于服務器支持了802.1q,且和交換機是以trunk相連,因此會根據報文中vlan tag將該報文由對應的某個虛擬VLAN網卡來接收。(此分配方式對于所有的DHCP報文都是一樣的,下文不再重復。)
5、DHCP服務器從某個虛擬VLAN網卡句柄中抓取到了該報文,首先判斷是否該報文是否屬于DHCP報文,即是否為發(fā)向67端口的UDP報文,否則直接結束,是進行下一步。
6、按照DHCP報文格式,一步一步解析出相應數據,包含客戶地址、報文類型,如是請求報文還是回復報文等,以及DHCP的option數據。
7、解析出的數據中option 53為0x01,即為discover類型,轉8;為0x03,即為request類型,轉9;為0x08,即為inform類型,轉10;為0x07,即為release類型,轉11;
8、Discover消息處理器接收到discover報文,解析出MAC地址和系統(tǒng)的bock list比較,如果在blocklist中,則直接返回不做處理;如果不在,則判斷是否給此MAC預留了IP,如果有,則直接分配預留IP,如果沒有,則先找到接收此報文的虛擬VLAN網卡對應的IP組,這個對應關系需要在創(chuàng)建虛擬vlan網卡時配置好,找到對應IP組后,就知道分配IP的范圍,從小到大依次比較是否已被分配,如果是,則找下一個,如果不是,則確定分配此IP,并把此IP加入到已分配列表。確定了分配IP,則再從IP組里獲取其他的option信息,包括網關、DNS、租賃周期等,并將所有信息封裝成offer報文,其目的端口68,通過虛擬vlan網卡句柄發(fā)送出去。
9、Request消息處理器接收到request報文,request報文前面的處理流程和discover一樣,預留IP判斷完后,則直接從報文中解析出請求IP,request報文和discover不一樣,包含了一個請求IP,如果請求IP和預留IP不一致,則不符合規(guī)則,直接返回;如果一樣,則將此IP和option信息封裝成ack報文發(fā)送,并將IP和MAC對應的租賃關系表更新。
10、Inform消息處理器接收到inform報文,直接從報文中解析出client IP,client IP是否屬于系統(tǒng)配置的某個IP組,如果不屬于,則直接返回;如果屬于,則將此IP組中配置的一些附加的信息封裝到ack報文中發(fā)送。
11、Release消息處理器接收到release報文,直接從報文中解析出client IP,client IP是否已存在租賃信息,如果不存在,則直接返回;如果存在,則判斷租賃信息中MAC地址是否和報文中的client MAC相同,相同則將租賃信息清空,不同則直接返回。
在本發(fā)明的一具體實施例中,以物理網卡eth0為例、且網絡中存在vlan 100、200、300三個vlan需要提供服務,通過三條命令vconfig add eth0 100、vconfig add eth0 200、vconfig add eth0 200創(chuàng)建了三個虛擬VLAN網卡,此時ifconfig就會看到多出了eth0.100、eth0.200、eth0.300三個網卡,即為虛擬VLAN網卡。然后需要給每個虛擬VLAN網卡配置一個IP,使用ifconfig命令:
ifconfig eth0.100 192.168.100.1 netmask 255.255.255.0
ifconfig eth0.200 192.168.200.1 netmask 255.255.255.0
ifconfig eth0.300 192.168.300.1 netmask 255.255.255.0
創(chuàng)建完成后輸入modprobe 8021q命令加載802.1q模塊,即完成配置。
另外,本申請的一部分可被應用為計算機程序產品,例如計算機程序指令,當其被計算機執(zhí)行時,通過該計算機的操作,可以調用或提供根據本申請的方法和/或技術方案。而調用本申請的方法的程序指令,可能被存儲在固定的或可移動的記錄介質中,和/或通過廣播或其他信號承載媒體中的數據流而被傳輸,和/或被存儲在根據所述程序指令運行的計算機設備的工作存儲器中。在此,根據本申請的一個實施例包括一個裝置,該裝置包括用于存儲計算機程序指令的存儲器和用于執(zhí)行程序指令的處理器,其中,當該計算機程序指令被該處理器執(zhí)行時,觸發(fā)該裝置運行基于前述根據本申請的多個實施例的方法和/或技術方案。
對于本領域技術人員而言,顯然本申請不限于上述示范性實施例的細節(jié),而且在不背離本申請的精神或基本特征的情況下,能夠以其他的具體形式實現本申請。因此,無論從哪一點來看,均應將實施例看作是示范性的,而且是非限制性的,本申請的范圍由所附權利要求而不是上述說明限定,因此旨在將落在權利要求的等同要件的含義和范圍內的所有變化涵括在本申請內。不應將權利要求中的任何附圖標記視為限制所涉及的權利要求。此外,顯然“包括”一詞不排除其他單元或步驟,單數不排除復數。裝置權利要求中陳述的多個單元或裝置也可以由一個單元或裝置通過軟件或者硬件來實現。第一,第二等詞語用來表示名稱,而并不表示任何特定的順序。
當然,對于本領域技術人員而言,顯然本申請不限于上述示范性實施例的細節(jié),而且在不背離本申請的精神或基本特征的情況下,能夠以其他的具體形式實現本申請。因此,無論從哪一點來看,均應將實施例看作是示范性的,而且是非限制性的,本申請的范圍由所附權利要求而不是上述說明限定,因此旨在將落在權利要求的等同要件的含義和范圍內的所有變化涵括在本申請內。不應將權利要求中的任何附圖標記視為限制所涉及的權利要求。
以上所述僅為本發(fā)明的較佳實施例而已,并不用以限制本發(fā)明,凡在本發(fā)明的精神和原則之內,所作的任何修改、等同替換、改進等,均應包含在本發(fā)明的保護范圍之內。