《一次与IP MTU、TCP MSS导致SSL协商失败的案例》

写在前面：

近期，博主在工作中碰到不少奇怪的的故障，有点身心俱疲，博客更新的进度也有些耽搁。

在这里，分享其中一个案例。从解决方式上来回溯可能是什么原因导致了这个问题，并回顾这里面所蕴含的知识。

故障现象：

部分用户反馈打开我方暴露在公网上的应用无法打开，浏览器提示检查TLS、SSL相关设置。通过客户端侧的抓包查看，似乎是SSL建立连接存在问题。常见的SSL建立连接过程如下：

与抓包进行对比查看

可以明显看到，SSL的协商没能继续完成。除此之外，我们可以看到，这里出现了IP包分片的现象。

以此，我们考虑该故障这是否与IP分片、TCP分片有关。

进一步分析：

通过上面的分析，我们可以看到，本次客户端与服务端进行TCP MSS协商，双方提交的MSS值均为1460

以此可以推测，加上20字节的IP包头和20字节的TCP包头，客户端侧与服务端侧的MTU值为1500，这也是MTU的常见数值。然而在故障的抓包中，针对分片的IP包，我们可以看到最大的IP包大小为1476

这代表着数据包在传输过程中，被分片转发了。

正常情况下，即使数据包被分片转发，当抓包侧拿到最后一个分片包后仍然能够通过解读关键位，解析该数据包。但故障数据包中，wireshark没有解析到server hello done等，TLS交互过程中，关键位置位的数据包。我们以此怀疑，数据包在除了在转发过程中被分片以外，还存在着数据包不完整的现象。我们顺着这样的思路，继续分析下去.

我们继续分析数据包，可以看到在客户端侧的抓包中，能够看到这存在着数据包乱序的现象。

经过分析，对比本抓包中的数据包顺序，正常的顺序应该是9—》11—》12—》10—》14，数据包13是TCP RTO超时后进行的重传。

点开数据包13，可以看到该数据包为带有TLS协商过程中标志的，这些标志位的置位代表着服务端完成了标准TLS协商过程中的2、3、4步。

之后，从数据包14的ACK No来看，客户端也确认了完整收到了之前服务器端发过来的TCP数据包。在操作系统将数据包进行重组后，应该可以提交给应用侧。

但之后比较奇怪的是，从数据包15来看，客户端通过发送FIN包直接将连接断开，这导致了SSL协商的失败。

在分析第二组TLS协商过程中的抓包时，现象与刚才的一组不同。在此作简要解释，如下图：

客户端在收到server hello done之后回应了客户端秘钥等信息，但服务器端没有响应，服务器端而是回应了收到客户端最开始发出的Client Hello。这第二组抓包表明，服务器端可能没收到客户端发出的认证信息，甚至服务器端可能没有收到数据包26.我们从抓包中也可以看到，客户端针对数据包26进行了重传。

之后服务器将连接RST掉，这可能是由于在经过一次重试后，RTO时间超时。

这个现象与第一组包中，情况相似，在第一组数据包中，服务器端似乎没有收到数据包9，这导致了客户端针对数据包9进行了重传，而之后客户端将连接断开，这可能也是由于TCP RTO超时。

通过分析这两组交互，我们可以得出，虽然两次交互结束的现象不同。但从数据包的现象来看，都是由于客户端回应的ACK没有被服务器端收到，在第一次交互中，客户端进行了重传；在第二次交互中，客户端与服务器端均进行了重传。两次的交互，区别在于第一次，客户端的RTO时间先超时，客户端将链接断开。而第二次客户端的RTO还未超时，所以客户端发出了关于TLS的客户端认证信息，而之后服务端的RTO超时，服务端将链接断开。

RTO时间超时的可能有很多，可能是ACK包确实没有被收到；也有可能是因为数据包乱序，客户端需要重组而导致等待确认数据包的时间边长。其中ACK包没有收到的现象，不禁让我想起博主的《锅来了！！！不要慌~~~》——那些你应该知道的知识（一）这篇文章，可能是由于IPS或WAF判断为重复ACK攻击，导致数据包交互异常的现象。

这里要讲到RTO的超时时间，在TCP连接建立完成后，RTO时间是根据每一次TCP交互的RTT时间动态变化的，不是一个固定值。

解决问题：

我们通过，改小客户端操作系统本地连接的MTU值，尝试是否能够解决该问题。

在windows客户端中，修改方法如下

netsh interface ipv4 set subinterface "本地连接" mtu=1476 store=persistent

在这里，根据前文的推测我们可以知道，路径中MTU值为1476，我们进行修改。

在这样的修改完成后，我们可以推测，MTU=1476，MSS=1476-20-20=1436

在TLS协商过程中，当TCP负载大于1436时，会在操作系统层面，进行TCP分片。这将避免数据包在中间转发的过程中发生分片。

最终经过验证，通过这种方法，解决了该问题。

原因分析：

在正常的情况下，即使在数据包转发的路径上，因为MTU不匹配，而导致在转发过程中出现了IP数据包分片的现象，在接收端收到该数据包后，也会将数据包进行整合,提供给应用进行处理。

在本故障中，客户端收到数据包为分片的IP数据包，需要将数据包进行重组。同样，由于TCP数据包存在乱序，客户端需要等待理应先到达的数据包收到后，才能确认该数据包，这也增加了客户端侧等待的时间。在服务器侧，同样也可能存在相同的问题，甚至不排除因为TCP乱序，而导致安全设备误杀的可能性。

针对此故障，我们怀疑可能是中间运营商设备在处理分片数据包时，存在问题，可能导致TCP乱序现象的出现。我们将客户端本地MTU改小，导致数据在客户端侧即进行分片，而不会在转发路径上分片，这有可能导致能够解决该问题。

总结：

网络工程师面对的环境错综复杂，很多环节也不是在我们的掌握范围之内。很多情况下，只能通过蛛丝马迹尝试去解决问题，推测可能导致问题出现的原因。只有在平时多积累，不轻易放过任何一个现象中存在的疑问，才能在真正出现问题时，体现价值与能力。