DHCP中继数据包互联网周游记

一.概述：

二层不少实验用GNS无法模拟，IOU大部分只有命令无法看到效果，好不容易有机会登录机架做实验，做了dhcp snooping实验，发现思科路由器如果作为DHCP服务器，必须配置ipdhcp relay information trusted，否则客户端无法获取IP地址，如是想DHCP服务器用Windows 2003会是什么效果，随即将登录机架的2003添加DHCP服务，但是发现DHCP服务不能使用，查询系统日志，是因为这台处于工作组中的2003同网段有一个域控，它上面也跑了DHCP,一山不容二虎，碰到正牌的DHCP，我的这个工作组的DHCP只能一边呆着了。

经过请示，域控无法让我登录测试，并且做测试用的服务器不准安装虚拟机软件，期间尝试修改过测试服务器的子网掩码，没有效果，如是想借用外部DHCP来做测试，下面是几次测试：

A.虚拟机（DHCP服务器）+宿主机端口转发+GNS测试
B.EzVPN拨入+测试服务器端口转发+连接机架测试
C.DHCP服务器同时VPN服务器，PC1拨VPN+GNS，直接采用路由方式测试
D.虚拟机（DHCP服务器，VPN服务器）+宿主机端口转发（同时拨入VPN)+GNS测试

二.虚拟机（DHCP服务器）+宿主机端口转发+GNS测试:

A.测试结果：

---成功

B.测试拓扑：

C.配置介绍：

①PC1其实是宿主机，配置了UDP端口转发

②之所以路由器中继代理的端口地址与宿主机一块网卡地址相同，是因为DHCP服务器会根据DHCP单播包中DHCP中继的地址回包，而不会看到达它的UDP三层包头的地址

③因为DHCP服务器回包的特点，所以端口转发需要配置两个方向

④R2配置了静态NAT，是因为需要确保UDP端口转发时，把数据回到中继代理端口地址

三.EzVPN拨入+测试服务器端口转发+连接机架测试：

A.测试结果：

---失败

B.测试拓扑：

C.失败原因分析：
①在PC1的100.7网卡上面抓包，只有发出去的DHCP单播包，但是没有回来的数据包

②在PC1上查看发出去的DHCP单播包，发现UDP的源端口从原先的67已经发生了改变

③在DHCP服务器上面抓包，发现DHCP服务器回包的UDP源端口和目标端口都是67

④估计是因为DHCP服务器回包的UDP目标端口与接收数据包的UDP源端口不一致，被EzVPN客户端或EzVPN服务器丢弃了

⑤因为VPN服务器与PC1中间的路由无法控制，因而这种方式无法用路由方式解决，

四.DHCP服务器同时VPN服务器，PC1拨出+GNS，直接采用路由方式测试:

A.测试结果：

---失败

B.测试拓扑：

跟上图类似，只是换了中拨号方式，把DHCP服务器同时配置成VPN服务器，PC1拨出。

C.失败原因分析：

拨号口无法作为下一跳地址。

五.虚拟机（DHCP服务器，VPN服务器）+宿主机端口转发（同时拨入VPN)+GNS测试:

A.测试结果：

---成功

B.测试拓扑：

C.成功总结：

说明微软的VPN不会像思科的EzVPN，会检查数据包的端口，即做状态检查，把UDP端口不一致的数据包丢弃。这种方式只需把PC1换成连接机架的PC即可。值得注意的是，拨号成功后默认网关会被修改，因此需要同网段的其他PC配合，远程登录到PC1进行拨号，拨号完成后手工做隧道分离。如果没有同网段的其他PC可以利用，也可以在拨入成功后，利用2003的VPN服务器远程登录，连接的地址为VPN分派给客户端的地址，或者通过如下方式修改拨号连接的属性：

通过登录机架验证了上面的方法，通过抓包可以看到交换机给DHCP的Discover包添加了82选项，并且微软DHCP不识别这个选择，也无需做其他的配置就能正常的下发IP地址：

六.实验总结：

A.DHCP中继口也需要配置ip dhcp relay information trusted，否则带有82选项的request包根本就不转发。

B.微软DHCP服务器不识别82选项。

C.DHCP Server分派地址时需要设定正确的网关，R2配置默认路由到200.1.1.8，PC1需要开启Routing and Remote Access，否则，DHCP Release包无法到达DHCP服务器。
D.如果交换机连接DHCP服务器或DHCP中继的接口没有配置ip dhcp snooping trust，交换机不会转发DHCP Request包

本文转自 碧云天 51CTO博客，原文链接：http://blog.51cto.com/333234/1204881，如需转载请自行联系原作者