顺藤摸瓜：一次从防火墙告警到设备实物的溯源实战

顺藤摸瓜：一次从防火墙告警到设备实物的溯源实战

一次从"现象异常 → 多源抓包 → 逐步推理 → 实物验证"的完整网络溯源过程，案子最终通过比对设备标签上的 MAC 地址画上了句号。

---

一、问题起源

某天在核心交换机（新华三，192.168.1.0/24 广播域）下发现一个令人困惑的现象：

1. 在 192.168.1.0/24 段的电脑上执行 ping 192.168.1.162 ------ 不通
2. 但 arp -a 却能看到 192.168.1.162 的动态 MAC：08:57:00:7f:07:3b
3. 而在下游的 192.168.20.0/24、192.168.3.0/24、192.168.16.0/24 段的电脑上，ping 192.168.1.162 ------ 全都通

这台设备"有 ARP 但 ping 不通"，像幽灵一样悬在网络里。更奇怪的是，从另外几个不同网段却能正常到达它。为了搞清楚真相，决定上抓包。

---

二、网络拓扑还原

经过多轮排查和抓包分析，最终还原出实际网络拓扑如下：
192.168.20.0/24 直连设备
溯源目标
端口A
端口B
端口C
端口D
☁️ 互联网
核心交换机

新华三

192.168.1.0/24 广播域
TP-LINK 路由器

WAN口: 192.168.1.162

MAC: 08:57:00:7f:07:3b
TP-LINK 路由器

LAN口: 192.168.20.1

MAC: 08:57:00:7f:07:3a
192.168.20.18

抓包机
192.168.20.76

VIEW-YPLZ03（Win10）
WiFi路由器A

WAN→20.1 | LAN: 192.168.3.1
192.168.3.x

终端设备
WiFi路由器B

WAN→20.1 | LAN: 192.168.16.1
192.168.16.x

终端设备
其他级联路由器

若干子网段
192.168.1.250

杀软服务器
192.168.1.249

NSFOCUS防火墙

⚠ 曾被 .162 NAT后非法登录
其他 1 段设备

图例说明：🟣 紫色 = 溯源目标（TP-LINK） | 🔴 红色 = 安全告警设备 | 🟢 绿色 = 服务器/核心设备 | 🔵 蓝色 = 路由器 | 🟡 黄色 = 终端设备

关键拓扑特征：

• TP-LINK 的 WAN 口接在核心交换机上，IP 就是 192.168.1.162
• TP-LINK 的 LAN 口（192.168.20.1）下挂了多台 WiFi 路由器，3段、16段等均是级联在 20 段下的子网
• 3段和16段设备访问外网时，流量路径为：终端 → 本地网关 → 192.168.20.1（TP-LINK LAN口） → 192.168.1.162（TP-LINK WAN口）→ 核心交换机

这就解释了为什么 3 段、16 段能 ping 通 192.168.1.162，而 1 段直连设备不行------前者从 LAN 口方向访问 TP-LINK，后者从 WAN 口方向访问，完全不同的防火墙策略。

---

三、抓包文件清单

本次分析共采集 5 个抓包文件：

文件名	大小/包数	抓包位置	采集时间
NFS.pcap	3.4MB / 25,559包	核心交换机镜像口	2026-04-15 22:02
192.168.1.162-new.pcapng	55MB / 77,372包	核心交换机镜像口（162出口流量）	2026-04-13~14
TP-link.pcapng	133KB / 848包	TP-LINK LAN口	2026-04-15 21:58
TP-LINK1.pcapng	137KB / 848包	TP-LINK LAN口	2026-04-15 21:58
tp-link2.pcapng	144KB / 711包	TP-LINK LAN口	2026-04-15 21:58
40.20.pcapng	2.4KB / 22包	192.168.40.20 设备	2026-04-15 22:17

四、证据链逐步分析

4.1 第一个线索：MAC 地址的 OUI 前缀

在核心交换机 1 段的电脑上执行 arp -a，得到：

192.168.1.162    08:57:00:7f:07:3b    动态

同时，TP-LINK 设备的 LAN 口 MAC（可从管理界面或机身看到）是 08:57:00:7f:07:3a。

