公司的服务器遇到这个奇怪问题，经常性的WIN7客户端的SYN被服务器丢弃，于是偶go了一下，发现下面的内容，相当有用。
最近遇到一个内网win7用户无法上部分网站的问题，同网段的其他机器都是正常，出问题的机器访问其他网站也是正常。
网络结构简单，client<->源地址转换NAT<->网站
经过在server上抓包发现，server上有时会对client的syn包无响应。
依次排查了服务器的iptables\backlog\syncookies依然没有效果，通过google查到了这样一个
Hi all,
we have a very weird problem here at hand which we can currently only trigger
in a moderately complex setup - however this one is the reality ;)
We have a pool of machines which are on RFC1918 addresses, have a NAT-gateway
to the outside (university /16 network) and some of the machines from the pool
access the web server also in the university network - mostly these are
reloading a status page every ~ 15s via meta refresh.
Now the weird part. If I ask colleagues with a MacOS laptops to access this
page with any web browser, the kick me "out" (standard Debian Squeeze laptop).
During this time, I cannot establish any new connection to this server
(neither via http(s) nor ssh) anymore, however my SYN packets all arrive at
the server (tcpdump/wireshark show this), but the server never replies to me.
If I access the server from another IP (e.g. outside world), there is no
problem.
We have ruled out iptables as the behavior is the same with or without.
We are running out of ideas, thus our question what we might miss here. Is
there a certain limit of connections from one IP (our gateway) to the server,
i.e. could the server run out of resources? I've checked /proc/net to some
extend but might have missed something there.
Anyone with ideas?
Cheers and TIA
Carsten
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
这个上面出的问题和我们遇到的非常相似，测试了下，完全解决问题。通过我们测试，部分win7系统中的注册表中有Tcp1323Opts这个选项，会导致其在发包时加入时间戳，经过nat之后，如果前面相同的端口被使用过，且时间戳大于这个链接发出的syn中的时间戳，就会导致在服务器上忽略掉这个syn。表现为用户无法正常完成tcp3次握手。方法是在服务器上禁止
sysctl -w net.ipv4.tcp_timestamps=0
或者修改客户端的注册表Tcp1323Opts设置为0。
rfc1323
Tcp1323Opts
