指南

受众和目的

本文档针对具有网络和 VPN 技术基础知识的网络和安全 IT 管理员。

作为下一代安全和网络产品，Jamf Connect ZTNA 的行为与传统 VPN 有显著不同。本指南旨在帮助管理员了解产品设计的基础知识，以便进行规划、部署、维护和故障排除。

本指南不是介绍如何配置 Jamf ZTNA 产品的产品文档，而是解释其工作原理，以便您能够预测和理解产品在您环境中的行为。如果您正在寻找文档，可以在我们的 Jamf Connect ZTNA 文档 中找到，或者如果您想先观看产品的技术视频概览，请观看 JNUC 2021 Jamf ZTNA 深度解析 演示。

如果您在组织内以生产能力使用 Jamf Connect ZTNA，我们强烈建议您阅读（并收藏！）本指南。

概述

Jamf ZTNA 产品从一开始就被设计为遵守 云安全联盟 (CSA) 的 软件定义边界 (SDP) 架构。该架构体现了更广泛的行业 零信任网络访问 (ZTNA) 定义的许多原则，包括最小权限访问、基于角色的访问、多因素身份验证、设备信任等。该产品最初由 Wandera 开发，2021 年 7 月被 Jamf 安全平台收购。

因此，虽然 Jamf Connect ZTNA 与传统 VPN 分享许多相同的结果——例如当 VPN 接口上线时远程资源变得可用——但支持这些结果的实际机制是完全不同的。这是因为 Connect ZTNA 利用 IP 寻址、DNS 和云技术来实现客户端到服务器的路由，相比传统 VPN 架构在性能、可扩展性和安全性方面是质的飞跃。

因此，让我们从 Jamf SDP 和传统 VPN 之间最显著和最重要的区别之一开始：连接代理与路由。

连接代理

让我们从这里开始：暂时搁置您对 VPN 如何工作的所有了解和假设。虽然最终的数据包路由看起来很像传统 VPN，但连接过程中存在全新的处理元素。

传统 VPN

当设备连接到传统 VPN 时，它会与 VPN 集中器建立安全隧道，集中器可能存在于本地或云中，由您或服务提供商运营。

无论集中器在哪里或由谁运营，一般行为是相同的：

1. 设备与 VPN 集中器进行身份验证并建立安全隧道，在端点上创建虚拟网络接口。
2. 设备由集中器动态分配一个 IP 地址，该地址在隧道生命周期内有效（有时可能由 DHCP 绑定"静态"重新分配）。
3. 为虚拟网络接口配置一个或多个路由，定义应通过 VPN 路由的组织拥有的网络子网。完全隧道 VPN 将设备的所有流量路由到集中器，消除所有本地网络访问。
4. 在设备上配置 DNS 名称服务器，通常位于 VPN 另一端的客户网络中。
5. 每当应用程序请求资源时，DNS 解析为 IP 地址，如果数据包的 IP 地址在 VPN 虚拟接口的某个路由范围内，流量将通过 VPN 路由。
6. VPN 集中器将数据包路由到客户网络中。在某些情况下，防火墙访问控制列表在整个网络中实施以限制访问控制。

虽然这当然有效，但这种架构的主要安全问题是路由子网内的所有资源本质上都对设备可用。这允许连接到 IT 服务和服务器，而大多数端点不应该连接到这些服务。如果您是恶意行为人并设法利用端点漏洞，您可以使用此 VPN 连接来寻找"防火墙后面安全的"服务器上的弱点，这些服务器可能未完全修补或以其他方式锁定。

当然，您可以在网络中实施访问控制规则，但这很难且容易出错。通常这些规则必须在 IP 地址层进行管理，因此它们易于出现问题且改变时危险。这导致网络级安全策略很快被跟不上新的和不断发展的关键应用程序所需的变化速率。您也没有很好的方法来监控和审计报告，以便紧密耦合用户身份与其连接。那么大多数组织做什么呢？放任不管，在出现事件时将报告拼凑在一起。

