以下内容来自cnblogs博客园, 作者ksiwnhiwhs
https://www.cnblogs.com/ksiwnhiwhs/p/10160580.html

3.OρenＶΡＮ协议

3.1.OρenＶΡＮ协议总揽

OρenＶΡＮ协议的封装格式如下图所示：

注意，正是ＯＶΡＮ头封装了OρenＶΡＮ的握手协议和记录协议，它起到了复用和解复用的功能，按信道划分，OρenＶΡＮ的信道有两类，一类是控制信道，另一类是数据信道，其中的操作码在该层协议上有“地址”的含义，正是操作码区分了控制信道和数据信道-换句话说就是控制协议和记录协议，其中控制协议分为握手协议和密钥协议，类似IP协议的IP地址，TCP/UDP的端口。操作码的含义如下：
P_CONTROL_HARD_RESET_CLIENT_V1：Key method 1, initial key from client, forget previous state.
P_CONTROL_HARD_RESET_SERVER_V1：Key method 2, initial key from server, forget previous state.
P_CONTROL_SOFT_RESET_V1：New key
P_CONTROL_V1：Control channel packet (usually TLS ciphertext).
P_ACK_V1：Acknowledgement for P_CONTROL packets received.
P_DATA_V1：Data channel packet containing actual tunnel data ciphertext.
P_CONTROL_HARD_RESET_CLIENT_V2：Key method 2, initial key from client, forget previous state.
P_CONTROL_HARD_RESET_SERVER_V2：Key method 2, initial key from server, forget previous state.
我们可以将上述的每一个操作码看做是一个子协议。KEY ID的作用很有意思，它表示一个key集合，OρenＶΡＮ中一共有3个key集合，想了解其中要旨需要再稍等片刻。

3.2.OρenＶΡＮ记录协议

OρenＶΡＮ记录格式如下图所示：

其中HMAC用于认证包的完整性，IV用于CBC解密，Packet ID用于防止重放，OρenＶΡＮ记录协议包含了一个非常简易的滑动窗口机制用于防止重放。通过和SSL记录协议做对比，我们发现它们真的很像，只不过SSL记录协议的下面是复杂的TCP协议，而OρenＶΡＮ记录协议下面首选的却是UDP协议。
可以看到，OρenＶΡＮ记录协议并不是ACK的相关信息，因此它封装的是一个“尽力而为”的网络。

3.3.OρenＶΡＮ控制协议

这个协议包含了两个部分，第一部分是握手协议，第二部分是密钥协议。由于OρenＶΡＮ使用SSL握手协议，为何不使用SSL握手协议最终协商出来的那个对称密钥，这是一个值得思考的问题。这里给出一些思路：
a.IPSec所使用的IKE两阶段模式无疑对所有ＶΡＮ几乎都有很大的影响，第一阶段构建的安全通道用于第二阶段的密钥协商而不是最终的数据传输；
b.SSL握手最终协商的那个密钥和SSL握手过程是分不开的，而OρenＶΡＮ最终的设计是希望将握手过程和数据传输过程完全分离，从而独立的实现单一的密钥重协商；
c.这样实现的OρenＶΡＮ协议更加简洁。
我们看一下OρenＶΡＮ的控制协议：

这里面最重要的恐怕要算ACK buffer了，由于SSL握手协议需要一个可靠的下层，因此需要确认机制，值得注意的是，不要一说确认就是TCP，UDP也可以实现的，只是这里的UDP实现的重传机制很简陋，确认机制也很简陋。另外还有一点值得注意，那就是OρenＶΡＮ只在控制协议中使用可靠机制的协议，在记录协议中是不使用的。
没有必要浪费太多的时间在OρenＶΡＮ的握手协议上，它仅仅是对SSL握手的一个封装而已，最终协商出一个加密的安全通道，密钥协议将运行于其上，实际上密钥协议的载荷也是封装在OρenＶΡＮ的控制协议头里面的。
接下来，我们来看一下OρenＶΡＮ的密钥交换/协商/管理协议

3.4.OρenＶΡＮ控制协议之-密钥协议

OρenＶΡＮ自己实现了密钥管理，密钥交换，密钥重协商等，需要注意的是，它并不使用SSL握手最终确定的那些密钥，OρenＶΡＮ使用SSL握手仅仅是完成了连接者身份认证以及为后续的密钥管理，密钥交换，密钥交换以及控制信道构建一个安全的加密通道，完全类似于IKE的第一阶段协商。
值得说明的是，虽然不断开SSL连接就可以重新协商密钥，也就是仅进行第二阶段，然而当前的OρenＶΡＮ实现中，reneg选项实现的是两个阶段同时重新协商，也就是说SSL握手也要重新进行。由于SSL的BIO直接接于一个内存BIO上，因此断开SSL连接并不意味着底层的传输层连接断开，OρenＶΡＮ实现了数据通道和控制通道的复用，因此任何通道都不是真正的物理通道，都是虚拟的，重新协商任何参数都不需要断开连接。在重新协商安全参数的时候，丝毫不影响数据通道的正常传输。
目前OρenＶΡＮ实现了两类密钥交换的方法，第一类比较简单，相当于直接告诉对方解密密钥了，虽然这样，依然很安全，因为这里的“告诉”并不是明文告知，而是在SSL握手后的加密通道中告知的，它的消息格式如下：

通过消息格式可知，一对连接中，一共需要4个密钥，一个方向2个，这也TM太像IPSec的SA了啊！
第二类方式稍微复杂一些，然而它又很像SSL握手协议中的密钥交换方法，使用了一个pre master的密钥，然后两方分别进行计算，最终算出相同的密钥。第二类密钥交换的数据格式如下：

