Linux 只能收到 SYN 包 不能回包

问题

如果用户发现云主机不能登录,例如无法远程 22 端口或其他端口,但是更换网络环境正常,服务端抓包发现客户端发包只有 SYN,没有回包,可以执行 netstat -s |grep rejec 查看下是否是 tcp_timestamps 的问题

1
2
3
[root@hfgo2 ~]# netstat -s |grep rejec
8316 passive connections rejected because of time stamp
780 packets rejects in established connections because of timestamp

如果出现很多数据包的 timestamp 被拒绝,则检查下内核参数 tcp_tw_recycle 是否开启,如果开启,将其关闭即可。

1
2
[root@hfgo2 ~]# cat  /proc/sys/net/ipv4/tcp_tw_recycle
1

原因

这个主意是和内核的 2 个参数相关

net.ipv4.tcp_timestamps

tcp_timestamps 会记录数据包的发送时间。基本的步骤如下:

发送方在发送数据时,将一个timestamp(表示发送时间)放在包里面
接收方在收到数据包后,在对应的ACK包中将收到的timestamp返回给发送方(echo back)
发送发收到ACK包后,用当前时刻now - ACK包中的timestamp就能得到准确的RTT
timestamps一个双向的选项,当一方不开启时,两方都将停用timestamps。比如client端发送的SYN包中带有timestamp选项,但server端并没有开启该选项。则回复的 SYN-ACK 将不带 timestamp 选项,同时 client 后续回复的ACK也不会带有 timestamp 选项。如果client发送的SYN包中就不带 timestamp,双向都将停用 timestamp。

tcp数据包中 timestamps 的 value 是系统开机时间到现在时间的(毫秒级)时间戳。

如果用户是在一个NAT 环境下,或者出口IP 为1个,如果同时要多个用户连接云服务器,则可能会出现这种问题,根据上述SYN包处理规则,在tcp_tw_recycle和tcp_timestamps同时开启的条件下,timestamp大的主机访问serverN成功,而timestmap小的主机访问失败。

net.ipv4.tcp_tw_recycle

TCP 规范中规定的处于 TIME_WAIT 的 TCP 连接必须等待 2msl 时间。但在linux中,如果开启了 tcp_tw_recycle,TIME_WAIT 的 TCP 连接就不会等待 2msl 时间(而是rto或者60s),从而达到快速重用(回收)处于 TIME_WAIT 状态的 tcp 连接的目的。这就可能导致连接收到之前连接的数据。为此,linux 在打开 tcp_tw_recycle 的情况下,会记录下 TIME_WAIT 连接的对端(peer)信息,包括IP地址、时间戳等。这样,当内核收到同一个 IP 的 SYN 包时,就会去比较时间戳,检查 SYN 包的时间戳是否滞后,如果滞后,就将其丢掉(认为是旧连接的数据)。这在绝大部分情况下是没有问题的,但是对于我们实际的 client-server 的服务,访问我们服务的用户一般都位于 NAT之后,如果NAT之后有多个用户访问同一个服务,就有可能因为时间戳滞后的连接被丢掉。

解决办法

1
# echo "0" > /proc/sys/net/ipv4/tcp_tw_recycle