DHCP协议深度解析：从DORA交互到地址池耗尽排查与安全防护实战

1. 从一个真实运维场景说起：为什么DHCP值得深挖

凌晨两点，值班手机响了。某办公区整片无线终端拿不到地址，用户报障说“连上WiFi但上不了网”。登录核心交换机一看，DHCP地址池利用率100%，租约表里一堆早已下线的设备还占着IP。手动清租约、扩容地址池、调整租期，半小时后恢复。这类事故我处理过不下十次，每一次的根因都指向同一个东西——DHCP协议。

DHCP，全称Dynamic Host Configuration Protocol，动态主机配置协议，干的事说白了就一件：让设备接入网络时自动拿到IP地址、子网掩码、网关、DNS等参数，不用人工一台台配。你家里路由器插上电，手机连WiFi自动就能上网，背后就是它在干活。但“自动”两个字掩盖了太多细节：地址怎么分配、租约怎么续、跨网段怎么转发、地址冲突怎么防、攻击怎么挡。这些才是运维和网络工程师真正要啃的部分。

这篇内容适合三类人看：一是刚入行的网络运维，想搞懂DHCP从发现到续约的完整链路；二是遇到过地址池耗尽、IP冲突、跨VLAN分配失败等问题的工程师，想找排查思路；三是准备网络相关认证考试的朋友，需要把DHCP的报文交互和部署方式吃透。我会从协议原理讲到实操配置，再到故障排查和防护，尽量把踩过的坑都摊开说。

2. DHCP协议核心机制拆解：从“喊话”到“拿到地址”的全过程

2.1 四个报文撑起一次完整交互

DHCP基于UDP工作，服务端用67端口，客户端用68端口。一次典型的地址获取过程由四个报文组成，业内叫DORA：

• Discover（发现）：客户端开机后没有IP，用源地址0.0.0.0、目标地址255.255.255.255广播喊一句“有没有DHCP服务器能给我个地址”。因为是广播，同一广播域内所有设备都能收到，但只有DHCP服务器会回应。
• Offer（提供）：服务器收到Discover后，从地址池里挑一个可用IP，通过Offer报文发回去。注意，此时客户端还没有正式使用这个地址，Offer更像是一个“预留提议”。
• Request（请求）：客户端可能收到多个Offer（比如网段里有两台DHCP服务器），它会选一个，然后广播Request报文正式请求这个地址。为什么用广播而不是单播给选中的服务器？因为要让其他发过Offer的服务器知道“我没选你”，它们好把预留的地址释放回去。
• Ack（确认）：被选中的服务器回Ack，里面带上IP、掩码、网关、DNS、租期等完整参数。到这一步，客户端才真正把地址配到网卡上。

提示：如果服务器认为客户端请求的地址不可用（比如已被占用），会回Nak（拒绝）报文，客户端收到后重新发起Discover。

很多人背过DORA，但没想过一个细节：Discover和Request都是广播，Offer和Ack通常是单播。单播怎么发？服务器把Offer/Ack发给客户端的MAC地址，但此时客户端还没IP，所以二层用客户端MAC，三层目标IP填的是服务器准备分配的那个地址（Offer阶段）或者广播地址。这个细节在抓包分析时特别容易把人绕晕。

2.2 租约机制：为什么你的IP会“过期”

DHCP分配的地址不是永久的，而是带**租期（Lease Time）**的。租期长短直接决定了地址池的周转效率。租期到了不续，地址就被回收。

租约续期分两个阶段：

• T1（续租）：默认在租期50%时，客户端向原服务器单播发送Request（此时是单播，因为客户端已有IP，知道服务器地址），请求续租。服务器如果同意，回Ack，租期重新计时。
• T2（重绑定）：如果T1续租失败（服务器没响应），客户端会在租期87.5%时，向整个网段广播Request，寻找任何能给它续租的DHCP服务器。这一步是兜底，防止原服务器宕机导致地址失效。

租期设置是个经验活。办公网终端流动性大，租期设短一点（比如8小时），下班后地址能回收，第二天新设备有地址可用；但租期太短会导致续租报文频繁，增加服务器和网络负担。服务器、打印机这类固定设备，通常用静态绑定（MAC和IP绑定），租期设无限大，避免地址变动导致服务中断。

2.3 地址分配策略：动态、自动、静态三种模式

DHCP有三种地址分配方式，很多人只知道动态分配，其实另外两种在特定场景下很有用：

静态分配不是“手动配IP”，而是在DHCP服务器上做MAC-IP绑定，客户端仍然通过DHCP获取，但每次拿到的都是同一个地址。这样做的好处是集中管理，改网关或DNS时只改服务器配置，不用逐台设备改。

