指南

目標客群和目的

本文件適用於具有網路和 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 位址。預設情況下沒有 IPv4 位址或路由被分配給 VPN 網路介面！
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. 應用要求 OS 將該主機名解析為 IP 位址以連接。啟用 Jamf Connect ZTNA 後，使用的 DNS 名稱伺服器是 fddd:dddd::，這是一個綁定到 Jamf Connect ZTNA 策略引擎的虛擬 IPv6 位址。
3. OS 對 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 轉換，導致目的地 IP 為原始 IPv4 位址（10.0.1.22）的封包。
    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 連接於 TCP/mTLS 型通道內時常見的傳輸協議「故障」。

資訊：SDP、VPN 和端到端應用加密

Jamf Connect ZTNA 經過設計旨在使用現代封包封裝和加密技術提供快速和動態的軟體定義網路功能，使您能夠輕鬆地通過網路介面的幾次點擊將流量和策略應用到幾乎任何目標。

但就像任何加密傳輸中流量的 VPN 技術一樣，Jamf 不可能提供從用戶端應用到伺服器應用的真正端到端加密。

因此，對於任何包含任何級別敏感資料的應用，您必須始終配置此類應用使用應用程式級加密技術，如 HTTPS 或 TLS。這現在是所有應用程式的標準做法。這是確保未授權中介無法在 Jamf 或客戶網路中任何時點獲得存取的唯一方法。

此連接仲介技術已被證實在 Jamf ZTNA 平台上以企業級效能和規模運作。所有現代作業系統原生支持 IPv6（即使設備只有 IPv4 網路連接），絕大多數應用和使用者支持 IPv6 並對所有連接使用 DNS。

除了那些不支持的……其中您需要為那些異常值進行特殊配置以通過 Connect ZTNA 工作。

可用性和容錯轉移

Jamf ZTNA 的架構考慮了網路分區和設備無法連接到 Jamf 安全雲端的情況。它使用各種重疊的方法實現此目的：

死網關檢測

Jamf Trust 可以檢測危險或不穩定的連接，這些連接通常是由不安全的強制網路門戶引起的。這些強制網路門戶可能攔截流量，造成連接問題。

透過死網關檢測（DGD），Jamf Trust 應用可以提供關於最終使用者設備上其連接當前狀態的通知。DGD 使用一般連接檢查（例如強制網路門戶和網路連接檢查），同時使用零信任網路存取（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 vs 10.0.0.0/16）。

這是因為透過在如此寬泛的級別建立路由，您實際上是在否定仲介連接模型的許多安全好處，恢復到傳統 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（例如 Docker for macOS）
• 舊版應用不知道 IPv6 存在，無法利用 AAAA 回應，在沒有 A 回應時故障。

對於這些應用，您能夠配置存取策略使用「相容」路由而不是「最佳化」。這樣做將導致以下情況：

• 受存取策略限制的端點將被推送 Jamf 雲端獨特 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 的內容過濾和/或網路威脅防護，請求可能會根據網際網路或安全策略被記錄或阻止）。

這導致「動態」分割通道行為，因為與使用靜態 CIDR 範圍建立的傳統分割通道不同，通道封裝的流量（或不封裝）可能會實時變更。這得益於上文所述的仲介連接方法，其中基於活動配置和設備的即時背景完全返回雲端流映射或使用公共 DNS 回應。

本地網路

好消息！除非您添加了與使用者本地網路子網重疊的直接 IP/子網，否則設備的大多數本地網路連接都很好！這對於本地設備（如印表機）很重要，特別是對於行動設備，許多使用者希望在其家庭網路上時能夠無縫使用其智慧家庭或娛樂導向應用。

大多數本地網路沒有授權 DNS 區域，因此設備改為依賴 mDNS 來發現和連接到其他本地設備。mDNS 在 VPN 網路介面上設定 Jamf ZTNA DNS 伺服器時不受影響，使此行為能夠正常運作。

萬用字元/不完全 ZTNA 存取策略

雖然 ZTNA 的安全承諾很吸引人，從寬開放的傳統 VPN 部署轉移到細粒度、應用程式級 ZTNA 環境將需要一些時間。對大多數組織來說，期望無需進行大量預先測試和/或最終使用者痛苦就能轉換到基於 ZTNA 的 VPN（如 Jamf）是不切實際的。

因此，Jamf Connect ZTNA 已適應此現實，使其能夠在多個重要方面像傳統 VPN 一樣運作。

FQDN 萬用字元

最細粒度和最佳安全配置是配置與您擁有的應用一樣多的存取策略，具有針對每個策略使用的特定 FQDN 和主機名。例如，對於應用 App，您可能