那么您如何解决这些挑战呢？进入 SDP 和"代理"网络连接。

SDP：连接代理

当 Jamf ZTNA 在端点设备上连接时，从一开始就存在一些显著的差异：

1. 在极轻的初始握手后，在端点上创建无状态 Wireguard 网络接口。注意：根据您的 ZTNA 部署，Apple 设备可能使用 HTTP/3 替代 Wireguard。
2. 配置简单的 IPv6 路由集——通过带外接口建立协商——用于 VPN 网络接口。默认情况下，这些路由不属于客户，而是由 Jamf 管理的保留 IPv6 范围（fd53:1c5a::/32, fddd:dddd::/128）。VPN 网络接口还分配了一个通过带外协商的静态 IPv6 地址。默认情况下不向 VPN 网络接口分配 IPv4 地址或路由！
3. 在设备上配置 Jamf 管理的 DNS 名称服务器 fddd:dddd::。

哇。什么？是的，您读得没错：没有企业端 IP 地址、子网或 DNS 名称服务器发布到最终用户设备的路由表中。甚至没有任何 IPv4 地址！这是 SDP 连接代理的关键构建块，使得端点和用户不了解内部网络拓扑，即使他们试图也无法连接到内部网络 IP。

那么设备上的应用程序如何连接到位于这些内部 IPv4 子网之一上的服务器上的应用程序呢？这就是连接代理发挥作用的地方，由 DNS、NAT 和 Jamf 路由技术的神奇组合便利。

信息：关于直接 IP 和子网访问的注释

除了不向端点发布内部子网的安全好处——更不用说任何 IPv4 地址——它还有助于避免用户可能在非企业管理网络（例如家庭、咖啡馆等）上经历的网络段重叠。这对于实现无缝的随处远程工作至关重要。

但是，在某些特定用例中，IPv4 地址或子网必须直接可用，不能依赖于基于 DNS 的连接代理。对于这些情况，Connect ZTNA 支持配置"直接 IP"访问。有关详细信息，请参阅本指南的"代理连接异常"部分。

让我们假设用户正在尝试连接到 App，其位于 app.acmeinc.com，内部 IP 地址为 10.0.1.22。以下是便利该来自 Jamf ZTNA 启用设备的连接发生的过程（下面的示例显示到目标应用的 TCP 连接，但类似的流用于 UDP 连接）：

1. 用户从其选择的浏览器或任何本机应用程序启动到 app.acmeinc.com 的连接。
2. 应用程序要求操作系统将该主机名解析为 IP 地址以连接到。当 Jamf Connect ZTNA 激活时，要使用的 DNS 名称服务器是 fddd:dddd::，这是一个虚拟 IPv6 地址，与 Jamf Connect ZTNA 策略引擎相结合。
3. 操作系统对 fddd:dddd:: 进行一系列 DNS 请求，针对 app.acmeinc.com，包括类型 A、AAAA 和 HTTPS。
4. Jamf Connect ZTNA DNS 名称服务器执行 FQDN 的上游查询，首先查看是否为域配置了自定义 DNS 区域（本例中 *.acmeinc.com 使用 10.0.1.10 作为权威名称服务器）。如果未找到自定义 DNS 区域，该服务使用一系列公共上游 DNS 解析器。
   1. 注意：该服务仅请求上游 A 记录，AAAA 和 HTTPS 目前被忽略。这仅对仅可通过 IPv6 到达的服务器是潜在问题，这在当今大多数公共和私有网络上非常罕见。
5. 从权威服务器接收 A DNS 响应后（在这种情况下，来自客户内部名称服务器通过自定义 DNS 区域配置的 A 10.0.1.22），Jamf Connect ZTNA DNS 名称服务器识别请求资源的用户和设备，并查找与将 app.acmeinc.com 定义为流量匹配标准的访问策略相匹配。
   1. 该访问策略评估用户的组成员资格和设备运行状况以确定是否应授予对资源的访问权限。
   2. 在策略中还定义了流量应如何通过 Jamf 云路由。在这种情况下，我们将假设客户配置了一个IPSec 互联网关作为到达此内部应用的私有路由。
