Linux DHCP部署实战：MAC绑定、超级作用域与中继配置全解析

DHCP 这东西，放在整个网络架构里确实不算起眼，但凡是做过机房运维、管过一两百台终端的人，都会被它坑过。最常见的场景就是：新加了一批设备，明明交换机、网线、VLAN 都没问题，终端就是拿不到 IP；或者是打印机、考勤机这种设备，每次重启 IP 就变了，业务系统直接连不上。追根溯源，多半就是 DHCP 服务器没配置到位。这篇我专门把 Linux 下 DHCP 部署里最实用的三个能力拆开讲清楚：MAC 绑定、超级作用域、DHCP 中继。前两个解决“固定分配”和“地址不够用”的问题，第三个解决“跨网段拿不到 IP”的麻烦，都是生产环境里实打实的高频需求。

我尽量把配置实例、命令、踩过的坑都摆出来，不是光讲概念，而是你照着能抄作业的程度。如果你手头正准备搭一台 Linux 的 DHCP 服务器，或者已经在跑了但时不时出幺蛾子，这篇应该能省你不少排查时间。

1. 先搞清楚这三个需求到底解决什么问题

1.1 一个网络管理员经常遇到的三种场景

先说个我印象很深的例子。之前接手某公司办公网，一个网段里塞了三百多台设备，地址池早就被 DHCP 分得七七八八。领导说下个月要再进一批办公电脑，我一看可用地址还不够二十个，这还怎么玩？后来跟网络那边商量，把另外一段空闲的地址也划到同一个二层链路里，这就用上了超级作用域。

第二个场景是打印机。行政那边三天两头报故障，说打印机动不动就连不上。我过去一看，打印机拿的是动态 IP，路由器和交换机的 ARP 缓存一刷新，它就换地址，电脑里配置的打印机端口还是旧地址，能不失败吗？这种设备必须做 MAC 绑定，让它在 DHCP 里永远拿同一个固定地址。

第三个场景更常见。公司有两层楼，市场部在一层，研发在二层，各用一个网段，中间靠三层网关隔开。这时候如果只有一台 DHCP 服务器放在研发网段，一层那些终端广播 DISCOVER 根本到不了服务器，自然拿不到地址。很多人第一反应是“那就再买一台服务器”，其实不用，用 DHCP 中继就好，一台服务器就能覆盖所有网段。

这三个需求我放在一篇文章里讲，是因为它们在实际部署里经常是一起出现的：一台服务器要同时做普通动态分配、给特定设备绑定地址、给多个网段提供分配服务。你可以在一个配置文件里把它们全部组合起来。

1.2 开始之前：DHCP 工作的基本流程

在写配置之前，先把 DHCP 的运行机制捋一遍，不然后面遇到问题容易乱。整个过程可以概括为四个报文：DISCOVER、OFFER、REQUEST、ACK。客户端开机后发一个广播的 DISCOVER，询问“谁是这个网络里的 DHCP 服务器”；服务器收到后回应一个 OFFER，告诉它“我可以给你这个 IP”；客户端收到 OFFER 后如果认可用，就发 REQUEST 确认要这个地址；最后服务器发 ACK 确认完成分配。

这里有个关键点：DISCOVER 是广播，路由器默认不会转发广播。所以当服务器和客户端不在同一个网段时，就需要中间那台路由器或者三层交换机开启 DHCP Relay 功能，也就是中继，把广播转成单播发给服务器。服务器回包的时候也先回给中继，中继再转发给客户端。

理解了这条链路，后面配置中继时你就知道为什么要在中间设备上做手脚，而不是简单地把服务器接到核心交换机就完事。而 MAC 绑定和超级作用域，本质上都是服务器端根据客户端信息决定“给什么地址”的策略，只是在配置写法上各有门道。

2. 基础配置：先把一台能用的 DHCP 服务器跑起来

2.1 安装与主配置文件结构

