背景

接到反馈所有 openvpn 客户端均无法连接，客户端的错误日志如下

服务端看到了如下的日志报错

5.45.79.116:61553 TLS Error: TLS handshake failed5.45.79.116:61553 Fatal TLS error (check_tls_errors_co), restarting5.45.79.116:61553 SIGUSR1[soft,tls-error] received, client-instance restarting

原因

默认的 ca 证书有效期为 3650 天，服务器证书为 825 天。查看服务器的 pki/issued 下的证书可看到已过期。

解决

1.已意识道问题是证书过期了，遂尝试续期证书

./easyrsa renew server nopass./easyrsa renew clientname nopass

2.续期完成后发现一直报告如下错误

3.重启了 openvpn 软件后仍然无法解决

4.备份相关文件后，尝试生成新证书，而后发现依然报告上述错误。

5.临时新开 ECS 解决客户的问题

6.继续研究，ChatGPT4 和文心均没有解决方案，直到在谷歌发现了如下的解决方案，而后直接重启(而后理解到也可以直接重启 tun 虚拟网卡)，发现 OpenVPN 恢复正常

经过上述的折腾，体会到 openvpn 其实是一个使用软件模拟出的 tun 虚拟网卡，它是一个网络层的设备，它用来操作和封装网络层的数据帧，直接重启 OpenVPN 并不能重启该虚拟网卡设备，当该虚拟网卡发生故障的时候也会导致 OpenVPN 解密失败，这个时候可以考虑重启该网卡或者是重启系统。

原理

特点

自 OpenVPN2.0 之后引入了用户名/口令组合的验证方式，在客户端可以省略掉客户端证书，但仍有一份服务器证书需要被用做加密。

TUN 与 TAP 模式

OpenVPN 的技术核心就是虚拟网卡，它是使用网络底层编程实现的一个驱动软件，会安装在 client 端和 server 上，

OpenVPN 中有两种工作模式，一种称为 TUN(tunnel)通道模式，我们的实验采用的就是 TUN 模式，另一种是 TAP 以太网桥的模式(不深入讨论此模式)。

TUN 模式是一种虚拟点对点的网络模式，它会在 client 端建立如下图所示的虚拟网卡，将通过该接口发送和接收 IP 数据包。

在 server 端建立一个 tun0 虚拟网卡，链路将会在 client 端和 server 端的虚拟网卡之间建立起来

证书之间的关系

根证书（Root CA Certificate）

根证书是一个信任的实体，用于签署其他证书。

在 OpenVPN 中，通常是用于签署服务器证书和客户端证书的根证书。根证书的私钥用于签署其他证书的公钥，确保其他证书的可信度。

服务器证书（Server Certificate）

服务器证书由根证书签署，用于证明 OpenVPN 服务器的身份。

包含服务器的公钥以及与之关联的一些信息，如服务器的主机名、IP 地址等。

客户端证书（Client Certificate）

客户端证书也由根证书签署，用于证明 OpenVPN 客户端的身份。

包含客户端的公钥以及与之关联的一些信息，如客户端的标识信息。

根证书私钥（Root CA Private Key）

根证书的私钥用于签署其他证书的公钥，是证书颁发机构（CA）的核心秘密。

Diffie-Hellman（DH）密钥

用于密钥交换，确保在 TLS 握手期间安全地生成共享密钥。

这些证书之间的关系建立了一个信任链：服务器和客户端证书都由根证书签署，建立了信任。

这确保了客户端连接到服务器时，它可以验证服务器的身份，并确保服务器的公钥是受信任的。

服务器和客户端都使用 Diffie-Hellman 密钥来协商共享密钥，用于保护通信的机密性和完整性。

在 OpenVPN 的配置中，这些证书和密钥通常会在服务器和客户端配置文件中指定，以建立安全的 TLS 连接。通过建立这样的信任链，OpenVPN 实现了安全、私密的通信。