OUI 查询 ：MAC 前缀 08:57:00 属于 TP-LINK Technologies Co., Ltd.

两个 MAC 仅最后一位不同（3a 和 3b），相差 1------这是 TP-LINK 的标准硬件分配策略：同一台路由器，LAN 口和 WAN 口使用相邻的 MAC 地址。

第一个推断 ：192.168.1.162 的 MAC 属于 TP-LINK，且与 TP-LINK LAN 口 MAC 相邻，极大概率就是那台 TP-LINK 路由器的 WAN 口。

---

4.2 第二个线索：TP-LINK LAN 口抓包中的 ping 行为

在 TP-LINK1.pcapng（LAN 口抓包）中，抓包机 192.168.20.18 向 192.168.1.162 发起 ping 测试：

时间                    源IP             目标IP          ICMP类型
21:17:42.431    192.168.20.18   192.168.1.162   Echo Request (type=8)
21:17:42.432    192.168.1.162   192.168.20.18   Echo Reply   (type=0)  ← 延迟 < 1ms
21:17:43.466    192.168.20.18   192.168.1.162   Echo Request
21:17:43.466    192.168.1.162   192.168.20.18   Echo Reply
...（共4组，全部正常响应）

Request 和 Reply 之间仅相差约 0.3 毫秒，说明 192.168.1.162 对来自 LAN 口方向的 ICMP 是正常响应的。

第二个推断：设备是活跃的，响应 LAN 口方向的 ping，但不响应 WAN 口方向（1段）的 ping------这与家用路由器默认关闭"允许WAN口Ping"的行为完全吻合。

---

4.3 第三个线索：核心交换机镜像口流量特征（NFS.pcap）

NFS.pcap 在核心交换机镜像口抓取，约 20 秒，共 25,559 包。

协议分布：

协议	帧数	占比
TCP	24,466	95.7%
UDP	1,060	4.1%
ICMP	33	0.1%

ICMP 详情（共33包）：

192.168.1.162 → 192.168.1.1    Echo Request    20包（每秒1次，持续ping网关）
192.168.1.162 → 36.144.42.93  Echo Request     1包
192.168.1.162 ← 39.137.84.196 Destination Unreachable 6包

关键发现：192.168.1.162 在持续 ping 自己的默认网关 192.168.1.1，TTL=64（Linux/嵌入式设备特征），说明 162 确实知道自己在 192.168.1.0/24 网段。

这解释了为什么 1 段 ARP 表里有 192.168.1.162------TP-LINK WAN 口在发这些 ping 包之前，需要先 ARP 解析 192.168.1.1 的 MAC，所以会主动广播 ARP Request，1 段所有设备被动学习到了这个映射。

HTTP Host / TLS SNI 抽样（TP-LINK 下游所有终端的汇总流量）：

域名	应用
findervp.video.qq.com:49155	腾讯视频 CDN
extshort.weixin.qq.com	微信
djvod.ndcimgs.com	抖音视频
shuc-pc-hunt.ksord.com	快手
hif-leim.deepseek.com	DeepSeek
static-1.pddpic.com	拼多多
qup.f.360.cn	360安全
training.jlkj.edufe.cn	在线教育

这些流量来自微信、抖音、腾讯视频、DeepSeek、拼多多等手机应用------不是 TP-LINK 路由器本身产生的 ，而是 TP-LINK 下游所有终端设备（手机、平板、电脑）的流量，经过 NAT 后以 192.168.1.162（WAN口IP） 的面目出现在核心交换机上。

UDP 高端口分布（P2P 特征）：

18200/UDP: 8包
18300/UDP: 14包
18400/UDP: 15包
18600/UDP: 17包
18700/UDP: 17包

18000-18700 段连续高位 UDP 端口是 BT/P2P 下载的典型指纹，说明下游有用户在进行大文件 P2P 下载。

---

4.4 ⚠️ 踩坑记录：为什么一度误判 192.168.1.162 是一台电脑？

在溯源过程中，曾经单独对 192.168.1.162 的出口流量做过一次抓包（192.168.1.162-new.pcapng，约 28 秒，77,372 包，55MB），这次抓包差点把分析带偏。

"像电脑"的证据：

