ZIAのZ-Tunnel 1.0とZ-Tunnel 2.0の違い

Zscaler Client ConnectorがZIAへトラフィックを転送する仕組みには、Z-Tunnel 1.0とZ-Tunnel 2.0の2種類があります。どちらもフォワーディングプロファイル（ネットワークタイプごとのアクション）で選択でき、テスト用と本番用で2つのフォワーディングプロファイルを使い分けて共存させることも可能です。

本記事ではアーキテクチャの詳細・バイパス設定・移行時の落とし穴、そして特に認証がいつ・どのように行われるかまで踏み込んで整理します。

ZIAとは

Z-Tunnelの話に入る前に、前提となるZIA（Zscaler Internet Access）について簡単に整理します。

ZIAは、Zscalerがクラウド上で提供する**Secure Web Gateway（SWG）/ Security Service Edge（SSE）**のサービスで、Zscalerの「Zero Trust Exchange」を構成する製品の一つです。従来のように自社データセンターにプロキシやファイアウォールのアプライアンスを構築するのではなく、世界150カ所以上に分散配置されたZscalerのデータセンター（Service Edge）へユーザーの通信を転送し、そこでインターネット・SaaS向けの通信をまとめて検査・制御します。

主な機能は次のとおりです。

プロキシとしてのトラフィック処理: HTTP/HTTPSを中心としたインターネット向け通信をプロキシとして中継し、TLS/SSLの復号・検査を行う
セキュリティ機能: ファイアウォール、アンチウイルス／アンチマルウェア、サンドボックス、脅威防御などをService Edge側でまとめて提供
URLフィルタリング・ポリシー制御: ユーザーやグループ単位のアクセス許可・禁止ポリシーを適用
データ保護（DLP）: 機密情報の外部送信を検知・防止するインライン検査
可視化・ログ: ユーザー・端末単位の通信ログを一元的に収集

ポイントは、ユーザーの通信をいかにして最寄りのZIA Service Edgeまで届けるかという「トラフィックフォワーディング」の設計が必要になることです。代表的な転送方法にはPACファイルによる明示的プロキシ設定、拠点からのGRE/IPSecトンネル、そしてエンドポイントにインストールするZscaler Client Connectorがあります。このうちClient Connectorがトラフィックを転送するために使うのが、本記事のテーマであるZ-Tunnel（1.0 / 2.0）です。

なお、ZIAはインターネット・SaaSへのアウトバウンド通信を扱う製品で、社内の業務アプリケーションへのプライベートアクセスを扱う**ZPA（Zscaler Private Access）**とは役割が異なります。Client Connectorは同じエージェントでZIA・ZPA両方のトラフィックを扱えますが、本記事はZIA向けのZ-Tunnelに絞って解説します。

代表的なトラフィックフォワーディング方式を図にすると以下のようになります。

flowchart LR
    User["エンドポイント／拠点"]
    PAC["① PACファイル<br/>(明示的プロキシ設定)"]
    GRE["② GRE／IPSecトンネル<br/>(拠点ルーター経由)"]
    ZCC["③ Zscaler Client Connector<br/>(Z-Tunnel 1.0 / 2.0)"]
    SE["ZIA Service Edge"]
    Net["インターネット／SaaS"]

    User --> PAC --> SE
    User --> GRE --> SE
    User --> ZCC --> SE
    SE --> Net

このうち③のClient Connectorがトラフィックを転送する際に選べるのがZ-Tunnel 1.0とZ-Tunnel 2.0です。

Z-Tunnelとは

Z-TunnelはZscaler Client Connectorがエンドポイント上のトラフィックを最寄りのZIA Public Service Edgeへ転送するために使うトンネルです。ZIA契約時のユーザートラフィックに加えて、ZDX契約時の診断トラフィックもこのトンネルを通ります。トンネルバージョンの選択は、フォワーディングプロファイルの「On-Trusted Network」「VPN-Trusted Network」「Off-Trusted Network」の各アクションごとに設定します。

Z-Tunnel 1.0のアーキテクチャ