2.4 跨网段分配：DHCP中继为什么必不可少

DHCP的Discover是广播，广播不能跨路由器。如果每个网段都部署一台DHCP服务器，成本太高。解决办法是DHCP中继（Relay Agent）。

中继的工作原理：路由器或三层交换机在收到本网段的DHCP广播后，把报文单播转发给指定的DHCP服务器，并在报文里插入一个叫giaddr（网关IP地址）的字段，告诉服务器“这个请求来自哪个网段”。服务器根据giaddr从对应地址池取地址，再把响应交给中继，中继转发回客户端。

配置中继时有个关键点：中继接口的IP必须和服务器上对应地址池的网段匹配。我见过有人中继指向了服务器，但服务器上没有为giaddr所在网段配置地址池，结果客户端一直拿不到地址，抓包看到服务器直接丢弃了请求。这个坑排查起来很费时间，因为表面上看中继和服务器都“正常”。

3. 主流部署方式与配置实操：从家用路由器到企业级架构

3.1 家用场景：路由器内置DHCP的默认逻辑

家用路由器开箱即用，DHCP默认开启，地址池通常是192.168.1.100到192.168.1.199，租期24小时，网关和DNS都指向路由器自己。这个默认配置对绝大多数家庭够用，但有几个细节值得注意：

• 地址池起始值从100开始，是为了给1到99留出来做静态分配（比如NAS、打印机手动配固定IP），避免和DHCP动态池冲突。
• 租期24小时意味着设备下线后地址还会被占一天，如果家里设备多、频繁来客人，可能遇到地址不够。可以把租期改短，比如2小时。
• 路由器重启后，租约表可能丢失，导致已分配地址被重新分配，引发IP冲突。部分路由器有租约持久化功能，建议开启。

3.2 企业级Linux服务器部署：ISC DHCP Server配置实录

企业环境更常见的是在Linux服务器上跑ISC DHCP Server（现由ISC维护，包名通常叫isc-dhcp-server或dhcp-server）。下面是一份可直接参考的配置。

安装：

# Debian/Ubuntu系 apt install isc-dhcp-server # RHEL/CentOS系 yum install dhcp-server

主配置文件/etc/dhcp/dhcpd.conf核心片段：

# 全局参数 default-lease-time 28800; # 默认租期8小时 max-lease-time 43200; # 最大租期12小时 option domain-name-servers 10.10.1.10, 10.10.1.11; option domain-name "corp.internal"; # 定义子网 subnet 10.10.20.0 netmask 255.255.255.0 { range 10.10.20.100 10.10.20.200; option routers 10.10.20.1; option subnet-mask 255.255.255.0; option broadcast-address 10.10.20.255; } # 静态绑定：打印机固定IP host printer-01 { hardware ethernet 00:1A:2B:3C:4D:5E; fixed-address 10.10.20.50; }

几个参数的计算和选择逻辑：

• range范围：10.10.20.100到200共101个地址。如果部门有150台设备，这个池子不够，需要扩大range或者缩短租期。经验公式是：地址池大小 ≥ 峰值在线设备数 × 1.2。
• default-lease-time：8小时适合办公网。如果是会议室、培训室这种高流动性场景，可以缩到2到4小时。
• option routers：必须填本网段的网关地址，填错会导致客户端有IP但出不了网。

配置完成后启动服务：

systemctl enable --now isc-dhcp-server systemctl status isc-dhcp-server

注意：服务器如果有多个网卡，需要在/etc/default/isc-dhcp-server里指定INTERFACESv4，否则服务可能监听错误的网卡，导致收不到请求。

3.3 跨网段中继配置：三层交换机上的关键命令

以常见的企业级三层交换机为例，在VLAN接口上配置DHCP中继：

interface Vlanif20 ip address 10.10.20.1 255.255.255.0 dhcp select relay dhcp relay server-ip 10.10.1.100

这段配置的意思是：VLAN20的网关接口开启中继功能，把本网段的DHCP请求转发给10.10.1.100这台服务器。服务器上必须有subnet 10.10.20.0的地址池声明，否则请求会被丢弃。

我踩过的一个坑：中继配置里dhcp relay server-ip指向了服务器，但服务器防火墙没放行来自中继接口IP的UDP 67端口，导致请求到了服务器但被防火墙拦了。抓包时看到服务器网卡有入包但没出包，才定位到防火墙。所以中继场景下，服务器防火墙必须放行所有中继接口IP的UDP 67入站。

3.4 高可用部署：双服务器冗余的两种模式

单台DHCP服务器是单点故障，企业环境通常做冗余。主流有两种模式：

