#38 RemoteAccessTech-011-Tunnel资源引流技术之引流与分流

• 0、篇首语
• 1、从Full-Tunnel说起
• 2、Split-Tunnel（拆分隧道/分割隧道)
• 3、IP形式-Tunnel资源的精准引流(分流)
• 3.1、虚拟网卡引流技术-IP型资源精准引流
• 3.2、Hooking/Filter引流技术-IP型资源精准引流
• 4、域名形式-Tunnel资源的精准引流(分流)
• 4.1、基础概念
• 4.2、域名型资源-精准引流方案汇总
• 4.3、逻辑方案一：Full-DNS全解析（公网DNS解析内网IP)
• 4.4、逻辑方案二：Split-DNS(拆分DNS)
• 4.5、逻辑方案三：Fake DNS
• 5、总结

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隧道技术的核心流程

7)、RemoteAccessTech-006-WEB资源-典型Layer7 VPN

8)、RemoteAccessTech-007-WEB资源-非标web站点的适配困境

9)、RemoteAccessTech-008-WEB资源正向反向代理之争

10)、RemoteAccessTech-009-Tunnel资源-典型3层和4层代理介绍

11)、RemoteAccessTech-010-Tunnel资源之引流技术两大流派

1、从Full-Tunnel说起

前面我们着重介绍了引流，引流的关键字在于 "引" ，但其实背后还有一个潜台词，是 不引。引流技术不仅要解决将哪些流量引走，还要解决哪些流量 不引走 。

我们试想一个场景，用户原本登录VPN/SDP后，主要目的是访问企业内网，但是，如果其访问互联网的流量如果也被引流了， 那么就可能会导致出问题。这种不能区分的引流方式，叫作 Full-Tunnel（全隧道)。

如下图，全隧道模式 不仅将 企业内网流量 引流至 代理网关(Gateway），还将 互联网流量 也引流到网关绕了一圈。

这显然会带来几大问题：

1)、带宽风险：额外消耗了企业的互联网带宽。

2)、延迟和体验风险：流量引至企业DMZ区绕了一圈，增加了延迟，访问变慢了

3)、性能和可靠性风险：互联网大流量访问(如观看视频)，对代理网关的性能和带宽都造成影响，可能会阻塞影响企业正常业务访问

2、Split-Tunnel（拆分隧道/分割隧道)

拆分隧道(Split Tunnel) 早期出现在IPSec VPN中，就是为了解决上述全隧道(Full-Tunnel) 所引入的问题。

可参考wiki (https://en.wikipedia.org/wiki/Split_tunneling),其定义如下：

拆分隧道是一种计算机网络[1]概念，它允许用户使用相同的或不同的网络连接同时访问不同的安全域[2]

总结点说，拆分隧道(Split Tunnel) 指一种通过 精准引流 来使 不同网络区域 的访问流量能被按需分流，从而使得用户在同一终端同一时间能够正常访问不同网络区域（如互联网和办公网）。如下图：

通过Split Tunnel 可以解决几大问题：

1)、不浪费额外的网关性能（"精准"引流：不必要的流量不被引流，实现分流，代理网关不需要处理)

2)、不影响互联网访问体验("精准"引流：不必要的流量不被引流，实现分流，避免了不必要的延迟)

3)、不浪费额外的带宽("精准"引流：不必要的流量不被引流，实现分流，避免了带宽浪费)

3、IP形式-Tunnel资源的精准引流(分流)

Tunnel资源 从形式上，可分为IP资源（如 1.1.1.1:22 )和域名资源(如 oa.company.com )。

IP型资源的引流相对简单，我们优先讲解一下IP型资源。

3.1、虚拟网卡引流技术-IP型资源精准引流

在 RemoteAccessTech-010-Tunnel资源之引流技术两大流派 我们提到过，虚拟网卡/系统扩展 主要是通过系统路由进行引流的。

以一台连接了WIFI，DHCP获取到物理网卡IP 172.22.0.27的PC客户端，访问192.168.1.1资源为例：

其典型流程如下：

1)、策略同步-获取引流列表(Route List)、资源列表(Resource List）：本步骤默认需要在用户登录后，根据用户权限配置获取下发。Route List确认哪些需要引流，Resource List 则用于确认哪些能够转发。通常的实现方案，引流列表和资源列表是一致的，当然，也可以有差异。。

2)、设置引流路由：通过将Route List设置至虚拟网卡路由表，使其正常引流。

