邮件服务器时常连接不上

helloiac

说明：
1.局域网内有大量的windows destkop 40~50台，使用outlook 或者foxmail 等 3分钟自动连接邮件服务器收件或者不定时发送邮件
2.局域网内有部分linux 内网服务器，偶尔连接邮件服务器进行发件
3.整个局域网连接外网都nat 成同一个公网ip ccc ，router C 本身也是一台linux 主机开启转发

问题概述：
1.局域网内windows 主机telnet 邮件服务器A 一般都没有问题 但是使用局域网内的部分linux 主机telnet 时常会连接不上，不管是什么端口（22，25.443，995）都是一样的情况
2.外网linux 服务器B telnet 邮件服务器A 一般也都没有问题

在邮件服务器上抓包，服务器有收到syn 但是服务器没有返回包
以443端口为例
使用一台内网Fedora 19 telnet 服务器443端口，服务器上的抓包情况

1. 15:16:55.144222 IP xxx.xxx.xxx.xxx.46989 > xxx.xxx.xxx.xxx.https: Flags [S], seq 939563650, win 29200, options [mss 1460,sackOK,TS val 23633360 ecr 0,nop,wscale 7], length 0
   
2. 15:17:03.160282 IP xxx.xxx.xxx.xxx.46989 > xxx.xxx.xxx.xxx.https: Flags [S], seq 939563650, win 29200, options [mss 1460,sackOK,TS val 23641376 ecr 0,nop,wscale 7], length 0

复制代码

使用一台window7 telnet 服务器443端口，服务器上的抓包情况
（window7 与Fedora19 位于同一台hub 上）

1. 15:20:54.484991 IP xxx.xxx.xxx.xxx.49218 > xxx.xxx.xxx.xxx.https: Flags [S], seq 31344922, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
   
2. 15:20:54.485034 IP xxx.xxx.xxx.xxx.https > xxx.xxx.xxx.xxx.49218: Flags [S.], seq 1361958840, ack 31344923, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
   
3. 15:20:54.485558 IP xxx.xxx.xxx.xxx.49218 > xxx.xxx.xxx.xxx.https: Flags [.], ack 1, win 4380, length 0
   
4. 15:20:55.685554 IP xxx.xxx.xxx.xxx.https > xxx.xxx.xxx.xxx.49218: Flags [S.], seq 1361958840, ack 31344923, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
   
5. 15:20:55.686359 IP xxx.xxx.xxx.xxx.49218 > xxx.xxx.xxx.xxx.https: Flags [.], ack 1, win 4380, options [nop,nop,sack 1 {0:1}], length 0
   
6. 15:21:05.122927 IP xxx.xxx.xxx.xxx.49218 > xxx.xxx.xxx.xxx.https: Flags [F.], seq 1, ack 1, win 4380, length 0
   
7. 15:21:05.123193 IP xxx.xxx.xxx.xxx.https > xxx.xxx.xxx.xxx.49218: Flags [F.], seq 1, ack 2, win 115, length 0
   
8. 15:21:05.123813 IP xxx.xxx.xxx.xxx.49218 > xxx.xxx.xxx.xxx.https: Flags [.], ack 2, win 4380, length 0

复制代码

服务器上sysctl -a 关于syn的

fs.quota.syncs = 0
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.tcp_syn_retries = 5
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 10240
net.ipv6.conf.all.max_desync_factor = 600
net.ipv6.conf.default.max_desync_factor = 600
net.ipv6.conf.lo.max_desync_factor = 600
net.ipv6.conf.eth0.max_desync_factor = 600
net.ipv6.conf.eth1.max_desync_factor = 600
net.ipv6.conf.eth2.max_desync_factor = 600

helloiac

发现一个问题，就是这些时常连接不上的都是发生在linux 系统下，widows 系统就没有这个问题，是不是因为局域网内的邮件客户端连接都是复用一个tcp/ip连接
而linux 由于包的不同所以不能复用该连接

cryboy2001

我觉得是其它问题产生的，而不是linux特定的问题。
没听说linux连postfix时会产生特别的问题。

helloiac

回复 3# cryboy2001


    感觉应该是mail服务器上对于相同来源ip连接的问题，应为使用线上其他IP的linux 主机去telnet 邮件服务器完全没有问题
   
   

woxizishen

楼主在你那个有问题和没问题的的linux主机分别traceroute以下你的邮件服务器，看下路由走向。

cryboy2001

你看看是不是防火墙，fail2ban或其它有封ip功能的软件设置造成的

helloiac

回复 6# cryboy2001


    不是，试过将fail2ban停止掉，情况依然

helloiac

终于找到坑货了

原来是内核中的 net.ipv4.tcp_tw_recycle=1 这个参数，将其置0就可以了

表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

大概和【经验总结】tcp_tw_recycle参数引发的故障有点类似

我们在一些高并发的 WebServer上，为了端口能够快速回收，打开了 tcp_tw_reccycle ，而在关闭 tcp_tw_reccycle 的时候，kernal 是不会检查对端机器的包的时间戳的；打开了 tcp_tw_reccycle 了，就会检查时间戳，很不幸移动的cmwap发来的包的时间戳是乱跳的，所以我方的就把带了“倒退”的时间戳的包当作是“recycle的tw连接的重传数据，不是新的请求”，于是丢掉不回包，造成大量丢包。

woxizishen

回复 8# helloiac

不带这样啃版主的^_^