ARP：把 IP 地址换成 MAC 地址

37.1先从一个例子理解概念

你知道同一条以太网链路上下一步接收者的IP，却还不知道该写哪个MAC。ARP就是用来询问这个对应关系的。

把下一跳IP查成MAC：ARP

ARP（地址解析协议）在本地链路上询问“哪个接口使用这个IPv4地址”。去远方服务器时，常查本地网关的MAC，而不是远端服务器的MAC。

出门先交给谁：网关与下一跳

去其他网络的包通常先交给某个路由器，这个接收者叫下一跳；常用默认出口叫默认网关。它不是DNS服务器这个概念，虽然家用盒子可兼任。

暂存查到的关系：邻居缓存

系统把近期地址映射与确认状态存起来，叫邻居缓存。缓存是暂存记录，不保证目标一直在线，状态也不是设备身份。

怎样读英文状态

Reachable表示近期确认；Stale表示确认已较旧；Incomplete表示尚无完整映射；Probe表示探测中。先记中文含义，再看它们怎样变化，不要把一个状态直接翻译成根因。

下面再用这些概念看原理、命令和结果。规范与官方资料列在本章末尾，类比只帮助理解，不代替协议规则。

37.2为什么需要 ARP

回顾《全景与基础》模块讲过的矛盾：

要把数据发出去，必须知道对方的 MAC 地址。可是应用程序和 IP 层只知道 IP 地址。

ARP（Address Resolution Protocol，地址解析协议）就是补上这一环的协议。 它回答的问题只有一个：

注意 ARP 只在本网段内工作。 如果你要访问的是外网地址，ARP 查的不是目标服务器的 MAC，而是默认网关的 MAC —— 因为包要先交给网关。这一点在《网络层》模块讲路由时会再遇到。

37.3ARP 报文长什么样

以太网解析IPv4时，ARP报文为28字节；协议本身支持不同硬件与协议地址长度：

37.4ARP 一问一答的两个包

① 请求：广播
   谁有 192.168.31.1？请告诉 192.168.31.215
   目的 MAC = FF-FF-FF-FF-FF-FF（广播，全网的网卡都收下）

② 应答：单播
   我是 192.168.31.1，我的 MAC 是 A4-39-B3-0B-AB-19
   目的 MAC = 提问方的 MAC（只有它需要知道答案）

为什么首次地址解析通常广播

首次没有映射时通常广播请求；已知缓存映射的可达性探测可以单播，不能说ARP请求一律必须广播。

代价是什么？ 同一个网段里所有设备都得收下这个帧、交给 ARP 模块处理一遍，然后发现"不是问我"再丢掉。这就是广播消耗 CPU 的由来。

如果每发一个包都广播一次 ARP，网络很快就被 ARP 报文的噪声淹没了。所以必须有缓存 —— 而这正是本章实测的重点。

37.5实测：ARP 缓存的五种状态

ARP 不是"查一次记一辈子"，而是一个带状态机的缓存。历史实测记录到的全部状态：

Get-NetNeighbor -AddressFamily IPv4 | Where-Object { $_.State -ne 'Permanent' }

实测结果（按状态分组）：

注意 Stale 那一行：它仍然带着 MAC 地址。 这说明"Stale不等于映射不可用；后续探测与发包关系需查实现和抓包"。这个细节很关键，下一节的实验会用到。

37.6实测一：对不存在的主机做 ARP 解析

ping 一个网段内不存在的地址：

ping -n 1 -w 2000 192.168.31.222

实测结果：

Pinging 192.168.31.222 with 32 bytes of data:
Request timed out.

  → 邻居缓存里出现了：
    192.168.31.222   MAC=00-00-00-00-00-00   State=Incomplete

这说明观察时尚无可用映射。 单凭Incomplete和超时不能证明请求确实发出、网段内没有设备或为何没有应答，仍需抓包和链路证据。

这个状态把两种失败区分开了：

37.7实测二：抓到 Stale → Probe 的瞬间

