Wireshark 抓包、过滤与 TLS 证据工具手册
CLI 已经超时，包究竟丢在哪一侧
开发机上的 curl 已经证明域名解析正确，却一直等不到 HTTPS 响应。客户端日志写着 connect timeout，网关日志里没有请求，服务端指标也没有异常。此时继续加大日志级别只能看到同一句超时；真正缺失的是包级中间状态：客户端有没有发 SYN，谁回了 RST，三次握手是否完成，TLS ClientHello 发出后有没有收到 alert。
Wireshark 能读取网卡交给抓包驱动的帧并交给协议 dissector 解码。它看到的是抓包点上的事实，不是全链路上帝视角：客户端抓到 SYN 只能证明包到达客户端抓包层，不能证明服务端收到；服务端抓不到包，也可能是抓错接口、流量在容器命名空间、负载均衡器或 VPN 的另一侧。开始前必须取得该网络与数据的抓取授权，并确定操作者、目标、接口、最长持续时间、最大文件量和销毁责任。
安装完成不等于拥有无限抓包权
Wireshark 4.6.7 是当前稳定版，4.4.17 是仍在维护的旧稳定线；4.7.x 属于开发版，不应因为版本号更大就进入共享分析环境。Windows 官方安装包包含 live capture 所需的 Npcap，macOS 提供通用安装镜像，Linux 通常由发行版仓库提供 Wireshark 与 dumpcap。安装来源、签名或哈希和补丁线要一起记录，尤其不能长期使用带有已修复解析器漏洞的旧构建处理不可信 pcap。
未安装 Npcap、驱动未运行或权限策略不允许时，Windows 会出现接口缺失或无法开始抓取。Linux 与 macOS 通过 libpcap 抓取，Wireshark 套件中的 dumpcap 负责低权限抓包路径。不要为了省事让整个 Wireshark GUI 长期以 root 或管理员运行，这会把解析复杂输入的图形程序也放进高权限边界。
从 Wireshark 官网 获取安装包后，先验证二进制、接口与链路类型：
wireshark --version
tshark --version
dumpcap -D
dumpcap -L -i <interface-id>dumpcap -D 输出接口编号与名称。VPN、无线网卡、有线网卡、Docker bridge、WSL 虚拟交换机和 loopback 可以同时出现，编号也可能在机器变化后改变，因此长期脚本优先引用稳定接口名并在启动前再次打印接口清单。GUI 中的实时波形只能说明接口有流量，不能说明目标流量经过这里。
Linux 上应按发行版提供的抓包组、capability 或 dumpcap 权限机制授予最小能力，并在变更后重新登录验证。验收不是“普通用户能打开 GUI”，而是普通用户能用 dumpcap -D 列出获准接口、能抓受控流量、不能借此读取未授权接口。共享服务器上更稳妥的做法是由受控账号执行限定 filter 和时长的 dumpcap，分析者离线读取最小文件。
正向实验：亲眼看到一次完整 TCP 会话
先用本机 loopback 做无敏感数据实验。启动临时服务：
mkdir -p /tmp/wireshark-lab
printf 'packet-ok\n' >/tmp/wireshark-lab/health
python3 -m http.server 18080 --bind 127.0.0.1 --directory /tmp/wireshark-lab在另一个终端找出 loopback 接口，然后开始限量抓取：
dumpcap -D
dumpcap -i <loopback-interface> \
-f 'tcp port 18080' \
-a duration:20 \
-a packets:200 \
-w /tmp/wireshark-lab/ok.pcapng第三个终端执行一次请求：
curl --noproxy '*' http://127.0.0.1:18080/health抓取停止后先用 TShark 检查文件，而不是直接双击一个可能巨大的捕获：
capinfos /tmp/wireshark-lab/ok.pcapng
tshark -r /tmp/wireshark-lab/ok.pcapng \
-Y 'tcp.port == 18080' \
-T fields -e frame.number -e ip.src -e tcp.srcport \
-e ip.dst -e tcp.dstport -e tcp.flags.str预期能依次找到 SYN、SYN/ACK、ACK，随后是带 HTTP 数据的分段，最后出现 FIN/ACK 或连接关闭。包序号与 flags 是机制证据：连接状态由两端内核按四元组维护，序列号和确认号推进字节流；Wireshark 根据同一会话中的字段重组并由 HTTP dissector 解释载荷。它不会替应用生成这些状态，也不能从一个孤立 SYN 推断后续已经成功。
GUI 中输入的 tcp.port == 18080 是 display filter。它只改变当前显示，capinfos 中的 captured packet count 和文件大小不会因此下降。抓取命令里的 tcp port 18080 是 capture filter，由 pcap/Npcap 路径在保存前筛选。两套语言的语法和执行阶段不同：前者能使用 tcp.flags.reset == 1、tcp.analysis.retransmission 等解码字段，后者只能使用抓取层可判断的 host、port、协议与方向等表达式。
反向实验：RST 和超时留下不同形状
停止临时 HTTP 服务，再抓一次 loopback 上的 18080，然后执行同一 curl。空端口通常由本机内核立即回 RST：
dumpcap -i <loopback-interface> -f 'tcp port 18080' \
-a duration:10 -a packets:50 -w /tmp/wireshark-lab/refused.pcapng
tshark -r /tmp/wireshark-lab/refused.pcapng \
-Y 'tcp.flags.reset == 1 || tcp.flags.syn == 1' \
-T fields -e frame.number -e ip.src -e ip.dst -e tcp.flags.str预期是客户端 SYN 后紧跟 RST/ACK，curl 很快报 connection refused。真实网络中的 connect timeout 更常表现为 SYN 间隔重发而没有 SYN/ACK 或 RST。若客户端抓到多次 SYN、服务端同一窗口完全抓不到，丢失点在两抓包位置之间；若服务端收到 SYN 并回 SYN/ACK，而客户端抓不到返回包，应检查反向路由、防火墙或中间设备；若两侧三次握手完整但应用超时，继续看 TLS 与应用日志，而不是调整 TCP 防火墙。
tcp.analysis.retransmission 是 Wireshark 根据当前捕获推导的分析字段，不是线上的设备主动标记。抓包从会话中途开始、镜像口乱序、抓包机丢包或校验和卸载都可能制造误报。先查看 Capture File Properties、capinfos 和接口统计是否有 dropped packets，再把 Expert Info 当线索，而不是当最终裁决。
实验结束后停止服务并删除整个 /tmp/wireshark-lab。删除前确认其中没有需要保留的证据；若需要留样，应重新生成无敏感数据的最小捕获，而不是把现场 pcapng 改名后提交仓库。
把 DNS、TCP 与 TLS 串成同一时间线
进入真实故障时，先从 CLI 已知的目标 IP 生成 capture filter。域名在 capture filter 中可能先被解析并固化成地址，DNS 轮转后会漏包，因此更稳妥的是显式写入当前获准目标地址，并单独决定是否需要 DNS：
(host 192.0.2.10 and tcp port 443) or (udp port 53 or tcp port 53)抓完后逐层应用 display filter：
dns.qry.name == "api.example.test"
ip.addr == 192.0.2.10 and tcp.port == 443
tcp.flags.syn == 1 or tcp.flags.reset == 1
tcp.analysis.retransmission
tls.handshake.type == 1 or tls.handshake.type == 2
tls.alert_messageDNS 响应中的 A/AAAA 应与 TCP 目标地址对应。TCP 完成后，TLS ClientHello 通常可见 SNI、支持版本与 ALPN；ServerHello 表明服务端开始协商，但仍不等于证书验证与 HTTP 成功。看到 TLS alert 时，记录方向、alert 与前一条握手消息，再去关联客户端 TLS 错误和服务端日志。只看到 encrypted application data 是 HTTPS 的正常结果，不代表 Wireshark 失效。
HTTP/3 使用 QUIC/UDP，tcp port 443 会完全漏掉它。客户端协商到 HTTP/3 时要补抓 udp port 443，并用 quic 过滤分析；若故障只在某种协议出现，可用 curl 的协议选项做受控对照，但不能把禁用新协议直接当永久修复。代理场景也要重画观测对象：客户端先连接代理，HTTPS 常通过 CONNECT 建隧道，目标 IP 可能只出现在代理侧；Wireshark 不会读取代理账号来替你重放或修改请求。
只有业务载荷必要时才引入 TLS key log
握手、RST、重传和 alert 已足够回答大量连接故障。确实需要看受控客户端的 HTTP 明文时，才为一次实验生成 TLS key log。客户端必须支持写出 session secrets；私钥本身通常不能解密使用前向保密密钥交换的现代 TLS 会话。
umask 077
export SSLKEYLOGFILE="$(mktemp /tmp/tls-keys.XXXXXX)"
curl --noproxy '*' https://api.example.test/health >/dev/null
test -s "$SSLKEYLOGFILE" || {
echo '当前 curl/TLS 后端没有输出会话密钥' >&2
exit 1
}在 Wireshark 的 TLS 协议首选项中把 (Pre)-Master-Secret log filename 指向该文件，再检查目标会话是否被解密。环境变量只影响支持该机制且从当前环境启动的客户端；系统中已有进程不会自动获得它，某些 curl TLS 后端也不会写出密钥。空文件是“不支持或没有捕获到密钥”的失败证据，不能继续声称已经具备解密条件。使用结束后先关闭产生密钥的客户端，清空 Wireshark 中的 key log 路径，再安全删除临时文件。
密钥日志的安全级别不低于对应会话明文。更容易忽略的是 pcapng 可以容纳 Decryption Secrets Block：一旦使用 Inject TLS Secrets，密钥材料会跟捕获文件一起传播。分享前不仅要删除旁边的 key log，还要从最小副本中显式丢弃所有嵌入密钥：
umask 077
editcap --discard-all-secrets minimal.pcapng sanitized.pcapng--discard-all-secrets 只处理解密密钥，不会自动删除包字节、comments、名称解析块或接口元数据。清理后仍要在无外部 key log 的隔离环境打开 sanitized.pcapng，确认业务载荷不能解密，并继续检查其他敏感字段；不要把一次命令成功误当作完整脱敏。
项目接入应交付策略，不交付现场数据
项目仓库适合保存经过评审的 filter 模板、采集命令骨架和销毁说明，不适合保存 .pcap、.pcapng、key log、导出对象或 Follow Stream 文本。需要协议回归 fixture 时，用本地实验服务生成合成流量，并让测试断言 fixture 不含企业域名、真实地址、Authorization、Cookie 和用户数据。
受控采集可以用 dumpcap 同时限制内容、时间、包数和文件数量：
install -d -m 0700 "$CAPTURE_DIR"
dumpcap -i "$CAPTURE_INTERFACE" \
-f "$CAPTURE_FILTER" \
-B "${CAPTURE_BUFFER_MIB:-8}" \
-s "${CAPTURE_SNAPLEN:-256}" \
-b filesize:"${CAPTURE_FILE_KIB:-10240}" \
-b files:"${CAPTURE_FILES:-4}" \
-a duration:"${CAPTURE_DURATION_SEC:-300}" \
-w "$CAPTURE_DIR/incident.pcapng"CAPTURE_INTERFACE 决定观测点，CAPTURE_FILTER 决定哪些包有机会落盘，-B 调整内核到用户态的捕获缓冲，-s 只保存每包前若干字节，ring buffer 的 filesize 与 files 限制磁盘上界，duration 保证任务自动停止。较小 snap length 能降低容量与载荷暴露，却可能截断 TLS、HTTP 头或重组所需数据；较大 buffer 能缓解写盘抖动导致的 drop，却增加内存占用。示例值只用于展示字段关系，正式值由接口吞吐、平均包长、磁盘写入能力、故障复现窗口和数据最小化要求共同计算。
粗略容量可以用“捕获字节率 × 持续时间”估算，再加 pcapng 元数据余量。display filter 不参与这个预算，因为数据已经保存。高吞吐接口上 GUI 实时解析、名称解析和大量 dissector 会消耗 CPU 与内存，可能让抓包机自身丢包；生产采集优先让 dumpcap 写环形文件，再把最小片段复制到隔离分析机。
抓包成本也不能只看本机磁盘。一次捕获复制到工单、对象存储、分析机和备份后，存储量与泄漏面都会成倍增加；全量文件还会占用传输带宽、分析 CPU 和工程师筛选时间。团队应以“每个事件只保留能够证明结论的最小副本”为成本边界，把采集频率、环形上限、复制次数与留存周期纳入同一预算。若问题只需要连接成功率或长期趋势，指标和流日志通常比持续全包捕获更便宜，也更容易治理。
权限、敏感数据与证据保管
pcapng 可能包含内部拓扑、DNS 名称、明文协议、认证头、Cookie、设备标识、文件内容和精确时序。即使 TLS 未解密，端点、SNI、流量大小与时间关系也可能敏感。Follow Stream、Export Objects、截图和 CSV 都是新的数据副本，必须继承原捕获的分级、访问控制和销毁要求。
现场采集目录使用仅 owner 可读写权限，文件通过受控工单或证据库传递并记录哈希，不能上传公共网盘或聊天群。共享者先用 display filter 找到必要帧，再通过 Export Specified Packets 生成最小副本；之后执行前述 secrets 清理，在另一台无 key log 的分析环境重新打开，检查 Packet Bytes、comments、name resolution、capture interface 信息和解密状态。用字符串替换直接修改二进制 pcapng 会破坏结构，也不能证明所有副本和元数据已脱敏。
权限回滚与数据清理是抓包动作的一部分。任务结束后停止 dumpcap，撤销临时组成员或 capability，删除 key log、临时捕获、导出对象与解压目录，确认环形文件没有遗留在 %TEMP% 或 /tmp。需要保留的最小证据应有 owner、用途、访问者和到期销毁动作，而不是无限期躺在工程师下载目录。
架构判断从双端证据开始
Wireshark 最适合回答“这个抓包点实际看到了哪些包以及顺序如何”。连接跨越 NAT、负载均衡、service mesh、容器网络或 VPN 时，单端捕获无法定位中间哪一跳改变了地址、丢弃了包或注入了 RST；在变更窗口内做客户端与服务端双端限量捕获，再按五元组、TCP 序列与相对时间对照，结论才足以推动网络策略或网关修复。
选型也取决于问题形状。需要修改 HTTP 请求、查看便捷明文或模拟响应时，使用获准的调试代理更合适；需要长周期聚合趋势时，使用指标、流日志或 eBPF 观测，不能让全量 pcap 替代监控；需要法证完整性时，应进入组织的取证流程，而不是由开发者自行裁剪；需要证明 SYN、RST、TLS alert、重传或协议协商时，Wireshark/TShark 才是直接证据。
长期治理应把抓包视为高权限、短时、按事件启用的能力。团队维护少量经验证的 capture filter、双端采集步骤和合成 fixture，定期验证普通用户权限边界、ring buffer 磁盘上界、drop 统计和销毁流程。真正可复用的产物是故障模式、必要帧号、脱敏后的字段和修复验证方法，而不是不断增长的现场抓包仓库。