远程抓包该不该排除 SSH 流量？

在远程机器上抓包、同时通过同一条连接查看输出，是一种自我参照的测量，它会扭曲你正在测量的东西。你打印的每个数据包都要经由被抓取的会话返回。排除这条流量通常是对的，但排除的尺度是一个真正的决定。范围太窄，抓包会把自己淹没；范围太宽，证据就消失了。

为什么抓包会记录自己

抓包看到的是它自己输出的回程路径。每一行打印到你终端的内容都会变成管理连接上的一个或多个数据包，过滤器随后再次匹配并打印它们。结果是一个不断增长的循环，直到缓冲区或链路放弃。

这就是为什么写入文件的抓包看起来一切正常，而同一次抓包实时流式输出时就变得无法使用。流量不是新的，是你自己制造的。十秒的抓包一旦循环开始，产生的输出就可能超过链路的承载能力。

把排除范围建成一个组

从远程主机如何看待你的会话出发，而不是从本地终端里的地址出发。跳板机或 NAT 设备可能让对端变成你从未输入过的地址，所以要从远端的自身视角读取地址。然后把主机和端口放在同一个组里，让取反作用于这一对。

tcpdump -ni eth0 '(net 10.60.0.0/24) and not (host 203.0.113.77 and tcp port 2222)'

给整个表达式加引号，可以避免 shell 把括号当成语法。在相信结果之前，先把过滤器打印回来看看。

看起来正确却放行一切的过滤器

错误的过滤器读起来很自然：源不是对端，或者目的不是对端。对于来自你工作站的包，第一个条件成立；对于回复，第二个条件成立。用 or 把它们连起来会同时保留两个方向，而那正是你想丢弃的部分。

pcap 的过滤逻辑让 and 与 or 优先级相同，并从左到右求值，所以混用时括号不是可选项。应该对一个分组后的表达式取反，而不是把两个否定拼在一起。正是这一处改动，把可用的过滤器与塞满你自己输入的抓包区分开。可以参考 pcap 过滤器参考，它短到可以直接在终端里读完，每当过滤器行为异常时都值得查一查。

按抓包必须证明什么来决定

先问抓包必须证明什么，再决定排除多少。如果需要看到发往同一主机的应用流量，就只排除 SSH 端口，并接受其他会话的噪声。如果这台主机与问题无关，整体排除更简单，还能去掉一整类自己生成的包。把这个选择写在抓包文件旁边，因为过滤器是对证据的一种假设。

接口的选择决定了你究竟能看到什么。在隧道上你看到的是内部流量；在物理接口上你看到的是加密后的传输。如果在选定的位置管理报文本来就不存在，那么再多的排除也修不好一次瞄错层次的抓包。