6. 假设找到访问策略，并且设备和用户通过连接到资源所需的所有标准，Jamf Connect ZTNA 路由结构创建"云流映射"，在发布到端点的保留 IPv6 子网内分配临时 IPv6（例如 fd53:1c5a::aaaa:bbbb ↔ 10.0.1.22）。
   1. 此流对每个连接和用户都是唯一的，不能在其生命周期之外或任何其他设备重复使用。
7. 此 IPv6 地址 fd53:1c5a::aaaa:bbbb 作为 AAAA DNS 响应返回到端点。
   1. 该服务默认不返回 A 或 HTTPS 响应！在使用 dig 等实用程序进行故障排除 DNS 响应时，请务必记住这一点！
8. 创建到 fd53:1c5a::aaaa:bbbb 的新套接字，由于该 IP 存在于分配给 Jamf Connect ZTNA VPN 网络接口的子网内，该套接字和所有后续数据包都通过 Wireguard 隧道转发回 Jamf 安全云。
9. 收到数据包后，Jamf Connect ZTNA 路由结构执行额外的安全检查，然后定位目标 IPv6 地址的云流映射。
10. Jamf Connect ZTNA 路由结构通过我们的全球云骨干网路由数据包，最终到达由访问策略定义的 IPSec 互联。在通过 IPSec 隧道转发数据包之前，根据云流映射发生 NAT64 转换，导致具有原始 IPv4 地址（10.0.1.22）作为其目标 IP 的数据包。
    1. 数据包的源 IP 设置为 IPSec 配置中"Jamf 安全云端"子网内的 IP 地址。所有发送到客户网络的流量将来自此子网内的伪随机 IP。
    2. 如果您对云端 NAT 出口使用区域数据中心，源 IP 将动态负载均衡到该数据中心的全球 IP 地址。
11. 所有匹配的代理连接都针对用户、设备和应用程序记录，可在 RADAR 的访问事件日志中查看，以及其他报告中。

如您所见，DNS、IP 路由和 NAT 之间存在紧密耦合，这在传统 VPN 配置中本身不存在。

尽管存在这些差异，Jamf Connect ZTNA 极其高效地处理数据包，因为所有路由在第 3 层本地进行，轻松支持 VoIP 和视频等实时应用程序。由于所有封装使用超快速高效的 Wireguard 或 HTTP/3 UDP 封装协议，不存在在有损网络上基于 TCP/mTLS 隧道内路由 TCP 连接时常见的传输协议"崩溃"。

信息：SDP、VPN 和端到端应用加密

Jamf Connect ZTNA 经过精心设计，使用现代数据包封装和加密技术提供快速动态的软件定义网络功能，使您能够轻松操纵流量并应用策略从端点到几乎任何目的地，只需点击 Web 界面中的几个按钮。

但与任何加密运行中流量的 VPN 技术一样，Jamf 不可能提供从客户端应用到服务器应用的真正端到端加密。

因此，对于包含任何级别敏感数据的任何应用程序，您必须始终将此类应用程序配置为使用应用级加密技术，如 HTTPS 或 TLS。这现在是所有应用程序的标准实践。这是确保未授权的中间人无法在 Jamf 或客户网络的任何位置获得访问权的唯一方法。

这种连接代理技术已被证明在 Jamf ZTNA 平台上以企业级性能和规模运行。所有现代操作系统本地支持 IPv6（即使设备具有仅 IPv4 网络连接），绝大多数应用程序和用户支持 IPv6 并将 DNS 用于所有连接。

除了那些不支持的……您需要为这些异常情况定义特殊配置才能通过 Connect ZTNA 工作。

可用性和故障转移

Jamf ZTNA 的架构考虑了网络分区和设备无法连接到 Jamf 安全云的情况。它使用多种重叠的方法这样做：-

死网关检测