• 主备模式（Failover）：两台服务器组成故障转移对，主服务器处理请求，备服务器同步租约数据。主挂了备接管。ISC DHCP支持这种模式，配置里用failover peer声明。
• 负载均衡模式（Split Scope）：两台服务器各管一半地址池，比如服务器A管100到150，服务器B管151到200。客户端广播时两台都可能响应，谁先回用谁的。这种模式配置简单，但地址利用率低，且两台服务器租约不同步，容易出现同一地址被两台服务器分配的情况。

主备模式更可靠但配置复杂，需要同步时钟、配置failover peer参数。中小企业如果预算有限，用两台服务器做Split Scope也能接受，但要确保地址池不重叠。

4. 故障排查实战：地址拿不到、冲突、耗尽怎么办

4.1 排查思路总览：从客户端到服务器的链路检查

DHCP故障排查有个基本顺序：先看客户端，再看链路，最后看服务器。

客户端侧：ipconfig /all（Windows）或ip addr（Linux）看有没有拿到地址。如果是169.254.x.x，说明Discover没得到响应，客户端自动配了链路本地地址。

链路侧：确认客户端和服务器之间二层通不通，中继配置是否正确，防火墙是否放行UDP 67/68。

服务器侧：看服务是否运行、地址池是否耗尽、租约表是否有异常、日志有没有报错。

4.2 常见问题速查表

4.3 地址池耗尽的深度处理

地址池耗尽是最高频的故障。表面看是“地址不够”，但根因可能有好几种：

• 租期过长：办公网租期设了7天，设备下线后地址一周才回收。改成8小时能显著缓解。
• 僵尸租约：设备已经不在网内，但租约没到期，服务器认为地址还被占着。可以在服务器上手动清理，或者用脚本定期扫描ARP表，把不在线的租约释放。
• 私接路由器：有人在办公网私接路由器，路由器的DHCP开了，导致部分终端从私接路由器拿地址，这些地址不在企业地址池里，但会干扰正常分配。排查方法是抓包看Offer来源MAC，如果不是企业DHCP服务器，就是私接设备。
• 地址池规划不合理：比如一个/24网段有250台设备，池子只开了100个地址。这种情况只能扩容网段或缩短租期。

我处理过一次典型的地址池耗尽：某会议室网段租期设了24小时，每天有大量临时设备接入，下午就耗尽。把租期改成2小时后，地址周转率大幅提升，问题消失。所以租期设置要匹配场景的设备流动性，这是最容易被忽视的优化点。

4.4 抓包分析实战：用Wireshark看懂DORA

抓包是排查DHCP问题的终极手段。在客户端或服务器上抓UDP 67/68端口，过滤表达式：

# tcpdump抓包 tcpdump -i eth0 -n port 67 or port 68 -w dhcp.pcap

用Wireshark打开后，正常流程应该看到Discover、Offer、Request、Ack四个包。常见异常：

• 只有Discover没有Offer：服务器没收到请求，或者收到了但没地址可分配。检查服务器日志。
• 有Offer但客户端没发Request：客户端可能收到了多个Offer，选择逻辑出问题，或者Offer里的参数客户端不接受。
• Request发了但没Ack：服务器可能认为请求的地址不可用，回了Nak。看Nak里的原因码。

提示：抓包时如果看到Discover的源MAC是客户端的，但Offer的目标MAC是广播地址，说明服务器配置了广播回应（有些场景下需要）。正常情况下Offer是单播到客户端MAC。

5. DHCP安全防护：别让“自动分配”变成“自动被攻击”

5.1 常见攻击手法与危害

DHCP设计之初没有考虑安全，任何设备都能伪装成DHCP服务器。常见攻击有：

• DHCP饿死攻击：攻击者伪造大量MAC地址，疯狂发送Discover，把地址池耗尽，导致正常用户拿不到地址。这是最粗暴但最有效的DoS。
• 伪造DHCP服务器：攻击者在网内架设假DHCP服务器，给客户端分配错误的网关和DNS，把流量引到自己这里，实现中间人监听。
• DHCP欺骗：伪造Ack报文，篡改网关或DNS，同样是为了劫持流量。

这些攻击在办公网、校园网、公共WiFi场景下都可能发生，危害从“上不了网”到“数据被窃听”不等。

5.2 交换机层面的防护：DHCP Snooping

最有效的防护手段是DHCP Snooping，部署在接入交换机上。原理是：交换机把端口分为“信任端口”和“非信任端口”。信任端口连接合法的DHCP服务器或中继，允许DHCP响应报文通过；非信任端口连接用户终端，只允许DHCP请求报文通过，丢弃所有DHCP响应。

配置示例（以常见企业交换机为例）：

