3. ARP协议深度解析：从请求到欺骗，再到防御
ARP协议，说白了就是以太网世界的「门牌查询系统」。你有一个IP地址，但不知道对方的MAC地址，数据帧就发不出去。这时候ARP就登场了。
我刚开始做网络运维那会儿，总觉得ARP是个小角色。直到有一次，整个办公区突然断网，排查了半天才发现是ARP缓存表被污染了。嗯，从那以后我再也不敢小看这个协议了。
3.1 ARP协议工作原理
ARP（Address Resolution Protocol）的核心任务只有一个：根据IP地址获取MAC地址。它工作在数据链路层和网络层之间，属于接口层协议。
3.1.1 ARP请求与响应
假设主机A（192.168.1.10）想和主机B（192.168.1.20）通信。A知道B的IP，但不知道B的MAC。这时候A会怎么做？
- A在局域网内广播一个ARP请求：「谁有192.168.1.20？告诉你的MAC地址给我。」
- 这个请求的目标MAC地址填的是
FF:FF:FF:FF:FF:FF，也就是广播地址。 - 局域网内所有主机都会收到这个请求，但只有B会响应。
- B回复一个ARP响应：「我是192.168.1.20，我的MAC是
AA:BB:CC:DD:EE:20。」 - A收到响应后，把IP-MAC映射写入自己的ARP缓存表。
关键点：ARP请求是广播，ARP响应是单播。这个不对称设计，其实是后面ARP欺骗攻击的根源。
3.1.2 ARP报文结构
ARP报文直接封装在以太网帧里，没有IP头部。我习惯用Wireshark抓一个ARP包，直接看字段最直观。
| 字段 | 长度 | 说明 |
|---|---|---|
| 硬件类型 | 2字节 | 1表示以太网 |
| 协议类型 | 2字节 | 0x0800表示IPv4 |
| 硬件地址长度 | 1字节 | 以太网MAC为6 |
| 协议地址长度 | 1字节 | IPv4为4 |
| 操作码 | 2字节 | 1=请求，2=响应 |
| 发送方MAC | 6字节 | 请求者/响应者的MAC |
| 发送方IP | 4字节 | 请求者/响应者的IP |
| 目标MAC | 6字节 | 请求时为0，响应时填写 |
| 目标IP | 4字节 | 被查询的IP |
我的小技巧：在Wireshark里直接输入 arp 过滤，就能只看ARP报文。然后点开「Address Resolution Protocol」那一行，所有字段一目了然。我每次培训都让学生先抓100个ARP包，看熟了再往下讲。
3.2 ARP缓存机制
如果每次通信都发广播，网络早就炸了。所以操作系统会把ARP解析结果缓存起来。
3.2.1 缓存表结构
在Windows上可以用 arp -a 查看，Linux用 ip neigh。缓存表一般包含：
- IP地址：目标主机的IP
- MAC地址：对应的硬件地址
- 类型：动态（Dynamic）或静态（Static）
- 老化时间：条目还能存活多久
3.2.2 老化与更新
不同类型的操作系统，ARP缓存老化策略不一样：
| 操作系统 | 动态条目超时时间 | 特点 |
|---|---|---|
| Windows | 15-45秒（未使用） | 使用中会刷新 |
| Linux | 60秒（默认） | 可通过 /proc/sys/net/ipv4/neigh/default/gc_stale_time 调整 |
| macOS | 20分钟 | 相对较长 |
我曾经遇到过一个问题：某台Linux服务器频繁更换网卡，但ARP缓存里还是旧MAC，导致业务中断了半小时。后来我养成了一个习惯——更换硬件后，第一时间手动清ARP缓存。
避坑指南：我曾经在排查一个间歇性丢包问题时，花了整整两天。最后发现是ARP缓存表里有一条静态错误条目。静态ARP条目不会老化，除非你手动删。所以，非必要不要设静态ARP，设了就要做好记录。
3.3 ARP欺骗攻击
ARP协议设计时没考虑安全性。它信任所有收到的ARP响应。这就给了攻击者可乘之机。
3.3.1 攻击原理
攻击者C向主机A发送伪造的ARP响应：「网关的IP是192.168.1.1，但MAC地址是我的 CC:CC:CC:CC:CC:CC。」A信了，更新了缓存。从此A发往网关的所有流量，都先到了C手里。
你想想看，这有多危险？
- 中间人攻击：攻击者可以监听、篡改通信内容
- 会话劫持：窃取Cookie或Token
- 拒绝服务：把流量引向不存在的MAC，直接断网
3.3.2 实战抓包分析
在Wireshark里，ARP欺骗攻击有几个典型特征：
- 大量ARP响应：正常网络ARP响应很少，攻击时可能每秒几十个
- IP-MAC映射频繁变化：同一个IP对应多个不同的MAC
- 重复的MAC地址：攻击者用一个MAC冒充多个IP
Wireshark过滤技巧：用 arp.duplicate-address-detected 可以快速检测重复IP地址。用 arp.opcode == 2 只看ARP响应，如果数量异常多，基本可以断定有问题。
3.4 ARP防御方案
防御ARP欺骗，说白了就是让设备不再盲目相信ARP响应。我总结了几种常用方案：
3.4.1 静态ARP绑定
在关键设备（如网关、服务器）上手动绑定IP-MAC映射。
# Linux下添加静态ARP条目
arp -s 192.168.1.1 AA:BB:CC:DD:EE:01
# Windows下添加静态ARP条目
arp -s 192.168.1.1 AA-BB-CC-DD-EE-01优点：简单有效。缺点：维护成本高，设备多了根本管不过来。
3.4.2 交换机端口安全
在接入交换机上配置端口安全，限制每个端口允许通过的MAC地址数量。
# Cisco交换机配置示例
interface GigabitEthernet0/1
switchport port-security
switchport port-security maximum 1
switchport port-security mac-address sticky
switchport port-security violation shutdown我个人的习惯是：核心网络设备之间用静态ARP，终端接入用端口安全。两层防护，基本能挡住90%的ARP攻击。
3.4.3 DAI（动态ARP检测）
DAI是思科交换机的特性，它会结合DHCP Snooping的绑定表来验证ARP报文。只有合法的IP-MAC映射才允许通过。
# 启用DAI
ip arp inspection vlan 10
ip arp inspection validate src-mac dst-mac ip我的建议：如果你用的是企业级交换机，优先考虑DAI。它比静态ARP灵活，比端口安全智能。我在一个500人的办公网里部署过DAI，ARP欺骗事件从每周3-4起降到了0。
3.5 Wireshark实战抓包
光说不练假把式。我们来动手抓一个ARP请求-响应的完整过程。
3.5.1 抓包步骤
- 打开Wireshark，选择正确的网卡接口
- 在过滤栏输入
arp，只显示ARP报文 - 打开命令行，执行
ping 192.168.1.1（假设网关是这个IP） - 观察Wireshark里的ARP请求和响应
3.5.2 报文解读
抓到的ARP请求报文大概长这样：
Frame 1: 42 bytes on wire (336 bits)
Ethernet II, Src: 00:1a:2b:3c:4d:5e, Dst: ff:ff:ff:ff:ff:ff
Address Resolution Protocol (request)
Hardware type: Ethernet (1)
Protocol type: IPv4 (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: request (1)
Sender MAC address: 00:1a:2b:3c:4d:5e
Sender IP address: 192.168.1.10
Target MAC address: 00:00:00_00:00:00 (全零)
Target IP address: 192.168.1.1注意看目标MAC是全零，操作码是1（请求）。响应报文里操作码变成2，目标MAC也填上了真实地址。
实战要点：我建议你同时抓两个方向的流量。在Wireshark里用 arp and ip.addr==192.168.1.1 可以过滤出与特定IP相关的ARP报文。这样能更清晰地看到请求-响应的对应关系。
3.5.3 模拟ARP欺骗
为了加深理解，你可以在实验环境里用工具模拟ARP欺骗。比如用 arpspoof（Kali Linux自带）：
# 开启IP转发
echo 1 > /proc/sys/net/ipv4/ip_forward
# 欺骗目标主机，告诉它网关的MAC是我
arpspoof -i eth0 -t 192.168.1.10 192.168.1.1
# 同时欺骗网关，告诉它目标主机的MAC是我
arpspoof -i eth0 -t 192.168.1.1 192.168.1.10然后在Wireshark里观察：你会看到大量伪造的ARP响应，目标主机的ARP缓存表里网关MAC变成了攻击者的MAC。这就是典型的中间人攻击。
重要提醒：以上操作只能在你自己搭建的实验环境里做。我曾经见过一个实习生在生产网络里测试ARP欺骗，结果导致整个部门断网半小时。切记，生产环境不是实验室。
好了，ARP协议的核心内容就这些。从请求响应到缓存机制，从欺骗攻击到防御方案，再到Wireshark实战抓包，这一套下来你应该能对ARP有比较深入的理解。下次遇到网络不通的问题，记得先看看ARP缓存表——很多莫名其妙的问题，根源就在这儿。