特征	抓包数据	看起来像什么
Windows NCSI 探测	www.msftconnecttest.com/connecttest.txt	Windows 桌面系统的网络连通性检测
Microsoft WNS	tile-service.weather.microsoft.com，UA 为 Microsoft-WNS/10.0	Windows 天气磁贴推送
Edge 浏览器	UA: Chrome/144.0.0.0 Safari/537.36 Edg/144.0.0.0，访问 218.246.50.70:18080/webserver/GetNewData	有人在用 Edge 上网
360 浏览器	UA: Chrome/132.0.0.0 Safari/537.36 QIHU 360SE，访问 upext.chrome.360.cn	360 浏览器扩展更新
WPS 云文档	drive.wps.cn、account.wps.cn、qingcenter.wps.cn（DNS 62 次）	WPS 在线办公
DeepSeek	TLS SNI: chat.deepseek.com、hif-leim.deepseek.com	AI 对话应用
直播流	douyincdn.com FLV 直播流（ttplayer UA）	抖音直播
华为/小米/荣耀 手机	connectivitycheck.platform.hicloud.com（Honor REA-AN00）、connect.rom.miui.com、osfsr.lenovomm.com	Android 手机

光看这份抓包，里面 Windows 桌面特征、浏览器流量、办公软件、AI 应用一应俱全，很容易得出结论："192.168.1.162 是一台 Windows 电脑"。

但这个结论是错的。

真相：这是 TP-LINK 下游所有终端设备的 NAT 汇总流量。

关键证据：

1. 抓包点在核心交换机侧，看到的是 192.168.1.162（TP-LINK WAN 口 IP）出去的所有流量------实际上背后有 20 段、3 段、16 段的多台手机、平板、电脑
2. 735 个 TCP SYN 连接，源端口范围 22177-46337------一台设备 28 秒内不可能建立这么多连接，说明是多台设备共享一个出口 IP
3. User-Agent 混杂------同时出现 Windows 桌面、Android 手机（Honor REA-AN00）、Linux 嵌入式等不同系统的 UA，不可能是同一台设备
4. 微信短链接域名 extshort.weixin.qq.com 请求 84 次，UA 为 MicroMessenger Client------路由器本身不会装微信

教训：当抓包点在 NAT 网关的上游时，看到的流量是"多人混用"的汇总，不能按单台设备来分析 User-Agent 和应用指纹。 这也是为什么后面切换到 TP-LINK LAN 口抓包（TP-link.pcapng、TP-LINK1.pcapng）后，才真正看清了拓扑结构------LAN 口侧的流量里只有 20 段的设备，清晰得多。

---

4.5 第五个线索：20 段广播域中的"接错网段"设备

在三个 TP-LINK LAN 口抓包文件中，发现两台异常设备：

设备 A：192.168.1.60（MAC: 20:04:0f:e7:6a:d8）

出现在 20 段广播域，但持续广播 1 段的网关 ARP 请求：

文件	ARP "Who has 192.168.1.1?" 数量
TP-link.pcapng	101 条
TP-LINK1.pcapng	198 条
tp-link2.pcapng	354 条

一台配着 1 段静态 IP 的设备，物理接到了 20 段网络，它在 20 段永远找不到 192.168.1.1 这个网关，所以每隔约 1 秒重试一次。 这是典型的"接错网段"现象，非恶意行为，但需要排查是谁的设备接错了位置。

设备 B：192.168.1.205（MAC: fc:34:97:e0:f2:fa）

同样出现在 20 段，请求 192.168.0.1 的 ARP，也是接错网段的设备。

---

4.6 第六个线索：40 段组播设备（40.20.pcapng）

源IP:  192.168.40.20
MAC:   ac:22:1e:01:09:01
协议:  IGMPv2
内容:
  - Membership Report (general)        每2分钟1次
  - Membership Report (group 230.1.9)  每2分钟1次

40 段设备定期发送 IGMP 心跳，加入组播组 230.1.1.9，可能是网络摄像头、IPTV 终端或监控设备。

---

五、核心谜题解析：为什么 1 段 ping 不通，其他段通？

这是整个分析的核心。结合拓扑和抓包数据，完整的数据包路径如下：

