企业官网建设流程全解析

很多学网络的同学第一次做Wireshark实验，最普遍的情况是：软件装好了，点开抓包，确实看到了一大堆帧，却说不清楚哪一条才是ARP，更看不明白“广播请求、单播应答”这个流程在抓包窗口里到底长什么样。我自己带实验课的时候，发现大家的困惑高度集中在几个点上：过滤条件怎么写得又快又准、免费ARP和普通ARP应答怎么区分、为什么有时候明明在同一个局域网却死活抓不到ARP报文。这篇文章就把利用Wireshark分析ARP协议的完整思路拆开讲一遍，从环境准备和抓包流程，一直讲到伪造ARP应答的进阶验证，适合刚做完实验还没理清头绪的同学，也适合想彻底搞懂ARP机制的网络运维新手。

1. 实验前的环境准备：先选网卡，再动手抓包

开始抓包之前，我建议你先花几分钟想清楚一个前提问题：这次实验到底要在哪一台机器上抓、抓的是谁的报文。想明白这一点，后面才不会被一堆莫名其妙的帧干扰。

1.1 为什么这次实验建议选择本机抓包而非端口镜像

Wireshark只能看到真正到达本机网卡的那些帧。ARP请求是以太网广播帧，目的MAC是全F的广播地址，所以理论上局域网内所有主机都能收到别人的ARP请求；但ARP应答是单播帧，只有请求方才能收到。如果你想在A机器上完整看到“A发出ARP请求→目标主机回ARP应答”这一对报文，最稳妥的做法就是直接在A机器上抓包，让A自己也参与到通信过程中。

端口镜像需要登录交换机做配置，很多实验环境里根本没有这个权限；即便配置好了，镜像口把双向流量全部复制过来，也会让抓包窗口里的无关流量成倍增加。对于ARP协议的实验来说，本机抓包已经足够看清全部关键行为，而且验证起来更直观：你自己执行的ping命令，马上就能在抓包结果里找到对应的那条ARP请求。所以说，不要把简单实验复杂化。

1.2 最小化干扰：把无关流量和虚拟网卡都排除掉

打开Wireshark的一瞬间，你会看到这台机器上所有网卡，包括虚拟机的虚拟网卡、虚拟拨号适配器之类。做ARP实验的时候，必须手动选中真正连接局域网的物理网卡。我之前见过很多人折腾半天抓不到包，最后发现选的是VMware自带的虚拟网卡，那个网卡上根本没有局域网流量。

干扰源主要有几个。

• 无线网卡与有线网卡并存时，建议优先用有线网卡。某些无线路由器开启了AP隔离之后，同一个Wi-Fi下的客户端之间是相互隔离的，ARP广播可能被路由器直接代答，你会看到很奇怪的应答来源。
• 抓包期间尽量关掉正在联网的软件，比如各类网盘、聊天工具的自动推送、系统更新。它们的周期性通信会产生大量TCP/UDP噪声，虽然不影响ARP过滤，但会让你分析数据时容易分神。
• 如果本机装了多个虚拟化软件，它们的虚拟网卡也要谨慎对待，最好在Wireshark的捕捉选项里只保留一个物理网卡勾选。

实验之前再做一个基本功：确认当前网络里的IP地址分配。Windows下在命令行执行ipconfig，Linux/macOS下执行ip addr，记下本机IP、网关IP和子网掩码。后面所有验证步骤都要围绕同一网段进行，否则你ping一个跨网段的地址，解析的根本不是目标主机，而是网关。

1.3 准备验证工具：命令行观察ARP缓存

Wireshark里看到的是“动态过程”，而ARP缓存表是“结果状态”。两次看结果，你才能确认解析成功之后系统把MAC地址存了下来。这是所有ARP实验里面最容易忽略的一步，很多人只看抓包，不看缓存，最后对原理的理解缺了一大块。

Windows上的查看命令是：

arp -a

Linux/macOS则是：

ip neigh show

在开始实验前，建议先清空缓存，确保第一个ping一定会触发新的ARP请求。Windows使用arp -d *清空；Linux使用sudo ip neigh flush all。注意，清空缓存之后，如果当前正好有正在进行的网络连接，系统会很快重新发起ARP解析，所以抓包窗口里可能比你预想的多几条请求，这属于正常现象。

准备好这些之后，再打开Wireshark，你就有了一个干净、可控的观测环境。

2. 让第一条ARP报文出现在屏幕上：完整抓包流程

环境准备完毕，下面开始正式抓包。这个阶段不需要背诵任何快捷键，只要按照“选网卡→开捕捉→产生流量→用过滤器锁定”这个顺序走，肯定能抓到。