実態はプロキシベースの軽量HTTPトンネルで、従来型プロキシと同様にCONNECTリクエストでトラフィックを転送する
Client ConnectorがWebプロキシとして動作するため、転送できるのは基本的にプロキシ対応トラフィック、またはTCPの80/443番ポートのみ（フォワーディングプロファイルの設定次第）
UDP・非Web系TCP・ICMP・非標準ポートのトラフィックは転送されない。ローカルのファイアウォールポリシー次第で直接通信になるかブロックされるかが決まる
1.0でもPacket Filterドライバの有効化が前提条件になっている点は誤解されやすい。「1.0はユーザー空間のプロキシだけでドライバ不要」ではなく、カーネルレイヤーでのトラフィック捕捉はドライバが担い、CONNECTベースのプロキシ処理はその上位で行われる
CONNECT形式であるため、HTTPプロキシを前提とした既存の企業ネットワーク機器（プロキシアプライアンスなど）と親和性が高い

flowchart LR
    App["アプリ／ブラウザ<br/>(Web宛のTCP 80/443のみ)"] -->|CONNECTリクエスト| ZCC1["Client Connector<br/>(Webプロキシとして動作)"]
    ZCC1 --> SE1["ZIA Service Edge"]
    SE1 --> Net1["インターネット"]

    Other["UDP／非標準ポート／ICMP等"] -.->|転送されない| Direct["直接通信 or<br/>ローカルFWでブロック"]

Z-Tunnel 2.0のアーキテクチャ

DTLSまたはTLSを使ったパケットレベルのトンネルで、暗号化チャネルの中に全ポート・全プロトコル（UDP、非標準ポートTCP、ICMPなど）を収容できる
DTLS: UDP/443、TLS: TCP/443。「Primary Transport Selection」でどちらを優先するか選べ、フォールバックも設定可能
- なお、ヘルプ記事本文はDTLSとTLSを同列に説明しているだけで「DTLSが既定で優先される」とは明言していません。フォワーディングプロファイルアクションのallowTLSFallbackというフィールド名から間接的にDTLS優先が推測されますが、これは推測であり公式に明記された挙動ではない点に注意してください
重要な前提条件: NATデバイスは同一端末からの全接続に対して単一のIPを使う必要があります。複数のNAT IPを経由すると、Z-Tunnel 2.0の制御コネクションとデータコネクションが異なるService Edgeに着地してしまい、トンネル確立に失敗してZ-Tunnel 1.0へ自動的かつサイレントにフォールバックします。「2.0を有効にしたはずなのに端末が1.0のまま」という問い合わせの大半はこれが原因です
Client Connector 2.1.2以降ではインナーIPパケットのMTU値（800〜1400）を調整可能。Path MTU Discoveryで自動検出させることもできる
GREトンネルとの併用は非推奨: Z-Tunnel 2.0のDTLS/TLSトラフィックをさらにGREでカプセル化すると、MTU超過やフラグメンテーションでパフォーマンスが劣化する。対策は「オンLANユーザーはTrusted Network条件でZ-Tunnel 1.0にフォールバックさせる」か「上流ルーターでZ-Tunnel 2.0トラフィックをGREから除外するポリシーベースルーティングを組む」のいずれか
モバイル（iOS/Android）でZ-Tunnel 2.0を全トラフィックに適用すると、プッシュ通知（APNs/FCM）が届かなくなることがある。APNs（17.0.0.0/8、TCP 443/5223）とFCM（fcm.googleapis.com等、TCP 443）を宛先除外に追加する必要がある

NATが単一IPになっていない場合にサイレントフォールバックが起きる流れは以下のとおりです。

flowchart TD
    App2["アプリ<br/>(全ポート／全プロトコル)"] --> ZCC2["Client Connector<br/>(Packet Filterドライバ)"]
    ZCC2 --> NAT{"NATは単一IPか？"}
    NAT -->|Yes| Tunnel["DTLS(UDP/443) または<br/>TLS(TCP/443)で確立"]
    NAT -->|No: 複数IPで<br/>分散| Fail["制御コネクションと<br/>データコネクションが<br/>別々のService Edgeに着地"]
    Tunnel --> SE2["ZIA Service Edge<br/>(Z-Tunnel 2.0)"]
    Fail --> Fallback["Z-Tunnel 2.0確立失敗<br/>→ 1.0へ自動かつサイレントに<br/>フォールバック"]
    Fallback --> SE1b["ZIA Service Edge<br/>(Z-Tunnel 1.0)"]

