简介这份资源围绕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 checkH3C 对应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。SSDPSimple 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_raweip /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确认安全策略状态抓完包立刻恢复配置避免留下隐患。希望这套流程能帮到你。本文还有配套的精品资源点击获取