2.1 启动、选网卡与混杂模式的坑

启动Wireshark之后，第一个窗口会列出所有可用的网卡接口。每个接口的右边还有一个实时波形图，这个波形能帮你判断那块网卡上是否有流量在动。选网卡的核心原则只有一个：网卡必须和你要通信的目标处在同一个广播域。

这里要特别说清楚“混杂模式”的适用范围。默认情况下，以太网网卡只接收目的MAC是本机的帧以及广播帧；勾选混杂模式之后，网卡才会把经过它的所有帧都收上来。ARP请求本身就是广播帧，所以不勾混杂模式也一定能抓到；但如果你想同时观察同一网段其他主机之间的ARP应答，就必须勾选混杂模式。在Windows上，Wireshark的抓包服务可能需要管理员权限才能正常使用，Linux也需要以root身份运行或者给抓包工具相应权限。如果打开后发现所有网卡都是“无数据”状态，先检查权限。

2.2 让ARP流量出现的几种手段

光开着抓包软件，网络上不一定有持续的ARP报文，所以需要自己人为触发。最经典的方法是在命令行执行：

ping 192.168.1.1

前提是ping的地址相对于本机是一个全新的IP，或者在实验前你清空了ARP缓存。如果目标IP早就在缓存里，ping不会重新发起ARP请求，这一点经常让新手误以为“Wireshark抓不到ARP是软件坏了”。另一种方法是直接在Wireshark里执行Ctrl+K打开捕捉选项，然后在“Capture Filter”里填arp，再开始抓包。这样提前过滤，屏幕上只会出现ARP报文，效果更干净。

如果你在Linux环境里，可以用arping命令定向发送ARP请求，生成报文的节奏更可控。例如：

arping -I eth0 192.168.1.1

Windows没有内置arping，就老老实实用ping触发。不管用哪种方法，目的都是让系统产生一条ARP请求报文。

2.3 过滤器写法：从“看到所有包”到“只看ARP”

Wireshark的过滤器分为两种，很多人把它们的语法搞混。捕获过滤器是在数据包进入内存之前就丢弃，使用BPF语法，通常在抓包前设置；显示过滤器是对已经捕获的数据包做筛选显示，使用Wireshark自己的语法，在抓包结束后或者抓包过程中随时修改。

捕获过滤器只需要记一个：

arp

或者更底层的写法：

ether proto 0x0806

显示过滤器更灵活，实验时建议掌握这几个：

在Wireshark的过滤工具栏里输入表达式后，背景是绿色说明语法正确，红色说明写错了，不用死记硬背，多试几次就好。

3. 透过报文看协议：请求、应答与三种特殊ARP形态

抓到报文只是第一步，真正有价值的是把一条ARP报文从头到尾拆开，看明白每个字段和现实网卡行为之间的对应关系。

3.1 以太网帧头：谁在广播，谁在单播

先看Ethernet II这一层。ARP协议本身不直接跑在IP之上，而是直接封装在以太网帧里，这是很多初学IP协议的人容易忽略的点。以太网帧头里的Type字段如果是0x0806，就说明上层载荷是ARP。

在一条ARP请求里，目的MAC地址显示为ff:ff:ff:ff:ff:ff，这就是“广播”。广播地址的意义是：这个帧会被交换机从所有非接收端口转发出去，到达广播域内每一台主机的网卡。而ARP应答的目的MAC地址是请求方网卡的单播MAC，只有那一台主机才会接收。

这里有个小细节可以写进实验报告：ARP报文加上14字节的以太网头之后，载荷长度是28字节，加起来42字节。因为以太网帧有最小长度限制，所以你抓到的帧长度通常会显示为60字节，多出来的部分是填充字节。在Wireshark里，如果你展开Ethernet头部，能看到一个“Padding”字段，这就是负责凑长度的。

3.2 ARP正文：一个“寻人启事”的四个关键字段

点开ARP层，看到的是一组固定格式的字段。我给学生们打过一个比方：ARP请求本质上就是局域网里的一个寻人启事。

它先写了寻人启事的格式约定，也就是“我用的是什么网络类型”。字段含义如下：

接下来的Opcode才是关键。1表示请求，2表示应答。请求报文里，发送方MAC和发送方IP填的是自己的信息，目标MAC填的全零，目标IP填的是要找的那个IP；应答报文里则会把对方的MAC地址填进“目标MAC”字段，同时把对方的IP填进“目标IP”字段。

四个地址字段要分清：

• Sender MAC address / Sender IP address：发起方自己的地址。
• Target MAC address / Target IP address：希望找到的对方地址。