Jamf Trust 可以检测危险或不稳定的连接，这些连接通常由不安全的强制门户导致。这些强制门户可以拦截流量，导致连接问题。

使用死网关检测 (DGD)，Jamf Trust 应用可以在最终用户设备上提供关于其连接当前状态的通知。DGD 使用常规连接检查，例如强制门户和 Web 连接检查，同时使用零信任网络访问 (ZTNA) 端点解析来检测死网关。为直接支持 DGD，Jamf Trust 中的绕过模式可防止危险流量通过 VPN 隧道传递。这允许最终用户在没有其 VPN 或工作应用程序的情况下安全地浏览互联网。

负载均衡和区域入口位置

检测到实时连接后，Jamf Trust 请求由本地网络 DNS 提供商（通常由 DHCP 提供）确定的本地 IP 端点。这些端点的 TTL（生存时间）为 60 秒。如果这些端点之一变得不可用，它将在 60 秒内从池中移除。这导致 RTO（恢复时间目标）最长为 60 秒，但与死网关检测配对时，从单个端点故障的恢复是即时的。

本地策略缓存

如SDP：连接代理中所述，Jamf 使用本地 DNS 代理将设备流量重新路由到相应的资源。这些本地 DNS 记录的 TTL 也为 60 秒。如果实施策略更改（由于基于风险的策略自动或由管理更改），本地设备上的策略更新最长期间为 60 秒。注意策略不在设备上本地生存，但由于 DNS 缓存，可能看起来策略更新每 60 秒推送一次。

代理连接异常

虽然大多数应用程序和服务通过 Jamf ZTNA 服务本地运行且无需特殊考虑，但存在某些特定用例和应用程序类别，需要代理连接方法不支持的连接。

不使用 DNS 的应用/服务

如您从上面学到的，如果应用或用户不使用 FQDN 连接到资源，那好吧，这是行不通的。

这是因为没有 DNS 请求来启动连接，代理 IPv6 地址将永远不会被发出。由于目标的 IPv4 地址未添加在设备的路由表中，该数据包将进入互联网并永远不会返回。

虽然在总体上不常见，但不涉及 FQDN/DNS 的连接情况对于以下情况很常见：

• IT 管理员尝试直接连接到网络设备
• 开发人员连接到未向 DNS 注册的虚拟实例的新实例
• 通过 IPv4 地址而不是 FQDN 连接的遗留应用程序

正是由于这个原因，Jamf Connect ZTNA 支持在应用的访问策略中可选地定义"直接 IP 和子网"。

错误：安全和直接 IP 和子网异常

我们仅建议为绝对必须以这种方式访问资源的用户和应用配置基于 IP 的访问。如果您确实配置了它们，您定义的子网应尽可能狭隘地确定范围（例如 10.0.1.0/29 与 10.0.0.0/16）。

这是因为通过在这样的广泛级别建立路由，您实际上抵消了代理连接模型的许多安全优势，恢复到传统 VPN 的行为。这使您的组织容易受到由启用过度访问网络资源导致的影响传统 VPN 的相同类型攻击。

以这种方式配置一个或多个 IP 地址时，定义的 CIDR 子网将发布到分配给该策略的设备的路由表中。这意味着除了默认 fd53 IPv6 子网外，VPN 网络接口还将包含跨所有适用访问策略定义的所有 IPv4 子网。

保存定义了这些 IP 地址的访问策略后，这些更改最多可能需要 30 分钟才能传播到所有设备。启用和禁用 Jamf Connect ZTNA 将触发这些策略的立即更新。

现在，假设 10.0.1.22 被添加到相同的 App 访问策略，Jamf ZTNA 最终用户将能够通过 http://10.0.1.22 或 ping 10.0.1.22 连接。

值得注意的是，尽管连接不通过 DNS 代理，但连接到资源的能力仍然受到访问策略中定义的所有条件的约束。

使用 FQDN 但不支持 IPv6 的应用

有一些应用程序由于各种原因就是不喜欢 IPv6：

