以太网与ARP协议：从帧结构到安全攻防

各位同学，今天我们来啃第二块硬骨头——以太网和ARP协议。说实话，这两个东西在协议栈里属于“底层民工”，天天干活但很少被关注。但你要是抓过包，就会发现网络里一半的“噪音”都是ARP搞出来的。

我个人习惯把以太网比作“物理层的快递员”，而ARP就是那个“查门牌号的导航员”。两者配合不好，网络就卡壳。下面我们一层层剥开。

以太网帧，说白了就是数据在网线上跑的时候穿的“马甲”。我刚开始抓包时，看着一堆十六进制数字头皮发麻，后来发现只要记住几个关键字段，读帧就跟看快递单一样简单。

标准的以太网帧长这样（不含前导码）：

这里有个坑——最小帧长64字节。为什么？因为要防止“冲突检测”时误判。我在项目里遇到过一种情况：有人把MTU改小了，结果小包发出去，对端网卡直接丢弃，因为帧长不够64字节。嗯，这个坑我踩过。

抓包小技巧： 在Wireshark里看以太网帧，直接展开"Ethernet II"那一行。重点关注Type字段——0x0800是IP包，0x0806是ARP包。如果看到0x8100，那是带了VLAN标签，帧结构会多4字节。

MAC地址，每个网卡出厂时烧录的全球唯一标识。但注意，这个“唯一”只是理论上的——我见过虚拟机克隆后MAC冲突导致网络瘫痪的案例。

MAC地址的结构：前24位是OUI（厂商代码），后24位是序列号。比如我的网卡是00:1A:2B:3C:4D:5E，前3字节00:1A:2B代表Intel，后3字节是Intel分配的。

但有个特殊地址——广播地址FF:FF:FF:FF:FF:FF。所有网卡收到目的MAC为全F的帧，都必须接收。ARP请求就是靠这个广播地址“喊话”的。

注意： 交换机转发帧时，只看目的MAC。如果目的MAC是单播，交换机查表转发；如果是广播，交换机向所有端口（除接收口）泛洪。这就是ARP广播风暴的根源。

ARP协议解决的是这个问题：我知道对方的IP（比如192.168.1.1），但不知道它的MAC地址，怎么把帧发过去？

流程很简单，我画个图你就明白了：

你看，主机A想知道B的MAC，就发一个广播帧，里面写着“谁有192.168.1.20的MAC？告诉我”。主机B收到后，发现问的是自己，就单播回复“我的MAC是00:1A:2B:3C:4D:5E”。

抓包时，ARP请求包的特征很明显：目的MAC是全F，操作码是1（请求）。响应包操作码是2，目的MAC是请求方的MAC。

核心要点： ARP只在同一个广播域内有效。跨网段通信时，主机把包发给默认网关，由网关的MAC地址来响应。所以你在抓包时，如果看到ARP请求问的是网关IP，说明主机在找“出口”。

ARP协议有个致命缺陷——无状态、无认证。任何主机收到ARP响应包，都会直接更新ARP缓存表，不管这个响应是不是你主动问的。

这就是ARP欺骗的原理。攻击者伪造一个ARP响应，告诉受害者“网关的MAC是我”，然后所有发往网关的流量都跑到攻击者机器上去了。

我曾经在客户现场排查过一个“间歇性断网”的问题。用户反映每天下午3点准时掉线，持续5分钟。我抓包一看，发现ARP缓存表里网关MAC被篡改了。后来查出来是有人用手机开了ARP欺骗工具在恶作剧。

ARP欺骗的典型攻击流程：

怎么防御？我给出几个实战建议：

避坑指南： 我曾经在配置静态ARP时犯过一个低级错误——把网关的MAC地址写错了。结果整个网段的主机都上不了外网。排查了半小时才发现是ARP表里网关MAC多打了一个0。所以，静态绑定一定要核对三遍MAC地址。

另外，抓包时如何发现ARP欺骗？看两个特征：

嗯，ARP这块内容就这些。说白了，以太网和ARP是局域网通信的基石，但也是最容易被忽视的安全短板。你抓包时多留意ARP包，能发现很多网络问题的根源。