https://www.cloudshark.org/captures/6f185eb12e97
- 172.30.5.1 具有桥接网络的 Linux 虚拟机，在另一台服务器上运行，虚拟机仅具有 RFC1918 地址
- 144.76.103.194 具有一个接口的 Linux 主机，连接到互联网和 RFC1918 广播域，充当虚拟机的 NAT 网关
- 86.59.21.20 Linux HTTP 服务器
在来自 86.59.21.20 的延迟且已重新传输的段到达后，端口 29909 上的 TCP 流遇到来自 144.76.103.194 的 RST。
- 帧 #581 - 启动序列 522729 的重传
- 帧 #615 - 序列 522729 已重新传输
- 帧 #1727 - 原始序列 522729 到达，延迟约 600 毫秒
- 帧 #1728 - NAT 主机向 HTTP 服务器发送回 RST
直接从 NAT 主机发起的连接工作正常。
答案1
这似乎与 Linux conntrack 代码对“长”延迟段不满意有关，因为意外数据而中止连接。
netfilter/nf_conntrack_tcp_be_liberal通过设置为 1可以缓解此行为。
内核文档：https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt