• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
案例类型
搜索
取消
产品线
关键字
发布者
发布时间

ssh客户端通过ipsec vpn管理对方MSR3600路由器隔一段时间会断开

2015-10-24发表
  • 0关注
  • 1收藏,943浏览
李聪 四段
粉丝:0人 关注:0人

案例介绍:

 某公司的管理员发现在路由器A下面的PC使用ssh客户端通过vpn去管理路由器B的内网接口时不稳定,发现crt连接成功之后大概5分钟就会断开,需要重新连接才能继续敲命令。但是不通过vpn而是直接通过对方路由器的外网地址管理路由器B则没有问题。

 

一、测试现象:

首先看到这个问题,首先考虑的就是怀疑网络中断造成的,可能是vpn断开或者其他的原因。因此让代理商在连接ssh的同时也在电脑上面开启ping看看是否在ssh断开的时候有丢包或者延迟大的情况出现。结果代理商测试结果就是ssh客户端断开了,但是ping正常而且延迟很小,这个情况反映出网络正常的。

二、问题分析过程:

1.经过测试我们可以肯定网络应该没有问题,不然ping也跟着断开才正常的。因此怀疑内网是否有TCP flood攻击造成的tcp连接不够用导致的断开。让代理商在双边的设备上执行[H3C]dis session statistics summary
查看之后发现两边设备的会话数量很少,才2000多,因此也排除攻击的可能性。

2.经过以上的分析,现在又将思路转移到vpn上来。为什么直接通过对方路由器B的外网地址管理没有问题,但是通过vpn就不可以呢?下面就分别对通过外网地址ssh连接以及通过vpn连接的情况做了抓包分析:

2.1 两种情况在电脑上面使用wireshark抓包,发现连接外网的时候很正常的数据包;但是通过vpn连接的时候建立一段时间之后会有不断的重传的TCP报文。(下图只展示通过vpn连接的报文抓包)

从上面的两张图可以看出电脑ssh客户端一直在重传报文,最后一直没有收到对方的回包然后将就把seq=1632序列号加上52的长度作为新的报文的seq=1684,然后ack没变,发送过去一个rst报文断开连接。

从电脑端抓包发现是客户端收不到对方的报文,重传了多次失败之后发送rst报文重置了连接。现在问题进一步缩小,收不到对方的回应报文那么接下来就在设备端debugging抓包。

2.2 在设备端开启:

t d

t m

debug ssh server all

debug tcp packet acl 3999

debug ip pa acl 3999

然后由于信息比较多,现在需要找出断开ssh连接的之前的tcp报文的交互过程:

*Oct 19 15:20:41:087 2015 TJ-LY SOCKET/7/TCP:
Time(s):1445268041  TCP Retransfer(vrf = 0, state = ESTABLISHED):
 TCP packet: src = 10.237.250.1/22, dst = 10.237.243.46/51389
             seq = 2135685009, ack = 4007132849, flag =  PSH ACK
             window = 8054, checksum = 0xfc99, datalen = 52, headlen = 20

*Oct 19 15:20:42:109 2015 TJ-LY IPFW/7/IPFW_PACKET:
Receiving, interface = GigabitEthernet0/0, version = 4, headlen = 20, tos = 0,
pktlen = 92, pktid = 9677, offset = 0, ttl = 62, protocol = 6,
checksum = 5061, s = 10.237.243.46, d = 10.237.250.1
prompt: Receiving IP packet.

*Oct 19 15:20:42:109 2015 TJ-LY IPFW/7/IPFW_PACKET:
Delivering, interface = GigabitEthernet0/0, version = 4, headlen = 20, tos = 0,
pktlen = 92, pktid = 9677, offset = 0, ttl = 62, protocol = 6,
checksum = 5061, s = 10.237.243.46, d = 10.237.250.1
prompt: IP packet is delivering up.

*Oct 19 15:20:42:109 2015 TJ-LY SOCKET/7/TCP:
Time(s):1445268042  TCP Input(vrf = 0, state = ESTABLISHED):
 TCP packet: src = 10.237.243.46/51389, dst = 10.237.250.1/22
             seq = 4007132797, ack = 2135685009, flag =  PSH ACK
             window = 4312, checksum = 0x0, datalen = 52, headlen = 20