ARP请求发出时，Target MAC是全零，因为“我根本不知道对方MAC，所以这一项只能空着”。这就像寻人启事里描述的是目标外貌，不会直接写“目标站在哪里”。而ARP应答会把这个空的坑填上，让请求方知道“你要找的人，MAC是这一串”。

3.3 免费ARP、ARP通告与代理ARP：三种容易混淆的情况

实验里你很快会发现，不只有“先请求后应答”这一种ARP报文，还有一些看起来怪怪的形态。最常见的三种特殊形态：

免费ARP（Gratuitous ARP）。发送方IP和目标IP都填自己的IP，opcode可以是1，目的MAC是广播。这类报文的作用是：告诉整个广播域“我的IP地址是X，我的MAC是Y，如果有谁和我冲突，赶紧出来说”。主机启动获取IP地址后、IP地址变更后，都可能发送免费ARP。在Wireshark里，用显示过滤器arp.spa == arp.tpa可以直接把它们筛出来。

ARP探测（ARP Probe）。主机拿到一个候选IP之后，会用源IP地址为0.0.0.0的ARP请求去试探这个地址是否空闲。看到Sender IP=0.0.0.0的报文，不要觉得奇怪，这是设备在进行地址冲突检测。

代理ARP（Proxy ARP）。当主机需要访问一个不在本网段的主机，而中间路由器开启了代理ARP时，路由器会代替远端主机回应ARP请求。于是你在Wireshark里会看到，明明请求的是另一台主机的IP，应答方MAC却是路由器的接口MAC。这种现象在wireshark分析里很容易误判，要结合目标IP和应答方MAC的对应关系来判断。

理解了这些之后，你已经能读懂一场正常通信里所有ARP报文了。

4. 进阶验证：伪造ARP应答，理解ARP为什么“无状态”

很多学校实验做到第3节就结束了，但我建议再做一步进阶验证，因为这一步能真正暴露ARP协议的设计特点：信任一切收到的应答，不做校验。搞清楚这一点，前面所有抓包行为都有了深层次的解释。

4.1 观察正常流程：ping之前一定先有ARP

先回到正常流程。清空ARP缓存后，在Wireshark里开始抓包，然后执行：

ping 192.168.1.1

一秒之内，你会看到两条ARP报文紧挨在一起。第一条目的MAC是ff:ff:ff:ff:ff:ff，opcode是1，里面问“谁的IP是192.168.1.1，请告诉你的MAC”；第二条目的MAC是你本机网卡的MAC，opcode是2，里面回“我就是192.168.1.1，我的MAC是xx:xx:xx:xx:xx:xx”。

用Wireshark的“Follow”功能看不出ARP的优势，因为它不是TCP流。你应当关注的是包序号和时间戳这两列。正常情况下，请求和应答之间的时间间隔在几毫秒之内，如果中间隔了几秒，说明目标主机可能正在被大量其他流量压着，或者网络有问题。

4.2 用Scapy构造一条假ARP应答，验证缓存会被覆盖

ARP协议最被人诟病的一点，就是它不验证应答的真实性。只要收到一条opcode=2的ARP应答，无论来源是谁，系统都会直接用里面的Sender MAC去更新缓存条目。要验证这一点，可以写一条极短的Scapy脚本，往目标主机发送一条伪造的ARP应答，假装自己是网关。

安装好Python和Scapy之后，在实验环境里执行下面的代码：

from scapy.all import * target_mac = "目标主机的MAC地址" # 例如 00:11:22:33:44:55 target_ip = "目标主机的IP地址" # 例如 192.168.1.100 fake_gateway_ip = "网关IP地址" # 例如 192.168.1.1 fake_mac = "aa:bb:cc:dd:ee:ff" # 一个不存在的伪造MAC pkt = Ether(dst=target_mac) / ARP( op=2, hwsrc=fake_mac, psrc=fake_gateway_ip, hwdst=target_mac, pdst=target_ip ) sendp(pkt, iface="eth0") # Windows下填Wireshark里看到的物理网卡名

在目标主机上执行arp -a，你会立刻发现网关IP对应的MAC变成了aa:bb:cc:dd:ee:ff，而不是真实的网关MAC。如果此时再ping网关，因为目标主机认为网关的MAC是这个不存在的地址，二层帧根本送不出去，现象就是“ping不通但网络连接配置完全正常”。

