简介围绕Wireshark抓包定位网络故障的实战型docx文档面向网络运维、系统集成与网络安全初学者及一线工程师重点解决VLAN端口流量突增、异常报文排查和攻击源定位等问题。压缩包内共1个docx文件大小约385KB以案例讲解方式组织内容便于直接查阅和对照排障。文档结合锐捷交换机环境梳理镜像端口配置、端口安全策略关闭、Wireshark抓包分析等关键环节并给出内网IP与外网IP两类异常的处理思路前者可借助核心交换机、AC管理页面和MAC地址逐级定位终端位置后者可通过防火墙NAT映射排查并配合运营商溯源。文中还记录了SSDP协议攻击导致端口流量升至5000kbps以上、处置后回落至400kbps左右的完整案例可帮助读者建立从抓包、分析到定位、恢复的排错路径。目前已有1550人学习适合需要积累实战案例与故障处置经验的技术人员参考。1. 空载口流量突然翻二十倍抓包这件事得先做对哪几步日常巡检里有一种异常特别容易被放过每个 VLAN 内的端口流量突然增大平时只有 200 多 Kbps 的空载端口包量突然变成好几千 Kbps再到 AC 上一看AP 端口空载也有大量数据包所有无线网段的 VLAN 都挂在 5000 Kbps 以上。这个量级谈不到打满带宽但故障已经能看出轮廓了——设备本身没报警、链路没断、用户也未必立刻有感觉光看流量图查不出根因得把包抓下来看里面到底跑了什么协议、谁是源、打到谁身上。这套方案解决的就是这个环节用交换机端口镜像把异常端口的流量复制一份出来用 Wireshark 落成 pcap再从 pcap 里的 IP 和 MAC 一路回溯到具体的接入层端口和物理位置。它适合学校、园区这类有无线控制器、有多层交换、需要快速定位内网失陷终端的运维场景也适合拿来做网络故障排查方向的毕设或课设因为整条链路从采集到处置是可复现的。2. 方案边界与技术选型三个必须回答的问题与一套采集组合动手之前先想清楚两件事这次要回答什么问题用什么手段回答。前者决定抓哪里的包、写什么过滤表达式后者决定对业务的影响、能拿到的证据粒度以及整套方案的成本。很多人抓了两个 G 的包最后只得出“流量很大”这个结论问题就出在没有事先把要回答的问题列清楚。2.1 先确认要回答的三个问题第一个问题是异常流量是什么。协议、源端口、目的端口、报文大小分布这决定后面用哪条过滤表达式去统计。本次案例里抓下来一看 UDP 1900 占了绝大多数目的地址是 239.255.255.250SSDP 的名头一出来方向就清楚了一半。如果一开始不知道抓什么可以先不限过滤条件抓 1 到 2 分钟用“统计 → 协议分级”看一眼哪一层、哪个协议占比最高再回头写精确过滤。第二个问题是源在哪一侧。是内网地址还是外网地址这一步直接决定后续走两条完全不同的处置路径。内网源要回答的是“在哪个交换机的哪个口、物理位置在哪间教室”外网源要回答的是“防火墙上哪条映射策略、映射到哪台内网服务器、能不能换端口”。抓包文件里的ip.src字段一眼就能看出来但前提是抓的位置能同时看到两个方向——如果镜像口只配了 rx反方向的包就看不见判断会出错。第三个问题是处置手段是什么。内网失陷终端通常是现场断网、重装系统、或者先按 MAC 地址禁用联网再慢慢找位置外网来的扫描和攻击先在防火墙上调映射端口调完还被扫就联系运营商对攻击源做溯源同时把专线 IP 切到备用地址。这三个问题在抓包前就要写在纸上抓完对着回答答不上来就说明抓的位置或过滤条件不对。提示把这三个问题做成一张排查单现场每抓一次包就在单子上勾一项比抓完再凭记忆复盘靠谱得多。2.2 采集组合为什么定在交换机端口镜像加 Wireshark能把包弄到手的方式不止一种各自的取舍差别很大采集方式能看到什么对业务影响现实适用性集线器共享式抓包冲突域内全部报文无百兆时代产物现网基本淘汰终端本机装抓包软件本机收发全部报文需要装软件、占 CPU可控 PC 可以AP 和一体机不行交换机端口镜像被镜像口双向全部报文无侵入仅占用目的口带宽主力方案可管理交换机都支持NetFlow / sFlow五元组、字节数、采样流无只能看流量画像看不到协议内容分光器 / 流量复制器链路上全部光信号无成本高多用于骨干和出口本次选的是端口镜像加 Wireshark理由很直接异常口接的是 AP终端本身不受控不可能上去装软件而问题恰好出在“空载口上跑了什么协议”这个层面NetFlow 只给字节数给不出 SSDP 这种协议特征。镜像对业务零侵入配置几条命令就能起一个会话撤掉也只要一条no monitor session 1。Wireshark 这边则是免费、跨平台、过滤语法成熟遇到不认识的协议还能顺着字段一层层展开。代价也要说清楚镜像会把被镜像口的双向流量全部复制到目的口如果被镜像口本身跑满千兆目的口就得是万兆否则丢包。本次案例里异常口峰值也就 5000 多 Kbps百兆目的口都绰绰有余不存在这个顾虑。2.3 方案的适用面与不适用面适用的一面交换网络是可控的、能登上去配镜像网络里有 AC 或者至少有多层交换能靠 MAC 表逐跳回溯抓包时长在分钟级pcap 落盘不会撑爆磁盘。本次案例还多了一个便利条件——AC 管理平台上的用户档案是运维过程中实时更新过的IP、MAC、所连 AP 三者能对上定位速度比纯靠交换机命令快一截。不适用的一面也要讲明白。纯傻瓜交换机没有镜像能力这套流程走不通云上环境拿不到底层虚拟交换机的镜像口得靠 VPC 流量日志之类的替代手段全加密流量虽然能抓到包但应用层内容解不开只能靠五元组和 TLS 握手指纹做粗判骨干链路动辄几十 G镜像口根本接不住得用分光加专用采集设备。把这些边界写在方案开头评审和答辩的时候能省掉一半追问。3. 总体架构设计采集层、分析层、处置层的三层结构与镜像会话配置整套方案拆成三层每层有明确的输入输出层与层之间靠文件和时间戳衔接。这样拆的好处是排障时可以逐层验证抓不到包就查采集层抓到了看不出问题就查分析层看出来了处置不掉就查处置层不会一上来就怀疑人生。3.1 三层职责划分与数据流向采集层的职责是把线上的流量变成磁盘上的文件包含三样东西交换机上的镜像会话、一台接在目的口上的抓包终端、足够大的本地存储。输出是一批带时间戳的 pcapng 文件。分析层的职责是把文件变成结论工具就是 Wireshark 的几个统计模块加过滤表达式。输出是一张表异常 IP、异常 MAC、协议类型、报文速率、占比。处置层的职责是把结论变成动作工具是 AC 的用户管理页面、核心与接入交换机的命令行、防火墙的 NAT 策略页、以及运营商的应急通道。输出是“故障消除且可验证”。层主要工具输入输出采集交换机镜像会话、抓包终端、dumpcap被镜像口的双向流量带时间戳的 pcapng分析Wireshark 统计与过滤、tsharkpcapng 文件异常 IP/MAC/协议清单处置AC 管理页、交换机 CLI、防火墙策略页异常清单处置动作与验证结果3.2 镜像会话怎么建源口、目的口与端口安全策略配镜像之前有一个前置动作经常被跳过目的口上的端口安全和 ARP 检查要先关掉否则镜像过来的报文会被这些策略挡掉一部分抓出来的包看着像是“少了点什么”很难往策略上想。本次案例用的是锐捷交换机命令如下# 进入全局配置模式 configure terminal # 进入作为镜像目的口的 g0/24关掉端口安全校验和 ARP 检查 interface gigabitEthernet 0/24 no ip verify source port-security no arp-check exit # 建立会话 1源口 g0/1接 AP 的口双向镜像 monitor session 1 source interface gigabitEthernet 0/1 both # 指定目的口 g0/24switch 关键字表示目的口只出不进避免环路 monitor session 1 destination interface gigabitEthernet 0/24 switch # 回显确认会话状态 show monitor参数逐个解释一下。both表示同时镜像收和发两个方向排查“谁在发包”时这一项必须选 both只选 rx 会漏掉本机主动外发的流量如果只想看某个方向可以换成rx或tx能显著降低目的口压力。目的口后面的switch关键字是让这个口变为单向出口不再参与正常的转发和 MAC 学习少了它容易出现广播风暴或者目的口自己发出去的包又被镜像回来。会话号1是本机唯一的一台交换机上可以建多个会话不同会话的源口不能重复。show monitor的输出要会读。正常情况下能看到会话编号、源接口列表、目的接口、以及状态是否为 up。如果目的口显示 down先查网线和对端网卡的 link再看抓包终端那块网卡是不是被系统关掉了。注意不同品牌的镜像命令差异很大华为系一般是port-mirroring或observe-port华三系是mirroring-group配置前先确认型号和版本不要照抄。3.3 抓包点放在哪接入、汇聚还是核心镜像点选在哪个层级直接决定抓到的包有多“干净”。接入层交换机上一个口就接一台 AP 或一台终端镜像出来基本就是这个设备的全部流量噪声最小定位最快缺点是只能看到单台设备事先不知道是谁出了问题就无从下手。汇聚层能看到一整个 VLAN 的流量适合已经知道异常在哪个网段、但不知道具体是哪台设备的情况。核心层视野最广但流量也最大镜像口很容易被打满丢包抓出来的 pcap 反而不完整误判风险高。本次的路径是先从 AC 巡检发现所有无线网段 VLAN 都有 5000 Kbps 以上流量锁定到无线网段再在 POE 交换机上找到同 VLAN 的口配镜像。这个顺序其实是最省事的先用聚合视图缩小范围再用接入层镜像精确定位。如果一上来就在核心配镜像两个 G 的包抓下来光打开就要等半天。3.4 采集侧参数与过滤表达式抓包终端的存储要提前规划。5000 Kbps 跑满一个小时大约 2 GB 出头不加限制地抓一下午磁盘就满了Wireshark 打开也会卡死。用 dumpcap 做环形缓冲是比较稳妥的做法# -i 3 指定抓包网卡序号先用 dumpcap -D 列出所有网卡确认 # -b filesize 单位是 KB这里单个文件 100MB # -b files 表示最多保留 20 个文件超出后覆盖最旧的 dumpcap -i 3 -b filesize:102400 -b files:20 -w /data/cap/ssdp.pcapng环形缓冲的含义是始终只保留最近约 2GB 的抓包数据。排查一个正在发生的故障这个窗口足够了真要长期留证就把文件数调大或者加个定时搬运脚本。过滤表达式建议分两轮写。第一轮宽一点先看清全貌# 只看 SSDP 报文UDP 1900 是它的固定端口 udp.port 1900 # 看某个内网 IP 主动发出的所有报文 ip.src 10.20.30.44 # 看某个 MAC 的流量MAC 地址要从抓包结果或交换机表里拿 eth.src a0:b1:c2:d3:e4:f5第二轮收窄只留可疑组合# 内网段发往 SSDP 组播地址的报文通常就是异常源 ip.src 10.20.30.0/24 ip.dst 239.255.255.250 udp.port 1900 # 排除本机管理流量后的剩余部分抓包电脑自己产生的包会干扰判断 !(ip.addr 10.20.30.250) udp过滤表达式在捕获阶段和显示阶段都能用。捕获过滤器Capture Filter用的是 BPF 语法写错了直接抓不到显示过滤器Display Filter在已经抓到的文件上生效写错了只是显示不出来不影响原始数据。排查现场我一般只设一个很宽的捕获过滤器甚至不设把精细过滤放到显示阶段免得条件写死漏掉关键报文。4. 落地实现从一份 pcap 定位到具体那个物理端口文件抓到手接下来的动作是有固定顺序的先看统计确定异常主体再按 IP 或 MAC 往回追最后落到端口和位置。顺序乱了就容易在细节里打转明明一个排序就能解决的问题翻了几百个包还没头绪。4.1 打开抓包文件先看三样东西第一样是“统计 → 会话 → IPv4”按字节数或报文数倒序排。排在第一的那一对地址基本就是异常主体。本次案例里排第一的是一个内网地址和 239.255.255.250报文数远超其他所有会话问题源一眼就出来了。第二样是“统计 → 协议分级”。看 UDP 占了多少、TCP 占了多少、应用层里哪个协议占比最高。如果一个空载口的流量里 80% 以上都是同一个 UDP 协议那就不必再怀疑“是不是正常业务突增”了。第三样是随便找一个异常报文展开它的详情字段看源端口、目的端口、报文长度和载荷特征。SSDP 的 M-SEARCH 报文结构很简单HOST: 239.255.255.250:1900、MAN: ssdp:discover、ST:这几行一路展开就能确认。确认了协议特征后面写过滤、算速率、做对比都有依据。提示Wireshark 的“统计 → 端点”能看到每个 MAC 和 IP 的收发字节数比会话视图更适合找“谁在单方面猛发”。4.2 内网源定位MAC 地址逐跳回溯的命令链拿到异常 IP 之后第一件事是搞到它的 MAC。抓包文件里直接就有eth.src或者在内网交换机上执行show ip arp按 IP 查。拿到 MAC 后从核心交换机开始一层层往下追# 核心交换机用 MAC 后 6 位模糊匹配避免不同版本的格式差异 show mac-address-table | include a0b1.c2 # 假设返回的是 gigabitEthernet 0/20看这个口的邻居是谁 show lldp neighbors interface gigabitEthernet 0/20 # 从邻居信息里拿到下联汇聚交换机的管理地址远程过去 # 汇聚交换机上重复同样的动作 show mac-address-table | include a0b1.c2 show lldp neighbors interface gigabitEthernet 0/8 # 最后在接入层交换机上确认端口 show mac-address-table | include a0b1.c2几个容易卡住的点。锐捷的 MAC 表显示格式随版本不同有的是a0b1.c2d3四位点分有的是a0:b1:c2:d3:e4:f5冒号分隔所以include后面只写后 6 位十六进制最保险不会因为格式对不上而查空。show lldp neighbors要给具体接口全局敲一遍输出太长反而不好找。另外 MAC 表有老化时间默认 5 分钟如果查询间隔太久可能已经查不到了这时候要么在抓包同时就查要么先在接入层把 MAC 记下来。本次案例里还有一条更快的路因为异常终端连的是无线直接在 AC 管理页面的用户管理里输入 IP就能看到对应的 MAC 和它当前关联的 AP。AC 上的数据是运维过程中实时维护过的IP、MAC、AP 三者对得上顺着 AP 的安装位置直接找到了那台教学一体机。这条路径比交换机命令快得多前提是 AC 上的资产信息得是真的——如果 AP 位置表几个月没更新照着找过去只会扑空。4.3 外网源处置NAT 映射表与备用地址如果抓包结果里的异常源是外网地址处置路径完全不同。先在防火墙上按这个公网地址查 NAT 映射找到它对应到哪台内网服务器、映射的是哪个端口。命令因平台而异策略页上一般都能按公网地址直接搜# 示例查看地址映射策略不同平台命令不同按实际设备调整 show nat policy show nat mappings # 确认某个公网地址映射到哪个内网地址和端口 show nat mapping detail 203.0.113.10查到之后有两条路。如果这个映射端口没有别的业务在用直接关掉映射攻击面就消失了。如果端口上确实跑着业务不能关就换一个映射端口把外部访问引到新端口上同时把旧端口封掉。换完端口如果还被扫说明对方不是碰运气扫端口而是盯着这个地址打这时候把情况整理成时间、源地址、报文样本提交给运营商做溯源同时把专线 IP 切到运营商提供的备用地址上。这套动作里最容易被忽略的是“换端口之后要复抓验证”。很多人换完就收工过两天发现新端口又被打了其实是对方在跟着业务走。换完端口重新镜像一次确认新端口上没有异常扫描流量这一步才算做完。4.4 SSDP 把空载口打满的原理与复现SSDP 是简单服务发现协议跑在 UDP 1900 上组播地址 239.255.255.250。设备开机或者定期会发 M-SEARCH 报文去找局域网里的服务正常情况下每分钟也就几条字节数微不足道。但当某台设备的 UPnP 服务异常、或者被恶意程序控制后它会以极高的频率反复发送这类报文而且目的地址是组播交换机会把每一份都泛洪到同 VLAN 的所有端口上——一台设备发整个网段的所有口都在收这就是为什么“空载口”的流量会集体抬起来。本次案例里那台教学一体机重装系统之后再抓一次包UDP 1900 的报文基本消失端口流量从 5000 多 Kbps 降到 400 多 Kbps。400 这个数字不是零是因为网络设备上启用了 SNMP交换机之间的管理报文本身就要占掉一部分如果没开 SNMP这个底噪还能再降200 Kbps 左右甚至更低。观测阶段端口流量SSDP 报文占比判断异常发生时5000 Kbps 以上占绝对多数存在异常源定位后断网回落至 1000 Kbps 以下明显下降处置方向正确重装系统后复抓400 Kbps 左右接近 0故障消除这张表的价值在于它给出了“什么是正常”的基准。没有基准看到 400 Kbps 还会怀疑是不是没修干净有了基准400 就是这套网络环境下的正常底噪。5. 避坑与常见问题五个最容易翻车的点镜像配完了、包也抓到了剩下的坑基本都在细节里。下面这几条是实操中反复出现的每一条都按现象、原因、解决写方便对着现场情况翻。5.1 镜像会话建好了抓包软件里只有零星广播现象show monitor显示会话 up源口和目的口都对但 Wireshark 里几乎看不到包偶尔有几条 ARP 或者广播。原因通常有三个。一是目的口的端口安全策略没关镜像过来的单播报文被ip verify source port-security或者arp-check挡掉了只放行了广播。二是目的口的switch关键字漏了口子进入了正常的转发和 MAC 学习状态行为不可预期。三是抓包终端选错了网卡机器上有多块网卡有线、无线、虚拟网卡Wireshark 默认选的往往不是插网线那块。解决先回交换机把no ip verify source port-security和no arp-check补上确认show monitor里目的口带 switch 属性再在抓包终端上用dumpcap -D列出所有网卡确认序号用-i明确指定。这三步走完还抓不到就换一根网线和一个口试试排除物理层问题。5.2 抓到的包里混着自己电脑的管理流量现象打开 pcap 一看抓包电脑自己的 IP 频繁出现SSH、RDP、DNS 查询一大堆把真正想看的异常流量稀释了做统计时排序也被打乱。原因抓包电脑接在镜像目的口上如果这个口和业务口在同一个 VLAN、又配了管理地址它自己的收发报文也会进入捕获。另外有些交换机会把目的口本身的管理流量一并复制过来。解决最彻底的做法是把镜像目的口划到一个独立的、不承载业务的 VLAN 里只用于抓包不配网关。临时方案是在显示过滤器里排除本机地址比如!(ip.addr 10.20.30.250)但这只是眼不见为净原始文件里还是混着。还有一种情况是抓包电脑自己起了自动更新或者云同步后台流量不小排查期间把这些服务关掉更省心。5.3 pcap 文件太大Wireshark 打开就卡死现象抓了一两个小时文件好几个 GWireshark 一打开就转圈切个视图要等半分钟最后干脆无响应。原因Wireshark 打开文件时会做全量解析文件越大内存占用和首次解析时间呈线性甚至更差的增长。5000 Kbps 跑一小时就是 2 GB 出头跑一下午轻松过 10 GB普通办公机扛不住。解决抓的时候就用 dumpcap 做环形缓冲把总量控住已经抓大的文件用editcap按时间切分分批打开# 按 60 秒切分成多个小文件前缀是 part editcap -i 60 big.pcapng part.pcapng # 只保留指定时间段的报文起止时间格式是 yyyy-MM-dd HH:mm:ss editcap -A 2024-06-01 09:00:00 -B 2024-06-01 09:05:00 big.pcapng slice.pcapng切完之后挑异常时段那几个文件看就行不用全量加载。另外命令行工具 tshark 在这种场景下比图形界面好用tshark -r big.pcapng -q -z io,phs能直接在终端打印协议分级不占多少内存。5.4 抓到了异常 IP却怎么也定位不到端口现象异常源 IP 明确MAC 也拿到了但在核心交换机上show mac-address-table | include查不到或者查到了但指向的端口明显不对。原因有几种。MAC 表默认老化时间是 300 秒如果抓包和查询之间隔了十几分钟表项早就清了设备配置了静态 IP 且和实际 MAC 不匹配抓到的eth.src和 ARP 表里的对不上中间存在 NAT 或者三层转发源 IP 在跨网段时已经被改写用抓到的 IP 去查根本对不上任何终端。解决先在抓包同一时间段内做查询或者抓包时同步记录 ARP 表快照。查不到就换用 MAC 后 6 位模糊匹配别带分隔符。如果是跨网段的情况抓包点要往前移到靠近源头的接入层或者同时在核心和接入两端抓靠时间戳对齐。实在追不下去还可以走 AC 这条捷径——无线用户的 IP、MAC、AP 关联关系在 AC 上是实时可见的比逐跳查表快。5.5 处置完就收工第二天同样的口又起来了现象断网、重装、流量回落一切看起来都好了。第二天巡检同样的 VLAN、同样的流量曲线又出现了。原因只处理了“这一台”没处理“这一类”。SSDP 这种组播报文的特点是发一份、全网段都收只要网段里还有第二台同样问题的设备流量还是会起来。另外如果没在接入层做广播/组播抑制任何一台设备异常都能把整个 VLAN 抬起来。解决处置完成后做三件事。一是在同一 VLAN 内重新抓一次包确认没有第二个异常源这一步经常能揪出漏网之鱼。二是在接入层配置组播和广播抑制阈值给这类流量加个上限单台设备再怎么发也不会把整个网段拖垮。三是把 AC 上的用户档案再核对一遍IP、MAC、AP 位置三者的对应关系要是实时的下一次再出问题才能靠它快速定位。6. 验收与答辩用一条流量曲线和一条定位链证明方案跑通了验收这套方案不需要多复杂的指标两条证据链就够了一条是流量曲线一条是定位链。流量曲线证明“问题确实存在并且确实被解决了”定位链证明“解决方案是可复现的换个人来也能走通”。先把整条时间线整理成一张表答辩时按这张表讲逻辑最清楚时间点动作观测指标判定T0日常巡检发现异常空载口 200 Kbps 升至 5000 Kbps 以上触发排查T030min配镜像、抓包 2 分钟UDP 1900 报文占绝对多数锁定协议T040min按 MAC 回溯或查 AC定位到接入层 g0/20 或某台 AP锁定位置T1现场断网、重装系统端口流量开始回落处置生效T12h重新抓包验证回落至 400 Kbps 左右SSDP 接近 0验收通过讲的时候重点落在两个“可复现”上。第一镜像配置是可复现的源口、目的口、端口安全策略这几条命令写进文档换一台同品牌交换机照着敲就行。第二定位链是可复现的从 pcap 里的 MAC 到核心表、到 LLDP 邻居、到汇聚、到接入端口每一步都有明确命令和预期输出不依赖某个人对网络拓扑的熟悉程度。答辩时被问得最多的三个问题提前准备好答案。问“为什么不直接拔网线”答拔网线只能止血找不到根因同类设备还会再犯而且现场断网会影响教学得先定位再动手。问“为什么不用 NetFlow”答NetFlow 给的是五元组和字节数能看出流量异常但看不出这是 SSDP 还是别的协议而这次的关键恰恰在协议特征上。问“镜像口会不会丢包”答会所以要先估算被镜像口的峰值带宽目的口带宽要大于峰值本次峰值 5000 多 Kbps百兆目的口余量充足。还有一个加分项把处置前后的两张抓包文件都留着答辩时现场打开对比。左边是满屏的 SSDP右边干干净净中间隔着一次重装系统。这比任何文字描述都有说服力。从那以后我每次配镜像都强制走一遍固定顺序——先关目的口的端口安全和 ARP 检查再建会话再show monitor确认最后才插网线开抓。这个顺序跳过任何一步后面都可能花半小时去找一个本来不存在的“疑难问题”。希望帮到你。本文还有配套的精品资源点击获取
简介围绕Wireshark抓包定位网络故障的实战型docx文档面向网络运维、系统集成与网络安全初学者及一线工程师重点解决VLAN端口流量突增、异常报文排查和攻击源定位等问题。压缩包内共1个docx文件大小约385KB以案例讲解方式组织内容便于直接查阅和对照排障。文档结合锐捷交换机环境梳理镜像端口配置、端口安全策略关闭、Wireshark抓包分析等关键环节并给出内网IP与外网IP两类异常的处理思路前者可借助核心交换机、AC管理页面和MAC地址逐级定位终端位置后者可通过防火墙NAT映射排查并配合运营商溯源。文中还记录了SSDP协议攻击导致端口流量升至5000kbps以上、处置后回落至400kbps左右的完整案例可帮助读者建立从抓包、分析到定位、恢复的排错路径。目前已有1550人学习适合需要积累实战案例与故障处置经验的技术人员参考。1. 空载口流量突然翻二十倍抓包这件事得先做对哪几步日常巡检里有一种异常特别容易被放过每个 VLAN 内的端口流量突然增大平时只有 200 多 Kbps 的空载端口包量突然变成好几千 Kbps再到 AC 上一看AP 端口空载也有大量数据包所有无线网段的 VLAN 都挂在 5000 Kbps 以上。这个量级谈不到打满带宽但故障已经能看出轮廓了——设备本身没报警、链路没断、用户也未必立刻有感觉光看流量图查不出根因得把包抓下来看里面到底跑了什么协议、谁是源、打到谁身上。这套方案解决的就是这个环节用交换机端口镜像把异常端口的流量复制一份出来用 Wireshark 落成 pcap再从 pcap 里的 IP 和 MAC 一路回溯到具体的接入层端口和物理位置。它适合学校、园区这类有无线控制器、有多层交换、需要快速定位内网失陷终端的运维场景也适合拿来做网络故障排查方向的毕设或课设因为整条链路从采集到处置是可复现的。2. 方案边界与技术选型三个必须回答的问题与一套采集组合动手之前先想清楚两件事这次要回答什么问题用什么手段回答。前者决定抓哪里的包、写什么过滤表达式后者决定对业务的影响、能拿到的证据粒度以及整套方案的成本。很多人抓了两个 G 的包最后只得出“流量很大”这个结论问题就出在没有事先把要回答的问题列清楚。2.1 先确认要回答的三个问题第一个问题是异常流量是什么。协议、源端口、目的端口、报文大小分布这决定后面用哪条过滤表达式去统计。本次案例里抓下来一看 UDP 1900 占了绝大多数目的地址是 239.255.255.250SSDP 的名头一出来方向就清楚了一半。如果一开始不知道抓什么可以先不限过滤条件抓 1 到 2 分钟用“统计 → 协议分级”看一眼哪一层、哪个协议占比最高再回头写精确过滤。第二个问题是源在哪一侧。是内网地址还是外网地址这一步直接决定后续走两条完全不同的处置路径。内网源要回答的是“在哪个交换机的哪个口、物理位置在哪间教室”外网源要回答的是“防火墙上哪条映射策略、映射到哪台内网服务器、能不能换端口”。抓包文件里的ip.src字段一眼就能看出来但前提是抓的位置能同时看到两个方向——如果镜像口只配了 rx反方向的包就看不见判断会出错。第三个问题是处置手段是什么。内网失陷终端通常是现场断网、重装系统、或者先按 MAC 地址禁用联网再慢慢找位置外网来的扫描和攻击先在防火墙上调映射端口调完还被扫就联系运营商对攻击源做溯源同时把专线 IP 切到备用地址。这三个问题在抓包前就要写在纸上抓完对着回答答不上来就说明抓的位置或过滤条件不对。提示把这三个问题做成一张排查单现场每抓一次包就在单子上勾一项比抓完再凭记忆复盘靠谱得多。2.2 采集组合为什么定在交换机端口镜像加 Wireshark能把包弄到手的方式不止一种各自的取舍差别很大采集方式能看到什么对业务影响现实适用性集线器共享式抓包冲突域内全部报文无百兆时代产物现网基本淘汰终端本机装抓包软件本机收发全部报文需要装软件、占 CPU可控 PC 可以AP 和一体机不行交换机端口镜像被镜像口双向全部报文无侵入仅占用目的口带宽主力方案可管理交换机都支持NetFlow / sFlow五元组、字节数、采样流无只能看流量画像看不到协议内容分光器 / 流量复制器链路上全部光信号无成本高多用于骨干和出口本次选的是端口镜像加 Wireshark理由很直接异常口接的是 AP终端本身不受控不可能上去装软件而问题恰好出在“空载口上跑了什么协议”这个层面NetFlow 只给字节数给不出 SSDP 这种协议特征。镜像对业务零侵入配置几条命令就能起一个会话撤掉也只要一条no monitor session 1。Wireshark 这边则是免费、跨平台、过滤语法成熟遇到不认识的协议还能顺着字段一层层展开。代价也要说清楚镜像会把被镜像口的双向流量全部复制到目的口如果被镜像口本身跑满千兆目的口就得是万兆否则丢包。本次案例里异常口峰值也就 5000 多 Kbps百兆目的口都绰绰有余不存在这个顾虑。2.3 方案的适用面与不适用面适用的一面交换网络是可控的、能登上去配镜像网络里有 AC 或者至少有多层交换能靠 MAC 表逐跳回溯抓包时长在分钟级pcap 落盘不会撑爆磁盘。本次案例还多了一个便利条件——AC 管理平台上的用户档案是运维过程中实时更新过的IP、MAC、所连 AP 三者能对上定位速度比纯靠交换机命令快一截。不适用的一面也要讲明白。纯傻瓜交换机没有镜像能力这套流程走不通云上环境拿不到底层虚拟交换机的镜像口得靠 VPC 流量日志之类的替代手段全加密流量虽然能抓到包但应用层内容解不开只能靠五元组和 TLS 握手指纹做粗判骨干链路动辄几十 G镜像口根本接不住得用分光加专用采集设备。把这些边界写在方案开头评审和答辩的时候能省掉一半追问。3. 总体架构设计采集层、分析层、处置层的三层结构与镜像会话配置整套方案拆成三层每层有明确的输入输出层与层之间靠文件和时间戳衔接。这样拆的好处是排障时可以逐层验证抓不到包就查采集层抓到了看不出问题就查分析层看出来了处置不掉就查处置层不会一上来就怀疑人生。3.1 三层职责划分与数据流向采集层的职责是把线上的流量变成磁盘上的文件包含三样东西交换机上的镜像会话、一台接在目的口上的抓包终端、足够大的本地存储。输出是一批带时间戳的 pcapng 文件。分析层的职责是把文件变成结论工具就是 Wireshark 的几个统计模块加过滤表达式。输出是一张表异常 IP、异常 MAC、协议类型、报文速率、占比。处置层的职责是把结论变成动作工具是 AC 的用户管理页面、核心与接入交换机的命令行、防火墙的 NAT 策略页、以及运营商的应急通道。输出是“故障消除且可验证”。层主要工具输入输出采集交换机镜像会话、抓包终端、dumpcap被镜像口的双向流量带时间戳的 pcapng分析Wireshark 统计与过滤、tsharkpcapng 文件异常 IP/MAC/协议清单处置AC 管理页、交换机 CLI、防火墙策略页异常清单处置动作与验证结果3.2 镜像会话怎么建源口、目的口与端口安全策略配镜像之前有一个前置动作经常被跳过目的口上的端口安全和 ARP 检查要先关掉否则镜像过来的报文会被这些策略挡掉一部分抓出来的包看着像是“少了点什么”很难往策略上想。本次案例用的是锐捷交换机命令如下# 进入全局配置模式 configure terminal # 进入作为镜像目的口的 g0/24关掉端口安全校验和 ARP 检查 interface gigabitEthernet 0/24 no ip verify source port-security no arp-check exit # 建立会话 1源口 g0/1接 AP 的口双向镜像 monitor session 1 source interface gigabitEthernet 0/1 both # 指定目的口 g0/24switch 关键字表示目的口只出不进避免环路 monitor session 1 destination interface gigabitEthernet 0/24 switch # 回显确认会话状态 show monitor参数逐个解释一下。both表示同时镜像收和发两个方向排查“谁在发包”时这一项必须选 both只选 rx 会漏掉本机主动外发的流量如果只想看某个方向可以换成rx或tx能显著降低目的口压力。目的口后面的switch关键字是让这个口变为单向出口不再参与正常的转发和 MAC 学习少了它容易出现广播风暴或者目的口自己发出去的包又被镜像回来。会话号1是本机唯一的一台交换机上可以建多个会话不同会话的源口不能重复。show monitor的输出要会读。正常情况下能看到会话编号、源接口列表、目的接口、以及状态是否为 up。如果目的口显示 down先查网线和对端网卡的 link再看抓包终端那块网卡是不是被系统关掉了。注意不同品牌的镜像命令差异很大华为系一般是port-mirroring或observe-port华三系是mirroring-group配置前先确认型号和版本不要照抄。3.3 抓包点放在哪接入、汇聚还是核心镜像点选在哪个层级直接决定抓到的包有多“干净”。接入层交换机上一个口就接一台 AP 或一台终端镜像出来基本就是这个设备的全部流量噪声最小定位最快缺点是只能看到单台设备事先不知道是谁出了问题就无从下手。汇聚层能看到一整个 VLAN 的流量适合已经知道异常在哪个网段、但不知道具体是哪台设备的情况。核心层视野最广但流量也最大镜像口很容易被打满丢包抓出来的 pcap 反而不完整误判风险高。本次的路径是先从 AC 巡检发现所有无线网段 VLAN 都有 5000 Kbps 以上流量锁定到无线网段再在 POE 交换机上找到同 VLAN 的口配镜像。这个顺序其实是最省事的先用聚合视图缩小范围再用接入层镜像精确定位。如果一上来就在核心配镜像两个 G 的包抓下来光打开就要等半天。3.4 采集侧参数与过滤表达式抓包终端的存储要提前规划。5000 Kbps 跑满一个小时大约 2 GB 出头不加限制地抓一下午磁盘就满了Wireshark 打开也会卡死。用 dumpcap 做环形缓冲是比较稳妥的做法# -i 3 指定抓包网卡序号先用 dumpcap -D 列出所有网卡确认 # -b filesize 单位是 KB这里单个文件 100MB # -b files 表示最多保留 20 个文件超出后覆盖最旧的 dumpcap -i 3 -b filesize:102400 -b files:20 -w /data/cap/ssdp.pcapng环形缓冲的含义是始终只保留最近约 2GB 的抓包数据。排查一个正在发生的故障这个窗口足够了真要长期留证就把文件数调大或者加个定时搬运脚本。过滤表达式建议分两轮写。第一轮宽一点先看清全貌# 只看 SSDP 报文UDP 1900 是它的固定端口 udp.port 1900 # 看某个内网 IP 主动发出的所有报文 ip.src 10.20.30.44 # 看某个 MAC 的流量MAC 地址要从抓包结果或交换机表里拿 eth.src a0:b1:c2:d3:e4:f5第二轮收窄只留可疑组合# 内网段发往 SSDP 组播地址的报文通常就是异常源 ip.src 10.20.30.0/24 ip.dst 239.255.255.250 udp.port 1900 # 排除本机管理流量后的剩余部分抓包电脑自己产生的包会干扰判断 !(ip.addr 10.20.30.250) udp过滤表达式在捕获阶段和显示阶段都能用。捕获过滤器Capture Filter用的是 BPF 语法写错了直接抓不到显示过滤器Display Filter在已经抓到的文件上生效写错了只是显示不出来不影响原始数据。排查现场我一般只设一个很宽的捕获过滤器甚至不设把精细过滤放到显示阶段免得条件写死漏掉关键报文。4. 落地实现从一份 pcap 定位到具体那个物理端口文件抓到手接下来的动作是有固定顺序的先看统计确定异常主体再按 IP 或 MAC 往回追最后落到端口和位置。顺序乱了就容易在细节里打转明明一个排序就能解决的问题翻了几百个包还没头绪。4.1 打开抓包文件先看三样东西第一样是“统计 → 会话 → IPv4”按字节数或报文数倒序排。排在第一的那一对地址基本就是异常主体。本次案例里排第一的是一个内网地址和 239.255.255.250报文数远超其他所有会话问题源一眼就出来了。第二样是“统计 → 协议分级”。看 UDP 占了多少、TCP 占了多少、应用层里哪个协议占比最高。如果一个空载口的流量里 80% 以上都是同一个 UDP 协议那就不必再怀疑“是不是正常业务突增”了。第三样是随便找一个异常报文展开它的详情字段看源端口、目的端口、报文长度和载荷特征。SSDP 的 M-SEARCH 报文结构很简单HOST: 239.255.255.250:1900、MAN: ssdp:discover、ST:这几行一路展开就能确认。确认了协议特征后面写过滤、算速率、做对比都有依据。提示Wireshark 的“统计 → 端点”能看到每个 MAC 和 IP 的收发字节数比会话视图更适合找“谁在单方面猛发”。4.2 内网源定位MAC 地址逐跳回溯的命令链拿到异常 IP 之后第一件事是搞到它的 MAC。抓包文件里直接就有eth.src或者在内网交换机上执行show ip arp按 IP 查。拿到 MAC 后从核心交换机开始一层层往下追# 核心交换机用 MAC 后 6 位模糊匹配避免不同版本的格式差异 show mac-address-table | include a0b1.c2 # 假设返回的是 gigabitEthernet 0/20看这个口的邻居是谁 show lldp neighbors interface gigabitEthernet 0/20 # 从邻居信息里拿到下联汇聚交换机的管理地址远程过去 # 汇聚交换机上重复同样的动作 show mac-address-table | include a0b1.c2 show lldp neighbors interface gigabitEthernet 0/8 # 最后在接入层交换机上确认端口 show mac-address-table | include a0b1.c2几个容易卡住的点。锐捷的 MAC 表显示格式随版本不同有的是a0b1.c2d3四位点分有的是a0:b1:c2:d3:e4:f5冒号分隔所以include后面只写后 6 位十六进制最保险不会因为格式对不上而查空。show lldp neighbors要给具体接口全局敲一遍输出太长反而不好找。另外 MAC 表有老化时间默认 5 分钟如果查询间隔太久可能已经查不到了这时候要么在抓包同时就查要么先在接入层把 MAC 记下来。本次案例里还有一条更快的路因为异常终端连的是无线直接在 AC 管理页面的用户管理里输入 IP就能看到对应的 MAC 和它当前关联的 AP。AC 上的数据是运维过程中实时维护过的IP、MAC、AP 三者对得上顺着 AP 的安装位置直接找到了那台教学一体机。这条路径比交换机命令快得多前提是 AC 上的资产信息得是真的——如果 AP 位置表几个月没更新照着找过去只会扑空。4.3 外网源处置NAT 映射表与备用地址如果抓包结果里的异常源是外网地址处置路径完全不同。先在防火墙上按这个公网地址查 NAT 映射找到它对应到哪台内网服务器、映射的是哪个端口。命令因平台而异策略页上一般都能按公网地址直接搜# 示例查看地址映射策略不同平台命令不同按实际设备调整 show nat policy show nat mappings # 确认某个公网地址映射到哪个内网地址和端口 show nat mapping detail 203.0.113.10查到之后有两条路。如果这个映射端口没有别的业务在用直接关掉映射攻击面就消失了。如果端口上确实跑着业务不能关就换一个映射端口把外部访问引到新端口上同时把旧端口封掉。换完端口如果还被扫说明对方不是碰运气扫端口而是盯着这个地址打这时候把情况整理成时间、源地址、报文样本提交给运营商做溯源同时把专线 IP 切到运营商提供的备用地址上。这套动作里最容易被忽略的是“换端口之后要复抓验证”。很多人换完就收工过两天发现新端口又被打了其实是对方在跟着业务走。换完端口重新镜像一次确认新端口上没有异常扫描流量这一步才算做完。4.4 SSDP 把空载口打满的原理与复现SSDP 是简单服务发现协议跑在 UDP 1900 上组播地址 239.255.255.250。设备开机或者定期会发 M-SEARCH 报文去找局域网里的服务正常情况下每分钟也就几条字节数微不足道。但当某台设备的 UPnP 服务异常、或者被恶意程序控制后它会以极高的频率反复发送这类报文而且目的地址是组播交换机会把每一份都泛洪到同 VLAN 的所有端口上——一台设备发整个网段的所有口都在收这就是为什么“空载口”的流量会集体抬起来。本次案例里那台教学一体机重装系统之后再抓一次包UDP 1900 的报文基本消失端口流量从 5000 多 Kbps 降到 400 多 Kbps。400 这个数字不是零是因为网络设备上启用了 SNMP交换机之间的管理报文本身就要占掉一部分如果没开 SNMP这个底噪还能再降200 Kbps 左右甚至更低。观测阶段端口流量SSDP 报文占比判断异常发生时5000 Kbps 以上占绝对多数存在异常源定位后断网回落至 1000 Kbps 以下明显下降处置方向正确重装系统后复抓400 Kbps 左右接近 0故障消除这张表的价值在于它给出了“什么是正常”的基准。没有基准看到 400 Kbps 还会怀疑是不是没修干净有了基准400 就是这套网络环境下的正常底噪。5. 避坑与常见问题五个最容易翻车的点镜像配完了、包也抓到了剩下的坑基本都在细节里。下面这几条是实操中反复出现的每一条都按现象、原因、解决写方便对着现场情况翻。5.1 镜像会话建好了抓包软件里只有零星广播现象show monitor显示会话 up源口和目的口都对但 Wireshark 里几乎看不到包偶尔有几条 ARP 或者广播。原因通常有三个。一是目的口的端口安全策略没关镜像过来的单播报文被ip verify source port-security或者arp-check挡掉了只放行了广播。二是目的口的switch关键字漏了口子进入了正常的转发和 MAC 学习状态行为不可预期。三是抓包终端选错了网卡机器上有多块网卡有线、无线、虚拟网卡Wireshark 默认选的往往不是插网线那块。解决先回交换机把no ip verify source port-security和no arp-check补上确认show monitor里目的口带 switch 属性再在抓包终端上用dumpcap -D列出所有网卡确认序号用-i明确指定。这三步走完还抓不到就换一根网线和一个口试试排除物理层问题。5.2 抓到的包里混着自己电脑的管理流量现象打开 pcap 一看抓包电脑自己的 IP 频繁出现SSH、RDP、DNS 查询一大堆把真正想看的异常流量稀释了做统计时排序也被打乱。原因抓包电脑接在镜像目的口上如果这个口和业务口在同一个 VLAN、又配了管理地址它自己的收发报文也会进入捕获。另外有些交换机会把目的口本身的管理流量一并复制过来。解决最彻底的做法是把镜像目的口划到一个独立的、不承载业务的 VLAN 里只用于抓包不配网关。临时方案是在显示过滤器里排除本机地址比如!(ip.addr 10.20.30.250)但这只是眼不见为净原始文件里还是混着。还有一种情况是抓包电脑自己起了自动更新或者云同步后台流量不小排查期间把这些服务关掉更省心。5.3 pcap 文件太大Wireshark 打开就卡死现象抓了一两个小时文件好几个 GWireshark 一打开就转圈切个视图要等半分钟最后干脆无响应。原因Wireshark 打开文件时会做全量解析文件越大内存占用和首次解析时间呈线性甚至更差的增长。5000 Kbps 跑一小时就是 2 GB 出头跑一下午轻松过 10 GB普通办公机扛不住。解决抓的时候就用 dumpcap 做环形缓冲把总量控住已经抓大的文件用editcap按时间切分分批打开# 按 60 秒切分成多个小文件前缀是 part editcap -i 60 big.pcapng part.pcapng # 只保留指定时间段的报文起止时间格式是 yyyy-MM-dd HH:mm:ss editcap -A 2024-06-01 09:00:00 -B 2024-06-01 09:05:00 big.pcapng slice.pcapng切完之后挑异常时段那几个文件看就行不用全量加载。另外命令行工具 tshark 在这种场景下比图形界面好用tshark -r big.pcapng -q -z io,phs能直接在终端打印协议分级不占多少内存。5.4 抓到了异常 IP却怎么也定位不到端口现象异常源 IP 明确MAC 也拿到了但在核心交换机上show mac-address-table | include查不到或者查到了但指向的端口明显不对。原因有几种。MAC 表默认老化时间是 300 秒如果抓包和查询之间隔了十几分钟表项早就清了设备配置了静态 IP 且和实际 MAC 不匹配抓到的eth.src和 ARP 表里的对不上中间存在 NAT 或者三层转发源 IP 在跨网段时已经被改写用抓到的 IP 去查根本对不上任何终端。解决先在抓包同一时间段内做查询或者抓包时同步记录 ARP 表快照。查不到就换用 MAC 后 6 位模糊匹配别带分隔符。如果是跨网段的情况抓包点要往前移到靠近源头的接入层或者同时在核心和接入两端抓靠时间戳对齐。实在追不下去还可以走 AC 这条捷径——无线用户的 IP、MAC、AP 关联关系在 AC 上是实时可见的比逐跳查表快。5.5 处置完就收工第二天同样的口又起来了现象断网、重装、流量回落一切看起来都好了。第二天巡检同样的 VLAN、同样的流量曲线又出现了。原因只处理了“这一台”没处理“这一类”。SSDP 这种组播报文的特点是发一份、全网段都收只要网段里还有第二台同样问题的设备流量还是会起来。另外如果没在接入层做广播/组播抑制任何一台设备异常都能把整个 VLAN 抬起来。解决处置完成后做三件事。一是在同一 VLAN 内重新抓一次包确认没有第二个异常源这一步经常能揪出漏网之鱼。二是在接入层配置组播和广播抑制阈值给这类流量加个上限单台设备再怎么发也不会把整个网段拖垮。三是把 AC 上的用户档案再核对一遍IP、MAC、AP 位置三者的对应关系要是实时的下一次再出问题才能靠它快速定位。6. 验收与答辩用一条流量曲线和一条定位链证明方案跑通了验收这套方案不需要多复杂的指标两条证据链就够了一条是流量曲线一条是定位链。流量曲线证明“问题确实存在并且确实被解决了”定位链证明“解决方案是可复现的换个人来也能走通”。先把整条时间线整理成一张表答辩时按这张表讲逻辑最清楚时间点动作观测指标判定T0日常巡检发现异常空载口 200 Kbps 升至 5000 Kbps 以上触发排查T030min配镜像、抓包 2 分钟UDP 1900 报文占绝对多数锁定协议T040min按 MAC 回溯或查 AC定位到接入层 g0/20 或某台 AP锁定位置T1现场断网、重装系统端口流量开始回落处置生效T12h重新抓包验证回落至 400 Kbps 左右SSDP 接近 0验收通过讲的时候重点落在两个“可复现”上。第一镜像配置是可复现的源口、目的口、端口安全策略这几条命令写进文档换一台同品牌交换机照着敲就行。第二定位链是可复现的从 pcap 里的 MAC 到核心表、到 LLDP 邻居、到汇聚、到接入端口每一步都有明确命令和预期输出不依赖某个人对网络拓扑的熟悉程度。答辩时被问得最多的三个问题提前准备好答案。问“为什么不直接拔网线”答拔网线只能止血找不到根因同类设备还会再犯而且现场断网会影响教学得先定位再动手。问“为什么不用 NetFlow”答NetFlow 给的是五元组和字节数能看出流量异常但看不出这是 SSDP 还是别的协议而这次的关键恰恰在协议特征上。问“镜像口会不会丢包”答会所以要先估算被镜像口的峰值带宽目的口带宽要大于峰值本次峰值 5000 多 Kbps百兆目的口余量充足。还有一个加分项把处置前后的两张抓包文件都留着答辩时现场打开对比。左边是满屏的 SSDP右边干干净净中间隔着一次重装系统。这比任何文字描述都有说服力。从那以后我每次配镜像都强制走一遍固定顺序——先关目的口的端口安全和 ARP 检查再建会话再show monitor确认最后才插网线开抓。这个顺序跳过任何一步后面都可能花半小时去找一个本来不存在的“疑难问题”。希望帮到你。本文还有配套的精品资源点击获取