3)、应用程序发起Tunnel资源访问：应用程序访问内网资源 http://192.168.1.1 ， 被路由表引流至虚拟网卡(192.168.1.1->2.2.2.2)。

4)、资源访问流量捕获: SDP-Tunnel模块，通过相关接口，从虚拟网卡中抓取到 192.168.1.1 的访问流量。

5)、本地鉴权校验：Tunnel模块通常会根据 Resource List校验当前用户是否具有 192.168.1.1的资源访问权限，以避免被恶意攻击者手动增加虚拟网卡路由，引发安全风险。

6)、封装资源流量并转发：Tunnel模块将流量封装后，转发至Gateway公网IP (3.3.3.3) 。该流量被路由表引流至物理网卡。

注：数据协议格式可参考 RemoteAccessTech-009-Tunnel资源-典型3层和4层代理介绍 中的 4.3.1、3层代理-Payload和转发模式 小节。

7)、加密转发至代理网关：通过SSL加密转发。

8)、服务端二次鉴权：本环节在 RemoteAccessTech-005-VPN隧道技术的核心流程 的 1.2、完整的隧道转发典型逻辑 章节也有说明。服务端鉴权是必要的，恶意攻击者有可能可以绕开客户端本地鉴权向服务端直接转发流量，需要通过服务端鉴权进行预防 。

9)、代理转发：解决最后一公里的流量派送。

3.2、Hooking/Filter引流技术-IP型资源精准引流

Hooking/Filter引流技术则是另外一个类型的引流技术。由于其多数情况下过滤的是TCP/IP数据包，也被称为 包过滤(Packet Filtering)技术。

同样以一台连接了WIFI，DHCP获取到物理网卡IP 172.22.0.27的PC客户端，访问192.168.1.1资源为例：

1)、策略同步-获取引流列表(Route List)、资源列表(Resource List)：本步骤默认需要在用户登录后，根据用户权限配置获取下发。Route List确认哪些需要引流，Resource List 则用于确认哪些能够转发。通常的实现方案，引流列表和资源列表是一致的，当然，也可以有差异。

2)、设置引流规则：将Route List以ioctl方式下发给内核过滤驱动，使过滤驱动能够正常工作。

3)、应用程序发起Tunnel资源访问：应用程序访问内网资源 http://192.168.1.1 ， 被路由表引流至物理网卡(全路由0.0.0.0->172.22.0.27)。

4)、引流规则校验：Filter Driver 校验Route List，根据规则拦截192.168.1.1，等待Tunnel处理。

5)、资源访问流量捕获: SDP-Tunnel模块，通过相关接口，从过滤驱动中获取访问流量(192.168.1.1)。

6)、本地鉴权校验：Tunnel模块通常会根据 Resource List校验当前用户是否具有 192.168.1.1的资源访问权限，确认是否需要转发。

7)、封装资源流量并转发：Tunnel模块将流量封装后，转发至Gateway公网IP (3.3.3.3) 。该流量被路由表引流至物理网卡。

注：数据协议格式可参考 RemoteAccessTech-009-Tunnel资源-典型3层和4层代理介绍 中的 4.3.2、4层代理-Payload和转发模式 小节。

8)、加密转发至代理网关：通过SSL加密转发。

9)、服务端二次鉴权：本环节在 RemoteAccessTech-005-VPN隧道技术的核心流程 的 1.2、完整的隧道转发典型逻辑 章节也有说明。服务端鉴权是必要的，恶意攻击者有可能可以绕开客户端本地鉴权向服务端直接转发流量，需要通过服务端鉴权进行预防 。

10)、代理转发：解决最后一公里的流量派送问题。

4、域名形式-Tunnel资源的精准引流(分流)

前面提到 Tunnel资源 从形式上，可分为IP型资源（如 1.1.1.1:22 )和域名型资源(如 oa.company.com )。

IP型资源在第3小节已经讲解，那么域名型资源又有何差异呢？

4.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服务器地址"来实现解析。

4.2、域名型资源-精准引流方案汇总

域名型资源(如 oa.company.com )，相比IP型资源( 192.168.1.1) ，最核心的差异就是增加了一个DNS解析过程。