*Oct 19 15:20:42:109 2015 TJ-LY SOCKET/7/TCP:
Time(s):1445268042  TCP Output(vrf = 0, state = ESTABLISHED):
 TCP packet: src = 10.237.250.1/22, dst = 10.237.243.46/51389
             seq = 2135685061, ack = 4007132849, flag =  ACK
             window = 8054, checksum = 0x5fe5, datalen = 0, headlen = 20

*Oct 19 15:20:44:575 2015 TJ-LY SOCKET/7/TCP:
Time(s):1445268044  TCP Retransfer(vrf = 0, state = ESTABLISHED):
 TCP packet: src = 10.237.250.1/22, dst = 10.237.243.46/51389
             seq = 2135685009, ack = 4007132849, flag =  PSH ACK
             window = 8054, checksum = 0xfc99, datalen = 52, headlen = 20

*Oct 19 15:20:46:909 2015 TJ-LY IPFW/7/IPFW_PACKET:
Receiving, interface = GigabitEthernet0/0, version = 4, headlen = 20, tos = 0,
pktlen = 92, pktid = 9681, offset = 0, ttl = 62, protocol = 6,
checksum = 5057, s = 10.237.243.46, d = 10.237.250.1
prompt: Receiving IP packet.

*Oct 19 15:20:46:909 2015 TJ-LY IPFW/7/IPFW_PACKET:
Delivering, interface = GigabitEthernet0/0, version = 4, headlen = 20, tos = 0,
pktlen = 92, pktid = 9681, offset = 0, ttl = 62, protocol = 6,
checksum = 5057, s = 10.237.243.46, d = 10.237.250.1
prompt: IP packet is delivering up.

*Oct 19 15:20:46:909 2015 TJ-LY SOCKET/7/TCP:
Time(s):1445268046  TCP Input(vrf = 0, state = ESTABLISHED):
 TCP packet: src = 10.237.243.46/51389, dst = 10.237.250.1/22
             seq = 4007132797, ack = 2135685009, flag =  PSH ACK
             window = 4312, checksum = 0x0, datalen = 52, headlen = 20

*Oct 19 15:20:46:909 2015 TJ-LY SOCKET/7/TCP:
Time(s):1445268046  TCP Output(vrf = 0, state = ESTABLISHED):
 TCP packet: src = 10.237.250.1/22, dst = 10.237.243.46/51389
             seq = 2135685061, ack = 4007132849, flag =  ACK
             window = 8054, checksum = 0x5fe5, datalen = 0, headlen = 20

*Oct 19 15:20:51:351 2015 TJ-LY SOCKET/7/TCP:
Time(s):1445268051  TCP Retransfer(vrf = 0, state = ESTABLISHED):
 TCP packet: src = 10.237.250.1/22, dst = 10.237.243.46/51389
             seq = 2135685009, ack = 4007132849, flag =  PSH ACK
             window = 8054, checksum = 0xfc99, datalen = 52, headlen = 20

*Oct 19 15:20:56:509 2015 TJ-LY IPFW/7/IPFW_PACKET:
Receiving, interface = GigabitEthernet0/0, version = 4, headlen = 20, tos = 0,
pktlen = 40, pktid = 9696, offset = 0, ttl = 62, protocol = 6,
checksum = 5094, s = 10.237.243.46, d = 10.237.250.1
prompt: Receiving IP packet.

*Oct 19 15:20:56:509 2015 TJ-LY IPFW/7/IPFW_PACKET:
Delivering, interface = GigabitEthernet0/0, version = 4, headlen = 20, tos = 0,
pktlen = 40, pktid = 9696, offset = 0, ttl = 62, protocol = 6,
checksum = 5094, s = 10.237.243.46, d = 10.237.250.1
prompt: IP packet is delivering up.

*Oct 19 15:20:56:509 2015 TJ-LY SOCKET/7/TCP:
Time(s):1445268056  TCP Input(vrf = 0, state = ESTABLISHED):
 TCP packet: src = 10.237.243.46/51389, dst = 10.237.250.1/22
             seq = 4007132849, ack = 2135685009, flag =  RST ACK
             window = 0, checksum = 0x0, datalen = 0, headlen = 20