不管后面要加多少高级功能，根基都是一台能正常下发地址的 DHCP 服务。Linux 下最常见的 DHCP 服务程序是 dhcpd，几乎各主流发行版的软件源里都带，用对应的包管理器装上就行。

装完之后，核心的工作都集中在主配置文件里。这个文件一般叫 dhcpd.conf，有的发行版放在 /etc/dhcp/ 目录下，有的直接放 /etc/。不确定位置的话，可以用查找命令定位一下，或者直接看服务启动日志，它会告诉你具体读了哪个文件。

配置文件的逻辑分两大块：全局参数和地址池声明。全局参数影响所有地址池，比如租期、DNS、域名这些，通常写在文件最上面。地址池声明则用 subnet 块来描述“哪个网段，分配哪些地址，网关是谁”。一个基本配置大概长这样：

option domain-name "internal.example"; option domain-name-servers 192.168.1.2; default-lease-time 600; max-lease-time 7200; authoritative; subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.100 192.168.1.200; option routers 192.168.1.1; option subnet-mask 255.255.255.0; }

这里面每一项都有实际意义。domain-name-servers 是给客户端下发的 DNS 服务器地址；default-lease-time 是客户端没有单独要求租期时默认用的时间，单位是秒；max-lease-time 是客户端申请的租期上限。authoritative 这行比较重要，它告诉 dhcpd“你在这个网段里是权威服务器”，当客户端持有某个该网段的地址但不在 address pool 里时，服务器会主动发 NAK 让客户端重新申请，避免客户端死守一个不该用的地址。

2.2 subnet、range、option 到底怎么填

对于刚开始接触的人来说，最容易犯迷糊的是 subnet 后面那串数字。subnet 后面的地址和掩码决定了这个地址池属于哪个网段，但它的作用不只是声明“我有这个网段”，更重要的是，dhcpd 要根据收到请求的接口和网络号，来决定从哪个池子里分配地址。

range 才是真正划出可分配地址范围的语句。你可以写一行连续的地址，也可以写多行把地址段拆开，比如把 1~50 留给手工配静态 IP 的设备，从 100 开始给 DHCP 分。这个习惯我强烈建议保持，不然以后做 MAC 绑定会发现没有空闲地址可用。

option routers 就是给客户端下发网关。很多人不理解为什么 DHCP 配置里要写网关，因为客户端拿到 IP 只是一部分，它还需要知道怎么访问其他网段，网关、掩码、DNS 都必须通过 DHCP 一起下发，否则客户端只能跟自己在同一个广播域里的设备通信，上不了外网也访问不了其他部门。

这里的掩码和 subnet 声明的掩码一般不冲突，但要注意保持一致。你声明 subnet 192.168.1.0 netmask 255.255.255.0，然后 range 里写一个 192.168.2.0 的地址，dhcpd 会直接报错，这种错误用语法检查命令很容易发现。

2.3 启动、验证、看日志

配置写完之后，不要急着直接重启服务，先做语法检查：

dhcpd -t -cf /etc/dhcp/dhcpd.conf

-t 就是测试模式，它会解析配置文件，如果有语法错误会直接输出到终端，没有错误一般不打印东西。这一步非常值得养成习惯，我见过太多人一改配置就 systemctl restart，结果服务起不来，数据库里还不知道错在哪。

确认无误后启动服务，然后立刻看日志：

systemctl start dhcpd systemctl status dhcpd tail -f /var/log/messages

不同发行版查看日志的方式略有差异，但思路是一样的：启动时看有没有报错，运行中看有没有客户端的 DISCOVER 和 OFFER 记录。运行状态下，正常分配一条 IP 的日志大致长这样：收到某 MAC 的 DISCOVER，发给它 OFFER 某个地址，再收到 REQUEST，最后 ACK。如果日志里只有 DISCOVER 没有后续，说明服务器在某个环节拒绝了分配，这时候排查的重点就落在配置的 range、subnet 和中继设置上。