可参考 本文3.1小节， IP型资源是：IP(192.168.1.1) –> 路由表 –> 虚拟网卡/过滤驱动 –> 物理网卡 –> 代理网关。

而域名型资源，则需要增加一个解析过程，即 域名(oa.company.com) –> 【DNS解析】 –> IP(192.168.1.1) ==> 其他环节（同上）。

域名型资源精准引流方案有几种方案思路：

1)、Full-DNS(全解析）：通过一个统一的DNS Server，统一解析企业内网、互联网域名。

2)、Split DNS（拆分DNS）：为互联网、企业内网提供两个不同的DNS域名，以满足更灵活的使用需要。必要时，可以是更多套网络环境内的DNS，比如说 生产网、开发网、测试网、办公网等。

3)、Fake DNS（虚假DNS）：本文留白，待下一篇解释。

值得注意的是，方案思路和技术方案是两码事,比如说 Split DNS 既可以通过 PC客户端增加一个 本地DNS Server去解决，也可以通过写 hosts文件解决，还可以通过发布一个内网的远程DNS Server解决。

下面我们将各个方案一一道来。

4.3、逻辑方案一：Full-DNS全解析（公网DNS解析内网IP)

这个方案是最容易理解的，类似于Full-Tunnel（全隧道）引流了所有的隧道流量，Full-DNS(全解析）其实就是指所有的DNS流量被同一个DNS Server所解析。

在典型访问场景下，PC终端处于互联网，所以也就意味着是公网DNS解析内网IP。

下为namecheap 域名下的Advance DNS配置，可以配置 erp.domain.com 为内网IP(172.16.1.2)。

配置后通过nslookup查看解析结果 ，可以看到ERP被成功解析到了 172.16.1.2。

在此方案下，其关键配置如下：

4.4、逻辑方案二：Split-DNS(拆分DNS)

类似于 Split Tunnel(拆分隧道)，Split DNS(拆分DNS) 是指 将企业内网域名的DNS解析请求，引流至一个独立的DNS（如本地DNS Server或内网DNS Server)进行解析的方案。

参考 IPSEC IKEV2关于Split DNS的RFC标准，rfc8598 – # Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2) ， IPSEC针对Split Tunnel所引发的DNS问题，也通过Split DNS予以解决。

从技术实现方案上，Split DNS可分为Local Split DNS和Remote Split DNS两种模式。

4.4.1、方案1：Remote Split DNS（下发内网DNS)

本方案是指下发一个内网DNS（同样通过Tunnel代理访问) 到操作系统的DNS地址上，使其能正常访问的机制。

下为虚拟网卡方案的Remote Split DNS典型流程，相比本文第 3.1、虚拟网卡引流技术-IP型资源精准引流 小节，主要是增加了如下环节：

1)、A1-下发系统DNS：将从Controller中获取到的DNS List（此为10.10.10.10），下发到系统网卡中。

2)、A2-应用程序解析DNS: Application发起DNS解析，通常会经过操作系统的DNS服务，该服务会进行一定时间的缓存，避免反复发起DNS解析请求。

注：部分Application可能会跳过系统DNS，直接构建DNS Request请求解析(仍可被虚拟网卡或Packet Filtering捕获引流)。但更进一步，还有涉及到HTTP-DNS等非传统DNS请求的机制，这类跳开传统DNS流程的，就会导致Split DNS机制失效。

3)、A3-发起DNS请求：向内网DNS 10.10.10. 10 53发起真实DNS请求，流量被系统路由表引流至虚拟网卡。

4)、A4-流量捕获: SDP-Tunnel向虚拟网卡获取流量，获取到流量为10.10.10.10的DNS请求包。

5)、A5-本地鉴权：这一步同其他资源，并无区别。

6)、A6-封装流量并转发：将DNS请求封装后，发往3.3.3.3公网代理网关IP。将被路由表引流至虚拟网卡。

到代理网关后，则是由Gateway向真实内网DNS Server发起解析请求，从而获取到oa.company.com的IP地址为 192.168.1.1。

本方案在技术上还会有一些变种优化，比如说在SDP-Gateway 上增加一个 DNS服务进行解析缓存，降低内网真实DNS Server的负载 。

在此方案下，其关键配置如下：

4.4.2、方案2：Local Split DNS

本方案思路是指在PC客户端本地增加一个 Local DNS Server，提供DNS解析代理；其DNS规则是从服务端预解析或预配置从而下发。

