模板
教程
環境
性能
功能
管理
dhcp server
發表于：2007-07-04來源：作者：點擊數：
標簽：
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服務器對于工作組環境的機器還是會起作用的。
表達能力不強，見諒！
