邮件服务器时常连接不上
本帖最后由 helloiac 于 2014-10-15 09:16 编辑说明：
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端口，服务器上的抓包情况15:16:55.144222 IP xxx.xxx.xxx.xxx.46989 > xxx.xxx.xxx.xxx.https: Flags , seq 939563650, win 29200, options , length 0
15:17:03.160282 IP xxx.xxx.xxx.xxx.46989 > xxx.xxx.xxx.xxx.https: Flags , seq 939563650, win 29200, options , length 0使用一台window7 telnet 服务器443端口，服务器上的抓包情况
（window7 与Fedora19 位于同一台hub 上）15:20:54.484991 IP xxx.xxx.xxx.xxx.49218 > xxx.xxx.xxx.xxx.https: Flags , seq 31344922, win 8192, options , length 0
15:20:54.485034 IP xxx.xxx.xxx.xxx.https > xxx.xxx.xxx.xxx.49218: Flags , seq 1361958840, ack 31344923, win 14600, options , length 0
15:20:54.485558 IP xxx.xxx.xxx.xxx.49218 > xxx.xxx.xxx.xxx.https: Flags [.], ack 1, win 4380, length 0
15:20:55.685554 IP xxx.xxx.xxx.xxx.https > xxx.xxx.xxx.xxx.49218: Flags , seq 1361958840, ack 31344923, win 14600, options , length 0
15:20:55.686359 IP xxx.xxx.xxx.xxx.49218 > xxx.xxx.xxx.xxx.https: Flags [.], ack 1, win 4380, options , length 0
15:21:05.122927 IP xxx.xxx.xxx.xxx.49218 > xxx.xxx.xxx.xxx.https: Flags , seq 1, ack 1, win 4380, length 0
15:21:05.123193 IP xxx.xxx.xxx.xxx.https > xxx.xxx.xxx.xxx.49218: Flags , seq 1, ack 2, win 115, length 0
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
发现一个问题，就是这些时常连接不上的都是发生在linux 系统下，widows 系统就没有这个问题，是不是因为局域网内的邮件客户端连接都是复用一个tcp/ip连接
而linux 由于包的不同所以不能复用该连接 我觉得是其它问题产生的，而不是linux特定的问题。
没听说linux连postfix时会产生特别的问题。 本帖最后由 helloiac 于 2014-10-14 17:19 编辑
回复 3# cryboy2001
感觉应该是mail服务器上对于相同来源ip连接的问题，应为使用线上其他IP的linux 主机去telnet 邮件服务器完全没有问题
本帖最后由 woxizishen 于 2014-10-15 08:10 编辑
:sleepy:楼主在你那个有问题和没问题的的linux主机分别traceroute以下你的邮件服务器，看下路由走向。
你看看是不是防火墙，fail2ban或其它有封ip功能的软件设置造成的 回复 6# cryboy2001
不是，试过将fail2ban停止掉，情况依然 终于找到坑货了
原来是内核中的 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连接的重传数据，不是新的请求”，于是丢掉不回包，造成大量丢包。 回复 8# helloiac
不带这样啃版主的^_^
页:
[1]