1. 前言
IPSec与SSL均是当今应用广泛的VPN技术，两者都属于网络安全技术，都用于保护数据在网络上的安全传输。两者工作原理相似，但IPSec与SSL工作层级不同，协议交互对称性不同，认证对象侧重不同，访问控制粒度不同，应用场景也不同。
2. 两者的发展史
IPSec与SSL技术的起源都很早，均起源于上世纪90年代。IPSec与SSL携手见证并护航着IP互联网技术的发展。
直至今日，IPSec的IKE协议已两个国际标准版本：IKEv1、IKEv2。国密方面，由国家标准化管理委员会提出由国家密码管理局批准的我国自主制定的IPSec行业标准——《GM-T 0022-2014 IPsec VPN技术规范》于2014年发布，即IKEv1.1。近期国家标准化管理委员会正在将国密IPSec规范升级为国标。
SSL的发展历程更加丰富，国际标准方面，先后经历了SSL1.0、SSL2.0、SSL3.0、TLS1.0、TLS1.1、TLS1.2、TLS1.3，并推出UDP版本的DTLS1.0（基于TLS1.1）、DTLS1.2（基于TLS1.2）、DTLS1.3（基于TLS1.3）。国密方面，国家密码管理局也于2014年发布我国自主制定的SSL行业标准《GM-T0024-2014 SSL VPN技术规范》，并且，国家标准化管了理委员会已于2020年将其标准化为国标GB/T 38636-2020——《信息安全技术 传输层密码协议（TLCP）》。
3. 两者的共同点
- IPSec与SSL均是在不可信的网络通路上通过双方握手协商以建立可信的通信通路，业务数据便在其建立的可信通信通路内加密传送。
- 均能提供认证、加密、数据完整性和可靠性等安全服务。
- 密钥协商的机理相近，国际标准的IPSec与SSL均是以基于DH交换协议作为密钥交换的基础，国密标准的IPSec与SSL则均是以数字信封作为密钥交换的基础。
- 均支持多种认证机制，如基于数字证书的认证、基于预共享密钥的认证等（国密标准不支持预共享密钥认证）
- 均采用对称加密加HMAC认证的方式保障数据安全，即数据封装方式均是采用密钥协商出的对称加密密钥对报文进行对称加密，再采用密钥协商出的认证密钥对加密后的报文进行HMAC计算。
- 均支持多种加密算法与认证算法。
- 均非独立标准，均是由一系列协议支撑。
4. 两者的差异
4.1 作用层级不同
IPSec作用于网络层；
SSL作用于应用层。
4.2 协议对称性不同
IPSec是典型的对称隧道技术，协商两端角色是平等的；
SSL最初设计是为WEB应用服务的，SSL是典型的非对称隧道技术，有典型的客户端服务端之分。
4.3 认证对象侧重不同
IPSec与SSL都对业务数据进行加密传递，但在隧道建立过程中，IPSec与SSL认证的侧重是不同的。
IPSec有很强的连接设备合法性认证能力；SSL有很强的用户合法性认证能力。
换言之，IPSec能很好地识别协商两端的路由器/网关/防火墙等设备是否合法；SSL能很好地识别使用的人是否取得授权。
4.4 访问控制粒度不同
IPSec工作在IP层，访问控制粒度通常只能做到IP层与TCP层，换言之只能通过原始报文的IP头与UDP/TCP头中信息进行访问控制。
SSL工作在应用层，有很好的会话管理能力，除了IPSec能达到的访问控制效果外，还能基于应用层协议细节进行访问控制。不仅如此，SSL还能做到不同用户与不同资源间的映射管理。
4.5 应用场景不同
IPSec与SSL的作用层级差异、协议对称性差异、认证对象差异、访问策略控制粒度差异，决定着两者的应用场景不同。
IPSec多用于net2net的通信场景；
SSL多用于client2net的通信场景。
4.5.1 IPSec应用场景
-
IPSec典型应用场景之一--企业各地分支机构直接互联
在SDWAN诞生之前，此场景是大型公司各分支机构之间互联最常见的场景。对于企业总部或是较大的分支机构（拥有固定公网出口IP）间可以full-mesh组网方式网状互联；对于较小的分支机构（无固定公网出口IP）间的互联需要通过企业总部或关键IDC节点以hub-spoke组网方式星状互联。路由器间直接打通IPSec隧道。
-
IPSec典型应用场景之二--企业各地分支机构SDWAN互联
SDWAN诞生后，企业所有机构间均通过SDWAN网络互联。各分支机构（无论是企业总部、大型分支机构、小型分支机构、或者放于云内的资源）间不再IPSec直连，而是各分支机构各自与POP间IPSec打通，再由POP为各分支机构间转发流量。这种组网方式已成为当今主流。
值得一提的是，若企业有资源放置于云内，但当云产商并未提供云上VPN网关时，可以在云内云主机里部署VCPE来打通SDWAN。VCPE与CPE的组网方式并无差异，仅仅是虚拟机部署与物理机部署的差别。
-
IPSec典型应用场景之三--IPSec入云
当企业有业务部署在云内时，企业本地网络的出口路由器与云上IPSec网关间可以直接通过IPSec隧道打通，企业本地网络与云内网络便可安全通信。
-
IPSec可行但不典型场景--IPSec远程接入
移动终端远程接入并非是SSLVPN的专属能力，有多种途径都可以做到移动终端对企业本地IDC网络的安全通信。除SSLVPN外，IPSec协议同样可以，l2tp over IPSec、wireguard也可以。
Windows系统、iOS系统、Android系统均有系统自带的IPSec协议栈，十年前红极一时的The greenbow便是直接安装在windows终端上的IPSec客户端。
IPSec协议是L3协议，具有强大的网络层安全保护能力，能对隧道两端的设备有强有力的认证能力，但IPSec对此设备上承载用户认证却很弱，尽管IKEv1有扩展协议XAUTH与MODCFG支撑，IKEv2在设计之初也将EAP标准化，但相对于SSLVPN强大的用户认证能力，IPSec还是弱了些。l2tp over IPSec协议可以借助l2tp协议弥补IKE用户认证能力不足的问题，但现在l2tp用在终端设备上已经非常少见了。因此，在网络建设上，不建议使用IPSec做远程接入使用。
MOBIKE设计之初是为了填补IKE在移动接入方面的不足，但相比于SSL的远程接入能力，仍无法比拟。
4.5.2 SSL应用场景
SSL是CS模型隧道技术，多用于client2net的通信，其典型应用场景如下：
-
SSL典型应用场景之一--HTTPS
HTTPS是SSL最原始也是应用最广泛的应用。HTTPS协议是HTTP加上TLS/SSL协议构建的可进行加密传输、身份认证的网络协议，实现对HTTP的传输安全保护。移动终端浏览器内嵌SSL客户端，WEB服务内嵌SSL服务端。
这种场景是移动终端浏览器与WEB服务器间端到端直接通信，不需要SSLVPN网关参与通信。
-
SSL典型应用场景之二：移动接入
移动终端远程接入是SSLVPN最典型也是使用很多的场景。无论IDC网络是企业本地网络还是云上网络，通信模型都是一致的，即移动终端与SSLVPN网关间建立SSLVPN隧道，再由SSLVPN网关与后端网络通信。
SSLVPN移动接入的场景又可细化成如下三类。
- WEB反向代理
在互联网初期，web反向代理在SSLVPN应用中很常见。企业内网的web服务器不对外暴露，企业只暴露SSLVPN网关地址。SSLVPN网关起代理服务器作用。移动客户端想访问web服务器的资源时，移动客户端并非直接与web服务器间建立HTTP会话，而是与SSLVPN网关间建立。SSLVPN一方面终结移动客户端的HTTP连接，另一方面，再以HTTP客户端的身份与提供web服务的服务器建连。
这种方式需要SSLVPN网关对后端WEB服务做深入绑定，可在nginx基础上做定制开发。
- TCP协议代理
TCP协议代理与WEB反向代理作用原理比较相似，但TCP协议代理需要SSLVPN网关深入理解WEB业务，会更加友好。再者，如若企业想对外暴露的业务不单只有web服务一种，还想提供多种业务，例如SSH服务，即移动客户端想远程SSH访问企业内部的某个服务，这种场景下，TCP协议代理便派上用场。
SSLVPN TCP协议代理的业务流转发非常类似SSL协议与SOCKS5协议的叠加。移动客户端与SSLVPN网关间建SSLVPN隧道，移动客户端在与SSLVPN网关的业务报文里携带需要代理的协议类型。SSLVPN网关再以客户端的身份于内网与业务服务器间建连。
- 隧道封装
SSLVPN隧道技术是当今零信任最为常用的技术手段之一。
隧道技术有两个主要特点：
- SSLVPN隧道是TCPinIP / UDPinIP技术，移动终端到目标IDC网络通信的整个IP报文被封装到SSLVPN隧道内，外层可以是TLS协议封装也可以是DTLS协议封装。
- SSLVPN客户端子网地址与IDC网络地址需统筹规划，且IDC网络需要有到SSLVPN客户端虚拟子网地址的回程路由，即上图所示IDC网络需要有到168.1.0/24网段的回程路由。
-
SSL可行但不典型场景
SSLVPN也有隧道能力，也能像IPSec隧道那样在两个子网间建桥梁隧道，但是SSL协议的IP层的灵活性不如IPSec。因此net2net的场景仍是IPSec的主场。
5. IPSec与SSL组成最佳拍档
从前文可以看出，IPSec与SSL应用场景虽有重叠但各有优势。在net2net场景下IPSec更有优势，client2net场景下SSL更有优势，因此，IPSec与SSL可以完美组合在一起使用。
一段话总结：但凡net2net的访问通路，交给IPSecVPN；但凡移动终端接入的访问通路，交给SSLVPN。但凡侧重于网络间的打通，交给IPSecVPN；但凡侧重于用户对资源的访问控制，交给SSLVPN。