5.1 从 1 段发起 ping 192.168.1.162（❌ 不通）

① 1段电脑广播 ARP Request: "Who has 192.168.1.162?"
② 核心交换机泛洪，TP-LINK WAN口收到 ARP 请求
③ TP-LINK 用 WAN口MAC (08:57:00:7f:07:3b) 回复 ARP Reply
④ 1段电脑学到: 192.168.1.162 → 3b  ← ARP表有记录 ✅
⑤ 1段电脑发送 ICMP Echo Request，目标MAC = 3b
⑥ 核心交换机转发到TP-LINK WAN口
⑦ TP-LINK WAN口收到请求，检查防火墙规则：
   "允许WAN口Ping" = 关闭（家用TP-LINK默认值）
⑧ TP-LINK 丢弃该 ICMP，不发回包
结果：Request Time Out ❌

关键：ARP 能通（因为是 TP-LINK 主动回的）；ICMP 不通（因为 TP-LINK 防火墙拦了）。

5.2 从 20 段发起 ping 192.168.1.162（✅ 通）

① 20段电脑发 ARP Request: "Who has 192.168.1.162?"
② TP-LINK LAN口收到（与 20段在同一广播域）
③ TP-LINK 用 LAN口MAC (08:57:00:7f:07:3a) 回复 ARP Reply
④ 20段电脑发 ICMP Echo Request
⑤ 报文直接到达 TP-LINK LAN口
⑥ TP-LINK 对来自 LAN口方向的 ICMP 正常响应
⑦ Echo Reply 原路返回
结果：Reply from 192.168.1.162, time<1ms ✅

5.3 从 3 段发起 ping 192.168.1.162（✅ 通）

192.168.3.100 → 3.1（本地网关）→ 20.1（TP-LINK LAN口）→ 内部转发
→ 等同于从 LAN口方向发起，TP-LINK 正常响应 ✅

3 段、16 段的 WiFi 路由器 WAN 口网关都是 192.168.20.1，即它们都在 TP-LINK 的 LAN 侧，流量到达 TP-LINK 时走的是 LAN 接口，不经过 WAN 口防火墙。

5.4 为什么 1 段 ARP 表有记录但 ping 不通？（总结）

ARP 能学到 ：TP-LINK WAN 口每秒向 192.168.1.1 发 ping，发 ping 之前需要 ARP，这些 ARP Request 在 1 段广播，所有 1 段设备被动学到了 192.168.1.162 → 08:57:00:7f:07:3b。

ping 不通：TP-LINK 家用路由器默认关闭"允许WAN口Ping"，外部对 WAN 口 IP 发起的 ICMP 请求一律丢弃。

5.5 各网段 ping 结果对比

源网段	经过路径	到TP-LINK的接口	ping结果	ARP结果
192.168.1.0/24（1段直连）	核心交换机 → TP-LINK WAN口	WAN口（防火墙侧）	❌ 不通	✅ 有记录
192.168.20.0/24（20段直连）	TP-LINK LAN口广播域内	LAN口	✅ 通	✅ 有记录
192.168.3.0/24（3段级联）	3.1→20.1→TP-LINK LAN口	LAN口	✅ 通	✅ 有记录
192.168.16.0/24（16段级联）	16.1→20.1→TP-LINK LAN口	LAN口	✅ 通	✅ 有记录

---

六、衍生发现

6.1 异常设备 192.168.1.60

MAC 20:04:0f:e7:6a:d8，在 20 段广播域持续发 ARP 请求 "Who has 192.168.1.1?"，三个抓包文件合计 653 条。

判断为"接错网段"的终端设备------设备持有 1 段静态 IP，物理接到了 TP-LINK 的 LAN 口，找不到 1 段网关，导致 ARP 不停重试。建议：在 TP-LINK 客户端列表中找到该 MAC，定位物理设备，修改为自动获取 IP 或使用 20 段合法地址。

6.2 TP-LINK 下游大流量分析

NFS.pcap 20 秒内产生约 2.97MB 数据。TCP 目标端口 49155（腾讯视频CDN）一项就贡献了 10,218 包，UDP 18000-18700 段的 P2P 流量贡献了约 70 包。下游存在视频播放和 P2P 下载行为。如需带宽管控，可在 TP-LINK 的 QoS 中限速。

