DHCP报文分析

              在三级网络技术中,有一道考察DHCP服务器报文的综合题,考查的题目看似相同,考点比较固定,可是均有侧重,有必要挑出来分析一下。

基本工作原理:

         DHCP客户端申请IP租约的4个阶段

        

         租约的发现阶段:DHCP客户端以广播的方式发送DHCPDISCOVER 广播包给DHCP服务器

         IP租约的提供阶段:DHCP服务器以广播的方式发送DHCPOFFER包给予应答,并提供DHCP客户端所需的TCP/IP属性的配置参数。配置参数包括:IP地址、子网掩码、缺省网关、域名和域名服务器的IP地址。(因为DHCP客户端目前还没有IP地址,所以DHCP服务器同样使用广播进行通讯:源IP地址为DHCP服务器的IP地址,而目的IP地址为255.255.255.255。同时,DHCP服务器为此客户保留它提供的IP地址,从而不会为其他DHCP客户分配此IP地址。如果有多个DHCP服务器给予此DHCP客户端回复DHCPOFFER消息,则DHCP客户端接受它接收到的第一个DHCPOFFER消息中的IP地址。 )

         IP租约请求阶段:DHCP客户端以广播的方式发送DHCPREQUEST包给DHCP服务器,确定与此DHCP服务器建立地址租借关系,并通告其他DHCP服务器。(由于还没有得到DHCP服务器最后确认,DHCP客户端仍然不能使用租约中提供的IP地址,所以在数据包中仍然使用0.0.0.0作为源IP地址,广播地址255.255.255.255作为目的地址。)

         IP租约确认阶段:DHCP服务器在接收到一个DHCPREQUEST广播包后,在正常情况下,会以广播的方式发送 DHCPACK包给DHCP客户来确认关系。


ipconfig/all:

        DHCP客户机在执行ipconfig/all 时获取的信息分析

        

ipconfig/renew:

        使用命令ipconfig/renew,客户端刷新TCP/IP参数(重新获取)。

        由于之前客户端已有IP地址,并指导DHCP服务器的IP地址,所以只需要客户端发送DHCPREQUEST报文和服务器回应DHCPACK报文这两次交互即可,且均为单播发送。


ipconfig/release:

        客户端依次使用命令ipconfig/release和ipconfig/renew,客户端释放原本已经获取的TCP/IP参数,然后重新获取TCP/IP参数。相当于地址释放和地址获取的过程累加:

即共有五次交互

        请求地址释放:DHCP客户端以单播的方式发送DHCPrequest 给DHCP服务器,请求释放地址。(注意和首次申请IP租约时第三个阶段区分,也有资料显示发送的是DHCPrelease,欢迎大牛指导留言)

        其他的过程和上文中基础工作原理的四个阶段一致。(附上截图)

        

         编号6中的内容表示通过wins服务器来管理刚才得到的ip地址的注册,这一行的目的ip地址对题目无用,有兴趣可以自己研究。


续约:

        如果采用动态地址分配策略,则DHCP服务器分配给客户端的IP地址有一定的租借期限(默认8天),当租借期满后服务器会收回该IP地址。如果DHCP客户端希望继续使用该地址,需要更新IP地址租约。 
        在DHCP客户端的IP地址租约期限达到一半时间(50%)时,DHCP客户端会向为它分配IP地址的DHCP服务器单播发送DHCP REQUEST报文,以进行IP租约的更新。如果客户端可以继续使用此IP地址,则DHCP服务器回应DHCPACK报文,通知DHCP客户端已经获得新IP租约;如果此IP地址不可以再分配给该客户端,则DHCP服务器回应DHCPNACK报文,通知DHCP客户端不能获得新的租约。(比如这个IP被从作用域中移除,那么DHCP服务器会返回给客户端一个DHCPNACK的数据包)
        如果在租约的一半时间进行的续约操作失败,DHCP客户端会在租约期限达到7/8(87.5%)时,以广播发送DHCPREQUEST报文进行续约。如果仍然没有得到DHCP服务器的回复则发起DHCPDISCOVER进程以寻求IP地址。


实例分析:

        某客户机使用DHCP获取IP地址等信息,其获取IP地址过程中捕获的4条报文及对第2条报文的分析如下。

编号 报文摘要
1 DHCP:Request, Type:DHCP discover
2 DHCP:Reply, Type:DHCP offer      
3 DHCP:Request, Type:DHCP Request
4 DHCP:Reply, Type:DHCP ACK

DLC: ----- DLC Header -----
DLC: Destination    =ffffffffffff                                            ‘第二条报文为offer,故目的MAC地址为广播MAC地址ffffffffffff (十六进制)
DLC: Source     = 001122334455                                  ’源MAC地址为DHCP服务器MAC地址
DLC: Ethertype     = 0800 (IP)
IP: D =255.255.255.255 ,S = 192.168.0.1                    ‘目的地址和源地址,和上下文吻合
UDP: D= 68,S = 67                                                           ’使用UDP协议,目的端口68,源端口67

