OpenVPN TLS Error: TLS handshake failed

本文介绍了一种因TCP MSS设置引起的OpenVPN TLS握手失败的问题及其修改方案。

问题现象

测试环境

• 云服务器作为OpenVPN服务端，Ubuntu 18.04
• 内网服务器作为OpenVPN客户端，Centos 7.6

问题描述

内网服务器连接OpenVPN失败，查看服务端日志发现，TLS Error: TLS handshake failed。

Wed Dec  8 11:51:00 2021 us=147698 TCP connection established with [AF_INET]222.90.82.114:48051
Wed Dec  8 11:51:00 2021 us=147751 TCPv4_SERVER link local: (not bound)
Wed Dec  8 11:51:00 2021 us=147810 TCPv4_SERVER link remote: [AF_INET]222.90.82.114:48051
RWed Dec  8 11:51:01 2021 us=116217 222.90.82.114:48051 TLS: Initial packet from [AF_INET]222.90.82.114:48051, sid=e97fa061 75ff23e8
WRRWWWRRWWWWWed Dec  8 11:52:00 2021 us=81118 222.90.82.114:48051 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Dec  8 11:52:00 2021 us=81352 222.90.82.114:48051 TLS Error: TLS handshake failed
Wed Dec  8 11:52:00 2021 us=81508 222.90.82.114:48051 Fatal TLS error (check_tls_errors_co), restarting
Wed Dec  8 11:52:00 2021 us=81569 222.90.82.114:48051 SIGUSR1[soft,tls-error] received, client-instance restarting
Wed Dec  8 11:52:00 2021 us=81644 TCP/UDP: Closing socket

定位分析

分别在服务端和客户端启动抓包程序。客户端抓包如下，可见22号包后续一直在重传：

服务端抓包如下，未见客户端发出的22号包：

对比报文发现，客户端发送的22号后面在重传，服务端未收到，一段时间后OpenVPN认定超时，发送RST断开连接。

报文分析

该连接上其他报文能正常送达，证明网络相通，唯独22号包丢失。观察该包的特点，发现其长度为1514，猜测可能是由于超过了路径中MTU，中间网络设备丢弃了该报文。

MSS

解决验证

该报文中存在tcp选项，则tcp头的长度超过了20。故修改内网出口路由器tcp mss为1440，VPN通道建立成功。

[AR1-Dialer0]d this
#
interface Dialer0
...
 tcp mss 1440
 nat outbound
#
return

路由器tcp mss设置

总结

• tcp mss设置不正确可能会引起TLS握手失败；
• tcp mss的设置可通过 更改路由器mss 或者 修改iptables 。操作方法网上有大量文章，这里不再赘述。