ARP协议深度解析:从抓包排查到安全防护的实战指南

发布时间:2026/10/19 8:46:08
ARP协议深度解析:从抓包排查到安全防护的实战指南 1. 从一个抓包现场说起ARP到底在忙什么很多人第一次接触ARP是在抓包工具里看到满屏的Who has 192.168.1.1? Tell 192.168.1.100和192.168.1.1 is at xx:xx:xx:xx:xx:xx。当时我的反应是这不就是个喊话问路的协议吗有什么好理解的直到有一次在实验室调试一套跨网段通信的小系统明明IP配对了、路由也写了就是ping不通抓包一看——ARP请求发出去了但回应的MAC地址跟预期完全对不上。那一刻我才意识到ARP这东西看着简单真出问题的时候能让人排查到怀疑人生。ARP全称Address Resolution Protocol地址解析协议。它的核心任务只有一件事在同一个局域网广播域内把已知的IP地址翻译成对应的MAC地址。为什么需要这个翻译因为数据包在以太网里真正传输的时候靠的不是IP地址而是MAC地址。IP地址是网络层的逻辑标识MAC地址是数据链路层的物理标识两者各管一层中间必须有个翻译官ARP就是这个翻译官。这篇文章适合谁看如果你是刚学网络基础的学生或者工作中经常要排查网络不通问题的运维、开发人员又或者你正在准备网络相关的面试那这篇内容应该能帮你把ARP从背概念变成真理解。我会从协议的工作机制讲起然后拆解报文结构再聊几种典型场景同网段、跨网段、免费ARP、代理ARP最后重点讲我在实际排查中踩过的坑和总结出来的方法。全程用大白话加实际案例尽量不堆术语但该严谨的地方一定严谨。提示本文讨论的ARP均指IPv4环境下的经典ARP。IPv6用的是NDP邻居发现协议机制不同不在本文范围内。2. ARP的工作机制一次完整的问路过程2.1 同网段通信ARP请求与应答的完整链路先看最简单的场景主机A192.168.1.10要跟同网段的主机B192.168.1.20通信。A知道B的IP但不知道B的MAC这时候ARP就上场了。整个过程分四步查缓存A先翻自己的ARP缓存表看看有没有B的IP对应的MAC记录。有就直接用没有就进入下一步。这个缓存表可以用arp -a命令查看Windows和Linux都支持。发广播请求A构造一个ARP请求报文源IP是192.168.1.10源MAC是A自己的MAC目标IP是192.168.1.20目标MAC填全0因为还不知道。这个报文以广播形式发出目的MAC是FF:FF:FF:FF:FF:FF意思是局域网里所有设备都听一下。目标回应局域网内所有设备都收到了这个广播但只有IP是192.168.1.20的设备会处理它。B看到有人在问我的MAC就构造一个ARP应答报文单播回给A里面包含自己的MAC地址。更新缓存A收到应答后把192.168.1.20 → B的MAC这条记录写进自己的ARP缓存表然后就可以正常发包了。这里有个细节很多人忽略ARP请求是广播ARP应答是单播。为什么应答不用广播因为请求里已经带了源MAC和源IPB知道该回给谁没必要再广播一次打扰全网。这个设计很合理减少了不必要的广播流量。还有一个关键点ARP缓存是有老化时间的。不同系统默认值不一样Linux通常条目在缓存中会保留一段时间基础可达状态约30秒之后进入老化探测Windows的默认可达时间也类似。这意味着如果一台设备换了网卡MAC变了其他设备可能要等缓存老化后才能感知到。这就是为什么有时候换了网卡但IP没变别人还是连不上——对方的ARP缓存里还是旧MAC。2.2 跨网段通信ARP其实只关心下一跳这是最容易搞混的地方。假设主机A192.168.1.10/24要访问192.168.2.100这两个不在同一网段。A会怎么处理A先用自己的子网掩码算一下192.168.2.100跟自己在不在同一网段不在。那就不直接发而是发给网关假设网关是192.168.1.1。关键来了A发出的数据包目的IP是192.168.2.100但目的MAC是网关的MAC。也就是说A需要ARP解析的不是最终目标192.168.2.100的MAC而是网关192.168.1.1的MAC。数据包到了网关之后网关再根据自己的路由表决定下一跳如果下一跳也在另一个网段网关会再做一次ARP解析针对它自己的下一跳。所以记住一句话ARP只解析下一跳的MAC永远不解析跨网段的最终目标MAC。很多人以为访问外网要ARP解析百度的MAC这是完全错误的。你连百度服务器的MAC根本不可能知道也不需要知道你只需要知道网关的MAC就够了。这个机制带来的一个实际影响如果网关的ARP解析出了问题那整个网段的所有设备都上不了外网但同网段内互访可能还是正常的。排查的时候可以用这个特征快速定位问题范围。2.3 免费ARP设备上线时的自我宣告免费ARPGratuitous ARP是个很有意思的东西。它的特点是请求的目标IP就是自己的IP。设备发这个包的目的通常有两个一是检测IP冲突。设备刚配置好IP不确定局域网里有没有别人也在用这个IP就发一个免费ARP。如果收到回应说明有人已经在用这个IP了就会报IP冲突。这就是Windows里弹出检测到IP地址冲突提示的来源。二是更新其他设备的ARP缓存。比如设备换了网卡MAC变了但IP没变发个免费ARP告诉全网这个IP现在的MAC是我这个新MAC其他设备收到后就会更新缓存。这个在HA高可用切换场景里特别常见——主备切换时新主机会发免费ARP让网关和交换机把流量导到新的MAC上。注意免费ARP是广播发送的而且不需要回应正常情况下。如果你在抓包时看到大量免费ARP可能是网络里有设备在频繁上下线或者有IP冲突在反复发生值得警惕。2.4 代理ARP让路由器替人回答代理ARPProxy ARP是一个容易被忽略但实际很有用的机制。场景是这样的主机A192.168.1.10/24要访问192.168.1.100但192.168.1.100实际上在另一个物理网段中间隔了个路由器。正常情况下A会认为192.168.1.100跟自己同网段因为掩码是/24直接发ARP请求。这时候路由器如果开启了代理ARP就会替192.168.1.100回答192.168.1.100的MAC是我的MAC。A收到后就把数据发给路由器路由器再转发过去。代理ARP的好处是主机不需要配置网关就能跨网段通信因为路由器帮它骗了一下。但缺点也很明显增加了路由器的负担而且容易造成ARP表混乱。现在大多数网络都靠正确配置网关来解决代理ARP用得越来越少但在一些老设备或特殊场景里还能见到。3. 拆开ARP报文看结构每个字段都有它的道理3.1 报文格式逐字段解读ARP报文本身不长固定28字节不含以太网帧头。我把它拆成几个部分来看字段长度作用实际取值示例硬件类型2字节说明链路层是什么类型以太网是1协议类型2字节说明网络层是什么协议IPv4是0x0800硬件地址长度1字节MAC地址长度6协议地址长度1字节IP地址长度4操作码2字节区分请求还是应答1请求2应答发送方MAC6字节谁发的源设备MAC发送方IP4字节发送方的IP192.168.1.10目标MAC6字节要问谁的MAC请求时全0目标IP4字节要问的IP192.168.1.20操作码这个字段值得多说一句。除了1请求和2应答还有几个值3是RARP请求4是RARP应答RARP是反过来根据MAC查IP现在基本淘汰了。另外还有用于ARP探测的特殊情况。抓包的时候看操作码就能快速判断这个包是问还是答。硬件类型和协议类型这两个字段在纯以太网IPv4的环境里基本是固定的1和0x0800所以很多人直接忽略。但如果你在抓包时看到这两个值不是1和0x0800那说明可能不是标准的以太网ARP比如可能是其他链路层技术封装的这时候就要注意了。3.2 以太网帧头ARP报文外面还包了一层ARP报文不是光秃秃发出去的它被封装在以太网帧里。以太网帧头有14字节目的MAC6字节 源MAC6字节 类型2字节。对于ARP来说类型字段是0x0806。这里有个容易混淆的点以太网帧头里的目的MAC和ARP报文里的目标MAC是两回事。帧头里的目的MAC是链路层实际发送的目标ARP请求时是广播地址FF:FF:FF:FF:FF:FF而ARP报文里的目标MAC字段是我想问的那个IP对应的MAC请求时填全0。抓包工具通常会把这两层都展示出来看的时候要分清楚。帧头里还有个细节以太网帧有最小长度要求64字节不含前导码。ARP报文28字节加上帧头14字节才42字节不够64所以后面会填充一些字节Padding凑够最小长度。这个填充内容没有意义抓包时看到一堆0不用管它。3.3 抓包实操用工具亲眼看看ARP长什么样光看文字描述不够直观建议自己抓一次包。用Wireshark或者tcpdump都行。Linux下用tcpdump抓ARP包tcpdump -i eth0 -n arp这个命令会实时打印经过eth0网卡的ARP包-n表示不解析主机名直接显示IP速度更快。你会看到类似这样的输出ARP, Request who-has 192.168.1.1 tell 192.168.1.10, length 28 ARP, Reply 192.168.1.1 is-at aa:bb:cc:dd:ee:ff, length 28如果想抓下来用Wireshark分析可以加-w参数存成文件tcpdump -i eth0 -n arp -w arp.pcap然后用Wireshark打开arp.pcap就能看到每个字段的详细值了。Wireshark会把以太网帧头和ARP报文分层展示展开就能看到上面表格里的所有字段。Windows下可以用arp -a查看当前ARP缓存接口: 192.168.1.10 --- 0x3 Internet 地址 物理地址 类型 192.168.1.1 aa-bb-cc-dd-ee-ff 动态 192.168.1.20 11-22-33-44-55-66 动态类型列显示动态表示是ARP学到的静态表示是手动绑定的。手动绑定用arp -s命令这个后面讲安全的时候会提到。4. 那些年我在ARP上踩过的坑4.1 坑一ARP缓存不更新导致的幽灵故障有一次在实验室调试一套双机热备的系统。主机A和备机BIP都是192.168.1.100通过某种机制切换MAC不同。切换测试的时候发现备机接管后同网段的其他设备还是往主机A的MAC发包导致通信中断。排查过程先在备机上抓包发现备机确实发了免费ARP但其他设备好像没更新缓存。用arp -a一看其他设备的ARP表里192.168.1.100还是主机A的MAC。等了几分钟缓存老化之后才恢复正常。根因免费ARP虽然发了但有些操作系统对免费ARP的处理策略不一样。有的系统收到免费ARP后会更新缓存有的会忽略认为可能是攻击。而且如果免费ARP只发一次丢包了就没了。解决方案在切换脚本里改成连续发多个免费ARP比如发3到5个间隔1秒提高可靠性。另外在关键设备上做静态ARP绑定彻底避免缓存问题。这个经验后来在好几个项目里都用上了凡是涉及IP漂移的场景免费ARP的发送策略都要特别设计。4.2 坑二ARP表被打满导致网络瘫痪还有一次某台设备突然上不了网但同网段其他设备正常。登上去一看ARP缓存表里几千条记录全是乱七八糟的MAC地址而且还在不断增加。这是典型的ARP表溢出问题。攻击者或者某个出故障的设备在局域网里疯狂发ARP应答伪造大量IP-MAC映射把正常设备的ARP表塞满。表满了之后新的正常ARP记录就写不进去导致正常通信失败。排查方法用arp -a看记录数量和MAC分布。如果发现大量不重复的MAC对应同一网段的不同IP而且这些MAC明显不是真实设备的比如有规律地递增基本可以确定是ARP表被攻击了。应对措施一是静态ARP绑定把网关等关键设备的IP-MAC写死不受动态ARP影响二是在交换机上开启ARP防护功能不同厂商叫法不同有的叫DAI动态ARP检测有的叫ARP限速三是限制单端口ARP报文速率防止某个端口疯狂发ARP。4.3 坑三子网掩码配错引发的ARP跨网段假象这个坑比较隐蔽。主机A配置的是192.168.1.10/24主机B配置的是192.168.1.20/16。A要访问BA算了一下192.168.1.20跟我同网段因为/24直接发ARP请求。B收到了但B算了一下192.168.1.10跟我不在同一网段因为/16B认为自己的网段是192.168.0.0/16A的192.168.1.10其实也在里面……等等这里要仔细算。实际上/16的网段范围是192.168.0.0到192.168.255.255所以192.168.1.10确实在B的网段内。这种情况下B会正常回应ARP。但如果掩码配得更离谱比如A是/24B是/25就可能出现A认为同网段、B认为不同网段的情况导致ARP请求有去无回。排查这类问题的关键是先确认双方的子网掩码是否一致。用ip addrLinux或ipconfigWindows看掩码然后手动算一下双方是否在同一网段。这个坑我踩过一次之后现在排查网络问题第一步就是核对掩码。4.4 坑四抓包看到ARP请求但没应答问题出在哪这个现象很常见抓包看到A发了who-has 192.168.1.20但迟迟没有应答。可能的原因有好几种需要逐一排查目标设备不在线最简单的原因B关机了或者网线没插。目标设备IP配错了B实际配的是192.168.1.21不是.20自然不会有应答。中间有隔离比如交换机做了端口隔离或者VLAN配置把A和B隔在了不同广播域ARP广播根本到不了B。目标设备ARP防护开启有些安全软件或系统设置会忽略ARP请求。物理链路问题网线、光模块、交换机端口故障。排查顺序建议先ping一下目标IPping会触发ARP同时抓包看请求有没有发出去、有没有回应。如果请求发出去了没回应再检查目标设备是否在线、IP是否正确、是否在同一VLAN。这个排查链路我整理成了一个固定流程每次遇到类似问题按顺序走一遍基本能定位到原因。5. ARP相关的安全问题和防护思路5.1 ARP欺骗是怎么回事ARP协议设计之初没有考虑安全它有一个根本缺陷设备收到ARP应答后不管自己有没有发过对应的请求都会无条件更新缓存。这就给了攻击者可乘之机。ARP欺骗的典型手法攻击者C向主机A发送伪造的ARP应答说192.168.1.1网关的MAC是我的MAC。A收到后更新缓存之后A发给网关的所有数据都发到了C那里。C再转发给真正的网关或者不转发就实现了中间人监听或断网攻击。这个攻击在局域网里非常容易实施因为ARP应答是单播的A无法验证这个应答是不是真的来自网关。而且攻击者可以持续发伪造应答即使A的缓存老化了也会被重新污染。5.2 静态ARP绑定最直接但最费力的防护最直接的防护方法是静态ARP绑定。在主机上手动把网关的IP-MAC映射写死# Linux下添加静态ARP条目 arp -s 192.168.1.1 aa:bb:cc:dd:ee:ff # Windows下需要管理员权限 netsh interface ipv4 add neighbors 以太网 192.168.1.1 aa-bb-cc-dd-ee-ff绑定的条目类型会显示为静态不会被动态ARP覆盖。这样即使攻击者发伪造应答主机也不会更新缓存。但这个方法的问题也很明显维护成本高。如果网关换了网卡所有绑定的主机都要改。设备多了根本管不过来。所以静态绑定通常只用在关键设备上比如服务器绑网关普通终端还是靠其他机制。5.3 交换机层面的防护DAI和ARP限速在可管理的交换机上有更优雅的防护方案动态ARP检测DAI交换机维护一个IP-MAC-端口的绑定表通常来自DHCP Snooping然后检查经过的ARP报文。如果某个ARP报文声称的IP-MAC映射跟绑定表不符就丢弃。这样攻击者伪造的ARP包根本过不了交换机。ARP报文限速限制每个端口每秒能发多少ARP包。正常设备几秒才发一个ARP如果某个端口每秒发几百个肯定是异常的直接限速或阻断。这个能有效防止ARP表溢出攻击。端口隔离把每个端口隔离成独立的广播域用户之间不能直接二层通信ARP广播也到不了其他端口。这个在酒店、宿舍等场景很常用但会影响正常的局域网互访需求要权衡。注意这些功能都需要交换机支持而且配置不当可能影响正常业务。建议先在测试环境验证再上生产。特别是DAI如果DHCP Snooping表没建好就开DAI可能导致正常用户上不了网。5.4 检测ARP攻击的实用方法如果怀疑网络里有ARP攻击可以用这几个方法检测一是定期检查ARP表。写个脚本每隔几分钟arp -a一次对比MAC地址有没有异常变化。如果网关的MAC突然变了基本可以确定被攻击了。二是用ARP监控工具。有些工具比如arpwatch可以监听ARP流量发现IP-MAC映射变化时告警。Linux下可以装arpwatchsudo apt install arpwatch sudo arpwatch -i eth0它会在后台运行发现异常时发邮件告警需要配置邮件。三是抓包分析。如果看到大量ARP应答操作码2而对应的请求很少或者同一个IP对应多个不同MAC那就是异常信号。正常的网络里ARP应答应该跟请求大致成对出现。6. 几个容易混淆的ARP变种和它们的区别6.1 RARP、InARP、ARP的区别ARP家族其实有好几个成员容易搞混协议全称方向用途现状ARP地址解析协议IP → MAC根据IP查MAC广泛使用RARP反向地址解析协议MAC → IP根据MAC查IP基本淘汰被DHCP取代InARP反向ARPMAC → IP帧中继等场景用特定场景Proxy ARP代理ARP-路由器替设备应答特定场景RARP是最容易跟ARP搞混的。它的方向正好相反设备知道自己的MAC想知道自己的IP。早期无盘工作站用RARP来获取IP后来被DHCP取代了。现在基本见不到RARP了但面试的时候偶尔会问到。InARP用在帧中继Frame Relay和ATM网络里根据对方的MAC其实是DLCI查IP。这些技术现在也用得少了了解概念即可。6.2 免费ARP和ARP探测的区别这两个都是自己问自己类型的ARP但目的不同免费ARP目标IP是自己的IP目的是宣告我上线了或检测IP冲突。发送方希望别人更新缓存或者希望如果有人用同样的IP就回应。ARP探测ARP Probe也是目标IP是自己的IP但发送方的源IP填0.0.0.0。目的是在正式使用某个IP之前检测这个IP是否已被占用。如果收到应答说明IP冲突就不能用这个IP。DHCP客户端在获取IP后通常会做ARP探测确认没有冲突才正式使用。区别在于免费ARP的源IP是自己的IPARP探测的源IP是0.0.0.0。抓包的时候看源IP就能区分。6.3 什么时候ARP缓存会出问题ARP缓存出问题的典型场景设备换网卡MAC变了但IP没变其他设备的缓存还是旧MAC。需要发免费ARP更新。虚拟机迁移虚拟机从一台物理机迁到另一台MAC可能变取决于配置需要更新ARP缓存。HA切换主备切换时IP漂移必须发免费ARP。网络攻击ARP欺骗导致缓存被污染。缓存老化时间设置不当太短会导致ARP请求频繁太长会导致变化感知慢。理解这些场景就能在遇到问题时快速判断是不是ARP缓存的问题。7. 排查ARP问题的完整思路和常用命令7.1 一套可复用的ARP排查流程遇到网络不通的问题如果怀疑跟ARP有关我通常按这个顺序排查第一步确认现象。是全部不通还是部分不通是同网段不通还是跨网段不通这个信息能快速缩小范围。第二步看本地ARP缓存。arp -a看目标IP有没有对应的MACMAC是否正确。如果缓存里没有说明ARP没学到如果MAC不对说明可能被欺骗或缓存过期。第三步抓包看ARP交互。在发送方抓包看有没有发ARP请求有没有收到应答。如果请求发了没应答问题在对方或中间网络如果有应答但MAC不对可能是欺骗。第四步检查配置。确认双方的IP、掩码、VLAN配置是否正确。掩码不一致是常见坑。第五步检查中间设备。交换机端口隔离、VLAN划分、ACL规则都可能阻断ARP。第六步检查安全软件。有些终端安全软件会拦截ARP导致通信异常。这个流程走下来大部分ARP相关问题都能定位。7.2 常用命令速查# 查看ARP缓存Linux arp -a ip neigh show # 查看ARP缓存Windows arp -a # 添加静态ARPLinux arp -s 192.168.1.1 aa:bb:cc:dd:ee:ff # 删除ARP条目Linux arp -d 192.168.1.1 # 清空ARP缓存Linux ip neigh flush all # 抓ARP包 tcpdump -i eth0 -n arp # 查看ARP统计信息Linux cat /proc/net/arpWindows下清空ARP缓存用netsh interface ip delete arpcache需要管理员权限。7.3 一个真实的排查案例复盘最后分享一个我印象比较深的案例。某次一台服务器突然无法访问同网段的另一台服务器但能访问网关和外网。这个现象很奇怪能访问网关说明ARP没问题但同网段另一台却不行。排查过程先在服务器上arp -a发现目标服务器的IP对应的MAC是网关的MAC。这就解释了为什么不通——数据包都发到网关去了网关再转发回来但网关可能没有正确的路由或者做了隔离。为什么目标IP的MAC会变成网关的MAC后来发现是网络里有人开了代理ARP而且代理ARP的配置有问题把本网段的IP也代理了。正常情况下代理ARP只应该代理跨网段的IP结果配置成了代理所有IP导致本网段的ARP请求也被网关抢答了。解决方案关掉不正确的代理ARP配置或者在服务器上静态绑定目标服务器的MAC。这个问题排查花了不少时间因为一开始没想到代理ARP会影响到同网段通信。后来我把检查代理ARP配置加进了排查清单。这个案例说明ARP的问题不一定出在ARP本身可能是其他机制代理ARP、安全防护、VLAN干扰了ARP的正常工作。排查的时候要有全局视角不能只盯着ARP看。理解ARP关键不是背下来它的报文格式而是理解它在网络通信中的角色它是IP世界和MAC世界之间的桥梁是最后一跳的解析者。把这个定位搞清楚了很多看似复杂的问题就能找到头绪。

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询