openvpn

修改 OpenVPN 实现加密算法的自动协商

另一篇博中的分析可知,OpenVPN 中有两个加解密通道。一条是标准的 SSL 协议通道,被 OpenVPN 用于协商自己所用的密钥。这个通道的加密算法当然也是通过 SSL 协议来进行协商的,可以通过 --tls-cipher 选项来进行配置。另一条是 OpenVPN 自己的加解密通道,用于交换实际的数据,也就是虚拟网卡抓到的 IP 报文。这个通道的加密算法则是通过 --cipher--auth 两个选项,分别在通调两端指定的。

对于第二条通道的加密算法,必须要同时在两端分别指定一致的选项,有时候不是很方便(当然,我研究的还是 2.1.1 版本的 OpenVPN ,不知道最新的版本还是不是这样)。比如说,我想通过在服务端修改配置,指定加密算法,然后让连接我的客户端自动用同一个算法。最简单的修改思路,就是借用第一条通道中的算法协商机制,从 SSL 对象中取得协商出来的算法。

OpenVPN 的并发测试方法

由于 OpenVPN 本身协议的特殊性,用一般的方法不太好测它的并发。看过 LoadRunner ,但也最多只支持标准的 SSL/TLS 协议(当然,我也没细看这个)。于是动手改了其客户端的实现,最终完成任务。

其实阻止我们在一台机器上同时跑很多 OpenVPN 客户端的因素就只有虚拟网卡一个。貌似装十个左右的虚拟网卡驱动之后,机器就不行了。于是解决办法也很简单,把虚拟网卡相关的功能跳过就可以了。根据上篇的说明,只要在 incoming_push_message() 函数中,把对 do_up() 的调用直接换成 initialization_sequence_completed() 就 OK 了。

OpenVPN 的初始化过程分析

题外话:Eclipse CDT 很给力,至少在我用起来,比 gVim + Cscope 或者 SourceInsight 要来得给力,推荐一下。

更准确的来说,是 OpenVPN 的客户端与服务端之间,从协商密钥、到推送配置,以及最后的网卡与路由配置生效,开始进行 IP 报文的传递,这整个的过程。

完了。嗯,整个过程就像上面说的,这几个步骤而已。

不过重点当然还是代码啦。以前一直以为 OpenVPN 的点对点模式下,两端会进行一个决定谁是客户端,谁是服务端的协商过程,一直都想知道是怎么做的。后来才知道,原来通过配置信息,就已经决定好这个了。当然,我下面说的是客户端-服务器模式。

OpenVPN 的握手协议分析

又是好久没来这儿了啊。

最近因为工作需要(其实也没需要那么多),一直在断断续续地看 OpenVPN 的代码,终于大概搞清楚了它的握手是怎么个流程了。简单来说的话其实非常的简单,首先在 reliable 模块中实现了一个可靠的 UDP 报文协议,就是加上超时重传和确认报文的功能;然后用该协议交换一个 Hard Reset 命令,开始握手;最后建立 SSL 对象,并且通过内存 BIO 在可靠 UDP 协议的基础上转发 OpenSSL 的握手协议报文,通过这个 SSL 连接交换 OpenVPN 自己的密钥。接下来就是用这些密钥,该干嘛干嘛了。