Ping超时,Why?从Sniffer上捕获的数据包可以更清楚的进行说明:
下图是捕获的数据包,它描述了Fake(192.168.0.8) Ping 192.168.0.1的全部过程: Click here to open new window CTRL+Mouse wheel to zoom in/out
由于Fake(00:060:06:05:47)没有192.168.0.1的MAC地址,所以Fake发送ARP地址解析请求广播,询问192.168.0.1的MAC地址是什么;
ISA Server(00:03:47:F4:FC:E7)使用ARP应答回复Fake(00:060:06:05:47),告诉Fake自己的IP地址(192.168.0.1)和MAC地址;
获得192.168.0.1的MAC地址后,Fake(192.168.0.8)向192.168.0.1发送PING请求数据包;
192.168.0.1向192.168.0.8回复PING回复数据包;
Fake(192.168.0.8)再次向192.168.0.1发送PING请求数据包;
192.168.0.1再次向192.168.0.8回复PING回复数据包;
这一切看起来没有任何问题?那为什么Fake的Ping会超时呢?
这一切从表明上看是没有任何问题,但是仔细看捕获的数据包的以太网头部,你就会发现问题所在:
首先,我们看第三个数据包,Fake(192.168.0.8)向192.168.0.1发送的Ping请求,如下图所示,Fake以自己的MAC地址为源MAC地址、192.168.0.1的MAC地址(00:03:47:F4:FC:E7)为目的MAC地址发送数据包,这没有任何问题。
Click here to open new window CTRL+Mouse wheel to zoom in/out
那么看看第四个ISA Server回复的Ping回复数据包呢,源MAC地址是ISA Server的MAC地址(00:03:47:F4:FC:E7),这也没有问题,但是注意看目的MAC地址,00:0D:60:C3:05:34是离线的客户机True的MAC地址。还记得我们在ISA Server上做的IP地址(192.168.0.8)和MAC地址绑定吗?
ISA Server直接使用自己ARP缓存中的静态绑定项来发送数据,而不是使用收到的Ping请求数据包中的源MAC地址来作为目的地址。
因此,Fake认为此数据包不是发给自己的,不会处理此数据包,所以认为没有Ping回复数据包,自然就是超时了。
Click here to open new window CTRL+Mouse wheel to zoom in/out
最后说一下,
我不推荐大家使用静态IP地址和MAC地址的绑定,这会带来更多的管理负荷。你可以利用ISA Server强大的身份验证功能,结合IP地址来进行管理,这样具有更好的效果。也请不要在论坛问我ARP命令是如何使用的,Windows的帮助是最好的老师。