DHCP: ----- DHCP Header -----
DHCP: Boot record type          = 2 (Reply)                      ‘2(reply),表名是DHCP服务器回复的报文,包括offer和ack
DHCP: Hardware address type     = 1 (10M Ethernet)        'Client的网络硬件地址类型,1表示是10MB的以太网类型
DHCP: Hardware address length    = 6 bytes              ’Client的网络硬件地址长度,6表示长度是6 bytes
DHCP: Hops                    = 0                                             '跳数,表示当前的DHCP报文经过DHCPRELAY(中级)的数目
DHCP: Transaction id             = 6019121F
DHCP: Elapsed boot time          = 0 seconds
DHCP: Flags                    = 0000
DHCP: 0                       = no broadcast
DHCP: Client self-assigned address  = [0.0.0.0]        ‘当前客户机的IP地址
DHCP: Client address             =[192.168.0.180]          ’将要分配给客户机client的IP地址(offer报文中已经包含即将分配的ip地址的相关信息)
DHCP: Next Server to use  in bootstrap  = [0.0.0.0]
DHCP: Relay Agent              = [0.0.0.0] 
DHCP: Client hardware address     = 001234567890  ‘客户机物理地址
DHCP: Host name                   = ""
DHCP: Boot file name             = ""
DHCP: Vendor Information tag = 53825276
DHCP: Message Type            = 2                                       ’message type 为2,表示此为服务器回应的报文offer
DHCP: Address renewel interval    = 345600 (seconds)
DHCP: Address rebinding interval    = 604800 (seconds)
DHCP: Request IP Address leased time  = 691200 (seconds)
DHCP: Sever IP Address = 192.168.0.1                          ‘DHCP服务器的ip地址,和上文一致
DHCP: Subnet mask              = 255.255.255.0                ’子网掩码
DHCP: Gateway address           = [192.168.0.100]         ‘ 网关地址
DHCP: Domain Name Server address  = [202.106.0.100]    ’DNS地址,注意看首拼


扩展:

        DHCP Message Type 项表示DHCP的报文格式,共有8种,较为常用的有4种。

        DHCP: Message Type  = 1   客户机开始申请IP租约的第一个过程 DHCP discover

        DHCP: Message Type  = 2   服务器的相应报文DHCP offer

        DHCP: Message Type  = 3   客户机回应第二步发送给服务器的请求报文DHCP request  或者是 客户机续租IP地址租期时发送的报文DHCP request

        DHCP: Message Type  =5   服务器发出的确认报文DHCP ack,此后客户机才真正获得了IP地址和相关的配置信息。(注意此处值为5)


小结:

        笔者只是简单的分析了一些DHCP报文,除了报文以外,DHCP服务器中还有很多其它的内容(如何配置等)有待我们深入学习。相比较与手动配置IP等相关信息,在网络规模比较大或移动客户端时,DHCP服务器则更加快捷方便,只有得心应手的运用这些工具,才能大大提高效率。


        个人理解,知识有限,如何有错误或是不足之处,希望大牛们批评指正!



  • 29
    点赞
  • 84
    收藏
    觉得还不错? 一键收藏
  • 26
    评论
