IPSecVPN和OpenVPN-IPSec平反

一直以来汗牛充栋的文章和资料都在大谈特谈OpenVPN或者其它的使用SSL协议的SSLVPN多么的好，多么的比IPSec灵活，这使得IPSec渐渐淡出了普通人民的视线，成了核心网以及超高端设备的专用VPN。
如果要开发一个VPN产品，OpenVPN就好像一个各地百脑汇商场外面站立的那些拉客人员一样，把大家纷纷引来，而IPSec就像淮海路奢侈品专卖店一样，以高端，花费大，维护难等总之不是什么好听的话为理由而被拒绝。本文从最基本的几点来说明IPSec并不是那么的笨拙，很多灵活性是诸如OpenVPN之类的草根VPN所无法做到的。

1.IPSec由各种构件组成

IPSec并不是一个整体的结构，IPSec是由一整套的构件所构成的，这些构件部分是可以替换的，这些构件包括：
安全通道支持协议：IKE，ISAKMP...
可以使用不同的认证方式进行接入节点的认证。虽然无法直接使用被WEB用疯了的SSL协议，但是IKE并不比它差，此时我们完全没有必要用SSL协议在WEB领域的表现来为之加分，因为我们现在讨论的是VPN，而VPN是一个二层或者三层的概念，和WEB风马牛不相及。SSL使用了PKI核心，IKE也可以使用这些PKI组件，实际上基于X.509的认证方式在IKE中早已成了一个重要的组成部分。
隧道加密方式：传输ESP，隧道ESP，传输AH，隧道AH
传输模式的IPSec为端到端控制提供了很好的支持，这种模式下，IPSec除了加密或者认证之外并不对数据包进行任何封装，而隧道模式则为站到站的数据保护提供了很好的支持。而OpenVPN只是一个隧道模式，它是无条件封装的，端到端的可扩展性很差，比如OpenVPN面对强主机模式的Windows且还要认证源IP时就会心有余而力不足。
数据结构：SPD，SADB
这些数据结构是IPSec进行加密抉择时使用的重要证据，类似OpenVPN的路由表，OpenVPN只能以标准路由的方式将加密数据进行识别，如果要想通过的别的方式，必须在路由的前端增加其它识别方式，比如对于Liunx则需要在PREROUTING这个HOOK上为数据包打mark，然后将特定mark的数据包定向到某一个策略路由表，最终还是统一到路由。而IPSec的这些数据结构独立于IPSec加密以及秘要协商，可以以任何方式生成，并且可以以任何方式分发到任何设备，对于实现也更灵活，可以针对匹配数据库的包直接进行IPSec操作，这无疑提高了效率，也可以和其它的协议栈组件进行接口，见下节。
和其它协议栈构件的接口：和GRE的接口，和VTI的接口
如果你觉得OpenVPN使用统一的路由接口截获感兴趣包是一大优势的话(说实话，我也一直都这么认为，然而当你面对几百条隧道的时候，你可真的要晚上睡不着觉了，而我虽然还没有面对，却已经有临危的感觉了)，那也只是面对小型网络，如果面对成百上千的网段的话，更可恶的是这些网段路由还不能汇聚的情况下，路由就不妥了，不考虑路由表庞大的问题(如今高速硬件足以面对这种境况)，单单考虑维护人员的工作量就够你喝一壶的了。不管怎样，路由的方式是网管最熟悉的方式，有多种方式配置路由表，如果能将路由配置的灵活性和路由管理的便捷性结合的话就能克服OpenVPN的上述缺点，幸运的是IPSec和GRE结合就可以做到这一点。GRE是另一种技术，可以把路由管理的工作交给GRE来完成，IPSec只完成安全策略的维护即可，这是OpenVPN所做不到的。
以上如此丰富的可替换构件足以证明IPSec足够灵活，可以组织成各种复杂的VPN拓扑从而满足各种需求。OpenVPN的非组件化使得OpenVPN只能依赖其自身的特性，对外的接口充其量也就是一些事件接口，IPSec自身本来就是组件化的。

2.IPSec动态建立隧道，OpenVPN则不行

