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

案例介绍：

 某公司的管理员发现在路由器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的配置。重点排查nat的acl以及vpn的acl，经过两边设备的配置的仔细的检查之后发现在路由器B上面nat的acl没有将10.237.250.1到10.237.243.0/24这个网段排除。配置加上这个deny的命令之后发现现在能够正常连接ssh客户端了。

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

由于路由器B上面没将10.237.250.1到10.237.243.0/24这个网段排除，因此回包走了nat出去。在nat的rule之前加上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

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

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