バイパス設定はPACファイルではない

Z-Tunnel 1.0はPACファイル内のバイパス記述がそのまま有効ですが、Z-Tunnel 2.0はPACファイルのネットワークバイパスを見ません。1.0からの移行時にPACのバイパス設定をそのままコピーしても2.0には反映されず、「社内システムへの通信が2.0移行後にZIA経由になって壊れた」という典型的な事故につながります。

Z-Tunnel 2.0のバイパスは優先度順に以下の4種類があります。

優先度	種類	設定場所	備考
1（最優先）	VPN Gateway Bypasses	App ProfileのHostname/IP Bypass	カーネルレベルでZCCの処理自体をスキップ。FQDN指定時は評価のたびにDNS解決が走る
2	Destination Exclusions / Inclusions	App Profile	サブネット単位。より詳細なネットマスクが優先、同じネットマスクならフィールド数（ポート・プロトコル）が多い方が優先、同じ詳細度ならInclusionが優先
3	ポート指定バイパス	Destination Exclusionsにポートを付与（例: `192.168.1.0/24:80`）	WindowsとmacOSのみ対応。Linux/iOS/Androidは非対応
4（最低）	ドメインベース（PAC）	フォワーディングプロファイルPAC＋アプリプロファイルPAC	CDN配下のSaaSなどIPで表現できない宛先向け。ZCC 3.8以降は`Redirect Web Traffic to ZCC Listening Proxy`と`Use Z-Tunnel 2.0 for Proxied Web Traffic`の2つのフラグの組み合わせで挙動が変わる

認証はいつ・どう行われるか

ここが今回いちばん調べたかったポイントです。結論から言うと、Z-Tunnel 1.0と2.0の間で「認証のタイミング」自体が異なるという公式記載はありません。理由は、認証の主体がトンネルではなくClient Connectorアプリそのものだからです。

ZIAの「認証頻度」設定はClient Connectorには適用されない

ZIAにはDaily / Only Once / Once Per Session / Customという認証頻度の設定があり、Cookieを使ってユーザーの認証状態を管理します（Gatewayクッキーでログイン状態を保持し、ブラウザで訪問したドメインごとにDomainクッキーを発行、12時間ごとにローテーションする仕組みです）。

しかし公式ドキュメントには明記されています。

These options don’t apply to users with Zscaler Client Connector. （これらのオプションはZscaler Client Connectorを使うユーザーには適用されません）

Private Access (ZPA) and Zscaler Client Connector do not use cookies for authentication. （Private Access (ZPA) とZscaler Client Connectorは認証にCookieを使いません）

つまり、この「認証頻度」やCookieローテーションの話はPACファイルのみで転送している端末やGRE/IPSecトンネル経由の拠点など、Client Connectorを使わないユーザーに対するものであり、Z-Tunnel 1.0・2.0のどちらを使っていてもClient Connector経由であれば対象外です。この場合の認証の流れは次のようになります。

sequenceDiagram
    participant B as ブラウザ(PAC/GREのみ、ZCCなし)
    participant SE as ZIA Service Edge
    participant IdP as 社内IdP(SAML)

    Note over B,IdP: Client Connectorを使わない場合の認証(Cookieベース)
    B->>SE: HTTPリクエスト(未認証)
    SE-->>B: IdPへリダイレクト
    B->>IdP: SAMLログイン
    IdP-->>B: SAMLアサーション
    SE-->>B: Gatewayクッキー発行
    SE-->>B: 訪問先ドメインごとにDomainクッキー発行(12時間ごとにローテーション)
    Note right of SE: 以降は「認証頻度」設定(Only Once等)に<br/>従いクッキーで認証状態を維持

Client Connectorはアプリレベルでサイレント認証する

Client ConnectorはHTTPのCookieではなく、アプリ自体がSAML IdP（またはZscaler Client Connector PortalをIdPとして使う場合はデバイストークン）に対して認証します。SAML SSO環境では、アプリが端末からユーザーIDなどのパラメータを収集してSAMLリクエストとしてZscalerクラウドへ送り、Admin Console側で検証・プロビジョニングした上でユーザーとデバイスをサイレント認証する、という流れです。