还有一件容易忽略的事：DHCP 服务默认监听在所有支持广播的网卡上，但有时候你只想让它服务某一个网卡或者某几个网卡。这可以在服务的默认配置文件里指定，比如在 Debian 系的 /etc/default/isc-dhcp-server 里配置 INTERFACESv4 参数，在 Red Hat 系的 /etc/sysconfig/dhcpd 里配置 DHCPDARGS。如果服务器本身有多块网卡、连了多个不同的二层网络，这个参数不配好，很可能会出现“客户端请求来了但服务器不响应”的诡异问题，因为请求从没监听的网卡进来直接被忽略了。

3. MAC 绑定：让特定设备永远拿到同一个 IP

3.1 host 声明怎么用

MAC 绑定在 dhcpd 里的正式叫法是“地址保留”或 host 声明。原理很简单：DHCP 服务器收到客户端的 DISCOVER 报文时，报文里带着客户端的 MAC 地址，服务器根据 MAC 去匹配配置文件里已经定义好的 host 条目，如果匹配上了，就直接给这个客户端分配指定的 IP。

配置写法如下：

host printer-01 { hardware ethernet 00:1a:2b:3c:4d:5e; fixed-address 192.168.1.50; }

hardware ethernet 后面写的就是设备的 MAC 地址，fixed-address 后面写的是要固定分配的 IP。这个 host 块可以放在全局配置区域，也可以放进某个 subnet 块内部。放在全局区域时，dhcpd 会在收到匹配这个 MAC 的请求时，直接看 fixed-address 属于哪个网段，配对后分配出去。放在 subnet 内部时逻辑更直观，就是这个网段内的绑定。

还有个细节：fixed-address 指定的地址，最好是从 range 里排除出去的。比如你的 range 是 192.168.1.100 到 192.168.1.200，那绑定的地址就可以设在 50 这种较低的位置，避免动态分配池和保留地址相互冲突。如果你的固定地址写在 range 范围内，也可以工作，但可能会遇到一个尴尬情况：服务器已经把这个地址动态租给了另一台设备，这时再给绑定设备分配就会出现冲突，轻则客户端拿不到 IP，重则网络里出现重复地址，排查起来非常麻烦。

3.2 拿到准确的 MAC 地址

MAC 绑定看起来简单，实际部署时最花时间的反而是“怎么拿到设备的真实 MAC 地址”。客户端如果是一台已经开机的设备，可以在它本机上看网卡 MAC；如果是一台无法登录系统的设备，比如网络打印机，那就得在交换机上看 ARP 表，或者在 DHCP 服务器的租约文件里查。

租约文件是 dhcpd 自动生成的，一般位于 /var/lib/dhcpd/dhcpd.leases。里面记录着每次分配的地址、对应 MAC、租约起止时间。这个文件在生产环境里非常有价值，既能查历史分配记录，也能帮你找到还没做绑定设备的 MAC 地址。要注意的是，租约文件很长，而且会持续增长，做 MAC 绑定前最好先 grep 一下目标 MAC 有没有出现过，确认它确实是这个设备的。

还有一点要特别提醒：不要从客户端配置界面里随便复制 MAC，尤其是虚拟机。很多虚拟机平台支持修改网卡 MAC，同一个系统镜像克隆出去，网卡地址可能一样，导致多台设备 MAC 完全重复，这种情况下 MAC 绑定等于失效。物理机也要注意，主板上有线网卡和无线网卡的 MAC 是两回事，绑错了设备一样拿不到正确地址。写进配置文件之前，建议在客户端上用 ipconfig /all（Windows）或 ip link（Linux）确认一下活跃网卡的 MAC，别只看设备标签。

3.3 我在 MAC 绑定上踩过的坑

MAC 绑定这个功能很多人以为“写上 host 就完事了”，实际使用中坑不少，我这里集中说几个亲身经历过的。

第一个坑是 MAC 地址格式不统一。dhcpd 里标准的写法是用冒号分隔的十六进制，比如 00:1a:2b:3c:4d:5e。但有些设备管理界面上显示的是用短横线分隔的，比如 00-1a-2b-3c-4d-5e，或者在 Windows 的 ipconfig 里显示成 00-1A-2B-3C-4D-5E。直接复制过来放在配置文件里一般也没事，dhcpd 解析时对分隔符不敏感，但统一格式能减少维护时看花眼的概率。

