windows7vpn配置-()

近段时间以来，收到反馈想让我讲讲接入技术的呼声一直很高，而且确实随着政策、疫情、攻防演练、业务发展、安全态势等多方面的影响，企业对于接入安全也越来越重视。

而安全业界而言，零信任理念近几年受多方加持越来越火热，不论各家的零信任如何包装粉饰，接入技术也是其无论如何也跳脱不开的基本线。

RemoteAccessTech系列不会讨论零信任理念本身，但是会尝试将远程接入技术拆开来尽量给大家讲清楚。

#27 RemoteAccessTech-Learning-001-从互联网边界接入说起

#28 RemoteAccessTech-Learning-002-VPN技术发展史（上）

书接上文：

如果将时间点放到今天，我们可以毫不犹豫作出如下说明：

1)、ipsec从问世至今，在Site-to-Site组网场景中，已经很好地证明了自身的价值。但是IPSEC在Point-to-Site场景中，实际应用并不广泛。

2)、那么在Point-to-Site场景中，当之无愧的VPN王者是谁呢？

答案是:SSL VPN，The King of Point-to-Site。

可参考：https://fr.wikipedia.org/wiki/SSL_VPN 上的定义，SSL VPN（安全套接字层虚拟专用网络）是一种在传输层安全性[1]（TLS）之上工作的VPN[2]，可通过Web浏览器[3]或重型客户端[4]（OpenVPN[5]，AnyConnect[6]）访问，允许https[7]登录。它允许用户使用正确的Web浏览器或客户端从任何计算机建立与Intranet[8]的安全连接。

简而言之，所有通过SSL协议进行加密传输的VPN即可称之为SSL VPN，这也是它显著有别于 GRE、IPSEC等VPN关键特征点。

最初的SSL VPN，其实是指纯web、免客户端(clientless)的VPN，其实现原理为HTTPS反向代理，主打是避免繁琐的客户端安装过程。

在清华大学出版社于2005年出版的《网络安全: 技术与实践(第1版)》一书中，曾如此描述SSL VPN：大多数SSL VPN都电脑是HTTP反向代理，这使得它们非常适合于具有web功能的应用，只要通过web浏览器即可访问。 如下图：

那么问题来了，IPSEC VPN设计之初，同时考虑了Site-to-Site和Point-to-Site两大场景。

但是IPSEC VPN缘何败走Point-to-Site呢？

如果将时间点放到今天，或许我们会很容易地基于IPSEC和SSL VPN的差异对比，给出一些原因，比如：

1)、相比IPSEC，SSL VPN支持良好的权限管理、支持良好的用户身份对接，可基于RBAC权限模型，实现细粒度、灵活的权限管理

2)、相比IPSEC，SSL VPN认证对接能力更多样、能力更强，体验更好，更适合于多种接入人员身份的不同安全要求和体验要求

3)、IPSEC在复杂网络环境下电脑，比如NAT环境适应性较差，而SSL VPN适用于各种复杂网络环境。

4)、IPSEC客户端安装复杂，体验差；而SSL和浏览器兼容较好，访问web时无需客户端，只有访问复杂CS应用时才需要下载客户端。

但很不幸的是，上述其实并不是真正的原因，这只是多年发展后的结果而已。

简单分析：

1)、IPSEC为什么不支持细粒度、灵活的权限管理？是因为Point-to-Site终端远程接入场景下，各厂商的IPSEC都已经躺平了，明确IPSEC主要用于Site-to-Site组网场景，用不着。并不是不能做，而是没有必要、没有动力去做。

2)、IPSEC为什么认证对接能力相比稍弱？和上面一条是同样的原因，Site-to-Site场景用不着太多样。

这就像是两个小车厂同时造客货两用的车（比如说面包车），随着两个车厂的多年发展，最后A车厂发展成了货车厂，服务于货运行业；B车厂发展成了小汽车厂，服务于家用。

然后现在对比，为什么货车不适用于家用出行？显然不适合，因为两者核心定位不同啊。

非不能也，实不为也。

这让人不禁感叹：懒惰的人类啊，我们如果不多加思考，就容易步入以果为因的陷阱。