sequenceDiagram
    participant CC as Client Connectorアプリ
    participant IdP as 社内IdP(SAML)
    participant SE as ZIA Service Edge

    Note over CC,SE: Client Connectorを使う場合の認証(Z-Tunnel 1.0/2.0共通・Cookie不使用)
    CC->>IdP: SAML認証リクエスト(デバイストークン等を含む)
    IdP-->>CC: 認証結果
    CC->>SE: 認証済みセッションでトンネル確立<br/>(Z-Tunnel 1.0 または 2.0)
    Note right of SE: 以降の通信はCookieではなく<br/>トンネル(セッション)単位で識別

この認証はZ-Tunnel 1.0・2.0どちらの場合でも共通で、トンネルが確立される前提としてClient Connectorアプリのログイン・認証が完了している必要があるという位置付けです。トンネルのバージョン（プロキシ型かパケット型か）は転送方式の違いであって、認証の主体・タイミングを変えるものではありません。

実務上の違いとして考えられる点（公式に明言はされていません）

以下は上記の一次情報から導かれる合理的な推測であり、公式ドキュメントがトンネルバージョンの違いとして明言しているわけではない点に注意してください。

Z-Tunnel 1.0はHTTPプロキシとして動作するため、Webトラフィックであれば従来型プロキシ同様に407 Proxy Authentication RequiredやKerberos/NTLMのnegotiateヘッダをHTTPリクエスト単位でやり取りする余地があります
Z-Tunnel 2.0はIPパケットレベルのトンネルであり、UDPやICMPなど非HTTPトラフィックも流れるため、個々のリクエスト単位でのプロキシ認証という概念はそもそも当てはまりません。識別はトンネル（＝Client Connectorアプリの認証セッション）単位で行われます

比較表

項目	Z-Tunnel 1.0	Z-Tunnel 2.0
転送方式	HTTP CONNECTベースのプロキシ	DTLS / TLS パケットトンネル
対応トラフィック	プロキシ対応トラフィック、または80/443のみ	全ポート・全プロトコル
ドライバ要件	Packet Filterドライバ	Packet Filterドライバ
NAT要件	制約なし	単一IPでのNATが必須（複数IPだと1.0へフォールバック）
GREとの併用	問題なし	非推奨（MTU超過・パフォーマンス劣化）
バイパス設定場所	アプリプロファイルPAC	VPN Gateway Bypasses / Destination Exclusions・Inclusions / ポート指定 / ドメインPAC
Business Continuity Cloud	対応	非対応（BC Cloud接続時は1.0のみ）
フォールバック	フォールバック先そのもの	確立失敗時に1.0へ自動フォールバック
認証の主体	Client Connectorアプリ（SAML/デバイストークン）	Client Connectorアプリ（SAML/デバイストークン、1.0と同じ）

なぜZ-Tunnel 2.0が推奨されるのか

ZscalerはZ-Tunnel 2.0をできる限り全トラフィックに使うことを推奨しています。1.0はHTTPプロキシの仕組みに依存するためWeb以外のプロトコルを扱えませんが、2.0は暗号化トンネルの中に全ポート・全プロトコルを収容できるためです。ただし、単一IPでのNATが前提条件になっている点、GREとの併用は非推奨である点、モバイルではプッシュ通知向けの宛先除外が必要な点など、移行時に見落としがちな制約があるため、フェーズを分けた段階的な移行（テストグループ作成 → ICMPブロックテスト → 社内ネットワーク除外 → 1〜2週間の観察 → 100〜200人単位でのバッチ展開）が推奨されています。

まとめ

Z-Tunnel 1.0はHTTPプロキシ、2.0はDTLS/TLSのパケットトンネルという根本的にアーキテクチャが異なる
2.0はNATの単一IP要件を満たさないとサイレントに1.0へフォールバックするため、「2.0にしたつもりが実は1.0のまま」という事故が起きやすい
バイパス設定の仕組みがまったく別物なので、移行時にPACをそのままコピーしても効果がない
認証はトンネルバージョンに関係なくClient Connectorアプリ単位で行われ、Cookieベースの認証頻度設定は対象外というのが、今回調べて分かった一番の要点