第二个坑是绑定地址和动态地址池重叠。我前面提到过，如果绑定的 IP 落在 range 范围内，理论上也能工作，但偶尔会出现“绑定设备启动时发现这个 IP 已经租出去了，只能被分到别的地址”的情况。最稳妥的做法是把绑定 IP 规划在一个独立的小地址范围里，或者用 deny 语句把它们从 range 里排除掉。比如：

range 192.168.1.100 192.168.1.200; deny bootp;

甚至可以直接把 range 写成非连续的块，把固定地址所在的那一段空出来。这样既保证动态池有充足地址，又不会跟绑定地址打架。

第三个坑比较隐蔽，就是“同一 MAC 出现在多个 host 声明里”。不管是复制粘贴出了错，还是后来修改配置时忘记删旧条目，只要配置文件里出现两个相同 MAC 的 host，dhcpd 在解析时可能会通过语法检查，但运行时匹配逻辑就会出问题，表现为这台设备时而拿到这个地址、时而拿到那个地址，很难排查。所以大型环境里维护 host 列表，我建议写成一个单独的配置文件，然后在主配置里 include 进来，这样便于用脚本去重检查。

4. 超级作用域：一个物理链路不够用时怎么办

4.1 什么是超级作用域，什么时候必须用

先讲一个基本概念。正常情况下，一个物理网段（或者说一个广播域）对应一个 IP 网段。但现实里经常有这样的情况：公司扩张，网络设备没换，只是把两个原本独立的部门划到了同一个交换机网络里，或者原有网段地址不够用了，新规划了一个网段，但这两个网段在二层是打通的，所有设备都在同一根线上。

这时 DHCP 服务器如果只配置了一个 subnet 的 range，那第二个网段的机器虽然能和第一个网段的机器二层互通，但拿不到任何地址，因为服务器只会从自己的 range 里挑地址，而这个 range 属于另一个网段。如果你强行在服务器上再写一个 subnet，然后两个 subnet 平铺在配置里，dhcpd 会认为这是两个互不相干的网络，分配行为会变得不确定。

超级作用域就是解决这个问题的。它用一种叫 shared-network 的结构，把多个 subnet 包在同一个逻辑块里，告诉 dhcpd：这几个网段其实跑在同一条物理链路上，可以视为一个大的地址池。客户端广播 DISCOVER 时，服务器会在这个 shared-network 内部的所有 subnet 里统一挑选可用的地址。

这个需求在办公网合并、校区地址改造、临时会展网络这类场景里特别常见。只要“一个二层网络里跑多个网段”这个条件成立，超级作用域就是比写多个独立 subnet 更准确的配置方式。

4.2 shared-network 配置实例

直接看配置。假设办公区现在有 192.168.10.0/24 和 192.168.20.0/24 两个网段，它们在同一个交换机网络上，DHCP 服务器用一块网卡连着这个网络。配置可以这样写：

shared-network office { subnet 192.168.10.0 netmask 255.255.255.0 { option routers 192.168.10.1; option subnet-mask 255.255.255.0; range 192.168.10.100 192.168.10.200; } subnet 192.168.20.0 netmask 255.255.255.0 { option routers 192.168.20.1; option subnet-mask 255.255.255.0; range 192.168.20.100 192.168.20.200; } }

这样配置以后，客户端只要能和这台服务器广播互通，dhcpd 就会在两个 subnet 之间选一个还没满的地址池分配。如果 192.168.10.x 这个池子地址快分完了，新设备可能会拿到 192.168.20.x 的地址，网关也跟着变，不需要人工干预。