前面Remote Split DNS是需要依赖企业内网中，一定要有一台DNS Server提供Split DNS解析能力才OK。

而Local Split DNS则可以不依赖于企业内网DNS，通常可以由SDP-Controller直接下发DNS规则。其关键逻辑流程如下：

0)、B0-预解析域名型资源：SDP-Controller对域名型资源进行预解析，形成DNS解析列表。

1)、B1-获取到DNS解析列表：从SDP-Controller获取DNS解析列表，提供给LocalDNS作为启动配置。

2)、A1-初始化DNS解析：启动Local DNS服务，并修改系统DNS（增加2.2.2.254)。

Local Split DNS，以虚拟网卡技术引流DNS，则其相对完整流程如下：

4.4.3、Local Split DNS VS Remote Split DNS

Remote Split DNS 的优势在于能继承内网所有的DNS解析配置、和接入技术比较解耦；

不足之处在于，DNS请求需要经由代理网关向内网DNS Server请求一次，访问延迟会稍高一点，同时由于互联网DNS Server一般要更快返回，如果两者有域名冲突，则返回结果会被互联网DNS覆盖。

而Local Split DNS 则通常由服务端预解析下发，本地直接解析，所以通常DNS解析速度会更快，优于互联网DNS Server。

4.4.4、虚拟网卡引流、Hooking/Filter过滤驱动技术在Split DNS上的差异

两者都可以实现Split DNS引流，但是稍有差异，对比如下。

总结而言， 过滤驱动方案在DNS流量引流场景上（注：非协议流量引流场景），**兼容性整体要优于虚拟网卡DNS引流(注：仅指DNS引流)**。

但是正如 RemoteAccessTech-010-Tunnel资源之引流技术两大流派 第2.1 兼容性比拼 小节里所说，过滤驱动方案的操作系统兼容性相对较差。其对于移动端主流操作系统android/ios/鸿蒙都是不支持的，在PC操作系统上，windows通常支持，macos受限支持。

同时，又考虑到windows操作系统兼容性最为严峻（环境复杂、软件复杂），所以通常较优的选择：

1)、虚拟网卡解决全操作系统引流。

2)、在windows上增加过滤驱动进行DNS流量引流。

针对Split-DNS为例，如果采用过滤驱动进行DNS引流 ,则其关键配置如下：

4.5、逻辑方案三：Fake DNS

标题党。本文留白，本系列下一篇解释。

5、总结

1)、引流的关键字在于 "引" ，但其实背后还有一个潜台词，是 不引。引流技术不仅要解决将哪些流量引走，还要解决哪些流量 不引走 。

2)、IP型-Tunnel资源和域名型-Tunnel资源，在引流方案上有所差异。

3)、IP型-Tunnel资源引流方案，可划分为 Full-Tunnel全隧道方案和Split-Tunnel拆分隧道方案。前者是将PC端所有流量都引流走（只解决了引，没解决不引，可发不可收)。后者则是可发可收，可引可不引，可以实现 仅引流企业内网访问流量，不引流互联网流量。所以Split-Tunnel是标准的模式。

4)、域名型-Tunnel资源引流方案，也可划分为Full-DNS和Split-DNS 两个方向，其中后者又可细分为Local-Split-DNS和Remote-Split-DNS。

其关键配置如下：

5)、域名型-Tunnel资源的DNS引流方案对比，整体来看，Local-Split-DNS在体验、速度上均有优势。

6)、Hooking/Filter过滤驱动技术（如WFP/NDIS Packet Filter） 同样可用于DNS引流，通常用于优化windows操作系统的DNS引流兼容性，其劣势在于不能适配全终端操作系统。

而基于虚拟网卡/网络扩展技术的DNS引流，则通常是默认选择，用于实现全终端(windows/macos/linux/android/ios)的DNS引流兼容。

7)、万变不离其宗。了解引流的本质之后，我们就能知道，无论厂商如何宣传其引流分流技术，都离不开Full/Split二字、离不开Local/Remote之分。即使是本文暂未讲解的Fake DNS，其本质也是Local Split DNS的一种特殊变种。

参考资料

[1]

Computer network: https://en.wikipedia.org/wiki/Computer_network

[2]

Security domain: https://en.wikipedia.org/wiki/Security_domain