众所周知的一个特性就是IPSec可以动态建立隧道，数据包到来，如果发现隧道还没有建立好，则需要进行IKE协商，协商完成之前，所有的数据都要排队或者队列满后被丢弃，这是OpenVPN所做不到的，OpenVPN使用用户态的socket连接来建立隧道，对于隧道客户端，虚拟网卡和路由依赖于socket连接的建立，即使通过修改OpenVPN代码做到虚拟网卡在socket连接建立之前建立，也无法获知其IP地址从而建立路由表，对于服务端，所有的socket连接在OpenVPN的打开文件描述符中被维护，数据包路由到虚拟网卡后并不知道某条特定隧道是否可用，因此数据包会进入一个黑洞。
IPSec可以动态建立隧道，这是因为隧道的建立以及安全策略并不依赖任何socket连接或者其它网络连接，隧道状态和策略存在与否并不联动，一切都是SADB和PDB决定的，这些数据库和网络没有关系，数据包只要匹配到数据库中的条目，就会被加密，在被加密前需要懒惰建立隧道，如果隧道没有建立，那么就需要先进性IKE协商。

3.IPSec可以很灵活的实现高可用性和负载均衡

OpenVPN实现热备是很麻烦的，实现负载均衡几乎是不可能的，除非分割网段，然而这些对于IPSec却是小菜一碟，一切尽在SADB和PDB，这些纯数据可以被传输，可以同步到任何一台机器上，因此任何一台机器都可以接管当前的IPSec而无需面对用户断线的困扰。OpenVPN是无法进行数据同步的，因为这些数据是和进程高度相关的，而进程的数据字段又是不能跨越机器的，除非深拷贝所有的数据，然而跨机器深拷贝进程本身就是一个极富挑战性的工作。

4.IPSec并不是穿越不了NAT

网络的本质就是某种封装，隧道是一个同再层封装或者上层逆封装，数据其实可以被任意的封装。IPSec之所以无法穿越NAT是因为四层校验伪头的问题，如果将所有数据进行再封装，则完全可以绕开这个问题，因此我们可以使用UDP隧道，该UDP隧道对数据不进行校验(UDP可以选择不校验)，一旦检测到两个VPN节点之间有NAT，则两个节点在传输隧道数据时使用不校验的UDP将数据再次封装(其实检验也没有问题，这主要是为了效率)，数据流的5元组信息全部在IKE协商阶段确定，唯一需要注意的是，NAT后面的VPN节点一定要作为IKE的发起方，否则就需要面对UDO打洞的问题了。IKE建立之后，得到各自的5元组，然后偷梁换柱，将此五元组用来封装UDP数据即可。(本节的前置知识：IKE使用UDP进行协商)。

5.IPSec和GRE的合力其实就是OpenVPN

你会发现，IPSec和GRE合起来就是OpenVPN，只是它在内核态实现。GRE建立一个虚拟的网卡，通过路由将感兴趣包路由到该虚拟网卡，然后在该虚拟网卡上应用IPSec策略，所有从该网卡传输的数据都要被加密，所有从该网卡接收的数据都要被解密，这难道不就是OpenVPN的思想吗？IPSec虽然在配置上是对等的，实际上还是有一个发起者，数据通信没有一个发起者能行吗？？

6.解困

从操作系统概念和系统维护的角度，能在用户态实现的就不在内核态实现，这是因为用户态的API远比内核态的更加统一，举一个最简单的例子，各种操作系统都实现了伯克利套接字，且接口一致，可是在操作系统内核层面，各家实现却是大相径庭。这也许就是OpenVPN比IPSec更有优势的原因。然而从软件工程上考虑，IPSec的可替换组建化设计更符合软件工程的高内聚低耦合的原则，难道仅仅因为可怖的操作系统内核协议栈的复杂性就抛弃它吗？真心希望用户态的协议栈实现。具有讽刺意义的是，很多嵌入式系统，其协议栈真的就是在用户态实现的，有的嵌入式系统根本就不区分内核态和用户态，这种系统下OpenVPN和IPSec孰优孰劣呢？

注：全互联和星型拓扑结合-OpenVPN的优势