一起学DHCP系列（六）授权、分析

   本节将主要讲述有关DHCP的授权的问题。

   我们在讲述DHCP服务器操作界面的时候似乎没有提到授权这个概念，的确。在工作组环境下所安装的DHCP服务器并没有“授权”选项。但并不代表工作组下的DHCP服务器不需要授权，只是在安装完成后就自己授权自己了，不需要额外干预。如下图：

工作组如果有多台DHCP服务器，客户端获取IP时，发出的DHCP Discover 数据包大家都可以收到，谁的Offer先到达客户端，就会用谁指派的IP地址。其他的IP自然都会被回绝，这是一般性过程。当然这种“优先指派权”的选定取决于多种因素，如客户端性能、服务器性能、链路状态等等。

     但当我们的DHCP服务器是为域用户分配IP、DNS地址时，为了保证域环境的稳定性我们就必须加以控制。基本方法是，任何一台域内的DHCP服务器在为客户端提供网络配置前，必须要先得到授权，这样才可以正常工作。举个简单的演示来说明这个问题，这是有一张拓扑图。如下：

 

我搭建了一个域OS.AD，并且集成安装了DHCP和DNS服务，XP2为一台客户端。现在我们通过实验分析一下DHCP在授权前、后是如何为XP2指派IP地址的。

首先将WIN2K3提升为DC（此过程以后会有描述，此时省略）。完成后如下图：

可以看到，现在WIN2K3已经是一台DC服务器了。

现在安装DHCP组件并创建一个192.168.1.2―192.168.1.5的作用域（过程略）。

完成后如下图：

从上面的图可以看到，在域环境中的DHCP服务器安装完成后，服务默认是不可用的。相比之下，工作组中的DHCP服务器就要简单些了，安装好后不用做设置就是正常状态。右键WIN2K3.OS.AD，我们可以看到此时服务器并没有授权。如下图：

首先激活作用域，但先不进行授权操作，此时接入主机XP2。

这里依然使用wireshark辅助分析。直到XP2获取到IP地址，一共会经历2个过程。

过程一：发送DHCP Discover 数据包查找DHCP服务器。

如下图：

很遗憾，没有能从DHCP那里获取到IP。但在请求数据包中包含一个上次曾经使用过的IP（如果是全新的系统，则第一次申请时不会出现Requested  IP项 ）。如下图：

过程二：使用APIPA分配的IP或上一次使用的IP进行冲突检测。

如下图：

经过这个测试可以看出，即使激活了作用域，由于域中的DHCP服务器没有授权，依然无法被客户端发现，或者说无法接收到客户端的查询请求。现在我们为这台服务器授权，看一下客户端是否可以顺利获取到IP的。

如下图：

授权操作完成后DHCP就可以指派IP地址了。接入XP2主机并开启wireshark。

以下是数据包的捕获情况，同样也分为2个过程。

过程一：DHCP的客户端和服务器之间交互的4个过程。如下图：

这4个过程是客户端首次获取到IP的一般过程，关于详细的解释请参考上节内容。

过程二：对获取的IP进行冲突检测过程。

如下图：

可以看到，客户端利用Gratutous ARP对获取到的192.168.1.2这个IP进行冲突检测，以此确定此IP是否已被使用。现在，客户端现在可以正常使用这个IP了。

不难看出，域内的DHCP服务器只有经过授权后才可以正常指派IP，这个过程和工作组内指派没有很明显的区别。除了上面说的这种授权方式外，我们还可以利用如下方式进行授权。

右键点选DHCP最顶层的DHCP图标，选择【管理授权的服务器】。如下图：

点击【授权】按钮，输入需要授权DHCP服务器的名称或IP即可。如下图：

说了那么多，到底授权的目的是什么呢？其实很简单，就是防止非法的DHCP服务器为客户端提供错误的IP地址、掩码和DNS等网络参数而产生的网络访问故障。当活动目录中有多台DHCP服务器时，其余的DHCP服务器启动时会去查询已授权服务器列表，如果自己的IP在内则开始工作，否则将停止，直到管理员对其授权为止。

那如果某台服务器没有加入域，但也安装了DHCP服务，怎么办呢？我们把这种情况细分为2种。分析如下：

第一种情况：

  工作组中有一台服务器和域在同一个网络内，之后的某个时间在这台服务器上安装了DHCP组件。

   当这台服务器上DHCP服务启动时会向网内发出一个DHCP Inform的广播包，目的是查询网内是否有被授权的DHCP服务器，如果有则自己的DHCP服务禁用，也就是无法自动启用。

假设在现有的拓扑环境中新加入一台2003的服务器（仅仅是接入这个网络）。然后为这个服务器设置一个固定IP，如192.168.1.3，之后安装DHCP组件。原理上这台服务器应该会发送DHCP Inform数据包，我们看看协议上是如何体现的。如下图：

DHCP安装完成后，在启动DHCP服务前，会发送2个DHCP Inform数据包查询网内是否有已授权的DHCP服务器，上图就是Inform数据包的内容。

此时，已授权的服务器，也就是192.168.1.1收到这个数据包后利用DHCP的ACK包回应了此请求。如下图：

当1.3这台服务器收到此回应后，就知道网内已经存在授权的DHCP服务器，自然本机的DHCP服务无法启动，我们也可以从事件日志中查到相关记录。如下图：

紧接着，另一个日志提示告诉我们这台已授权的DHCP服务器的IP。如下图：

OK，通过对第一种情况的分析，我们可以知道在这种情况下，授权服务器可以迫使非法的DHCP服务器无法启动DHCP服务，从而减少了网络产生混乱的可能。

第二种情况如何呢？一起来看！

第二种情况：

    这台独立的服务器事先已经装好了DHCP组件并开启了服务，在某个时间接入了OS.AD域所在的网络（并非加入域）。

我们来模拟一下这个过程。首先在这台服务器安装DHCP服务组件并启动。如下图：

在服务器启动后，会发送4个DHCP Inform的包目的是来查询网内是否有授权的DHCP服务器。如果没有，服务器就可以自我授权了。事件日志中也有所体现，如下图：

可以确定，此时DHCP已经可以正常工作了。我们新建一个作用域scope2，IP范围192.168.1.6―192.168.1.10。如下图：

OK，关键步骤来了。将这台服务器接入到OS.AD的网络中后，发现那台DHCP服务器工作正常。应该是没有受到授权服务器的影响。为了进一步验证我们猜测，现在接入一台客户机，看一下会出现什么情况。如下图：

从上图不难看出同时有2台DHCP服务器为客户端指派IP，这样其实是很危险的，因为如果那台DHCP上随便设置了IP地址范围、DNS地址等重要的网络参数，这样就会导致客户端无法正常域AD通信，包括内、外网都会出问题。如果网络规模很庞大，那后果将不堪设想。所以我们应该极力避免这种情况的发生。一旦出现那该如何处理呢？最直接的办法是找到这台服务器并将其脱离网络，但如果网络规模很大，查找起来就非常困难了。幸好微软提供了Dhcploc这个工具，我们可以利用它来查找非法的DHCP服务器（文件已上传）。

通过这两种情况的分析，大家应该对DHCP服务器的授权有了一定的认识了。企业网内尤其需要注意DHCP等这类可以影响全局环境的服务器角色，它一乱，则全乱。

谢谢！

下节讨论有关租约以及相关命令的知识点。