最终，一个密钥导出函数计算出最终的密钥，关于密钥导出函数的细节，请google，或者Email给我，要是我不知道，我们一起学习。从第二类方式的消息格式中可以看出，pre-master的使用方式和标准的SSL握手中最终的密钥协商的方式一样，只不过SSL握手中这个pre-master是用server端的公钥加密的，而这里的pre-master直接使用SSL握手确定的对称密钥加密。第一类方式很像IPSec的SA，第二类方式很像SSL握手中的密钥协商，可见OρenＶΡＮ真的站在了巨人肩上啊。
最后，有个KEY ID十分奇妙，它的作用就是密钥更新时的平滑过渡。OρenＶΡＮ一共定义了3组密钥集合，其中只有一组是当前活动的，然而在新的活动密钥没有生效之前，还是可以用老的。值得再次强调的是，重新协商并不断开任何连接，虽然重新初始化了SSL，但是记住，SSL只是一个过滤，和Socket没有关系的，它可以用于任何管道性质的文件描述符之间的安全通道协商，在OρenＶΡＮ的场景下，重新协商SSL时，底层的UDP连接仍然没有断开(这里所说的UDP连接，是因为UDP之上实现了一个Reliability Layer)，只要OρenＶΡＮ客户端连上服务器，它就不会再因为重新协商而主动断开，除非协商失败，比如证书已经被吊销等。

3.5.OρenＶΡＮ协议总结

现在总结一下OρenＶΡＮ的协议。
它真的很复杂，我们先看一幅可以表示OρenＶΡＮ协议总体设计的图，我并没有按照传统的网络协议按照控制面和用户面来画图，那样太抽象，我选择的方式是直接的方式：

通过这幅图我们再来温习一下OρenＶΡＮ协议的设计。如图所示，虽然协议分了好几部分，每一个部分又分若干层次，然而它们在横向上是有联系的。从设计上说，首先是安全认证和第一阶段的握手，这和IKE一致，第一阶段握手为第二阶段密钥协商提供了安全通道，然后第二阶段最终协商出了加密/MAC密钥。从此记录协议和控制协议分离，直到再次协商。这是OρenＶΡＮ协议的第一个要点：分层次，分阶段。
OρenＶΡＮ协议的第二个要点就是多路复用到UDP。这样就不必为SSL协商之类的控制面专门设置一个通道，OρenＶΡＮ巧妙使用OρenSSL的BIO机制劫持了SSL握手包，实现了对其的封装，这样所有的协议都可以复用了一个UDP“连接”上，因此重新协商密钥的时候，数据传输不会停止。
OρenＶΡＮ的第三个要素有点历史原因，OρenＶΡＮ完全可以使用SSL记录协议来完成最终的数据加密，然而却面对着TCP重传叠加的问题，当时DTLS还没有出现，然而SSL握手实在太好了，因此OρenＶΡＮ做出了一个漂亮的折中，实现了协议的重新封装，保留了SSL握手，重新实现了“尽力而为”的记录协议。这样做的结果是，OρenＶΡＮ可以在本来已经很安全的SSL握手协商上又做了一层封装，可以实现比如tls-auth的功能，对TLS/SSL握手消息本身进行完整性验证，这样就预防了Dos攻击，消耗掉服务器的资源(SSL连接的处理很消耗资源，即使不消耗什么内存，消耗CPU是巨大的)...同时，大量显式的SSL连接也不复存在，再者，由于密钥交换和SSL握手彻底分离，这样可以实现更多的选择，比如可以配置cipher为none，然而SSL握手还是安全的，或者说仅仅提供数据的HMAC验证，此时SSL握手以及后面的HMAC密钥协商依然是安全的...要知道，SSL握手的结果永远都是协商出一条安全加密的通道，你在这通道上作甚，你自己配置，这就是分离的好处。

3.6.使用BIO封装SSL握手消息
这一点实际上并不是特别的重要，因为它是实现相关的，要不是OρenＶΡＮ使用了OρenSSL这个开源的SSL库或者OρenSSL中没有BIO，那OρenＶΡＮ还真得费点周折去思索如何得到SSL握手消息然后再封装成OρenＶΡＮ自己的控制消息。
BIO在这里我就不再深入介绍了，它很简单，就是一个堆栈式的IO部件，每一层都有一定的功能，比方说过滤，十分类似于Windows的IRP的概念，如果实在不懂，要么google，要么直接看OρenSSL的实现，但是千万别百度。为了说明如何使用BIO封装SSL握手消息，给出一幅图：

4.OρenＶΡＮ连接建立

OρenＶΡＮ连接的建立显得很诡异，不过本文看到此处，你就不觉得什么诡异了。如果不了解OρenＶΡＮ的协议设计，仅仅知道它使用了SSL握手的话，你会感到很费解，因为你用ssldump或者tcpdump抓取不到任何SSL握手的消息。实际上这很好解释，那就是SSL握手消息被OρenＶΡＮ的协议给封装了，上一小节讲述了如何封装SSL握手消息，使用OρenSSL的BIO可以很方便的做到这一点，实际上，OρenSSL本身将SSL类型的BIO设计成一个过滤型BIO，这才是精妙所在，这样SSL消息可以直接发往任何类型的IO实体了，而不一定必须是网络套接字了。
OρenＶΡＮ连接的建立大致分为4个阶段，每一个阶段完成不同的事情，如下图所示：

以上内容来自cnblogs博客园, 作者ksiwnhiwhs
https://www.cnblogs.com/ksiwnhiwhs/p/10160580.html