文章总结： Ongrid通过AIAgent实现自然语言驱动的远程抓包与分析，用户无需记忆复杂命令或逐台SSH。系统自动识别设备、选择网卡、下发任务，并返回可分析的数据包。它支持多机并行、异步任务和浏览器内分析，将抓包从个人经验转化为团队可复用的诊断能力。 综合评分： 86 文章分类： AI安全,网络安全,安全工具,实战经验

王炸！AI 能上服务器抓包了

原创

PolluxAI PolluxAI

PolluxAI

2026年8月21日 09:07 浙江

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

一句话完成远程抓包、PCAP 解析和协议下钻。不是生成一条 Tcpdump 命令让你自己执行，而是识别目标设备、选择网卡、下发抓包任务，并把结果直接变成可以查看和分析的数据包产物。

“在两台服务器上都抓包看一下，有没有访问 google.com 的流量。”

这是一次真实操作，也是 Ongrid (https://github.com/ongridio/ongrid) 最近完成的一条重要能力闭环。

系统从当前环境中识别出两台在线服务器，为每台设备确认 eth0，随后创建包含两个成员任务的 Capture Session。60 秒采集结束后，两份 PCAP 均已就绪，共得到 56 个 DNS 数据包事件和 30 条关联流。

整个过程没有登录服务器，也没有手写一长串 Tcpdump 参数。更重要的是，抓包完成并不是流程的终点：PCAP 会进入解析链路，数据包、TCP Stream、协议字段和 Hex 会成为下一步分析的证据。

自然语言生成双机抓包任务并等待确认

图 1：Agent 自动发现两台目标服务器，将自然语言转换为结构化抓包参数，并在执行前等待人工确认。

这和“让大模型写一条 Tcpdump 命令”不是一回事。

AI 已经可以进入真实运维链路：理解问题、定位对象、调用工具、等待异步任务、读取产物，再根据新证据决定下一步。

它第一次把抓包从一个孤立的专家工具，变成了 Agent 可以调用、可以理解、可以继续推理的基础能力。

不再一台一台 SSH：一次下达，多机并行

单台服务器抓包尚且繁琐，多台服务器同时排查更考验耐心。

传统做法通常是登录堡垒机，逐台 SSH，逐台确认网卡和 Namespace，分别启动 Tcpdump，再把散落在不同机器上的 PCAP 一个个下载回来。十台机器，就是十遍几乎相同、又不能出错的操作。

在 Ongrid 中，可以在权限范围内一次选择多台服务器，然后用一句自然语言描述统一的抓包目标。Manager 会把它展开成一个 Capture Session，为每台设备创建独立成员任务，通过持久化隧道并行下发，并在同一会话中汇总进度和产物。

选择：北京机房 8 台网关
要求：在业务 Namespace 抓取 443 端口流量
范围：每台最多 5,000 个包，持续 60 秒
结果：8 个独立 PCAP，统一归入同一个抓包会话

你不需要同时开着一排终端，也不需要记住哪个窗口对应哪台机器。设备、接口、执行状态和 PCAP 归属都由系统记录。

以前，你需要逐台登录服务器、逐条执行命令；现在，只需要说清楚“在哪些机器上抓什么”。你负责定义目标和边界，系统负责调度、执行和归档。

同一个抓包会话在两台服务器上并行采集

图 2：同一个 Capture Session 在两台服务器上并行采集，分别维护成员状态，统一汇总进度和产物。

受够了 Tcpdump 的命令和参数

Tcpdump 很强，但它从来不是一件低门槛的工具。

一次稍微具体的抓包，命令很快就会变成这样：

sudo ip netns&nbsp;exec&nbsp;<namespace> tcpdump \
&nbsp; -i eth0 -nn -s 1514 -c 100 \
&nbsp; -w /tmp/capture.pcap \
&nbsp;&nbsp;'(udp port 53 or tcp port 443)'

这里每个参数都可能影响结果：

• -i 选错接口，抓到的可能是一片空白；
• BPF 写错括号或 Shell 引号，过滤条件可能完全变样；
• Snaplen 太小会截断协议字段，太大又会增加文件体积；
• 包数、时长和文件大小没有限制，生产机器可能一直采集；
• 容器、虚拟网卡和 Linux Network Namespace 会让接口定位更复杂；
• 多台机器还要处理文件命名、权限、回收和下载。

Ongrid 并没有把这些专业参数删掉，而是把它们变成结构化字段：interface、network_namespace、filter、duration、max_packets、max_bytes、snaplen 和 promiscuous。

现在你可以直接说“进入这个网络命名空间，在 eth0 上抓 DNS 和 HTTPS 流量，最多 100 个包”。Agent 负责把意图转换成参数，边端负责校验和执行；需要精确控制时，工程师仍然可以明确指定接口、Namespace 和 BPF。

少记参数，不等于失去控制。恰恰相反，参数从一段容易出错的 Shell，变成了可以校验、审计和复用的任务定义。

抓包链路是怎么工作的

整套流程分为交互入口、Manager 控制面、Linux Edge 数据面和私有解析面。

Ongrid 抓包与解析整体架构

图 3：控制面负责任务和状态，Edge 负责现场采集，私有 Parser 负责协议解析。

Linux Edge 通过持久化隧道接收结构化抓包参数，在目标主机上使用 AF_PACKET 执行受限采集，并维护本地任务状态。调用方不能指定任意输出路径，边端返回的状态中也不会暴露本地文件路径。

Manager 负责设备解析、权限确认、任务协调和产物管理。抓包结束后，Manager 通过内部方法读取原始 PCAP，校验大小及 SHA-256，然后以 0600 权限保存到 Raw Store。

PCAP Parser 是独立的私有服务，不映射宿主机公网端口。Manager 使用 Ed25519 对解析请求签名；Parser 获取原始 PCAP 时，使用带有效期的 HMAC 下载凭据，并再次核对预期大小和 SHA-256。

这套设计的重点不是“让模型直接碰生产机器”，而是让它在边界清晰、过程可追踪的工具链中完成真实操作。

一次抓包在系统里经历什么

从用户发出请求，到浏览器出现可以查看的产物，完整时序如下。

从自然语言请求到 PCAP 产物发布的完整时序

图 4：抓包不是一次同步命令，而是一个可以跨越当前对话轮次的异步 Operation。

这里有几个工程细节值得单独说明。

第一，设备和网卡不是靠猜。系统会先解析会话中的设备对象，再通过边端工具确认真实网络接口和设备能力。

第二，抓包任务是有界的。时长、包数、文件大小和 Snaplen 都有上限，避免一次错误参数持续占用主机和网络资源。

第三，任务执行与聊天消息解耦。用户不需要让一个 HTTP 请求阻塞几十秒；抓包作为 Operation 异步运行，状态和最终产物会回到原会话。

第四，原始数据与解析结果分开保存。解析结果可以重新生成，原始故障现场不能重来。即使 Parser 暂时不可用或解析失败，Raw PCAP 仍然会保留，后续可以重新处理，也可以直接下载到本地分析。

浏览器里直接看 Packet、Stream 和 Hex

抓包完成后，可以直接从会话中的产物卡片打开数据包查看器。

浏览器内的数据包查看器

图 5：上方是 Packet List，中间是协议树，下方是原始 Hex 和 ASCII。

查看器保留了常见的抓包分析习惯：

• 按协议、IP、端口等条件过滤；
• 按 TCP Stream 查看连接；
• 查看源地址、目标地址、协议、长度和摘要；
• 展开 Frame、Ethernet、IP、TCP 等协议字段；
• 下钻查看原始 Hex 和 ASCII；
• 下载原始 PCAP，继续使用 Wireshark 深入分析。

截图中的 100 个数据包已经在浏览器内完成解析。快速定位问题时不用来回下载文件；需要更专业的过滤、统计或重组能力时，原始 PCAP 仍然可以交给 Wireshark。

网页查看器和专业桌面工具并不冲突，它们解决的是不同阶段的问题。

AI 怎么读这份 PCAP

Ongrid 不会把整个二进制 PCAP 直接塞进模型上下文。

PCAP Parser 会先把原始数据转换成 Wireshark 风格的结构化结果，包括 Packet List、TCP Stream、协议树、时间、方向、标志位、字段和值以及可选的 Hex 数据。Agent 读取的是这些可以定位、筛选和引用的包级证据。

例如，用户问“有没有访问 google.com”，Agent 可以先查找 DNS 查询名和应答记录，再根据解析出的 IP 关联后续 TCP 或 UDP 流，并说明在这次抓包的时间范围内找到了什么、没有找到什么。

重点不是让 AI 替代 Wireshark 的全部分析能力，而是让它能够围绕当前问题主动抓取现场数据，并快速完成第一轮筛选。需要进一步下钻时，人仍然可以在网页中查看协议树、Stream 和 Hex，或者下载原始 PCAP。

AI 读取双机抓包结果并给出包级证据

图 6：抓包完成后，Agent 读取 56 个 DNS 数据包事件，按设备、域名和时间窗口给出可以核对的结论。

这就是这项能力真正“王炸”的地方：AI 不再只能分析别人提前准备好的材料，而是可以为了回答眼前的问题，主动把网络现场取回来。

把抓包从个人经验变成团队能力

Tcpdump 和 Wireshark 已经足够强大，Ongrid 并不是要替代它们。

我们更想解决的是另外几个问题：

• 问题出现时，能不能更快留下现场？
• 不熟悉抓包参数的人，能不能在安全边界内完成操作？
• 多台设备的抓包任务，能不能统一管理和追踪？
• 抓包请求、执行过程和 PCAP 产物，能不能围绕同一个问题组织起来？
• 一次排查过程，能不能被团队复用，而不是只存在于某个人的终端历史里？

当抓包成为一个有状态、有权限、有产物、有上下文的标准操作，它就不再只是某位网络工程师掌握的命令，而会成为整个团队可以复用的诊断能力。

最后

从一句“抓 100 个包看看”，到浏览器里展开 TCP 字段和 Hex，再到围绕原问题继续判断，背后并不是什么神奇魔法。

它是一条由设备识别、权限确认、任务下发、边端采集、状态协调、原始数据保存、私有解析和证据汇总组成的工程链路。

模型是入口，也是这条工具链的编排者；真正让它具备生产价值的，是设备上下文、受限工具、异步任务、原始产物、协议解析和权限系统共同组成的闭环。

这意味着 Agent 不只是“懂网络知识”，而是开始具备网络工程师最重要的一项能力：当现有证据不够时，知道该去哪里取证，并真的把证据拿回来。

如果你也经历过“问题出现了，但包没抓到”，欢迎把这篇文章转给一起排障的同事。

接下来我们还会继续拆解：

• 如何通过 TCP Stream 判断连接异常；
• DNS 故障应该看哪些数据包；
• RST、重传和零窗口分别意味着什么；
• TLS 加密之后，数据包里还能看到什么。

关注公众号，加入Ongrid社区

GitHub：https://github.com/ongridio/ongrid

最新版本：https://github.com/ongridio/ongrid/releases/tag/v0.13.4

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：PolluxAI PolluxAI PolluxAI《王炸！AI 能上服务器抓包了》