6.3 40 段组播设备

192.168.40.20（MAC: ac:22:1e:01:09:01）每隔 2 分钟发送 IGMPv2 Membership Report 加入组播组 230.1.1.9，疑似 IPTV 或网络监控设备。如不需要组播，可在接入端口配置 IGMP Snooping 过滤。

---

七、安全事件：防火墙被非本人登录

在分析过程中，从 NSFOCUS 防火墙（192.168.1.249）导出的登录日志中，发现了一条值得关注的记录：

时间                  级别          模块   事件      详细信息
2026-04-15 07:4x:xx  Notification  WEB   LOGIN    admin 从 192.168.1.162 登录成功
2026-04-15 15:38:40  Notification  WEB   LOGOUT   admin 从 192.168.1.250 退出登录
2026-04-15 15:55:21  Notification  WEB   LOGIN    admin 从 192.168.1.162 登录成功

异常点：

1. 上班时间为 08:30，早上 07:4x 有人用 admin 账号从 192.168.1.162（TP-LINK WAN口）登录了防火墙
2. 登录来自 162，说明操作者在 TP-LINK 的下游（20段/3段/16段），经 NAT 后源IP变为 162
3. 一次登录成功（无失败记录），说明操作者知道密码

进一步发现：192.168.1.250（杀软服务器）的浏览器保存了防火墙 admin 账号密码，能自动填充登录------这台服务器上曾经有人手动操作过防火墙管理界面。

结论 ：早上 07:4x 那次登录不是运维人员本人操作，属于安全事件。防火墙密码已在当天修改。

后续加固建议：

• 防火墙管理页面限制源 IP，只允许指定运维终端（如 192.168.1.189、本人所在终端）访问
• 清除 192.168.1.250 杀软服务器浏览器中保存的防火墙凭据
• 导出并保存防火墙完整日志备查

---

八、最终结论：实物验证

经过以上五条证据链的推断，结论是 192.168.1.162 就是那台 TP-LINK 路由器的 WAN 口。

最终通过实物标签完成验证：

机身标签 MAC（LAN口）：  08:57:00:7F:07:3A
抓包/ARP 记录 MAC（WAN口）：08:57:00:7F:07:3B

两个 MAC 相差 1 位（3A → 3B），与 TP-LINK 双口设备的标准 MAC 分配规律完全吻合。案子结了。

结论项	内容
192.168.1.162 是什么	TP-LINK 路由器的 WAN 口地址
验证方式	机身标签（LAN口MAC=3A）+ ARP记录（WAN口MAC=3B），相差1位
ping 行为解释	WAN口方向来的 ICMP 被 TP-LINK 防火墙默认拦截
ARP 有记录原因	TP-LINK WAN口主动发 ARP 找网关，1段设备被动学习
NFS.pcap 大量流量	TP-LINK 下游所有终端经 NAT 后的汇总出口流量
防火墙登录事件	下游某用户通过 NAT 使用 admin 账号登录了防火墙，已改密码处置

---

九、溯源方法论总结

这次排查使用的是"多源佐证 + 逐步排除"的思路，不依赖单一线索，而是让多条证据互相印证：

现象异常（ping不通但arp有）
    ↓
OUI查询（确认厂商）
    ↓
MAC相邻规律（推断是同一设备的两个接口）
    ↓
抓包行为分析（LAN口通 vs WAN口不通，与路由器防火墙行为吻合）
    ↓
拓扑还原（3段16段级联在20段，解释了为什么下游通）
    ↓
流量特征印证（NFS.pcap中的手机应用流量是NAT汇总）
    ↓
实物标签比对（最终确认）

核心工具：

• arp -a：被动发现设备的 MAC-IP 映射
• tshark：命令行批量分析 pcap/pcapng 文件
• Wireshark：手动验证关键数据包
• OUI 查询：https://macvendors.com 或 https://maclookup.app

---

本次分析工具：tshark / Wireshark。所有数据包均为本单位内网环境采集，未包含任何用户隐私数据。
案例整理时间：2026-04-16