Stay hungry,Stay foolish

0%

同网段通信Server端发送arp请求Client端

同网段通信是基于MAC地址

clientA(192.168.168.1)发送数据/连接 serverA(192.168.168.2): clientA没有本地arp cache的情况下, 首先会发送arp请求

ServerA 抓包如下

1
2
3
4
5
6
7
8
17:02:03.332700 52:54:00:8c:d8:6e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.168.2 tell 192.168.168.1, length 28
17:02:03.332756 52:54:00:85:ff:6c > 52:54:00:8c:d8:6e, ethertype ARP (0x0806), length 42: Reply 192.168.168.2 is-at 52:54:00:85:ff:6c, length 28
17:02:03.333484 52:54:00:8c:d8:6e > 52:54:00:85:ff:6c, ethertype IPv4 (0x0800), length 98: 192.168.168.1 > 192.168.168.2: ICMP echo request, id 9336, seq 1, length 64
17:02:03.333575 52:54:00:85:ff:6c > 52:54:00:8c:d8:6e, ethertype IPv4 (0x0800), length 98: 192.168.168.2 > 192.168.168.1: ICMP echo reply, id 9336, seq 1, length 64
...
...
17:02:08.843216 52:54:00:85:ff:6c > 52:54:00:8c:d8:6e, ethertype ARP (0x0806), length 42: Request who-has 192.168.168.1 tell 192.168.168.2, length 28
17:02:08.844172 52:54:00:8c:d8:6e > 52:54:00:85:ff:6c, ethertype ARP (0x0806), length 42: Reply 192.168.168.1 is-at 52:54:00:8c:d8:6e, length 28

疑惑的是通信过程中serverA也会发送arp请求clientA的MAC,这个细节之前还真没注意过。

serverA通过while true; do ip neigh | grep 192.168.168.1 >> arp 2>&1; done看到其先后经历DELAY REACHABLE两种状态

1
2
192.168.168.1 dev eth0 lladdr 52:54:00:8c:d8:6e DELAY
192.168.168.1 dev eth0 lladdr 52:54:00:8c:d8:6e REACHABLE

man ip-neighbour着重看了下DELAY代表的状态含义

1
delay  neighbor entry validation is currently delayed.

代表这个记录要延迟验证,也就是说通过arp request拿到的地址不完全可信?

感觉是为了防范arp攻击的机制

man 7 arp中看到

1
2
delay_first_probe_time (since Linux 2.2)
Delay before first probe after it has been decided that a neighbor is stale. Defaults to 5 seconds.

syscta -a 查看delay_first_probe_time默认值为5秒, 跟抓包时间能匹配上

1
net.ipv4.neigh.eth0.delay_first_probe_time = 5

可以修改默认时间进行确认

1
echo "2" > /proc/sys/net/ipv4/neigh/eth0/delay_first_probe_time

TODO: arp 邻居状态的变更路径