windows7vpn配置 () #29 RemoteAccessTech-002-VPN技术发展史(下)1、篇首语

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

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

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


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

#28 RemoteAccessTech-Learning-002-VPN技术发展史(上)


书接上文

3.6、SSL VPN3.6.1、The King of Point-to-Site

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

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

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

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

3.6.2、什么是SSL VPN

可参考: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浏览器即可访问。 如下图:

3.6.3、IPSEC为何败走Point-to-Site

那么问题来了,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强标准牵制,反应慢一拍,错过了黄金发展时期。

3.6.3.1、IPSEC VPN的PC端连接配置体验展示

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仍显复杂。

3.6.3.2、IPSEC的网络适应局限性

在 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有关的案例,也可以窥之一二。

3.6.4、SSL VPN的应用场景

毫无疑问,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资源的相关技术在本系列后续篇幅中会进行讲解

3.6.5、 SSL VPN的协议简述

依惯例,这里应当贴图讲一下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 )。

3.6.5.1、OPENVPN(SSL Tunnel VPN)

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/)。

3.7、其他VPN隧道协议

可以用于构建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

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


电脑 电脑