简介：这份资源围绕Wireshark抓包处理网络故障展开，面向网络运维人员、网络工程师及需要排查异常流量的技术人员，帮助解决VLAN端口流量突增、内网与外网IP攻击等实际问题。资源包内含1个docx文档，压缩包约385KB，以图文案例形式记录抓包分析全过程，便于对照学习与查阅。内容结合锐捷交换机环境，讲解镜像端口配置、关闭端口安全策略、使用Wireshark分析抓包文件，并区分外网IP与内网IP两类攻击的处理思路：外网侧可结合防火墙NAT映射切换端口或联系运营商溯源，内网侧可通过核心交换机、AC管理页面定位异常终端，最终找到教学一体机并断网重装恢复。案例还展示了SSDP协议攻击导致端口流量从5000多kbps降至400多kbps的验证过程。目前已有1550人学习，适合希望掌握抓包排障思路、提升网络故障定位能力的读者参考。
1. 从一次端口流量异常说起：这套抓包排障方案到底解决什么问题
空载端口平时跑 200 多 KBPS，某天巡检突然发现所有无线网段 VLAN 都飙到 5000 KBPS 以上，AC 上 AP 端口没带业务也在拼命收发数据包。这种场景下，重启设备、拔网线、换端口都是碰运气，真正能定位到「谁在发包、发给谁、用的什么协议」的手段只有一个：在交换机上做端口镜像，用 Wireshark 把流量抓下来看。这套方案面向的是日常要处理 VLAN 流量异常、广播风暴、内网攻击、外网扫描的运维人员和正在做网络排障课程设计的学生，核心思路是「镜像口配置 → 抓包 → 协议分析 → 定位终端 → 恢复验证」五步闭环。整套流程不依赖高端设备，一台支持端口镜像的接入交换机加一台装了 Wireshark 的笔记本就能跑通，关键在于每一步的命令和判断依据要清楚。
2. 抓包前的环境准备：镜像口配置与安全策略处理
端口镜像（Port Mirroring）是把被监控端口的流量复制一份到监控端口，Wireshark 接在监控端口上就能看到全部原始报文。听起来简单，但实际配置时有两个坑：一是交换机默认开启的端口安全策略会把镜像流量拦掉，二是不同品牌交换机的镜像命令差异很大。下面以本次案例中使用的锐捷交换机为例，把配置流程拆开讲。
2.1 关闭端口安全策略
在配置镜像之前，必须先确认被镜像端口和镜像端口上没有启用 IP 源防护和 ARP 检查。这两条策略的作用是防止 IP 欺骗和 ARP 攻击，但它们会过滤掉部分镜像流量，导致抓包结果不完整。
# 进入被镜像端口和镜像端口的配置模式 interface gigabitEthernet 0/1 no ip verify source port-security no arp-check exit interface gigabitEthernet 0/24 no ip verify source port-security no arp-check exitno ip verify source port-security关闭的是 IP 源地址验证，no arp-check关闭的是 ARP 报文检查。这两条命令在不同品牌交换机上写法不同，华为对应undo ip source check和undo arp anti-attack check，H3C 对应undo ip verify source和undo arp detection。配置前先用show running-config确认当前端口有没有启用这些策略，没有启用就不用执行。
注意：关闭安全策略只是临时操作，抓包结束后要记得恢复，否则端口会失去防护能力。
2.2 配置镜像源端口和目的端口
锐捷交换机的镜像配置分两步：指定源端口（被监控的口）和目的端口（接电脑的口）。
# 配置镜像会话，源端口为 g0/1，双向流量都镜像 monitor session 1 source interface gigabitEthernet 0/1 both # 配置目的端口为 g0/24，电脑接在这个口上 monitor session 1 destination interface gigabitEthernet 0/24 switch # 查看镜像会话状态 show monitorboth表示同时镜像入方向和出方向的流量，如果只关心某个方向可以改成rx或tx。switch关键字表示目的端口工作在交换模式，允许多个镜像会话共用。执行show monitor后应该能看到 session 1 的状态是 active，源端口和目的端口都正确列出。如果状态显示 inactive，检查目的端口是不是已经被其他会话占用，或者端口本身处于 shutdown 状态。
2.3 抓包前的连通性确认
电脑用网线接到镜像口之后，先确认网卡能正常 up。Windows 下在「网络连接」里看适配器状态，Linux 下用ip link show确认。然后打开 Wireshark，选择对应的网卡，不要急着点开始，先在捕获选项里设置一个抓包过滤器。
# Wireshark 捕获过滤器示例：只抓 HTTP 和 SSDP 流量 tcp port 80 or udp port 1900捕获过滤器（BPF 语法）在抓包阶段就过滤掉无关流量，减少文件体积。显示过滤器（Wireshark 语法）是在抓完之后筛选，两者不要搞混。如果不知道异常流量用什么协议，捕获过滤器留空，先全量抓 30 秒，看协议分层统计再决定下一步。
3. 抓包结果分析：从协议分布到异常 IP 定位
抓到包只是第一步，真正花时间的是分析。Wireshark 的「协议分层统计」和「会话统计」两个功能能快速缩小范围，然后再针对具体 IP 做深度排查。
3.1 用协议分层快速定位异常协议
打开抓包文件后，点菜单栏「统计」→「协议分层」，会看到所有协议的报文数量和占比。正常空载端口的协议分布里，ARP、STP、LLDP 这些基础协议占大头，每个协议的包量都在几百以内。如果某个协议突然出现几万甚至几十万个包，那就是异常源头。
本次案例中，协议分层里 SSDP 的包量排在第一，远超 ARP 和 STP。SSDP（Simple Service Discovery Protocol）是 UPnP 设备用来互相发现的协议，走 UDP 1900 端口，正常情况下一个网段里只有几台设备会发，包量很小。当某台设备中招或者系统异常时，它会以极高频率发送 SSDP 报文，形成类似广播风暴的效果。
# 显示过滤器：只看 SSDP 报文 ssdp # 显示过滤器：看某个 IP 发出的所有 SSDP ip.src == 192.168.1.100 && ssdp用ssdp过滤器筛出来的报文，看 Source 列就能找到发包最多的 IP。如果源 IP 是内网地址，说明问题终端在内部；如果是外网地址，说明流量来自外部或者内网设备在跟外部通信。
3.2 内网 IP 的终端定位方法
确认异常 IP 是内网地址后，下一步是找到这台设备接在哪个交换机、哪个端口上。有两种路径可以走。
第一种是通过核心交换机逐级查 MAC 地址表。先用arp -a或者 Wireshark 里的 ARP 报文拿到 IP 对应的 MAC，然后登录核心交换机：
# 在核心交换机上查 MAC 地址对应的端口 show mac-address-table | include 00d0.f822.33a1 # 输出示例： # 00d0.f822.33a1 VLAN 10 GigabitEthernet 0/12拿到下联端口后，用show lldp neighbors看这个端口对端接的是哪台汇聚交换机，远程登录上去重复同样的操作，直到找到接入层交换机上的具体端口。这个过程通常要跳两到三层，每层都要确认 MAC 地址表。
第二种是通过 AC 管理平台直接查。如果异常设备是无线终端，AC 的用户管理页面里输入 IP 地址就能看到关联的 MAC、连接的 AP 名称和 AP 的物理位置。本次案例中，AC 平台上的运维数据是实时更新的，直接定位到 AP 所在教室，发现是一台教学一体机在发 SSDP 报文。
提示：AC 平台的数据准确性取决于日常运维有没有及时更新 AP 位置信息。如果数据不准，还是得走交换机命令逐级排查。
3.3 外网 IP 的映射端口排查
如果异常 IP 是外网地址，排查思路不同。先在 Wireshark 里打开对应的数据包，看目的端口是多少，然后登录防火墙查 NAT 映射表，确认这个端口映射到了内网哪台服务器。
# 在防火墙上查看 NAT 映射规则 show nat translations | include 8080 # 输出示例： # tcp 10.1.1.50:8080 203.0.113.10:8080 --- ---如果确认某个映射端口没有实际业务在使用，可以直接关掉。如果有业务在用，就切换到另一个映射端口，同时更新防火墙规则和内部服务的监听配置。切换之后继续抓包观察，如果新端口还是被扫描，说明攻击源在持续跟踪，这种情况需要把专线 IP 切换到备用地址，并联系运营商做溯源。
4. 故障处置与恢复验证：从断网到流量回落
定位到异常终端之后，处置动作本身不复杂，关键是处置后的验证要做到位，否则容易出现「以为修好了其实没修好」的情况。
4.1 终端处置的两种策略
对于内网异常终端，处置方式取决于紧急程度。如果网络已经严重拥堵，影响面大，先在核心交换机上禁用该 MAC 地址，让网络先恢复：
# 在接入层交换机上禁用异常 MAC mac-address blackhole 00d0.f822.33a1 vlan 10这条命令把 MAC 地址加入黑名单，该设备的所有流量会被丢弃。网络恢复后再慢慢处理终端本身。如果影响面不大，可以直接到现场断网、重装系统或者杀毒。
本次案例中，异常设备是一台教学一体机，现场断网后重装系统，SSDP 报文消失。重装后再次抓包确认，端口流量从 5000 多 KBPS 降到 400 多 KBPS。这里要注意，400 KBPS 是启用了 SNMP 协议后的正常底噪，如果没有启用 SNMP，空载端口的流量应该更低，大概在 200 KBPS 左右。
4.2 恢复验证的检查清单
处置完成后，按下面几个维度确认故障是否真正解决：
| 检查项 | 正常标准 | 验证方法 |
|---|---|---|
| 端口流量 | 回落到基线水平 | 交换机show interface看 5 分钟平均速率 |
| 异常协议包量 | 大幅下降或消失 | Wireshark 协议分层统计对比 |
| 异常 IP 活动 | 不再发包 | 显示过滤器ip.src == 异常IP确认 |
| 终端状态 | 系统正常、无异常进程 | 现场检查或远程桌面确认 |
| 网络质量 | 延迟和丢包恢复正常 | ping 网关和核心业务地址 |
验证时至少观察 10 分钟，因为有些异常行为是周期性的，抓 30 秒可能刚好落在间隔期。如果条件允许，在处置前后各抓一次包做对比，这样在写故障报告或者答辩时也有据可依。
5. 避坑与常见问题：抓包排障中最容易翻车的五个点
这套流程看起来线性，但实际操作中翻车的地方不少。下面五条是项目里踩过的坑，每条按「现象 → 原因 → 解决」展开。
现象一：镜像口配好了，Wireshark 里一个包都看不到。原因通常是端口安全策略没关干净，或者镜像会话的目的端口被其他功能占用。解决方法是先show monitor确认会话状态，再检查目的端口有没有被划到其他 VLAN 或者被 ACL 拦截。另外，有些交换机的镜像目的端口不能同时作为普通业务口使用，配之前确认端口角色。
现象二：抓到的包全是重复的，每个报文出现两次。这是因为镜像源端口配了both，同时镜像了入和出两个方向，而某些报文在入和出方向都会经过一次。解决方法是根据排查目标只镜像一个方向，比如只关心设备发出的流量就配rx，只关心收到的流量就配tx。
现象三：Wireshark 显示「没有找到接口」或者抓包按钮是灰的。Windows 下通常是 WinPcap 或 Npcap 驱动没装好，重新安装 Wireshark 时勾选 Npcap 组件。Linux 下是当前用户没有抓包权限，用sudo setcap cap_net_raw+eip /usr/bin/dumpcap给 dumpcap 赋权，或者直接用sudo wireshark启动。
现象四：抓到异常 IP 了，但在交换机上查不到 MAC 地址表。这种情况一般是 MAC 地址表老化时间到了，默认 300 秒。解决方法是先在 Wireshark 里找到该 IP 对应的 ARP 报文拿到 MAC，然后立刻去交换机上查，动作要快。如果还是查不到，可能是终端已经离线，或者中间经过了 NAT 设备，内网看到的 IP 不是终端的真实 IP。
现象五：处置完终端后流量没降下来。先确认是不是有多台设备在发异常报文，Wireshark 里按 Source IP 排序看是不是只有一个源。如果确实只有一台，检查处置动作是否生效，比如黑名单命令有没有敲错 VLAN，或者终端重装后连到了另一个网段。还有一种可能是交换机本身的流量统计有延迟，等 5 分钟再看。
6. 验收与答辩：怎么证明这套排障流程真的有效
这套方案的验收标准不是「配置敲完了」，而是「故障定位准、处置动作对、恢复验证有数据」。如果你是在做课程设计或者毕设，答辩时老师最关心的不是你用了多少命令，而是你能不能把「为什么这么判断」讲清楚。
验收时准备三样东西：抓包文件、交换机配置截图、处置前后的流量对比数据。抓包文件要能展示异常协议的特征，比如 SSDP 报文的高频发送；配置截图要能证明镜像会话建立成功；流量对比数据要能说明处置前后的差异，比如从 5000 KBPS 降到 400 KBPS。
答辩时按这个顺序讲：先描述故障现象（端口流量异常升高），再说排查思路（为什么选择端口镜像而不是其他手段），然后展示关键证据（Wireshark 里的协议分布和异常 IP），接着讲定位过程（怎么从 IP 找到 MAC 再找到端口），最后给恢复验证数据。整个过程控制在 8 到 10 分钟，重点放在「判断依据」上，命令本身不用逐条念。
有一个技巧：提前把 Wireshark 的显示过滤器保存成按钮，答辩时直接点按钮切换视图，比现场敲过滤器语法要稳。另外，如果老师问「怎么确认不是误报」，你可以展示正常空载端口的抓包文件做对比，说明正常情况下的协议分布和流量基线是多少。
我自己的习惯是每次处理完故障后，把抓包文件、配置命令、处置步骤和验证数据整理成一个文件夹，命名规则是「日期-故障类型-涉及设备」。这样下次遇到类似问题可以直接翻记录，答辩或者写报告时也有现成素材。从那以后我每次做端口镜像之前，都会先show running-config确认安全策略状态，抓完包立刻恢复配置，避免留下隐患。希望这套流程能帮到你。
本文还有配套的精品资源，点击获取