这里有一个容易被忽略的细节：客户端拿到 192.168.20.x 的地址后，网关是 192.168.20.1，这意味着这台客户端要访问外部网络，数据包会走 192.168.20.1 出去。如果这个网关在三层交换机上已经配置了对应的 VLAN 接口，那就没问题；如果网络实际只有一个 VLAN，网关只有 192.168.10.1，那你需要在 20 段里也把 option routers 指到 192.168.10.1，否则客户端虽然拿到了地址，还是上不了网。

4.3 超级作用域容易被忽略的细节

超级作用域还有个特点，就是它不改变 DHCP 服务器的物理监听行为。服务器还是监听在那块网卡上，但地址池变成了一个“共享空间”。如果服务器有多块网卡、连接多个互不相通的网络，那你需要特别注意每个网卡对应的 shared-network 得和它的物理网络匹配，否则会出现一个网络里的客户端，收到另一个网络地址池里的地址，配置完全不为所动。

另外，有人会把超级作用域和中继混为一谈。其实这是两码事：超级作用域解决的是“同一个二层网络里多网段”的分配问题；中继解决的是“服务器和客户端不在同一个二层网络里”的通信问题。如果客户端在另一个楼层、隔了三层交换机，那光写 shared-network 是不够的，必须配合中继或者多网卡拉通，让 DISCOVER 报文能到达服务器。

从配置角度来说，超级作用域里的 subnet 块里也可以写 host 绑定。比如我想让 20 网段里的一台打印机绑定到 192.168.20.50，直接在对应的 subnet 块里加一个 host 声明就行，逻辑上很清晰。这也是我比较推荐的做法：把 MAC 绑定和地址池的规划放在同一个结构里，后续维护时打开配置文件一目了然。

我实际用下来还有一个体会：超级作用域适合做“短期过渡方案”，不太建议长期依赖。比如公司合并、地址重新规划期间，新旧网段都有设备在用，用 shared-network 能让新旧设备平滑过渡，等所有设备都迁到新网段后，再逐步缩小旧网段的 range，最后把旧段整个删掉。如果在地址规划阶段就预估到“这个物理网络未来几年会有多个网段”，那不如直接把三层的 VLAN 划分做好，让每个 VLAN 一个网段，再用中继来统一分配，这样以后扩容和维护都清晰得多。

5. DHCP 中继：跨网段分配 IP 的必杀技

5.1 为什么需要中继

前面反复提到中继，这里单独拿出来细说。DHCP 的 DISCOVER 和 REQUEST 都是广播报文，广播不能跨三层。也就是说，一台交换机上的客户端发出的请求，正常情况下只有同一网段里的 DHCP 服务器能收到。如果服务器在另一个网段，请求到不了，客户端永远拿不到 IP。

解决这个问题有两种思路：一种是在每个网段都放一台 DHCP 服务器，简单粗暴，但地址池分散、管理麻烦、成本也高；另一种就是配置 DHCP 中继，让位于客户端和服务器之间的三层设备（路由器、三层交换机或一台 Linux 主机）把广播请求转为单播，替客户端把请求送到服务器，再把服务器的应答带回客户端。

中继的原理可以这样理解：客户端广播找“谁是这个网段的 DHCP 服务器”，三层设备听到了，一看这不是发给自己的，但它认识真正的服务器在哪，就顺手把请求封装一层单播包发给服务器，同时在包里的 giaddr 字段填上自己的 IP。服务器一看 giaddr，就知道客户端在哪个网段，于是从对应网段的地址池里选地址，把 OFFER 发给中继，中继再在客户端那个网段里广播出去。整个过程对客户端是透明的，它甚至感受不到中间经了一道手。

5.2 服务器端和中继端的配置

要跑通中继，服务器端和中继端两边都要配置，缺一不可。

服务器端要做的事很简单：在 dhcpd.conf 里，把每个需要服务到的网段都写成对应的 subnet 块。比如服务器在 192.168.10.0/24，要给 192.168.20.0/24 提供服务，那你就要在配置文件里写一个 192.168.20.0/24 的 subnet 块和对应的 range。dhcpd 会根据中继报文里的 giaddr 找到这个 subnet，然后选择地址。如果服务器上压根没有这个 subnet 声明，它收到中继过来的请求也不会回应，因为在它看来不知道从哪儿掏出一个地址给客户端。

