dhcp server

发表于:2007-06-09来源:作者:点击数: 标签:
platinum 老大这里确实理解有问题,ip数据报不可能没有mac信息 二层数据报: frameheader---framebody 三层数据报: frameheader---ipheader---ipbody 对于工作在二层的设备来说任何数据报都只区分为数据头和数据体,一个ip包的ip头和ip数据会被统一认作二层
platinum 老大这里确实理解有问题,ip数据报不可能没有mac信息

二层数据报:
frameheader---framebody
三层数据报:
frameheader---ipheader---ipbody

对于工作在二层的设备来说任何数据报都只区分为数据头和数据体,一个ip包的ip头和ip数据会被统一认作二层数据体。
而对于工作在三层的设备来说,基本上是二层已经根据二层头作过相应处理提交上来的,但你不能说它没有二层头,这个信息肯定是保留的,只是对于三层设备来说只能拿到二层设备已经分拣过的数据。

iptables确实是工作在三层及以上,这从iptables几个钩子函数的位置可以看出。有了这个结论,再澄清两点:
1,关于iptables的mac过滤----虽然工作在三层,但是二层信息也是存在的,所以过滤也是可行的,但有一点限制,就是二层向三层递交时,只会递交你能对应识别的三层包:
        (1)iptables是工作在第三层ip协议下,你iptables当然不可能抓到其他三层协议的数据报,比如,你无法处理ipx包。
        (2)iptables是工作在第三层ip协议下,不能处理二层没有提交到三层的数据报,比如arp请求和rarp请求,你是过滤不到的。
2,关于为什么iptables无法过滤dhcp请求----根据第一点的结论,这一点也很显然可以得出结论了:
       (1)dhcp协议是一个ip地址分配协议,面向的是还没有建立ip协议盏的client,对于此类的client,很显然不可能使用目前还不存在的三层协议通讯来分配三层地址。
       (2)由(1)的结论以及rfc可知,dhcp是通过二层广播来传送报文的,所以共享hub环境和交换环境的广播处理的不同导致的不同的结果。
       (3)根据(2),此时的dhcp报文,对于dhcpserver来说,不可能提交到ip层,所以不经iptables处理,对于dhcpclient,ip协议盏还没建立起来,你iptables都还没出生,你还能干什么?



所以对于dhcp,只能从二层环境想办法,iptables就别想了,ebtables应该还可以有所作为,再加上交换环境和共享环境的不同,相信也能得出自己相应的解决办法了。

再有就是Windows的验证dhcp问题,这个是因为Windows特有的AD构建的特有的安全边界导致的,你可以看一下,所谓的验证dhcp服务器,只能用于域存在的环境,如果在同一网段即存在域和工作做,那恶意dhcp服务器对于工作组环境的机器还是会起作用的。


表达能力不强,见谅!


原文转自:http://www.ltesting.net