#33 RemoteAccessTech-006-WEB资源-典型Layer7 VPN

#33 RemoteAccessTech-006-WEB资源-典型Layer7 VPN

0、篇首语

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

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

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

1)、RemoteAccessTech-001-从互联 边界接入说起

2)、RemoteAccessTech-002-VPN技术发展史浅析（上）

3)、RemoteAccessTech-002-VPN技术发展史浅析（下）

4)、RemoteAccessTech-003-理解隧道协议

5)、RemoteAccessTech-004-SDP也是一种SSL VPN？

6)、RemoteAccessTech-005-VPN隧道技术的核心流程

1、web资源历久弥新

在 RemoteAccessTech-002-VPN技术发展史浅析（下） 的第 3.6.4、SSL VPN的应用场景 中，我们曾提到过,SSL VPN分为 Portal VPN和Tunnel VPN两种，而SSL Portal VPN又是SSL VPN赖以起家的形态：

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

所以说，WEB资源可谓是SSL VPN的起家资源，带着历史的气息。

即使到了零信任SDP火爆之后，由于早期零信任践行者Google BeyondCorp实践时，就以WEB方式为主，并且就算是针对CS类资源，BeyondCorp也是封装至HTTP Connect代理隧道中，在web中转发流量。

这也造成不少SDP厂商曾一度打着零信任SDP免客户端、纯web，比SSL VPN体验更佳的旗 ，主推Layer 7 WEB资源，充分说明web资源历久却弥新。

而时至今日(2022年)，我们发现零信任SDP基本上已经不再主推web资源、免客户端，这里面除却 增强安全性离不开终端agent外，是否还有其他的因素呢？

在接下来几篇文章中，就会从接入技术视角，对此进行补充解读，或许能为大家解除一些疑惑。

2、WEB资源 VS 隧道资源(Layer 3/Layer4)的基本对比

对WEB资源和隧道资源做一个初步的对比，可以发现，在体验和审计层面上，Layer 7 WEB资源是占据优势的；

其弱势如下：1)、CS类访问的兼容性差(表现为脚本、插件无法访问)，

2)、发布上线的复杂度较高（涉及修改公 DNS解析）

3)、安全性相对稍弱（和agent联动弱）

4)、业务功能适配性存在风险，主要体现为发布后业务功能可能有部分不正常（后文会详述原因）

3、无代理情况下，WEB站点如何被访问？

3.1、基础概念

1)、域名(Domain) ：域名是IP地址的代称，如 www.baidu.com 就是百度的域名。比如通过ping，可以发现 www.cnbeta.com 指向的IP是 125.90.93.20。注：可参考( https://zh.m.wikipedia.org/zh/%E5%9F%9F%E5%90%8D )

2)、DNS(Domain Name System): 域名系统，域名既然是IP地址的代称，那么就需要有一个转换机制可以通过域名查询到IP，这个机制就称为DNS。当前大多数 络环境已经不需要手动配置DNS服务器了，默认都通过“自动获得DNS服务器地址”来实现解析。

3)、超文本传输协议（HyperText Transfer Protocol, HTTP）: 一种用于传输超媒体文档（例如 HTML）的应用层[1]协议，我们最常使用的浏览器，就是以HTTP(s）为主要通信协议完成各类通信。

HTTP是为 Web 浏览器与 Web 服务器之间的通信而设计的，但是当前HTTP(s)已经成为非常主流的通信机制，我们手机上各类APP，比如说淘宝、京东、微博等，和服务端的主要内容通信也都采用HTTPS。

可参考 https://developer.mozilla.org/zh-CN/docs/Web/HTTP .

3.2、web站点访问流程

可以看到，web站点的首页访问流程大致有如下5步：

1)、【用户发起访问】用户输入 https://oa.company.com 并回车访问

2)、【DNS解析请求】浏览器向DNS Server发起解析请求

3)、【DNS解析返回】DNS服务器向浏览器返回解析结果

4)、【HTTP请求发起】浏览器向Web Server发起HTTP(s)请求

5)、【HTTP请求响应】Web Server向浏览器返回HTTP(s)结果

在完成上述步骤，可以正常访问后，用户就可以在 oa.company.com 地登录页面，输入用户名密码进行登录访问了。当然，根据业务系统的不同，也可以用来做其他操作。

4、Layer 7 VPN代理介入后，WEB站点如何被访问？

4.1、相比直接访问，WEB资源带来的变化

Layer 7 VPN代理介入后，实质上是在原访问流程中间增加了一个Proxy Server，用于流量转发、认证鉴权等环节。可见下图：

4.2、web资源访问流程(典型反向代理)

下图是以SDP架构（数据面和控制面分离）为例，进行的举例。如果是数控一体的，差异仅为设备少了一台、IP变成一个。

== 认证前阶段 ==

1)、用户输入 https://oa.company.com 进行业务访问

2)、浏览器向 公 DNS Server(如114.114.114.114) 发起DNS解析请求，解析 oa.company.com 。DNS Server 返回 oa.company.com的IP地址，其IP实际为 SDP-Gateway(数据面)的 公 IP地址(如125.93.90.20）。

3)、浏览器向 SDP-Gateway(数据面) 的公 IP地址发送请求，https://oa.company.com

4）、SDP-Gateway(数据面) 发现 用户未认证，于是302 跳转到 sdpc.company.com 要求认证