*Oct 19 15:20:56:509 2015 TJ-LY SSHS/7/ERROR: Read error from remote host 10.237.243.46: Connection reset by peer
%Oct 19 15:20:56:509 2015 TJ-LY SSHS/6/SSHS_DISCONNECT: SSH user admin (IP: 10.237.243.46) disconnected from the server.
*Oct 19 15:20:56:510 2015 TJ-LY SSHS/7/EVENT: PAM: cleanup
*Oct 19 15:20:56:510 2015 TJ-LY SSHS/7/EVENT: Close pty: pseudo-terminal-master(-1), pseudo-terminal-sub(17)
%Oct 19 15:20:57:300 2015 TJ-LY SHELL/5/SHELL_LOGOUT: admin logged out from 10.237.243.46.

 

只截取了最后几个报文的交互过程其实从上面标红的地方就可以看出来设备可以收到ssh客户端发送过来的报文,但是蓝色标注的是设备返回的报文。从报文的交互可以看出,ssh客户端一直以之前的seq以及ack一直在重发,设备已经使用seq=ack回应ssh客户端了,但是在ssh客户端却看不到回应的报文。因此ssh客户端将自己的seq+len作为新的seq发送了rst报文断开连接,因此无法再crt里面输入命令了。

3.3 从上面两边的分析可以看出设备能够收到报文并且返回,ssh客户端看不到回包。因此问题应该出在vpn链路上面。居然设备回包出不去,那么现在来看vpn的配置。重点排查natacl以及vpnacl,经过两边设备的配置的仔细的检查之后发现在路由器B上面natacl没有将10.237.250.110.237.243.0/24这个网段排除。配置加上这个deny的命令之后发现现在能够正常连接ssh客户端了。

3.4 ping没有问题而ssh有问题是因为ping属于icmp报文,这个报文只要ping完成之后就会删除会话;而ssh连接会保持连接并且需要server端回应报文,一旦连接需要server发起的会话连接的时候就会有问题。因此ssh连接通过vpn连接时候需要保证两边都能够互通。

 


由于路由器B上面没将10.237.250.110.237.243.0/24这个网段排除,因此回包走了nat出去。在natrule之前加上deny这个网段的acl即可解决。

acl number 3200
 rule 0 deny ip source 10.237.250.1 0.0.0.0 destination 10.237.243.0 0.0.0.255
 rule 1 deny ip source 10.237.96.0 0.0.31.255 destination 10.237.5.0 0.0.0.255
 rule 2 deny ip source 10.237.96.0 0.0.31.255 destination 10.237.64.0 0.0.31.255
 rule 3 deny ip source 10.237.96.0 0.0.31.255 destination 10.255.0.0 0.0.255.255
 rule 4 deny ip source 10.237.96.0 0.0.31.255 destination 10.237.0.0 0.0.63.255
 rule 5 deny ip source 10.237.96.0 0.0.31.255 destination 10.237.181.0 0.0.0.255
 rule 6 deny ip source 10.237.96.0 0.0.31.255 destination 10.241.80.0 0.0.0.255
 rule 7 permit ip

 


1ssh通过vpn连接时候需要保证两边都能够互通才能正常的工作。

2.配置vpn的时候需要将通过vpn的流量在natacl里面进行排除。


0 个评论

该案例暂时没有网友评论

编辑评论

举报

×

侵犯我的权益 >
对根叔知了社区有害的内容 >
辱骂、歧视、挑衅等(不友善)

侵犯我的权益

×

泄露了我的隐私 >
侵犯了我企业的权益 >
抄袭了我的内容 >
诽谤我 >
辱骂、歧视、挑衅等(不友善)
骚扰我

泄露了我的隐私

×

您好,当您发现根叔知了上有泄漏您隐私的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您认为哪些内容泄露了您的隐私?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)

侵犯了我企业的权益

×

您好,当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 zhiliao@h3c.com 邮箱,我们会在审核后尽快给您答复。
  • 1. 您举报的内容是什么?(请在邮件中列出您举报的内容和链接地址)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
  • 3. 是哪家企业?(营业执照,单位登记证明等证件)
  • 4. 您与该企业的关系是?(您是企业法人或被授权人,需提供企业委托授权书)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

抄袭了我的内容

×

原文链接或出处

诽谤我

×

您好,当您发现根叔知了上有诽谤您的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您举报的内容以及侵犯了您什么权益?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔知了社区有害的内容

×

垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载 >
辱骂、歧视、挑衅等(不友善)
骚扰我
诱导投票

不规范转载

×

举报说明

提出建议

    +
标杆的神器激活
鼠年的运维 skr skr

亲~登录后才可以操作哦!

确定

你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作