记录一次排查vpn无法通讯的过程
- One minute read - 93 words今天收到一个项目重构的需求，项目源码使用私有 gitlab 托管平台，但由于考虑安全原因，必须通过vpn软件才可以访问。公司用的vpn客户端是 Pritunl, 看了一下项目主页 https://github.com/pritunl/pritunl-client-electron，发现它是一个 OpenVPN 客户端，是基于Golang+Electron 框架开发的一个跨平台的客户端。
以前主要接触的是 wireGuard 和 openvpn 这两个项目，这个客户端还是第一次听说。不过后面发现使用这个客户端会经常出现DNS无法解析的情况，不清楚具体是什么原因引起的，因此不推荐这个客户端。另外从性能方面考虑openvpn也不是推荐方案，推荐优先考虑 wireGuard 这个项目，它的客户端也是跨平台的，而且性能要比openvpn好太多，代码也少很好，无论维护和开发成本都要低的多。个人有很长一段时间一直用wireGuard作为内网穿透方案，不过此方案需要一个公网IP地址，所以后期换成了更节约成本的解决方案，当然这是另一个话题了，不是本文要介绍的内容。
遇到问题
当在macOS上安装好客户端后，使用同事发给我的vpn配置文件，发现一直无法连接到vpn服务器。第一反映就是怀疑是配置文件有问题，但同事反馈一直这样用的，他也是第一次遇到这个情况，所以就排除了配置文件这个原因。
通过查看客户端也并未发现什么原因，一直在重试连接错误。
初步分析
由于以前做零信任网关时，对于网关客户端的流量拦截也是通过vpn这套机制来实现的，因此知道一般会在客户端机器创建一个 tap/tun 虚拟网卡。同时再创建一些路由规则，根据这些规则将需要代理的流量导入到创建的虚拟网卡。然后客户端再从虚拟网卡读取流量内容，然后通过 UDP 协议传到vpn服务端，最后服务端再解包重放从而进入到 vpn服务所在的内网，最终实现流量代理。
虚拟网卡
因此这里首先就要排查本机是否存在tap/tun虚拟网卡，奇怪的是竟然未发现任何虚拟网卡，为什么无法创建虚拟网卡呢？权限问题？正好本机安装有 Cloudflare WARP 这个软件，打开软件测试后，发现本机是可以正常创建 tun 虚拟网卡的，那这样就排除了权限问题了。
路由规则
上面说过vpn的原理，是通过虚拟网卡和路由来配合使用的，路由规则创建了没有？经排查路由规则也没有创建。
客户端版本
难道是客户端版本的原因？咨询了几个同事，版本有的相同，有的不同，但都可以正常连接服务器，并未出现此现象。
openvpn工作原理
由于一直无法找到原因，因此只能还是从vpn工作原理这块入手了。
前面我们知道了虚拟网卡和路由规则都没有创建，那问题会不会出现在前面的一些初始化步骤呢？要确认这一点，首先我们先看一下 openvpn的实现原理：
- 建立连接：OpenVPN 客户端与服务器之间首先建立一个 TCP 或 UDP 连接。这个连接可以是客户端主动发起，也可以是服务器响应客户端的请求。
- 身份验证：在连接建立之后，客户端需要通过提供用户名、密码或其他认证方式（如证书）向服务器进行身份验证，以确保连接的合法性。
- 密钥交换：通过使用密钥交换协议（如 TLS/SSL），客户端和服务器交换密钥，生成一个共享的对称密钥。这个密钥将用于后续的数据加密和解密过程，确保数据的机密性。
- 数据传输：一旦加密通道建立，客户端和服务器就可以在其中安全地传输数据。数据在发送前会被使用共享密钥进行加密，接收方在收到数据后会使用相同的密钥进行解密。
- 使用 TUN/TAP 虚拟网络设备：OpenVPN 利用操作系统内核中的虚拟网络设备 TUN/TAP 来转发数据。TUN 工作在网络层，负责 IP 数据包的传输；TAP 工作在数据链路层，负责以太网帧的传输。这些虚拟设备使得 OpenVPN 能够在用户空间处理网络数据。
- 配置路由：OpenVPN 服务器会为每个客户端分配一个虚拟 IP 地址，并配置相应的路由规则。这样，客户端就成为了虚拟网络的一部分，可以访问服务器所在网络的其他资源。
- 数据封装：OpenVPN 将网络层的数据封装在 VPN 数据包中，然后通过物理网络发送。在接收端，OpenVPN 将数据解封装，恢复原始数据包，然后通过虚拟网络设备发送给目标。
- 安全性：OpenVPN 支持多种加密算法（如 AES、DES、3DES 等），并提供了数据完整性检查和抗重放攻击的特性，增强了通信的安全性。
从VPN实现原理得知，我们上面排查的虚拟网卡和路由规则是步骤中的第5和第6步，现在我们只需要对前面这几步进行确认基本就可以找到原因了。
先看**“建立连接”** 这一步，当客户端启动后，会向openvpn服务器IP发送一个http连接，一般情况是向 https://openvpnserver:443 这个地址发送一个请求，后面可能会有一些客户端身份认证相关的信息，如个人证书等。通过查看同事给的 vpn 配置文件发现此ip的443端口并不通，因此这一步就直接失败了，同时导致后面虚拟网卡和路由规则也无法创建。
将分析原因告知负责这一块的同事，经排查确认确实是配置文件错误，原来昨天晚上这一块做了一些调整，有些地方未同步，至此问题彻底解决！
总结
虽然排查问题走了一点弯路，但最终分析方向是没有错误的，搞清楚 vpn 的实现原理才是分析问题的前提。