# 全局开启DHCP Snooping dhcp snooping enable # 上联口设为信任端口 interface GigabitEthernet0/0/1 dhcp snooping trusted # 用户接入口设为非信任（默认即非信任） interface GigabitEthernet0/0/2 dhcp snooping enable

开启后，用户口如果收到DHCP Offer/Ack，会被直接丢弃，伪造服务器就失效了。同时DHCP Snooping还会建立一张“IP-MAC-端口”绑定表，可以配合动态ARP检测（DAI）防止ARP欺骗。

5.3 端口限速与MAC数量限制

针对DHCP饿死攻击，可以在接入端口上限制MAC地址数量和学习速率：

interface GigabitEthernet0/0/2 mac-limit maximum 4 mac-limit action discard

一个用户端口最多学习4个MAC，超过就丢弃。正常一个端口接一台电脑或一个AP，4个足够。这样攻击者无法通过伪造大量MAC来耗尽地址池。

5.4 服务器侧的加固措施

服务器侧也能做防护：

• 限制响应速率：ISC DHCP支持rate-limit参数，限制每秒处理的请求数，防止被洪水攻击打垮。
• 日志审计：记录所有分配和拒绝事件，便于事后追溯。日志里能看到哪个MAC在疯狂请求。
• 定期审计租约表：用脚本对比租约表和ARP表，发现异常租约及时清理。

注意：DHCP Snooping的信任端口配置错误是常见事故。如果把用户口误设为信任，防护就失效了；如果把上联口误设为非信任，合法服务器的响应会被丢弃，导致全网拿不到地址。改配置前一定要确认端口角色。

6. 进阶话题：DHCPv6与IPv6环境下的地址分配

IPv6环境下，地址分配机制和IPv4有本质区别。IPv6主机可以通过SLAAC（无状态地址自动配置）自己生成地址，不依赖DHCP。但SLAAC只能分配地址，不能下发DNS等参数，所以实际部署中常用DHCPv6来补充。

DHCPv6有两种模式：

• 有状态（Stateful）：类似IPv4 DHCP，服务器分配地址和参数，客户端用DHCPv6获取。适合需要集中管理地址的场景。
• 无状态（Stateless）：地址由SLAAC生成，DHCPv6只下发DNS、域名等参数。这是目前企业网较常见的模式，兼顾了自动配置的简便和参数管理的集中。

配置DHCPv6时，路由器通告（RA）报文里的M和O标志位决定客户端行为：M=1表示用有状态DHCPv6获取地址，O=1表示用无状态DHCPv6获取其他参数。这两个标志位配错，客户端行为就不符合预期。

IPv6地址池规划也比IPv4宽松得多，一个/64网段有海量地址，基本不用担心耗尽。但租期机制仍然存在，DHCPv6的租期叫“首选生命周期”和“有效生命周期”，概念和IPv4租约类似。

7. 个人实操体会与几个容易忽视的细节

搞了这么多年DHCP，有几个体会特别深。

第一，租期设置是门平衡艺术。设长了地址周转慢，设短了续租报文多。我的经验是：办公有线网8小时，无线网4小时，会议室2小时，服务器和网络设备用静态绑定不设租期。这个组合在多个项目里验证过，地址利用率能控制在70%以下。

第二，日志一定要开。DHCP服务器默认日志可能只记录启动信息，分配和释放事件需要单独配置。ISC DHCP在dhcpd.conf里加log-facility local7;，然后在syslog里把local7指向单独文件。出问题时，日志能直接告诉你哪个MAC在什么时候拿了哪个IP，比抓包快得多。

第三，跨网段中继的giaddr字段是排查关键。服务器收到请求后，是根据giaddr决定从哪个池取地址的。如果客户端拿不到地址，先确认服务器日志里giaddr是不是预期的网段网关IP。如果giaddr是0.0.0.0，说明中继没配好或者请求是本地广播，服务器不知道从哪个池取。

第四，静态绑定和动态池千万别重叠。我见过有人把打印机静态绑定在10.10.20.150，但动态池range是100到200，结果打印机和动态分配的设备撞了IP。静态绑定的地址一定要在动态池范围之外，或者用range语句把静态段排除掉。

第五，测试环境先验证再上生产。DHCP配置改错影响面很大，轻则部分用户上不了网，重则全网瘫痪。每次改配置前，在测试网段先验证DORA流程、中继转发、静态绑定是否正常，再推到生产。这个习惯帮我避免了好几次重大事故。

最后分享一个实用技巧：如果怀疑网内有伪造DHCP服务器，可以在交换机上临时开启DHCP Snooping，或者用抓包工具监听UDP 68端口的Offer报文，看源MAC是不是合法服务器的。如果发现陌生MAC在发Offer，基本可以确定有私接设备。定位到端口后，直接shutdown该端口，再排查是谁接的。