这会带来一个安全问题，也就是ARP欺骗。攻击者向目标主机持续发送伪造的网关ARP应答，可以让目标主机把所有去往网关的流量都交给攻击者，进而形成中间人。所以这类实验一定要限制在你自己可控的、专门搭设的实验网络里，不要对真实办公网或家庭网络做无意义的测试，更不建议用别人的主机做实验。

4.3 防御思路：静态ARP与交换机DAI

看到ARP的天然缺陷，接下来自然会想到怎么防御。如果你是网络管理员，第一道防线是静态ARP绑定。Windows下用管理员权限执行：

arp -s 192.168.1.1 00:11:22:33:44:55

这样网关的MAC地址不会因为收到伪造应答而变化。缺点是管理成本高，局域网里主机数量一多就不现实了。

真正在交换机层面解决问题的是DAI，也就是动态ARP检测。它需要交换机配合DHCP Snooping使用，交换机维护一张“IP-MAC-端口”的绑定表，一旦交换机收到一条ARP应答，而这个应答的地址组合不在绑定表中，就直接丢弃。Wireshark在主机侧看不出来这种被丢弃的包，但从实验角度你已经理解了它的防御逻辑就够了。

5. Wireshark里常见ARP异常与抓包失败排错

文章最后说排错，因为真实网络里你一定会遇到“抓不到”或者“抓到了但看不懂”的状况。这里整理的是我这些年遇到的高频问题以及完整的排查思路。

5.1 为什么Filter输入正确却什么也抓不到

这个问题出现过太多次。先把最值得怀疑的几项按概率排序：

还有一个非常隐蔽的坑：如果目标IP和本机不在同一个子网，你ping它时，系统不会直接解析目标主机的MAC，而是把报文发给网关，Wireshark里出现的ARP请求解析的是网关IP。这不是故障，是路由逻辑的正常表现。排错时先确认子网关系，别指望ARP请求的目标永远是你ping的那个IP。

5.2 大量重复ARP请求意味着什么

正常通信中，一条ARP请求通常只出现一次。如果你发现Wireshark里同一对IP反复发出成千上万条ARP请求，先看Time列的时间间隔。

• 如果每隔几十秒到几分钟出现一次，而且伴随IP地址相同，这多半是ARP缓存条目超时后的正常刷新。不同操作系统的超时时间不一样，有的几秒，有的好几分钟。
• 如果毫秒级连续出现，而且发送源来自同一台主机，那就要警惕了。可能是主机上运行了扫描工具，也可能是网卡驱动异常导致系统反复重发请求。
• 如果请求发出后完全没有应答，同时通信失败，就要去目标主机侧检查防火墙、睡眠策略、网络负载。

处理思路是先在Wireshark里用“Statistics→Protocol Hierarchy”看看ARP流量占比。正常局域网ARP流量占比通常很低，如果超过20%，广播域里大概率有异常设备，用IO Graph画一条速率曲线，再顺着MAC地址找到发送源机器。

5.3 广播风暴与ARP泛洪在Wireshark里如何判断

广播风暴这个词常和ARP泛洪混在一起，但它们并不完全一样。ARP泛洪只是ARP请求报文数量异常高；广播风暴则指广播帧在二层环路里被反复复制转发，整网带宽被拖垮。

判断广播风暴，最直观的是看Wireshark捕获速率。一个正常的百兆局域网里广播帧通常每秒几个到几十个，如果持续每秒成千上万个，同时伴随网络卡顿，可以怀疑存在环路。先在Wireshark里应用显示过滤器，筛出所有广播帧：

eth.addr == ff:ff:ff:ff:ff:ff

再用“Telephony→ANOVA”工具或者IO Graph按源MAC地址做分类，找到广播帧占比最高的网卡。处理风暴的方法不是继续抓包，而是从交换机上拔线分段定位，一台一台缩小范围，直到找到产生环路的链路。这个场景虽然不属于日常ARP实验，但掌握了“用广播地址过滤+按源MAC统计”这两招，你排查类似问题的速度会快很多。

写在最后：实验里值得养成的几个习惯

做完整个实验，我建议你在报告里重点记录三组数据：本地ARP缓存的初始状态、ping目标时请求和应答的序号间隔、以及清空缓存之后系统自动发出的第一条ARP请求方向。这些数据比单独截一张图更有说服力，也能让老师一眼看出你真的理解了解析流程。

最后分享一个我自己的小技巧：抓包过程中如果觉得ARP报文不够多，不要反复去点ping，那只会增加干扰；直接把本机的ARP缓存删掉，然后访问一个局域网里的共享文件夹或者网页，系统会在后台自动发起一系列ARP请求，你反而能看到更真实的协议行为。多做几次这个动作，你对ARP的把握会比单看课本牢固得多。