腾讯云网络vpc之arping返回MAC一样问题
背景
在腾讯云vm里面,通过arping命令测试vpc子网内所有机器返回的网卡硬件地址(mac地址)都是一样,其实也可以通过arp -n查看其信息。
这里可以明显的看到,arp请求的报文大概率被劫持了,然后统一回复了FE:EE:FF:AD:71:C8这样的MAC。
这里涉及到一个概念ARP Proxy。ARP Proxy是一个设备(通常是路由器或防火墙)代替另一个设备响应 ARP 请求。
例如:
● 主机 A 问:“谁有 192.168.1.100?”
● 路由器 R 回答:“我有,我的 MAC 是 xx:xx:xx:xx:xx:xx”
● 实际上,192.168.1.100 在另一个网络上,由 R 代为转发
腾讯云vpc网络通信原理
在腾讯云网络vpc中a连接b机器流程: vm(a)->arp代理->桥接->主机->虚拟交换机->gre封包->腾讯云网络->gre解包->虚拟交换机->主机->vm(b)
在a连接b的过程中,a的mac地址会被主机拦截并伪造一个mac返回给a的网络协议栈,a的请求会优先在交换机与主机的arp缓存表中进行寻找b的ip与mac地址,如果寻找不到,会通过gre(vpcid)封包,发送到默认网关,然后通过网关进行转发,并最终到达b主机。
这里我推测,这个网络路径应该是内核版本的虚拟交换机的流程。
在报文最终进入到目的端的vm之前,虚拟交换机会将目的mac替换成真实的mac,源mac替换为假的mac。这样,进行报文通信的双方vm无感。
为什么ARP代理可行?
1)ARP协议的本质是“问-答”机制:
○ 当一台主机(源主机)需要与另一台IP地址在同一子网但实际不在同一物理网络的主机(目标主机)通信时,它会发送一个ARP请求广播,询问“谁拥有这个IP地址?”。
○ 这个请求是广播的,意味着同一广播域内的所有设备都能收到。
2)路由器/三层设备可以“监听”并“冒充”:
○ 路由器通常连接多个网络(或子网)。当它收到一个ARP请求,即使请求的目标IP地址不是它自己的接口IP,它也可以检查自己的路由表。
○ 如果路由器发现它知道如何到达该目标IP地址(例如,通过另一个接口),它就可以代替那个真正的目标主机进行响应。
○ 它会发送一个ARP应答,其中包含自己的MAC地址,并声称“这个IP地址对应我的MAC地址”。
3)源主机的“信任”与“缓存”机制:
○ 源主机收到这个来自路由器的ARP应答后,无法分辨这是真正的目标主机还是一个代理。它会信任这个应答。
○ 源主机会将“目标IP地址 <-> 路由器的MAC地址”这个映射关系缓存到自己的ARP表中。
4)后续通信被“重定向”到路由器:
○ 当源主机要发送数据包给目标IP地址时,它会查找ARP表,发现目标IP对应的MAC地址是路由器的MAC地址。
○ 因此,它会将数据帧封装成发往路由器MAC地址的形式,并发送出去。
○ 路由器收到这个帧后,根据IP包头中的目标IP地址,通过路由表查找到真正的下一跳,并将数据包转发出去,最终送达目标主机。
总结来说,ARP代理可行的关键在于:
● 协议层面:ARP协议本身没有验证ARP应答真实性的机制,源主机默认接受第一个有效的ARP应答。
● 设备能力:路由器具备路由功能和网络接口,能够接收ARP请求、做出决策、发送ARP应答,并转发IP数据包。
● 网络拓扑:源主机和目标主机在逻辑上被视为同一子网,但实际上被路由器分隔开。ARP代理充当了“桥梁”,让源主机误以为目标主机就在本地。
其他
腾讯云 & 阿里云vpc都是相同效果即私有网络内arping服务器返回网卡硬件地址(mac地址)都是一样的,华为云和aws的vpc和传统以太网效果类似即arp -a 中可以查到私有网络内其他服务器的网卡硬件地址(mac地址)。
在网络的世界中,代理的线上还是比较常见的。
比如:http/https代理;socks代理等。
参考
《腾讯云vpc网络通信原理》:https://cloud.tencent.com/developer/article/1684435