那又是什么原因，导致IPSEC在Point-to-Site逐步走向躺平、不为，然后产生当前结果的呢？

以笔者浅见，大致有如下原因：

1)、早期阶段，体验有落差:标准的IPSEC 电脑 VPN可以通过操作系统内置的client进行接入，但配置步骤非常复杂。后续多数厂商会通过推送厂商独有的client来实现接入，但是安装体验仍然较差。

而SSL VPN主打的是WEB资源，以浏览器为端，实现无端(clientless)，所以早期入口抢占上，SSL VPN胜。

2)、IPSEC VPN基于IP层设计过于底层，修改不易且早期网络适应性差：由于IPSEC是基于IP层的VPN协议，过于底层，在早期协议设计上，对于NAT、多层NAT等环境均不适应，后续才慢慢补充NAT支持；另一方面，是IP层协议对底层网络设备依赖严重，修改协议相对困难

3)、IPSEC VPN受RFC强标准桎梏：上面提到，本身基于IP过于底层，修改困难；同时又受RFC强标准牵制，反应慢一拍，错过了黄金发展时期。

1)、使用windows 7内置IPSEC客户端的连接配置体验

可参考 https://service.tp-link.com.cn/detail_article_725.html ， 在windows7上配置，共需要超过9个UI界面，选择、配置超过10个。可以看出，内置ipsec client并非一个良好的连接体验。

2)、The GreenBow VPN Client的IPSEC连接配置体验

The GreenBow VPN Client是一个专门的VPN客户端，我们以它来看一下IPSEC VPN的典型客户端配置体验。

可参考：https://wiki.qno.tw/index.php?title=NAT%E4%B8%8B%E4%BD%BF%E7%94%A8the_greenbow_VPN%E8%BF%9E%E6%8E%A5QVM1250%E9%85%8D%E7%BD%AE%E6%8C%87%E5%8D%97&variant=zh-hans 或 https://www.thegreenbow.com/wp-content/uploads/2021/05/tgbvpn_cg-fortigate-vpn-series-zh.pdf ，可以看到如下几个配置界面。简单数一数，配置IPSEC接入，大概需要配置3个界面，超过10个界面参数，显然不是一个良好的用户体验。

3)、SSL VPN典型登录体验

对比SSL VPN，早期SSL VPN是纯web化的(clientless)，只需要输入登录地址，再输入用户名密码即可登录，相比之下，简单了不止一筹。

以下为Sangfor SSLVPN的早期登录界面截图：

以下为FortiGate的SSL VPN登录界面截图（可参考 https://blog.csdn.net/meigang2012/article/details/51441681 )：

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等多种协议的代理服务器，如下图：

部分参考：https://codeantenna.com/a/ejKQp2EO https://datatracker.ietf.org/doc/html/rfc1825 https://datatracker.ietf.org/doc/html/rfc2401 https://datatracker.ietf.org/doc/html/rfc4301 https://www.juniper.net/documentation/cn/zh/software/junos/standards/vpn-ipsec/topics/concept/ipsec-ike.html### https://www.barracuda.com/glossary/ssl-vpn https://www.fortinet.com/resources/cyberglossary/ssl-vpn https://en.wikipedia.org/wiki/ActiveX https://openvpn.net/faq/why-ssl-vpn/ https://docs.microsoft.com/zh-cn/troubleshoot/developer/browsers/connectivity-navigation/use-proxy-servers-with-ie

[1]Transport Layer Security: https://fr.wikipedia.org/wiki/Transport_Layer_Security

[2]Réseau privé virtuel: https://fr.wikipedia.org/wiki/R%C3%A9seau_priv%C3%A9_virtuel

[3]Navigateur web: https://fr.wikipedia.org/wiki/Navigateur_web

[4]Client lourd: https://fr.wikipedia.org/wiki/Client_lourd

[5]OpenVPN: https://fr.wikipedia.org/wiki/OpenVPN

[6]Cisco AnyConnect VPN Client: https://fr.wikipedia.org/wiki/Cisco_AnyConnect_VPN_Client

[7]Https: https://fr.wikipedia.org/wiki/Https

[8]Intranet: https://fr.wikipedia.org/wiki/Intranet

本文由 微信公众号文章同步助手 同步