台虚机:192.168.3.4 ,192.168.3.14。
在192.168.3.14上执行iptables禁用进来的vrrp数据包,但是还能收到192.168.3.4的数据包,这是为什么?
直奔主题
一个packet从网卡的DMA Receive Ring buffer向内核Stack流水线内推(input),内核stack已经提前将packet通过callback发给抓包软件如Wireshark、TCPDUMP、Sniffer,谁运行发给谁。如果3个都运行,3个软件都会收到。
Stack的input流水线并没有因为抓包软件的存在而停止,而是继续内推packet。当推到iptable/NF模块时,恰好match到题主的Filter Policy:
-A input -p vrrp -j DROP
其中:
A = Append
p = protocol
j = jump
通俗地说,增加(Append)一个Policy条目,input方向(packet从网卡上行到stack),如果protocol ==vrrp,直接Drop。
以上是完整的答案。如果对VRRP的工作原理了解,接下来的文字不用阅读了。
VRRP
Virtual Router Redundancy Protocol的缩写。
广播域里每一个主机离开本地广播域依靠谁?
当然是网关(Gateway)了。
如果这个Gateway挂了,包括重启、崩溃、以及莫名其妙的故障,广播域每一个主机还能离开广播域,访问外面的世界(Internet)或公司其它内网网段?
肯定不能了。
电脑前的员工哈哈太爽了,不用干活了。
老板肯定不太爽,什么破网络?赶紧修复并改进,严格杜绝一个节点(网关)失效而造成的网络故障。
如果一个广播域,有多个路由器充当Gateway,且多个路由器拥有相同的IP地址、相同的MAC地址,当其中的一个Gateway挂了,流量会自动切换到其它网关上,是不是就可以避免单点故障(Single Point Failure)?
是的。
但是,一个广播域内多个网关同时使用相同的IP地址/MAC地址会造成地址冲突。
有没有一个解决既什么(物理冗余)又什么(避免地址冲突)的解决方案?
有的,它的名字叫VRRP。
假设,该广播域提供的Virtual IP = 192.168.3.1,它对应的Virtual MAC是多少呢?
图片里显示该广播域使用的vrid(Virtual Router ID) ==51。
将vrid从十进制的51,换算成16进制,得到
vrid == 51 ==0x33(16进制)
加上一个固定的前缀00-00-5E-00-01,得到00-00-5E-00-01-33
Virtual MAC = 00-00-5E-00-01-33
Virtual IP = 192.168.3.1
广播域内的主机在DHCP动态IP地址等参数时,被分配的
Default Gateway= 192.168.3.1
恰好就是上文的Virtual IP,只要有任何一个物理网关可以工作,主机就可以无障碍上网。当ARP广播请求192.168.3.1的MAC地址时,返回的应答MAC==00-00-5E-00-01-33。
以上是VRRP呈现给用户光鲜靓丽的一面,但是VRRP协议是怎么工作的?
VRRP使用的IP = 224.0.0.18,对应的MAC地址可以算出来!
将IP换算成2进制,取从右到左的23位,应该是
0000000.00000000.00010010(2进制)
换算成16进制
0x0.0.12 (16进制)
在左侧添加一个固定的前缀01.00.5e,最终的呈现效果是:
01.00.5e.0.0.12
这个就是VRRP协议自身通信的MAC地址。
当你配置vrrp成功时,发生了什么?
系统将“01.00.5e.0.0.12” 下发到物理网卡,系统有人对这个MAC地址感兴趣,请允许它进入!
当外部vrrp报文到达网卡时,由于上文的高层指示,网卡会用packet的destination MAC做一个判断:
Packet’s Destination MAC ==? 01.00.5e.0.0.12
很显然,会顺利匹配并允许上行。
上行的流水线,抓包工具如tcpdump对流量同样感兴趣,被copy一份走raw socket特殊通道上行。
上行流水线继续上行,到达iptable/NF被policy匹配到扔了。
题主将VRRP配置删除,网卡的感兴趣MAC地址列表立马删除01.00.5e.0.0.12,抓包工具、应用进程再也不会收到来自VRRP的消息了。
为什么?
推荐站内搜索:最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
还没有评论,来说两句吧...