VPN 网卡上的混杂模式会掐断连接

Wireshark 在以太网口上一切正常，可换到 VPN 网卡后，抓包一开始，隧道就不再转发流量。抓包窗口还在不断填充，工具看起来一切正常，底下的连接却已经死了。原因通常是混杂模式：隧道驱动被要求接收本不属于它的网段上的每一帧，最后可能进入什么都不往外发的状态。

先关掉这个选项，再决定你真正需要看哪一层。

两块网卡，两种视角

VPN 客户端通常提供两个接口：承载加密传输的物理网卡，以及承载解密后内层流量的虚拟网卡。它们回答的是不同的问题。物理侧的抓包显示端点、端口和包长，虚拟侧则显示隧道交付的应用层协议。不清楚自己要问什么就随便选一个，等于浪费这次抓包。

两种视角谁也不包含谁，一次抓包也很少能同时回答两个问题。

要按照问题选接口，而不是按列表顺序，因为 PPP 风格的客户端可能把它的网卡呈现为以太网设备，显示名称根本不会告诉你选的是哪一层。在网关或镜像端口抓包会加入第三种视角，显示转发之后的路径，非对称路由和过滤正是在那里显形。

混杂模式为什么会弄坏隧道网卡

混杂模式要求驱动把并非发给本机的帧也交付上来，这在共享以太网段上说得通，在点到点隧道的网卡上却几乎没有意义。有些驱动会平静地接受这个请求，另一些则不再从队列里取出待发送的流量，接口就这样悄无声息地变成黑洞。抓包文件仍然在记录到达的帧，于是它看起来像是链路正常的证据。文件显示的内容和接口实际做的事之间的这道缝，正是整个陷阱。

在第一个包之前就关掉选项，把抓包过滤器收窄，并使用较小的缓冲区。忙接口上的大环形缓冲区丢掉的恰好是那些重要的帧，结果除出事的那一处之外，抓包到处都完整。

如果链路在抓包中途卡住，就停下来观察它能否恢复。这一次观察足以把抓包的副作用和真正的隧道故障区分开，也比任何过滤器调优都省时间。

让 IPsec 抓包变得可读

单看 IPsec 抓包是读不懂的，因为 ESP 加密了载荷。当你提供会话密钥，或者 Wireshark 能跟到生成这些密钥的 IKE 协商时，它才能解码，这意味着握手必须留在同一个文件里。

密钥会过期。对端重新协商密钥之后，一组旧密钥在抓包中途就失效了，结果看起来像解码器的缺陷，而不是一条时间界线。

要遵循厂商文档写明的密钥格式，而不是从无关来源导入材料，并且预期有些平台会彻底拒绝这套流程。当网关不肯交出密钥、也不允许抓包时，就接受载荷无法从你所在的位置检查这一点。剩下的证据是端点日志和接口计数器，它们通常足以回答路由问题。

可以安全分享的抓包

内层抓包更接近凭据泄漏，而不是日志。它可能包含名字、地址，以及那些“反正没人会读”的协议里的明文，于是敏感的东西是文件本身，而不是分析结论。

确认主机和网络都是你获准抓包的范围，把接口和过滤器连同结果一起记下来，把会话限制在能回答问题的几分钟内，做完之后删除文件。如果必须分享，先描述流量特征，或者先把载荷去掉。

然后再做一遍用户最初的任务。证明包已经到达的抓包，并不等于应用接受了这个回答，而这两者之间的差别，通常正是真正故障所在。