4)、FortiGate中后期客户端体验：

当然，有一个值得补充的发现，就是在翻阅FortiGate的在线手册时发现，FortiClient for IPSEC将登录步骤进行了简化，大概简化到只有2个UI，5个配置参数（参考 https://docs.fortinet.com/document/fortigate/6.0.0/cookbook/411062/configuring-forticlient ）：

相比系统内置IPSEC Client或The GreenBow Client有着较大简化，但相比SSL VPN仍显复杂。

在 RemoteAccessTech-002-VPN技术发展史浅析（上） 中我们提到，IPSec 共有3次重大历史变更，分别是：1995年8月-RFC 1825系列、1998年11月-RFC 2401系列、2005年12月-RFC 4301系列 。

正是因为IPSEC协议有较长的历史，事实上，在1995、1998年前两次变更中，均未很好地考虑到NAT场景。

1)、在2004年3月，RFC3715 (https://datatracker.ietf.org/doc/html/rfc3715 ) IPsec-Network Address Translation (NAT) Compatibility Requirements 中明确提出NAT兼容性问题需要解决。

2)、2005年1月，RFC 3947，Negotiation of NAT-Traversal in the IKE（ https://www.rfc-editor.org/rfc/rfc3947 ）和RFC 3948，UDP Encapsulation of IPsec ESP Packets ( https://www.rfc-editor.org/rfc/rfc3948 )中，专门提出了NAT穿越解决方案。

3)、2005年12月，RFC4301系列中的 RFC 4306,Internet Key Exchange (IKEv2) Protocol ( https://www.rfc-editor.org/rfc/rfc4306 ) ，包含并优化了NAT穿越实现机制。

NAT-T机制，解决了在绝大多数NAT环境下，IPSEC无法正常建立连接的问题，从不可用到主体可用。

然而，机制底层的设计缺陷所带来的NAT-T补丁，显然是难优雅、整洁地解决问题，容易引入关联故障，大规模用户如果基于此进行Point-to-Site连接的话，大抵上是每个企业的IT运维人员难以承受之重，这也同样成为了导致IPSEC在Point-to-Site场景下并未大规模使用的关键原因之一。

如下图，我们以华为AR1000路由器的IPSEC官方故障处理手册（ https://support.huawei.com/enterprise/zh/doc/EDOC1100118117#ZH-CN_CONCEPT_0210795148 ） 中和NAT有关的案例，也可以窥之一二。

毫无疑问，SSL VPN的核心应用场景是Point-to-Site终端远程接入场景，用于员工接入。

但是放到SSL VPN类别内，还有两种区分。

1)、SSL Portal VPN: 这是最初的SSL VPN，可称为7层SSL VPN。是可以通过纯浏览器、无需额外安装其他客户端(clientless)的方式访问web站点，通过SSL/TLS进行加密传输。

劣势：不支持非web协议，如RDP、SSH及其他本地CS客户端访问内网业务。

2)、SSL Tunnel VPN : 通过对4层TCP或3层IP包进行隧道转发，以支持RDP、SSH及其他CS客户端应用，按转发层次不同，分为4层(Layer 4)或3层(Layer 3)SSL VPN。

劣势：需要安装客户端，丢失了免客户端特性(clientless)。

从实际的演进中，在SSL VPN早期，以WEB化免客户端为主打价值,除了WEB(HTTP、HTTPS)的7层代理外，还会额外支持类似FTP/NFS/SMB代理,以实现文件共享需求；甚至还有基于可自动安装的浏览器的插件（如IE ActievX插件)来实现加密端口转发，从而使得CS资源也可访问(RDP、SSH等)。

到SSL VPN中后期，在Point-to-Site战场基本上大局抵定后，各厂商的SSL VPN实际也转变为了以Tunnel VPN为主打。

从基于浏览器的SSL Portal VPN，切换为基于客户端的SSL Tunnel VPN的这个变化，主要是几个因素:

1)、SSL Client下载安装体验被接受：SSL VPN支持在web portal页面下载并安装客户端，下载安装比IPSEC容易；下载后登录体验也比IPSEC VPN客户端简单。虽然丢失了免客户端(Clientless)特性，但是仍然可被接受。

2)、跨浏览器、非windows操作系统群雄并起，基于IE的ActievX插件方案受限：ActievX插件机制只能适应IE，兼容性不足。彼时浏览器持续大战，IE份额持续被Firefox/Opera/Chrome吞食，跨浏览器需求增多。多操作系统场景也不断增加(如Mac OS)，并非只使用windows。而ActiveX插件只支持IE，使用面越来越局限。即使过程中又有基于JAVA语言(JRE)的插件机制，但是支持也越来越受限，最终浏览器插件机制被淘汰。

3)、web资源兼容性差: web资源涉及到对web站点的URL改写，兼容性问题偏多，无法根本解决。更别说在2000年后的很长一段时间中，WEB站点经常使用ActiveX插件、Flash插件，使得纯WEB无法导致WEB资源兼容性更差。

注：具体web资源的相关技术在本系列后续篇幅中会进行讲解

依惯例，这里应当贴图讲一下SSL VPN的协议。

但是很不幸，SSL VPN自身是没有RFC标准的，这就意味着各大厂商会各显神通，协议自然千差万别。

当然SSL VPN顾名思义，是基于 SSL/TLS的VPN，而SSL/TLS是有RFC标准的,如 TLS 1.0(https://www.rfc-editor.org/rfc/rfc2246 )

SSL/TLS的协议握手、数据包在此就不再展开详述了，感兴趣的网络上搜索，还是蛮多资料的。

只简单补充：读者有时会搞不清SSL(Secure Socket Layer，安全套接字层) 和 TLS(Transport Layer Security，传输层安全协议) 的关系，实质上两者本为一体。SSL 3.0(1996年发布)是SSL系列的尾声，IETF在1999年发布了TLS 1.0的RFC2246标准，并从此开始持续迭代，截止2022年已经发布到了TLS 1.3(RFC8446， https://www.rfc-editor.org/rfc/rfc8446 )。

OPENVPN也是一种典型的SSL VPN，当前使用非常广泛。

OPENPVN只提供客户端(client)接入模式，所以属于Tunnel VPN。

OPENVPN最早在2002年发布了1.0版本，后续通过开源社区力量持续改进，2.0版本（ https://github.com/OpenVPN/openvpn ）至今已经发布了上百个版本迭代。甚至还基于C 11，重写了3.0版本(https://github.com/OpenVPN/openvpn3/)。

可以用于构建VPN隧道的协议还有不少，凡是可以用于代理访问 的协议，都具备此能力。比如说Socks5协议、FTP协议、甚至大家天天使用的HTTP(s)协议都可以用于 打通网络间代理隧道 ，既可以称之为“代理协议”，也属于隧道协议的一种。

当然，从使用场景上，相信使用过的读者会更倾向于称呼它为“代理协议”。

比如Internet Explorer浏览器，由于其历史久远、经历了很长时间的代理技术发展的大时代，IE的“代理设置”中，即可配置HTTP、HTTPS、FTP、Socks等多种协议的代理服务器，如下图：