tcpdump抓包可精准定位ssh断连根源：通过分析fin/rst包的源ip判断客户端、服务端或中间设备发起断连，结合wireshark过滤tcp.flags.fin==1 or tcp.flags.reset==1，并用ss命令验证连接状态与保活行为。
用 tcpdump 抓包是定位 SSH 断连根源最直接有效的方式，尤其能分辨是客户端、服务端还是中间设备（如防火墙、NAT、负载均衡器）主动发起了断连。关键不在于“抓到包”，而在于“抓对包”并看懂 FIN/RST 的发起方和时间点。
明确目标：只抓 SSH 流量，聚焦断连瞬间
执行前先复现问题——保持 SSH 连接，等它空闲几分钟后断开。断开后立即抓包或提前运行抓包命令持续监听。推荐命令：
-
基础抓取（推荐）：
tcpdump -i any 'host 192.168.1.100 and port 22' -w ssh_break.pcap -G 300
其中192.168.1.100换成你的服务器 IP；-G 300表示每 5 分钟自动轮转一个文件，避免单文件过大漏掉断连前的包。 -
加时间戳与详细协议头：
tcpdump -i any -nn -vv -ttt 'host 192.168.1.100 and port 22'
实时输出，带毫秒级时间戳和 TCP 标志位详情，适合观察断连发生的确切时刻。
重点看什么：FIN 和 RST 包的源 IP 与方向
SSH 断连本质是 TCP 连接被终止，抓包中要盯住两类关键包：
- FIN 包：表示某一方“主动提出关闭连接”。如果 FIN 来自服务器 IP → 服务端（sshd 进程或内核）关闭了连接；来自客户端 IP → 本地终端或 SSH 客户端主动退出；来自中间设备 IP（如 10.0.1.1 网关）→ 防火墙/NAT 设备回收了空闲连接。
- RST 包：表示“强制重置连接”，通常意味着对方已不认这个连接。若 RST 紧随 FIN 后出现，属正常四次挥手；若无 FIN 直接出现 RST，大概率是中间设备丢弃了保活探测后强行中断。
用 Wireshark 打开 ssh_break.pcap，过滤 tcp.flags.fin == 1 or tcp.flags.reset == 1，按时间排序查看最后几个包的 Source IP 和 Info 字段，就能快速锁定断点位置。
结合 ss 命令看连接状态变化
抓包同时，在服务器上运行：ss -ti dst :22（客户端视角）或 ss -ti src :22（服务端视角），观察连接的 retrans（重传）、rto（超时时间）、lastsnd/lastrcv（最后发送/接收时间）。如果 lastrcv 停滞超过 300 秒，而抓包里又没看到客户端发来的保活包，说明客户端心跳没生效或被中间设备拦截。
排除干扰：确认保活包是否真正发出
在客户端机器上执行：tcpdump -i any -nn 'tcp port 22 and (tcp[tcpflags] & (tcp-fin|tcp-rst)) == 0 and greater 64' -w client_keepalive.pcap
该命令过滤掉 FIN/RST，并只抓大于 64 字节的包（SSH 保活探测通常是空数据包，长度约 64 字节以内，但部分实现会带 timestamp option，略长）。如果完全看不到周期性的小包（比如每 60 秒一次），说明客户端配置未生效或被本地防火墙阻断。
