NetWatch深度包检测实战15种L7协议解码器全解析从SNI提取到QUIC/HTTP3重组【免费下载链接】netwatchReal-time network diagnostics in your terminal. One command, zero config, instant visibility.项目地址: https://gitcode.com/gh_mirrors/netwatc/netwatchNetWatch 是一款运行在终端里的深度包检测DPI与网络诊断工具一条命令启动抓包零配置即可实时解码 L7 应用层协议——自动提取 TLS 的 SNI 主机名、识别 15 种明文协议、解密 QUIC Initial 包并重组 HTTP/3 响应体还能给每个 TLS/QUIC 握手打上 JA4 指纹。本文带你从 SNI 提取讲到 QUIC/HTTP3 重组完整解析它的解码管线。为什么终端里的包检测值得用传统习惯是 Wireshark 看包、ss/netstat 看连接但两者是割裂的。NetWatch 把抓包、解码、进程归属、诊断放在同一个终端 TUI 里不是端口标签而是真解码——看每条流的前 N 字节实际内容来判断协议而不是端口 443 就叫 TLS流级跟踪——分类器只跑一次结果缓存在流记录上整条连接生命周期复用性能开销极低对抗样本 fuzz 验证——官方用 2 万轮随机/畸形字节流验证所有解析器绝不 panic恶意流量不会打崩工具。分类器的调度与优先级逻辑集中在 classify_once廉价魔数匹配放前面需要完整解析的放后面同格式协议靠端口辅助区分。30秒上手一条命令开始L7解码sudo netwatch # 需要抓包权限进入Packets 标签页按4按c开始捕获按/打开 Wireshark 风格过滤器。无需任何配置文件过滤器语法和 Wireshark 基本一致实战中最常用的是decrypted:true只看已解密的记录和ja4:xxx按指纹找同源流量。15种L7协议解码器一张表看懂NetWatch 的解码器源码全部在 src/dpi/ 目录下每个协议一个文件、一个分类器。以下是完整的 15 种 L7 分类器清单及各自提取的关键字段协议源码提取的关键字段TLStls.rs版本、SNI、ALPN、ECH 标志、JA4 指纹QUICquic.rsInitial 包识别、重组后的 SNI、ECH、JA4Q、HTTP/3HTTPhttp.rs方法、Host、路径、状态码请求/响应双向DNS / mDNSdns.rs查询名、记录类型、响应码LLMNRllmnr.rs与 DNS 同格式靠 5355 端口区分SSHssh.rs客户端/服务端 banner 与版本MQTTmqtt.rs控制包类型、CONNECT 的 client-idSNMPsnmp.rs版本、community 字符串BitTorrentbittorrent.rsBEP 3 握手、info hashFTPftp.rs控制通道命令USER/RETR/STOR…NetBIOSnetbios.rs名称服务/数据报/会话三类服务SSDPssdp.rsNOTIFY / M-SEARCH 及目标类型STUNstun.rs消息类型magic cookie 无歧义识别NTPntp.rs版本、模式123 端口门控DHCPdhcp.rsBOOTP 操作码1 请求 / 2 应答几个设计细节值得注意HTTP 双向识别——请求行GET / HTTP/1.1提取方法和路径若只抓到服务端方向则从HTTP/1.x 200 OK提取状态码并标记为RESPONSE单向抓包也不丢标签端口门控——FTP 只在 21 端口扫描避免把 SMTP/IMAP 的220 ...误判成 FTP 应答SSDP 在 1900 端口优先于 DNS 检查因为它的M-SEARCH * HTTP/1.1长得像 HTTP 又不像别的同格式协议靠端口消歧——LLMNR 与 DNS 线上格式完全相同用 5355 端口区分SNMP161/162、NetBIOS137–139则强端口锁定。解码结果会实时出现在连接表和协议统计里例如按协议聚合的分布视图SNI提取TLS解码器怎么把主机名读出来TLS 分类器解析 TCP 流上第一条 TLS 记录0x16 0x03快速预检从 ClientHello 的server_name扩展RFC 6066提取 SNI同时拿到 ALPNh2/h3/http/1.1。更有意思的是ECHEncrypted ClientHello识别如果 ClientHello 携带encrypted_client_hello扩展type0xfe0dNetWatch 会打上ech标志——此时报告的是外层 SNI真正的目标域名对网络观测者是隐藏的。官方文档诚实地说明无法区分真 ECH 和 GREASE-ECH但两者对用户意味着同一件事你看不到内层 SNI。每个 ClientHello 还会同步计算JA4 指纹ja4.rs协议前缀 TLS版本 SNI有无 加密套件数 扩展数 ALPN提示后接加密套件与扩展列表的 SHA256 摘要。同一客户端软件浏览器、CLI 工具、恶意软件的 JA4 是稳定的可以拿一个指纹作为线索找出所有同源流量——这就是威胁狩猎里指纹狩猎玩法。⚠️ 已知边界只从客户端方向分类且跨 TCP 分段的 ClientHello 首段会漏识别官方估算 1% 真实流量这类流会保持为普通 TCP 标签。QUIC解密实战从Initial包到ClientHello重组QUIC 流量默认全加密NetWatch 走了一条硬核路线按 RFC 9001 主动解密 Initial 包再重组出 TLS 1.3 ClientHello 提取 SNI。完整管线在 src/dpi/quic.rs 的模块注释里写得很清楚共 7 步解析长包头类型、版本、DCID、SCID、token、长度拒绝一切非 v1 Initial 的包用 DCID 经 HKDF v1 Initial salt 派生客户端 Initial 密钥用 AES-128-ECB 派生的掩码去除头部保护以nonce iv XOR 包序号做 AES-128-GCM AEAD 解密遍历解密后的帧按 offset 累积CRYPTO 帧数据重组 ClientHello跑 TLS 解析器提取 SNI顺手计算 JA4Q 指纹q前缀。即使第 3 步之后任何一环失败AEAD 认证失败、帧畸形流仍会被打上QUIC标签——识别永远成功SNI 尽力而为。工程上还有一个值得一提的细节CRYPTO 帧声明的 offset 是发送方自选的 62 位 varint若直接用它做缓冲区分配单个恶意 Initial 包就能触发多 GiB 内存分配。官方把重组缓冲区上限钳制在 1 MiBMAX_QUIC_CRYPTO_BUF这个洞是在 2026-09 的代码评审里发现并修掉的。完整实施过程含短包头解析、密钥派生、跨包重组的分阶段记录见 docs/quic-decryption-plan.md。HTTP/3重组把QUIC应用数据还原成人能读的响应体拿到 SNI 只是握手层HTTP/3 的响应体在 QUIC 1-RTT 短包头应用数据里这一层由 src/dpi/http3.rs 负责分三步解析 QUIC 帧RFC 9000 §19从解密的 1-RTT 载荷中抽出 STREAM 帧数据跨包重组——H3StreamReassembler按流ID、方向、offset在多个包之间累积 STREAM 字节从 offset 0 开始解码连续前缀压缩流必须从头喂缺头就还原不了嗅探 解压缩——HEADERS 帧里的Content-Encoding被刻意不解QPACK 太重改为魔数检测 gzip/deflate再对无魔数的 brotli 做尝试性解码。效果是配合SSLKEYLOGFILE导出密钥后浏览器发出的 HTTP/3 响应体gzip 压缩的 JSON 也一样可以直接在 Packets 标签页里读到明文并用decrypted:true过滤出来。TLS 1.3 / 1.2 的解密能力同属这一机制演示如下延伸阅读源码与文档地图资源路径说明DPI 模块总入口src/dpi/mod.rs15 个分类器、AppProtocol枚举、优先级调度QUIC 解密管线src/dpi/quic.rsInitial 解密、CRYPTO 重组、1-RTT 密钥派生HTTP/3 重组src/dpi/http3.rsSTREAM 跨包重组、gzip/brotli 解压JA4 指纹src/dpi/ja4.rsJA4/JA4Q 计算、GREASE 过滤协议解码器官方文档docs/REFERENCE.md解码字段、过滤器、TLS 解密完整说明QUIC 解密实施计划docs/quic-decryption-plan.md分阶段实现记录与验证结果小结NetWatch 的深度包检测覆盖了日常排障 95% 的场景——TLS SNI/ECH、QUIC ClientHello 重组、HTTP/3 响应体还原、JA4 指纹狩猎外加 15 个明文协议分类器全部零配置。对于想摆脱端口猜协议的用户它把 Wireshark 级的 L7 解码塞进了一个终端窗口而且每个解析器都经过对抗样本 fuzz 验证恶意流量不会让它崩溃。【免费下载链接】netwatchReal-time network diagnostics in your terminal. One command, zero config, instant visibility.项目地址: https://gitcode.com/gh_mirrors/netwatc/netwatch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