== 认证登录阶段 ==

5)、浏览器向 DNS Server发起DNS解析请求，解析 sdpc.company.com 。DNS Server 返回 sdpc的IP地址，其IP地址实际为 SDP-Controller(控制面)的公 IP地址。

6)、浏览器向 SDP-Controller(控制面) 发起请求，用户在上面输入用户名密码+MFA完成认证登录

7)、SDP-Controller（控制面) 向浏览器返回登录成功，并携带 一次性OA-AppTicket 跳转回 oa.company.com

== 鉴权访问阶段 ==

8)、浏览器携带 OA-AppTicket 向 SDP-Gateway(数据面) 请求访问 oa.company.com

9)、【鉴权】SDP-Gateway(数据面) 向 SDP-Controller(控制面) 校验 OA-AppTicket， 获取 AppToken

10)、SDP-Gateway(数据面) 发起内 DNS解析，DNS-Server返回内 IP (如 172.16.1.101)

11)、SDP-Gateway(数据面) 代理转发HTTP请求至 oa.company.com 服务器的内 IP( 172.16.1.101 )，完成代理访问

4.3、对应隧道技术核心流程

参考 RemoteAccessTech-005-VPN隧道技术的核心流程 中第 1.2章节 ，我们看到隧道核心流程如下：

引流->预鉴权->封装->加密->传输->解密->解封装->鉴权->转发

我们可以和 4.2的访问流程对照一下：

1)、引流：通过公 DNS Server(如114.114.114.114)解析进行引流 ，将流量引至Proxy Server（如SDP-Gateway代理 关)

2)、预鉴权：web资源一般不涉及预鉴权。

3)、传输：加密主要基于TLS完成 ；而 封装的解封装，则依赖于 HTTP协议格式，在整个访问流中，通常会在HTTP Cookie或Header中增加鉴权所需信息（如AppToken应用访问令牌、UserSession用户会话等)。

4)、鉴权：SDP-Gateway 一般至少要完成中下3个鉴权工作：

4.1)、【应用名单检查】 会根据企业预设的资源列表(app list), 确认 oa.company.com 是否企业的有效资源，如果不是，直接返回 HTTP 400、404等状态码 ；

4.2)、【用户认证】和 SDP-Controller 进行通信，由SDP-Controller实现用户认证.

4.3)、【应用鉴权】和 SDP-Controller进行通信，和 SDP-Controller 协同完成应用鉴权。

5)、转发：当鉴权通过后，SDP-Gateway 代理转发HTTP(s)访问请求，实现业务访问。

5、web资源的一些关联问题

5.1、谈谈免客户端(clientless)

5.2、说说web资源的发布复杂度

综合来看，资源发布复杂度中，WEB资源是相对复杂的，原因是需要修改公 DNS解析。

这个一方面是 修改公 DNS操作依赖于域名供应商，对内可能需要跨部门/小组协调， 另一方面会体现在测试环节，可能 业务本身( 如 oa.company.com )就有较大量的员工正在直接访问 ，那么将DNS解析切换至SDP-Gateway则属于 风险变更行为 。

当然这里各大厂商的实现有时会通过一些折衷操作，简单举例比如说有：

1)、手动修改操作系统本机hosts文件：这是最简单的操作，只是由于修改繁杂，一般只能支撑少数几台PC进行修改。

2)、 通过客户端实现DNS劫持：通过客户端下发DNS规则，能实现只要安装客户端，就可以劫持DNS实现引流，从而避免修改域名供应商的公 DNS解析。一般会称之为私有DNS、专属DNS等。

3)、通过 络设备劫持DNS：对于条件具备的场景，还可以通过在 络设备上进行DNS劫持。

比如说职场的上 WIFI设备上，劫持DNS，使 oa.company.com 指向 SDP-Gateway的公 IP；

比如说指定分支职场的出口Firewall上，进行对应的DNS劫持。

注：如果是职场场景，还可以通过IP回流的方式，实现公 IP直接引流到内 ，避免流量到互联 绕圈。

4)、新增二级泛域名实现DNS劫持 : 前面所有的都是直接修改 oa.company.com，但是直接修改影响较大。

是否能转变思路，从修改变为新增呢？

当然是可以的，比如说指定一个 *.sdp.company.com 二级泛域名，默认指向 SDP-Gateway(代理 关)

5.3、聊聊WEB资源的终端agent安全联动

针对隧道资源(Layer 3/Layer 4)，往往能相对容易地在终端agent上明确每一条连接(TCP Connection) 的安全状态，实现连接级安全验证，而WEB资源由于两个原因：

1)、标准的WEB资源主打的是免客户端(Clientless），体验优先，而体验和安全是有一定程度的冲突。

2)、由于web资源（https)是TLS加密的，客户端agent默认无法读取和修改HTTPS内容，从而无法准确获取到连接级(TCP Connection)状态。 注：单纯这一点，技术上也有办法，但是变得更重，没有必要。

所以通常综合考虑定位和实现复杂度之后，开发团队/厂商在实际实现时，依赖终端agent的安全能力，都会和隧道资源优先实现，针对web资源仍会保留其免客户端(Clientless)的特性。

5.4、 遗留一个尾巴（业务适配性）

前面还提到 一个业务适配性的问题，暂且留待下一篇揭晓。

参考资料

[1]应用层:
https://en.wikipedia.org/wiki/Application_Layer