说明: 1, 暂未实现重传机制, 所以若抓包无响应, 请尝试停止后重发. 2, dhcp状态显示采用1s定时器刷新, 所以状态显示可能存在延时的情况; 3, xcap通过pcap导入报文会有部分字段自动变化, 且导入的报文DHCP数据部分无法正常解析, 建议通过新建的方式解决; 4, 添加报文格式举例: 1,2 说明: 1表示报文组1, 选中报文组后, 在状态栏会显示报文组的索引, 2表示第三个报文, 即索引为3的报文. 版本记录: V1.0.1(基础版本) 1, 支持连接xcap并读取报文功能; 2, 支持刷新按钮自动更新报文功能; 3, 支持选择网卡功能; 4, 支持通过pcap文件打开报文功能(已废弃); 5, 支持指定服务器交互; 6, 支持dhcp交互状态显示; 7, 支持输入框通过正则表达式限制输入字符; 8, 支持选择特定报文操作; V1.0.2 1, 将状态修改为自动显示, 即动态识别报文类型并显示结果; 2, 解决解析option字段, 若字段中存在多个value时存在丢失的问题; 3, 增加鼠标点击状态显示气泡信息; 4, 增加隔行显示不同颜色; V1.0.3 1, 修改dhcp的状态机, 之前的版本是收到报文则发送request, 之后收到报文则认为收到ack. 现修改为只有收到offer报文才发送request报文 , 收到ack报文才结束. 2, 增加dhcpv6功能; 3, 优化代码; V1.0.4 1, 修改request报文由于校验和和报文长度未初始化导致构造错误的问题 V1.0.5 1, 增加服务器地址的气泡提示; 2, 增加自动填充的气泡提示; 3, 添加的报文默认为选中状态; 4, 选择网卡下拉框中将虚拟网卡排放靠后; 5, 关闭程序时自动保存设置; V1.0.6 1, 优化代码, 将字段设置使用统一的函数处理; 2, 状态气泡显示格式化; 3, 双击表格表头实现全选和反选; 4, 增加renew(50%), rebind(87.5%)和release的自动发送功能; 5, 增加手动释放按钮和实现; 6, 增加部分打印信息用于调试; 暂未实现报文重传机制, 计划下一个版本实现 V1.0.7 1, 实现discover/solicit报文自动重传机制 2, renew, rebind以及release修改为手动发送 3, 解决报文发送错乱问题 4, 增加decline报文的发送 5, 解决设备无故发送discover报文问题 问题解决: 1, 停止后再次发送数据会出现数据错乱 分析: 停止客户端的时候, 删除过滤器是通过callback函数删除的, 这里应该是通过filter来进行删除. self.widget.sniff.del_filter(self.callback)修改为 self.widget.sniff.del_filter(self.filter) 2, 设备无故发送discover问题 分析: 由于发送discover报文使用的定时器, 定时器是通过判断当前的direction来确定是否重传的, 而当定时器老化时, 可能正好收到报文导 致direction被修改, 所以导致错误的发送discover报文的问题. 将接收逻辑修改为重传时判断当前状态是否为discover报文, 若是则重传, 否则不重传. V1.0.8 1, 增加inform实现 V1.0.9 1, 增加报文五元组的源mac地址和xid的气泡显示; 2, 增加步长和报文限制功能; 问题解决: 1, 修改ipv6报文添加失败的问题. 由于ipv4报文为xid, ipv6报文为trid, 需要区分处理. V1.0.10 1, 在发送dhcpv6报文之前, 先发送na报文触发服务器学习nd消息. V1.0.11 1, 增加发送solicit/request前, 自动响应ns报文. 自动响应ns报文的目标地址为solicit/request报文源mac地址生成的ipv6地址 2, 实现dhcpv6的renew续约功能. 3, 解决ipv6地址转换格式化不正确, 导致无法响应ns报文问题. 4, 增加日志输出到dhcp.log文件. V1.0.12 1, 增加dhcpv6的续约功能, 通过renew和rebind实现续约, 增加release、decline报文的实现; V1.0.13 1, 解决服务器无法设置ipv6地址的问题. 之前的输入框只允许输入数字和., 修改为运行输入数字.:和a-f 2, 解决多个客户端时, 若选中其中的部分客户端发送时报错. 由于客户端采用的是列表中包含元组的形式, 即[(row, [client1, client2])], 这样实际客户端无法直接通过row索引到clients, 导致列表读 取时溢出. 譬如有1、2、3三行数据, 这里只选中了第三行, 限制为1, 那么如果点击发送, 则clients = [(row, [client1]], 此时clients[2] 就会溢出. 所以这里讲clients修改为字典, 即通过row来索引客户端client = {3: [client1]} 3, 将数据发送放到线程中, 规避模拟大量客户端时界面假死的问题. 4, 当客户端限制小于等于50, 则气泡显示trid和ip地址信息. 当大于50, 则气泡显示获取ip地址的数量. V1.0.14 1, 解决监听报文使用的网卡不正确问题. V1.0.15 1, 解决dhcpv6的响应报文的IANA中包含Status code选项导致程序无法解析的问题. 兼容性处理, 即option为IAAddress时按照IAAddress解析, 当option为status code时按照Status code解析 V1.0.16 1, 解决DHCPv6的client_id的duid处理, 支持任意格式的duid.
Wireshark是一款开源的网络分析工具,可以用来捕获和解析网络数据包。它可以帮助我们分析和研究网络流量以及协议。 在解析DHCP(Dynamic Host Configuration Protocol)报文时,Wireshark可以提供以下信息: 1. 源IP地址和目标IP地址:DHCP报文中包含了源IP地址和目标IP地址,通过解析这些信息,我们可以了解到DHCP服务器和客户端之间的通信情况。 2. DHCP消息类型:DHCP报文中包含了不同的消息类型,如Discover、Offer、Request、Acknowledge等。Wireshark可以识别并解析这些消息类型,帮助我们分析DHCP报文的交互过程。 3. 客户端MAC地址:Wireshark可以提供DHCP客户端的物理地址(MAC地址),这对于追踪和诊断网络问题非常有帮助。 4. IP地址分配情况:在DHCP报文中,包含了IP地址分配的相关信息,如IP地址池的范围、分配的IP地址、租约时间等。Wireshark可以将这些信息解析出来,方便我们了解IP地址的使用情况。 5. DHCP选项:DHCP报文中还包含了一些选项,如子网掩码、网关、DNS服务器等。Wireshark可以对这些选项进行解析,帮助我们了解DHCP服务器提供的配置信息。 通过对DHCP报文进行解析,我们可以深入了解DHCP协议的工作原理,识别网络中的问题,以及追踪网络中设备的通信情况。Wireshark作为一款强大的网络分析工具,提供了便利的界面和功能,可帮助我们更好地理解和管理网络。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 26
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值