検索

ホームページ  >  に質問  >  本文

linux - 某台Centos服务器端口连接出现异常

我遇到这个很诡异的问题,我把做过的分析跟大家说说,看是否有遇到相同问题的,或者能否提供一下解决思路。
有个机房的一台CentOS服务器,突然出现了时常端口不能被连接的情况,但是网络可以ping通。前提并没有iptable的影响。

  1. 从公司测试了该服务器的所有的端口都不能telnet,但可以ping通,但过一段时间又自动好了。
  2. 从公司访问该服务器IDC所在的其它服务器正常。
  3. 从该服务器所在的同机房的其它服务器可以登陆可以访问,内网测试所有端口没有问题,再测试外网ip所有的端口没有问题。
  4. 从其它机房测试,端口可以访问。
  5. 怀疑是否是ssh的连接数问题,该服务器上面有建立6个ESTABLISH,调整了几个参数 LoginGraceTime 0  ClientAliveCountMax 0   MaxStartups 100 (当然这怀疑是在刚开始没有测试所有端口的时候,现在所有端口都有问题 而且除了从公司访问其它地方都是正常的 所以肯定跟ssh没有关系的)
  6. 从系统日志上message 也没有看出什么问题

最后,我有几个不是很成立的怀疑

  1. 有没有可能系统记住了某些ip,类似黑名单之类的
  2. 或者说因为单个ip的连接数过高,系统会有保护机制(因为公司出口是一个ip)这种也是瞎猜,因为我们还有其它服务器访问量更高的也没有出现问题;
  3. 难道是我们公司的路由器的问题?如果系统本身没有问题,从公司到该服务器,最受影响能让我们控制的就是我们的出口路由器了(IDC没有防火墙)。

大牛们帮我看下,或者提供下解决思路,总这样时好时坏,让人太郁闷了。

========================================================================
我自己通过多次断公司的网络,直接连接外网出口的线,跳过路由器,证实问题依旧。(公司的其它同事估计抓狂了,不用再断了。)
是否有办法可以测试telnet 在网络的哪一步出现的问题吗?是已经达到服务器了,还是在半路就出现问题了。

我用tcpdump抓包分析,而且进行了一个对比,这里我用1.1.1.1代替这台有问题的外网ip地址
公司内服务器访问1.1.1.1

访问1.1.1.1的rsync服务873端口,超时
14:23:28.391863 IP 192.168.1.253.22806 > 1.1.1.1-BJ-CNC.rsync: S 1300386517:1300386517(0) win 5792 <mss 1460,sackOK,timestamp 46829182 1160219871,nop,wscale 7>
14:23:31.385611 IP 192.168.1.253.22806 > 1.1.1.1-BJ-CNC.rsync: S 1300386517:1300386517(0) win 5792 <mss 1460,sackOK,timestamp 46829932 1160219871,nop,wscale 7>
14:23:37.403764 IP 192.168.1.253.22806 > 1.1.1.1-BJ-CNC.rsync: S 1300386517:1300386517(0) win 5792 <mss 1460,sackOK,timestamp 46831432 1160219871,nop,wscale 7>

访问1.1.1.1的22号端口,超时
14:24:12.929751 IP 192.168.1.253.14380 > 1.1.1.1-BJ-CNC.ssh: S 1352972660:1352972660(0) win 5840 <mss 1460,sackOK,timestamp 46840315 0,nop,wscale 7>
14:24:15.923519 IP 192.168.1.253.14380 > 1.1.1.1-BJ-CNC.ssh: S 1352972660:1352972660(0) win 5840 <mss 1460,sackOK,timestamp 46841065 0,nop,wscale 7>
14:24:21.921609 IP 192.168.1.253.14380 > 1.1.1.1-BJ-CNC.ssh: S 1352972660:1352972660(0) win 5840 <mss 1460,sackOK,timestamp 46842565 0,nop,wscale 7>

ping 1.1.1.1 有回应
14:26:12.615584 IP 192.168.1.253 > 1.1.1.1-BJ-CNC: ICMP echo request, id 41566, seq 1, length 64
14:26:12.620142 IP 1.1.1.1-BJ-CNC > 192.168.1.253: ICMP echo reply, id 41566, seq 1, length 64
14:26:13.614589 IP 192.168.1.253 > 1.1.1.1-BJ-CNC: ICMP echo request, id 41566, seq 2, length 64
14:26:13.619458 IP 1.1.1.1-BJ-CNC > 192.168.1.253: ICMP echo reply, id 41566, seq 2, length 64
14:26:14.613947 IP 192.168.1.253 > 1.1.1.1-BJ-CNC: ICMP echo request, id 41566, seq 3, length 64
14:26:14.618159 IP 1.1.1.1-BJ-CNC > 192.168.1.253: ICMP echo reply, id 41566, seq 3, length 64

从国外一个机房访问1.1.1.1

访问1.1.1.1的22号端口,成功
14:25:13.853515 IP sg-test1.ispipes > 1.1.1.1.ssh: S 689779547:689779547(0) win 5840 <mss 1460,sackOK,timestamp 3275537225 0,nop,wscale 7>
14:25:14.080372 IP 1.1.1.1.ssh > sg-test1.ispipes: S 1586901313:1586901313(0) ack 689779548 win 5792 <mss 1460,sackOK,timestamp 1160354377 3275537225,nop,wscale 7>
14:25:14.080402 IP sg-test1.ispipes > 1.1.1.1.ssh: . ack 1 win 46 <nop,nop,timestamp 3275537453 1160354377>
14:25:14.312687 IP 1.1.1.1.ssh > sg-test1.ispipes: P 1:22(21) ack 1 win 46 <nop,nop,timestamp 1160354610 3275537453>
14:25:14.312697 IP sg-test1.ispipes > 1.1.1.1.ssh: . ack 22 win 46 <nop,nop,timestamp 3275537686 1160354610>

ping 1.1.1.1 有反应
14:25:58.158062 IP sg-test1 > 1.1.1.1: ICMP echo request, id 63102, seq 1, length 64
14:25:58.441169 IP 1.1.1.1 > sg-test1: ICMP echo reply, id 63102, seq 1, length 64
14:25:59.158279 IP sg-test1 > 1.1.1.1: ICMP echo request, id 63102, seq 2, length 64
14:25:59.451250 IP 1.1.1.1 > sg-test1: ICMP echo reply, id 63102, seq 2, length 64
14:26:00.158310 IP sg-test1 > 1.1.1.1: ICMP echo request, id 63102, seq 3, length 64
14:26:00.459578 IP 1.1.1.1 > sg-test1: ICMP echo reply, id 63102, seq 3, length 64
14:26:01.158345 IP sg-test1 > 1.1.1.1: ICMP echo request, id 63102, seq 4, length 64          
14:26:01.467353 IP 1.1.1.1 > sg-test1: ICMP echo reply, id 63102, seq 4, length 64

有人可以从这两段tcpdump看出什么问题吗?

PHP中文网PHP中文网2785日前927

全員に返信(1)返信します

  • 怪我咯

    怪我咯2017-04-17 11:06:12

    用tcpdump抓包看看

    返事
    0
  • キャンセル返事