原教程记录某条Stale邻居在ping附近出现Probe状态，并且第一次ping超时。这是时序相近的观察，不证明系统为ARP探测主动丢弃了ICMP，也不能断言第一次超时必然正常。

邻居状态机与发包可能并行。IPv6邻居发现明确规定：可用缓存链路地址继续发送，并在缺少确认时从Stale进入Delay再Probe。Windows IPv4行为须结合实现文档与同次抓包；不能直接把IPv6规范当成所有ARP实现的逐步证据。RFC 4861 §7.3.3、Microsoft ARP缓存行为

正确排查是保存连续探测、邻居状态和抓包时间线，再区分地址解析、ICMP策略、无线省电、丢包与超时设置。重试有助于观察，不代表“只要第二次通就证明第一次被ARP丢弃”。

37.8为什么要有缓存和状态机

每次发包都广播解析会增加负担，永久使用旧映射又会造成错误转发，因此邻居缓存保存映射并按实现进行可达性确认和老化。

缓存是否可用于发送、何时发探测、何时排队或丢弃报文，应按状态与实现判断。 Stale、Incomplete、Reachable不能简单分别翻译成“必须先验证”“对方不存在”“对方永远可达”。

37.9免费 ARP 与 ARP 欺骗

免费 ARP（Gratuitous ARP）

设备开机、或者换了网卡之后，会主动广播一条"我是 X，我的 MAC 是 Y"，即使没人问它。用途有两个：

1. 1检测 IP 冲突：如果广播出去之后收到了别人的回应，说明这个 IP 已经有人在用了
2. 2通知大家更新缓存：网卡换了，主动告诉全网"以后发给我用新 MAC"

ARP 欺骗

ARP 协议没有任何认证机制 —— 谁来问都答，谁说自己是网关都信。这带来一个经典攻击方式：

攻击者持续广播：192.168.31.1（网关）的 MAC 是 我的 MAC
  → 全网设备的缓存都被污染
  → 你的所有上网流量都会先经过攻击者的机器
  → 这就是局域网里的「中间人攻击」

防御手段：

37.10实测发现：TUN 接口的 ARP 条目

再回头看那张状态表，有一条很特别：

198.18.0.2       (空)         Reachable    FlClash

它是 Reachable，但 MAC 地址是空的。

因为 FlClash 是 TUN 虚拟网卡，工作在 IP 层，根本没有二层地址（《MAC 地址》那一章讲过）。Windows 的邻居缓存仍然为它建了条目，但永远填不上 MAC。

同一个命令、同一个系统，"有没有 MAC"这件事完全取决于接口的类型。 这是分层思想在运维层面的又一次体现。

37.11常见误解

误解一："ARP 是 IP 协议的一部分"

不是。ARP 是独立的协议，它介于链路层和网络层之间 —— 它用链路层的广播来工作，但解析的是网络层的地址。在 TCP/IP 分层模型里它通常被归到网络接口层。

误解二：ping超时能确定端点不存在。

超时可能来自地址解析、过滤、链路丢失或处理延迟；应连续观察并抓包，不能无证据归因为“Stale探测期间必然丢包”。

误解三："ARP 缓存可以随便清"

实测：Remove-NetNeighbor 需要管理员权限，普通用户会得到 Access is denied。不过缓存自己会老化，日常不需要手动清。

误解四："ARP 请求只发给目标设备"

请求是广播的，同网段所有设备都会收到并处理一遍。只有目标设备会回应，但所有设备都消耗了一次 CPU。这就是广播的代价。

37.12本章小结

37.13自测题

37.14参考资料与适用范围

• RFC 826：ARP报文与处理流程
• Microsoft：Windows ARP缓存行为
• RFC 4861 §7.3.3：邻居可达性检测
• RFC 1122 §1.1.3、§2–4：TCP/IP分层与主机要求

修订核对日期：2026-10-13。规则按所列协议与实现范围理解；文中的原始命令输出是历史观察，不表示本次重新实测。跨版本、代理/隧道及不同捕获位置需要另行核对。