为什么在接收到 SYN/ACK 时，会向某些站点发送 RST 数据包答案

【问题标题】：Why on receiving SYN/ACK, a RST packet is sent with certain sites为什么在接收到 SYN/ACK 时，会向某些站点发送 RST 数据包
【发布时间】：2013-04-26 02:31:41
【问题描述】：

我正在运行 ArchLinux，最近遇到了这个奇怪的问题。一段时间后，连接到 Google 会超时，因为我的系统在接收到来自服务器的 SYN/ACK 数据包时不断发送 RST 数据包。谷歌的其他IP和端口号也是如此。 yahoo.com 也会发生这种情况。

这从未发生过。我认为我的系统可能有问题，但我不记得我最近更改了系统配置。

[更新]

这又发生了，我得到了 skjaidev 建议的以下tcpdump 输出：

$ sudo tcpdump -i eth0 "ip host 209.85.153.100"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:44:15.737180 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [S], seq 1037252805, win 14600, options [mss 1460,sackOK,TS val 33830667 ecr 0,nop,wscale 6], length 0
13:44:15.905741 IP encrypted.google.com.https > 10.20.1.113.53894: Flags [S.], seq 371070936, ack 1037252806, win 5672, options [mss 1430,sackOK,TS val 266521270 ecr 33818028,nop,wscale 6], length 0
13:44:15.905761 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [R], seq 1037252806, win 0, length 0
13:44:16.209090 IP encrypted.google.com.https > 10.20.1.113.53894: Flags [S.], seq 371070936, ack 1037252806, win 5672, options [mss 1430,sackOK,TS val 266521573 ecr 33818028,nop,wscale 6], length 0
13:44:16.209111 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [R], seq 1037252806, win 0, length 0
13:44:18.738936 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [S], seq 1037252805, win 14600, options [mss 1460,sackOK,TS val 33831568 ecr 0,nop,wscale 6], length 0
13:44:18.896373 IP encrypted.google.com.https > 10.20.1.113.53894: Flags [S.], seq 417800121, ack 1037252806, win 5672, options [mss 1430,sackOK,TS val 266524260 ecr 33818028,nop,wscale 6], length 0
13:44:18.896391 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [R], seq 1037252806, win 0, length 0
13:44:24.752266 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [S], seq 1037252805, win 14600, options [mss 1460,sackOK,TS val 33833372 ecr 0,nop,wscale 6], length 0
13:44:25.102758 IP encrypted.google.com.https > 10.20.1.113.53894: Flags [S.], seq 514770952, ack 1037252806, win 5672, options [mss 1430,sackOK,TS val 266530467 ecr 33818028,nop,wscale 6], length 0
13:44:25.102777 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [R], seq 1037252806, win 0, length 0
13:44:36.765603 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [S], seq 1037252805, win 14600, options [mss 1460,sackOK,TS val 33836976 ecr 0,nop,wscale 6], length 0
13:45:28.236165 IP 10.20.1.113.53890 > encrypted.google.com.https: Flags [P.], seq 31651351:31651378, ack 2535469155, win 279, options [nop,nop,TS val 33852417 ecr 299514426], length 27
13:45:28.236184 IP 10.20.1.113.53890 > encrypted.google.com.https: Flags [F.], seq 27, ack 1, win 279, options [nop,nop,TS val 33852417 ecr 299514426], length 0
13:45:28.426021 IP encrypted.google.com.https > 10.20.1.113.53890: Flags [F.], seq 1, ack 27, win 194, options [nop,nop,TS val 299629642 ecr 33852417], length 0
13:45:28.426044 IP 10.20.1.113.53890 > encrypted.google.com.https: Flags [.], ack 2, win 279, options [nop,nop,TS val 33852474 ecr 299629642], length 0
13:45:28.426983 IP encrypted.google.com.https > 10.20.1.113.53890: Flags [.], ack 28, win 194, options [nop,nop,TS val 299629644 ecr 33852417], length 0

【问题讨论】：

您可以发布简单的数据包跟踪，以提供更多详细信息。以 root 身份运行并在此处发布输出：tcpdump -i "ip host "。例如：tcpdump -i eth0 "ip host 192.168.1.1"。

标签： networking tcp

【解决方案1】：

我终于找到了解决方案——禁用 TCP 时间戳 (sysctl net.ipv4.tcp_timestamps=0) 为我解决了这个问题。这些数据包的时间戳似乎无效。

【讨论】：

【解决方案2】：

注意这两个数据包的源端口、序列号等是相同的吗？

13:44:16.209111 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [R], seq 1037252806, win 0, length 0
13:44:18.738936 IP 10.20.1.113.53894 > encrypted.google.com.https: Flags [S], seq 1037252805, win 14600, options [mss 1460,sackOK,TS val 33831568 ecr 0,nop,wscale 6], length 0

你不能这么快地重用源端口。你的机器出了点问题。看起来您的 TCP 堆栈没有看到来自服务器的任何数据包，其他东西正在生成 RST。要么您有 iptable 规则，要么可能存在校验和错误，完整的数据包捕获（使用 -s 0 -w foo.pcap 并分析 wireshark 中的跟踪）应该会显示任何校验和错误。

【讨论】：

我在wireshark中看到过，没有显示错误。另外，我没有 iptable 规则。
它肯定是 SYN 重传（请参阅源端口 53894 在时间 13:44:15.737180、13:44:18.738936、13:44:24.752266 和 13:44:36.765603 的 SYN 数据包）。指数超时表示 SYN re-tx。 SYNACK 没有通过 TCP 堆栈，因此响应数据包中有一些错误。
但是我怎么知道错误是什么，或者是什么导致了错误？应该不是随机事件，因为它发生了好几次，只有重新启动才能修复它。我猜这与正常运行时间或休眠有关？

【解决方案3】：

您的时钟很可能在漂移。将 NTPD 设置为更积极地更新系统时间，以便您始终更准确。特别是如果您的系统经常进入休眠状态。时钟总是会落下时间。

【讨论】：

我有 ntpd 正在运行，但我从未观察到错误。忘了说这个问题只发生在一个特定的网络上（当我移动并连接到另一个网络时，它就起作用了）。我无法访问现在出现问题的网络。