中继端在大多数企业环境里是路由器或三层交换机上开启 DHCP Relay 服务，配置方式因设备而异，原理都一样：指定哪个接口收到 DHCP 广播要中继，以及把请求送往哪台服务器的 IP。比如在核心交换机上，进入对应 VLAN 的三层接口，开启 relay 并指定 DHCP 服务器地址：

interface Vlan20 ip helper-address 192.168.10.10

如果你手上没有现成的三层设备，也可以拿一台双网卡的 Linux 主机当中继。Linux 下常用的中继工具是 dhcrelay，用法很直接：指定监听客户端请求的接口，然后传服务器的 IP 地址。

dhcrelay -d -i eth1 -i eth2 192.168.10.10

其中 -i 参数指定参与中继的网卡，最后一个是 DHCP 服务器地址。这样配置后，eth1 收到的客户端广播会被转发到服务器，In服务器回包也会通过 eth2 送回来。注意这台 Linux 主机必须能路由到服务器，也就是两台机器之间的路由要通，而且防火墙要放行 UDP 67 和 68 端口。

5.3 抓包验证中继是否工作

中继配置完之后不可见性很高，最容易出现“配置了但发不到”的情况。我的习惯是用抓包来验证，而不是只凭感觉。

在客户端上，可以观察它有没有发起 DISCOVER。在服务器上，直接抓 UDP 67 和 68 端口的包：

tcpdump -i any -nn -vv port 67 or port 68

如果客户端发起了请求且中继工作正常，服务器上会看到来源 IP 是中继设备的地址。如果看到来源 IP 是客户端地址，说明中继没生效，这个请求大概率是广播直接过来的，那服务器回包也会因为跨网段回不去而失败。

还有一种情况：服务器上能看到 DISCOVER，但日志里没有 OFFER，或者直接发 NAK。这时候优先检查配置文件里是否包含对应该网段的 subnet 声明。如果你在服务器上只写了 192.168.10.0/24，而中继填的服务器收到的是 192.168.20.0/24 网段的请求，那服务器会因为找不到匹配池而保持沉默，客户端一看没人应答，过几秒再发一次广播，如此反复直到失败。

另外一个容易忽略的点是：如果 DHCP 服务器有多块网卡，要确保它和中继设备之间的那条链路是可用的。中继是单播发给服务器，服务器也是单播回给中继，这两个报文不需要客户端网段里的任何参与，但需要服务器本身路由可达。很多中继排到最后发现是防火墙拦截了 67/68 端口的单播流量，或者服务器上只有一块网卡配了默认网关，导致回包从错误的接口出去，白折腾好久。

6. 常见问题排查速查表

6.1 客户端拿不到 IP

客户端拿不到 IP 是 DHCP 部署最经典的问题，涵盖的原因也最多。如果客户端开着 DHCP 却一直停留在“获取地址中”，我的排查顺序是固定的：先看客户端网络通不通，再看 DHCP 服务器在哪，最后看配置对不对。

客户端网络不通的问题里，比较常见的是物理链路问题，比如网线没插好、交换机端口 VLAN 配错。这个可以通过静态配置一个临时 IP 来验证，如果能 ping 通网关，说明链路没问题。如果静态 IP 都不通，那问题在链路和交换机，跟 DHCP 关系不大，先别急着折腾服务器。

如果链路正常但 DHCP 拿不到地址，那就转到服务器上看日志。日志里如果连 DISCOVER 都没出现，说明请求可能根本没到服务器，要么是广播域被隔离，要么是中继没配置。日志里出现了 DISCOVER 但服务器没回应，大概率是服务器认为这个网段“不该由我来管”，也就是 subnet 声明缺失或 range 没有覆盖。日志里出现了 OFFER 但客户端没收到，则可能是回包路径被防火墙拦截，或者中继设备的 ARP 缓存有问题。

