ARP 协议抓包解析

协议设计

场景

layer3 网络中（网络层），IP 协议中 IPv4 使用32位地址

layer2 网络中（链路层），机器间通讯寻址是用 MAC 48位地址，ARP 协议在这一层游走。

那么当 layer3 下发一个数据包时，硬件需要知道目标设备的 MAC 地址才能确定接收方，但报文中只给了一个 IP 地址，硬件设备玩不来 layer3 那一套，老头子们就整出一套 ARP 协议。

报文内容

我们直接通过 tshark 抓包后的字段信息学习，更清晰易懂

有耐心的同学可以去 RFC 看看字段定义

Request

Address Resolution Protocol (request)
    Hardware type: Ethernet (1)
    Protocol type: IPv4 (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (1)
    Sender MAC address: Dell_aa:aa:aa (80:18:44:aa:aa:aa)
    Sender IP address: 10.0.2.123
    Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Target IP address: 10.0.2.251

Fields：

Protocol: 请求转换的地址协议类型，此处未 IPv4
Size: 地址字段的字节数
Sender: 发起方
Target MAC address: all 0 broadcast
Target IP address: 请求转换的地址

Reply

Address Resolution Protocol (reply)
    Hardware type: Ethernet (1)
    Protocol type: IPv4 (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: reply (2)
    Sender MAC address: Dell_cc:cc:cc (f4:8e:38:cc:cc:cc)
    Sender IP address: 10.0.2.251
    Target MAC address: Dell_aa:aa:aa (80:18:44:aa:aa:aa)
    Target IP address: 10.0.2.123

字段含义同上，建议阅读下方伪代码，就基本能理解 arp 的工作原理了。

Received arp frame

If I have Hardware type (mac addr) == False: exit
If I have Protocol (IPv4) == False: exit
# 上面两个都没的话，没得玩
Set Merge_flag = False
    # 更新旧记录，设置flag
    If <protocol type, sender protocol address> in arp_table:
        Update it
        Set Merge_flag = True
# 如果我是被请求方
If target target protocal(ip) address == mine:
    If Merge_flag == False: 
        # 新纪录，直接添加
        arp_table.append(<protocol type, sender protocol address, sender hardware address>)
    If Opcode == Request:
        # 直接在原报文中互换字段，设置新值后发送。巧妙~
        Swap Mac and IP
        Set Sender info = mine
        Set Opcode = reply
        Send this arp

拓展信息： MAC Address Table

交换机有很多个端口，当需要转发帧给未知 mac 地址时，会 arp flood 所有的端口，这显然是比较浪费资源的。

因此交换机会维护一个 mac address table，当从 a 端口收到来自 h 地址的广播帧时，会将 a-h 作为一条记录加进 mac address table。当后续有发往 h 地址的广播时，就能直接将广播帧转发给 a 端口。

Arp Spoof 就是利用这一机制，不停向交换机发送虚假的 mac 地址，塞满它的 table，让它在转发时不得不 flood 所有端口，是比较常见的攻击手段。

Tshark 抓包

Case1 - 同子网

host-a: 10.0.0.123
gateway:
host-b: 10.0.0.125
拓扑结构图

Tips:

layer2 switch 是二层交换机，只有二层网络功能的交换机
layer3 switch 是含有部分路由功能（三层网络）的交换机

host-a ping host-b 捕捉 ARP 协议

# 清除 arp 缓存内容
host-a$ sudo ip -s neigh flush all
host-b$ sudo ip -s neigh flush all
# 抓包开始
host-a$ sudo tshark -i eno1 -f 'arp host 10.0.0.125 or icmp'
host-a$ ping 10.0.0.125 -c1

# 抓包结果
# host-a 发出 arp request，寻求 host-b mac addr
    1 0.000000000 Dell_aa:aa:aa → Broadcast    ARP 42 Who has 10.0.0.125? Tell 10.0.0.123
# host-b 响应了
    2 0.000158010 Dell_bb:bb:bb → Dell_aa:aa:aa ARP 60 10.0.0.125 is at 80:18:44:f0:ea:38
# 开始通讯
    3 0.000168966   10.0.0.123 → 10.0.0.125   ICMP 98 Echo (ping) request  id=0x2017, seq=1/256, ttl=64
    4 0.000328873   10.0.0.125 → 10.0.0.123   ICMP 98 Echo (ping) reply    id=0x2017, seq=1/256, ttl=64 (request in 3)
# 来自网络中其他节点的广播~~
    5 1.008209509 Dell_cc:cc:cc → Broadcast    ARP 60 Who has 10.0.0.4? Tell 10.0.0.251
# 很奇怪，怎么 host-b 又发了一个 unicast
    6 5.150301642 Dell_bb:bb:bb → Dell_aa:aa:aa ARP 60 Who has 10.0.0.123? Tell 10.0.0.125
    7 5.150311419 Dell_aa:aa:aa → Dell_bb:bb:bb ARP 42 10.0.0.123 is at 80:18:44:aa:aa:aa

现象及疑问

发现一个有趣的现象，原本设想只会抓到两个包(request from 123 + reply from 125)，但实际抓到了 4 个(125 主动发起一次 request)。

ARP RFC 中提到，在完成 reply 后 target host 节点应该是记下了 source mac 地址了，为何还发起了一次查询 10.0.0.123 的。

猜想

有可能是以下原因:

ARP spoofing （我的网络挺安全啊）
Directed ARP (跨子网，路由会向相邻路由发起 ARP)
ARP 的 Refresh 行为，通过发起 Unicast Poll

简单排除:

125 发起的是 Unicast ARP Request，且两台机器同子网，不需要借助路由可直接访问，因此可以排除交换机行为

验证

Linux APR:
前两种情况都与我们的网络环境不相符，所以搜了下 Linux arp(7) table cache refresh 机制。

When there is no positive feedback for an existing mapping after some
time (see the /proc interfaces below), a neighbor cache entry is
considered stale. Positive feedback can be gotten from a higher
layer; for example from a successful TCP ACK.

arp 将一个 ip 标记为 stale 后，会在间隔 delay_first_probe_time(5s) 后发起 Request 探针。
arp 会为可用 record 基于 base_reachable_time_ms(30s) 参数生成一个随机有效时间。

# 查看第一次 probe 发起的延迟
host-b$ cat /proc/sys/net/ipv4/neigh/eno1/delay_first_probe_time 
5
# 发现跟我们抓包时的间隔时间很像，修改成 10 试一试
host-b# echo 10 > cat /proc/sys/net/ipv4/neigh/eno1/delay_first_probe_time
# 真的间隔变成 10s，这里就不放结果了~~信我就是了！

# 再看一下记录的状态转换
# 清理两端的 apr cache
host-a$ ping host-b -c1
host-b$ ip neigh
10.0.0.123 dev eno1 lladdr 80:18:44:f0:bb:7c DELAY

# host-b probe request 发起后
host-b$ ip neigh
10.0.0.123 dev eno1 lladdr 80:18:44:f0:bb:7c REACHABLE

# 等一段比较长时间 >60s
host-b$ ip neigh
10.0.0.123 dev eno1 lladdr 80:18:44:f0:bb:7c STALE

# 这时候从 125 发起 ping (arp 表内已存在)
host-b$ ping host-a -c1
# host-a 收到 ping，但没有 arp request
# host-b 上的记录变为 DELAY
host-b$ ip neigh
10.0.0.123 dev eno1 lladdr 80:18:44:f0:bb:7c DELAY

# 10s 后 probe 发起并受到 reply
host-b$ ip neigh
10.0.0.123 dev eno1 lladdr 80:18:44:f0:bb:7c REACHABLE

# 以上行为与 linux arp 文档描述一致

总结

同子网通讯，发起端广播 arp 请求目标机 mac 地址
等待 arp 请求得到回应，取得 10.0.0.125 的 mac-address
与目标建立通讯
Probe request 是 linux 下行为，非 arp 协议定义行为。

Case2 - 跨子网

host-a: 10.0.2.123 （改了下 ip 和 gateway）
host-b: 10.0.0.125
Gatway: 10.0.2.251、10.0.0.251 （同一台三层交换机）
拓扑结构图