我在与位于 Cisco ASA 防火墙后面的中央服务器通信的 RHEL7 盒子上遇到了一个问题。
这些机器启动并启动一个代理，该代理建立并保持与中央服务器的连接。然后，中央服务器定期通过该隧道将流量发送到客户端。在第 5 分钟，我们看到代理断开连接，并且无法通过连接发送流量，除非我们重新启动连接，此后它工作正常。
进一步的研究表明，问题不仅仅出在这个应用程序/代理上，事实上，我们可以使用“nc”毫无差错地复制它。我们进行了数据包捕获，发现在 5 分钟时，ASA 丢弃了从客户端服务器发送的 ACK 数据包。中央服务器看不到任何数据包，并继续尝试重新传输。客户端将收到重新传输，发送 ACK，ASA 将丢弃它 - 重复上述操作。
在调查捕获时，我们发现在 5 分钟时，客户端服务器将 ACK 数据包上的 TSVal 重置为某个较低的数字。
您可以在下面的数据包捕获中看到，对于数据包 101，客户端发送了一个 TSVal 为 4294962488 的 ACK。然后，服务器推送更多数据（数据包 102），但在数据包 103 上，客户端现在以 TSVal 设置为 196 的 ACK 进行响应。
No. Time Timestamp Source Destination Protocol Length Info
96 2017-07-11 15:16:04.717785 22:16:04.717785 10.158.35.162 10.153.195.227 TCP 101 4506 → 38208 [PSH, ACK] Seq=3089107029 Ack=2031069343 Win=29056 Len=35 TSval=1400815609 TSecr=4294947477
97 2017-07-11 15:16:04.717802 22:16:04.717802 10.153.195.227 10.158.35.162 TCP 66 38208 → 4506 [ACK] Seq=2031069343 Ack=3089107064 Win=29312 Len=0 TSval=4294952481 TSecr=1400815609
98 2017-07-11 15:16:09.721130 22:16:09.721130 10.158.35.162 10.153.195.227 TCP 101 4506 → 38208 [PSH, ACK] Seq=3089107064 Ack=2031069343 Win=29056 Len=35 TSval=1400820612 TSecr=4294952481
99 2017-07-11 15:16:09.721152 22:16:09.721152 10.153.195.227 10.158.35.162 TCP 66 38208 → 4506 [ACK] Seq=2031069343 Ack=3089107099 Win=29312 Len=0 TSval=4294957485 TSecr=1400820612
100 2017-07-11 15:16:14.724742 22:16:14.724742 10.158.35.162 10.153.195.227 TCP 101 4506 → 38208 [PSH, ACK] Seq=3089107099 Ack=2031069343 Win=29056 Len=35 TSval=1400825616 TSecr=4294957485
101 2017-07-11 15:16:14.724757 22:16:14.724757 10.153.195.227 10.158.35.162 TCP 66 38208 → 4506 [ACK] Seq=2031069343 Ack=3089107134 Win=29312 Len=0 TSval=4294962488 TSecr=1400825616
102 2017-07-11 15:16:19.728187 22:16:19.728187 10.158.35.162 10.153.195.227 TCP 101 4506 → 38208 [PSH, ACK] Seq=3089107134 Ack=2031069343 Win=29056 Len=35 TSval=1400830619 TSecr=4294962488
103 2017-07-11 15:16:19.728207 22:16:19.728207 10.153.195.227 10.158.35.162 TCP 66 38208 → 4506 [ACK] Seq=2031069343 Ack=3089107169 Win=29312 Len=0 TSval=196 TSecr=1400830619
104 2017-07-11 15:16:19.728556 22:16:19.728556 10.158.35.162 10.153.195.227 TCP 66 [TCP Dup ACK 2#1] 4506 → 38208 [PSH, ACK] Seq=3089107169 Ack=2031069343 Win=29056 Len=0 TSval=1400830619 TSecr=4294962488
105 2017-07-11 15:16:19.928307 22:16:19.928307 10.158.35.162 10.153.195.227 TCP 101 [TCP Spurious Retransmission] 4506 → 38208 [PSH, ACK] Seq=3089107134 Ack=2031069343 Win=29056 Len=35 TSval=1400830820 TSecr=4294962488
106 2017-07-11 15:16:19.928319 22:16:19.928319 10.153.195.227 10.158.35.162 TCP 78 [TCP Dup ACK 103#1] 38208 → 4506 [ACK] Seq=2031069343 Ack=3089107169 Win=29312 Len=0 TSval=396 TSecr=1400830820 SLE=3089107134 SRE=3089107169
107 2017-07-11 15:16:19.928702 22:16:19.928702 10.158.35.162 10.153.195.227 TCP 66 [TCP Dup ACK 2#2] 4506 → 38208 [PSH, ACK] Seq=3089107169 Ack=2031069343 Win=29056 Len=0 TSval=1400830820 TSecr=4294962488
然后，ASA 认为其格式不正确并将其丢弃，因为 TSVal 不应该减少。
我们尝试通过 /proc/sys/net/ipv4/tcp_timestamps 禁用 tcp_timestamps。此方法有效，问题消失，但禁用时间戳可能会对其他应用程序流量产生其他影响。
此外，问题仍然存在，为什么主机在线 5 分钟后 TSVal 会重置为如此低的数字？这只发生在我们的 RHEL7u2 系统上 - 我们的 RHEL6 系统没有遇到此问题。
任何想法/帮助都将不胜感激。
答案1
我不认为防火墙应该丢弃这些，它应该查看两个序列号和时间戳在一起...我猜测发生的事情是，RHEL 7 现在出于安全原因随机化时间戳，但也许防火墙已经很旧了？”