腾讯云网络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中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无感。

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代理等。