• 一些现代应用程序具有不兼容 IPv6 的复杂/自定义网络堆栈（例如 macOS 的 Docker）
• 不知道 IPv6 存在的遗留应用程序，无法利用 AAAA 响应，在没有 A 响应时失败。

对于这些应用程序，您能够配置访问策略以使用"兼容"路由而不是"优化"。这样做会导致以下结果：

• 受访问策略约束的端点将被推送 Jamf Cloud 唯一 IPv4 子网，其运行方式与连接代理的 IPv6 范围相同
  • 这相同的范围用于以这种方式配置的一个或多个访问策略。
  • 此新路由发布到所有设备最多可能需要 10 分钟，或者 VPN 可能被重启以立即触发更新。
• 受访问策略约束的端点将在 VPN 网络接口上分配 IPv4 地址。
• 当接收到与访问策略设置为"兼容"模式的访问策略相匹配的 DNS 请求时，AAAA 响应将为空，但将使用 IPv4 云流映射而不是选择"优化"时使用的 IPv6 返回 A 响应。
• IPv6 不兼容/遗留应用将使用 A 记录响应中返回的 IPv4 地址，并建立到该地址的套接字，该地址将通过 Jamf ZTNA VPN 接口路由，感谢发布的 IPv4 路由。

结果是几乎相同的用户体验作为优化路由，减去在网络堆栈上使用 IPv6 与 IPv4 的一些细微效率。

动态分割隧道

对于所有不与访问策略相匹配的连接——无论是通过代理 DNS 连接还是直接 IP——A/AAAA/HTTPS DNS 响应完全按照上游 DNS 解析器返回的方式返回。换句话说，结果将等同于尝试连接到应用程序，就好像 Jamf ZTNA 在设备上被禁用一样。

在这种情况下，不会为这些请求创建云流映射，也不会执行日志记录（例外是如果您也配置了 Jamf 的内容过滤和/或 Web 威胁保护，其中请求可能会根据互联网或安全策略被记录或阻止）。

这导致"动态"分割隧道行为，因为与使用静态 CIDR 范围构建的传统分割隧道不同，由隧道封装（或不封装）的流量可能会实时改变。这是通过上述代理连接方法实现的，其中返回云流映射或使用公共 DNS 响应，完全基于活跃配置和设备的瞬时上下文。

本地网络

好消息！除非您添加了与用户本地网络子网重叠的直接 IP/子网，否则设备的大多数本地网络连接都能正常工作！这对于打印机等本地设备很重要，但对于许多用户期望在家庭网络上时能够无缝使用其智能家居或娱乐导向应用程序的移动设备来说尤其重要。

大多数本地网络没有权威 DNS 区域，因此设备依赖 mDNS 来发现和连接到其他本地设备。当在 VPN 网络接口上设置 Jamf ZTNA DNS 服务器时，mDNS 不受影响，使此行为正常工作。

通配符/准 ZTNA 访问策略

虽然 ZTNA 的安全承诺很吸引人，但从开放式传统 VPN 部署转移到粒度、应用级 ZTNA 环境将需要一些时间。大多数组织无法期望在没有大量前期测试和/或最终用户痛苦的情况下切换到基于 ZTNA 的 VPN（如 Jamf 的）是不现实的。

因此，Jamf Connect ZTNA 已适应此现实，使其能够以多个重要的方式功能得像传统 VPN。

FQDN 通配符

最粒度和最佳案例安全配置是为您拥有的尽可能多的访问策略配置尽可能多的应用，并为每个应用配置特定的 FQDN 和主机名。例如，对于应用程序 App，您可能有 app.acmeinc.com 和 images.app.acmeinc.com。

但是，仅仅发现所有这些主机名，更不用说在访问策略中配置它们，就可能需要大量时间。

因此，特别是如果您正在试用或刚开始使用 Jamf Connect ZTNA，我们建议创建一个名称像"Acme Inc 通配符默认值"的访问策略，并配置像 *.acmeinc.com 的主机名