6.2 配置检查与日志怎么看

dhcpd 的日志信息量很大，但格式比较固定，学会看几个关键字能省不少时间。正常分配时日志里依次出现 DHCPDISCOVER、DHCPOFFER、DHCPREQUEST、DHCPACK。如果你看到 DHCPDISCOVER 后直接跟着 DHCPNAK，说明服务器拒绝了这个请求，原因通常是客户端携带的地址不在允许范围内，或者网络号对不上。看到多次 DHCPDISCOVER 没有后续，则说明服务器没有任何应答，重点查 subnet 是否匹配。

配置层面的自查，我会把 dhcpd.conf 的几个关键参数检查一遍：subnet 地址和接口实际 IP 是否在一个网段；range 是否和 subnet 掩码匹配；host 里的 MAC 是否重复；shared-network 里是否嵌套了不该嵌套的语句。所有这些检查，第一条永远是 dhcpd -t 语法测试，先把语法错误排除掉，再去查逻辑问题。

租约文件也是一个重要排查入口。如果多次分配后客户端还是拿不到想要的地址，去查 /var/lib/dhcpd/dhcpd.leases 里这个客户端最近一次拿到的地址，看看服务器当时是怎么分配的。如果租约文件里记录的地址和配置里的绑定地址不一致，那问题多半出在 host 声明写错或者绑定地址和 range 重叠。

6.3 几个屠宰率最高的问题

我整理了这么几张速查表，方便你遇到问题的时候直接对照。

再单独说说防火墙的坑。很多发行版的防火墙规则默认不会放行 DHCP 的 UDP 67/68 端口，尤其是从外部网络接口进来的请求更容易被拦。如果你配置都正确但服务始终不响应，可以先临时关掉防火墙测一下，如果一关就好，那就在防火墙规则里给 DHCP 放行。SELinux 也是类似的排查方向，开启状态下可能拦截 dhcpd 写入租约文件或读取接口信息，日志报错会非常诡异。

还有个大坑是虚拟机网络模式。如果你是在一台虚拟机里测试 DHCP，客户端是另一台虚拟机，务必把两块虚拟网卡放在同一个虚拟交换机上。很多初学者把服务器放在 NAT 模式、客户端放在桥接模式，两边根本不在一个广播域里，无论怎么配都不可能通。

7. 给想继续折腾的人一些方向

这篇文章主要围绕“把 DHCP 跑起来、跑得稳”展开，但其实这些配置只是入门。在实际生产里，我还有一些建议，适合你在基础功能稳定之后继续研究。

第一个方向是租期和冗余。单台 DHCP 服务器总有宕机的时候，一宕机整个网络的新设备都无法上线。dhcpd 支持 failover 双机模式，两台服务器互相备份租约信息，主服务器挂了备机可以接管。这个配置稍微复杂一点，但可靠性提升是非常明显的，适合公司网络核心这种不允许停的位置。

第二个方向是安全和审计。DHCP 本身没有强认证机制，网络上任何一个设备都可能伪装成服务器下发错误网关，这就是常说的 DHCP 欺骗。有条件的话，可以在交换机上开启 DHCP Snooping，只信任连接真正 DHCP 服务器的端口，其他端口只允许客户端发 DISCOVER，不允许回 OFFER。这样即使有人接了一台家用路由器进来，也无法干扰正常分配。

第三个方向是地址规划前置。每次配置 DHCP 之前，花点时间把固定绑定、动态池、手工静态地址单独规划成三段，宁可留一些冗余地址，也不要让它们互相交叉。这个习惯看起来不起眼，但确实能帮你避免日后大量的排查时间。

DHCP 看起来是个“小服务”，但它直接影响整个网络的可用性。一个真正稳定的 DHCP 部署，靠的不是什么高深技巧，而是把基础配置做扎实、把常见问题预案做好。希望这篇里讲到的 MAC 绑定、超级作用域和中继配置思路，能帮你在实际环境里少走一些弯路。